Date post: | 24-Dec-2015 |
Category: |
Documents |
Upload: | collin-green |
View: | 220 times |
Download: | 3 times |
C&DH System
Mid-Term Project Reviews
Sunday 16 Mar 5 pm-6 pm Group 1Monday 17 Mar 10 am-11 am Group 2Tuesday 18 Mar 3 pm -4 pm Group 4Friday 21 Mar 3 pm-4 pm Group 3
C&DH System
C&DH
Central brain and nervous system for the spacecraft. Main spacecraft computer; can be the control system
processor. Provides for the receipt, authentication and transfer of
commands. Master Clock: time for all spacecraft functions. Collects, routes and stores engineering and science
data Provides the control function for power management.
C&DH System
Allocating Requirements
Define computer system operational modes/states Functionally partition / allocate the computational requirements to:
– Ground – Space
Subsystem– Hardware or Software
Analyze Data Flow Select and Set the Baseline Architecture Form the Baseline System
C&DH System
General Overview
CDS receives and processes commands sent from Earth
– High Level Discretes (commands): Latch Relay– Serial Digital Commands: realtime or stored
Collects and packages information from all of the science instruments and engineering subsystems for downlink.
– CCSDS Packets Stores Data. Broadcasts timing to subsystems Fault Protection Functional Partitioning of Systems
C&DH System
Command Uplink
The hardware portion of the S/C uplink system is responsible for:
1. Detection of an uplink carrier signal >from a ground station 2. Extraction of uplinked data from the sub-carrier 3. Verification the data has the correct S/C identification 4. Rejection of data that has been corrupted during transmission 5. Transmission of valid data from the receivers to the S/C computer 6. Reporting command frames, to the flight software telemetry system,
that have failed due to corruption
000011110000
C&DH System
Command Standardization
Commands transmitted in a group Code Blocks – Individual Commands Command Link Transmission Units (CLTU)
– Start sequence – Code blocks – Parity bits
CCSDS Compatibility
C&DH System
KnockKnock MailmanMailman BagBag LetterLetter EnvelopeEnvelope Have a nice day
Have a nice dayMagMag
Sync Code
Sync Code
S/C ID
S/C ID PP
CommandLabel
CommandLabel InstInst PP
MemAdd
MemAdd ValueValue
Command Packets Bill – Due DateTelegram – UrgentLetter – No TimeLocation for everything
High Level – 28v relayLow Level – 5v logicSerial Digital - 01001010
C&DH System
Error Correction
CCSDS Compatibility (Consultive Committee on Space Data Systems) Data Packets Error Detection and Correction
– Bit Error Rate (BER)– (n,k) Block Codes – data taken in blocks of k bits, parity bits
added, n symbols produced BCH Codes (Bose-Chadhuri-Hocquehem) Parity bit checking Reed Solomon (255, 223) takes in 223 data bits, produces 255
data symbols (k bits in =1.143 n symbols out). Parity checking Hamming codes – special positions for parity bits in data block
– Convolutional codes – more advanced than block codes– Concatenation – use of two codes
C&DH System
Software Uplink
The software uplink system is responsible for: 1. Rapidly moving valid uplinked data from the receivers to buffers in
memory before that data is over written with new data. 2. Extracting S/C data >from data used to route commands from the
ground to the S/C 3. Decoding S/C data into meaningful commands words 4. Verification the command words have the correct format 5. Reporting of invalid commands to the flight software telemetry system 6. Moving decoded and verified uplinked commands to computer
command queues also stored in memory.
C&DH System
Onboard Command Execution
Once commands have been received, validated, decoded, and placed on the command queues, the flight software will attempt to translate those commands into a physical operation.
The requirements of the onboard command execution system are: 1. Periodically check all command queues for new commands 2. Further decode the commands to determine the precise operation 3. Further validate the commands to ensure that the commands will not place the
S/C into a hazardous state 4. Report to flight software telemetry system if a command was rejected because it
could not be decoded or it was hazardous
C&DH System
Onboard Command Execution
5. Determine the time the command is scheduled to execute 6. Move commands that are not immediately scheduled to execute to a
stored command queue in memory 7. Translate commands that are scheduled to execute immediately to an
actual operation in the flight software, or into a signal that will be transmitted from the flight computer to a S/C subsystem
8. Log the times and the commands that execute, and pass that log to the
telemetry flight software
C&DH System
COMPUTER
Command Sequencer (Washing Machine) Central vs. Distributed
– Data control: memory, able to handle data (engineering and payload), adequate speed
– ADCS: matrix manipulation, very high speed Computer Anatomy
– CPU – the brain– ALU (in cpu) Arithmetic Logic Unit – fixed or floating– Instruction set: machine language commands– Bus: parallel connection between computer elements– Memory RAM, ROM, EEPROM, FLASH– Clock
Why so old?
C&DH System
Computer Throughput
100 wpm (600 characters/min)
28=256 8 bit words (byte)
600 x 8 = 4800 bits/min (4800/60=80bps)
To Display: 10 computer instructions (CI) / char + 100 CI / word 600(10) + 100(100) = 1600 instructions / min 266.7 instructions/secEach Instruction Requires: 5 clock cycles to bring data from memory 1 clock cycle to execute 1600(6)=96000 cycles/min = 1600 cycles/sec (1.6Khz clock)Storage: [80 bps +266.7inst.(8bits)] x 3600 sec/hr x 24 hrs = 6.2 Gbits
C&DH System
Control of S/C subsystems
When the S/C is not in contact with the ground, the C&DH system is responsible for maintaining the S/C state of health by continuously monitoring all sub-systems.
Hardware tasks for maintaining S/C state of health: 1. Commanding non-essential sub-systems off upon detection of a
possible S/C under voltage 2. Charging and discharging of batteries 3. Resetting the flight computer upon detection of a flight software lock up
C&DH System
Control of S/C subsystems
4. Resetting the flight electronics in response to massive current spikes due the interaction between energetic particles and semi-conductors
5. Detection and correction of memory cells corrupted by single event upsets(SEUs)
6. Reporting SEUs to the flight software 7. Reporting temperatures, currents, voltages, limb crossings,
and other physical measurements to the flight software.
C&DH System
Control of S/C subsystems
8. Warning the flight software, well in advance, of an under voltage that can potentially shut down the computer
9. Resetting the flight electronics in a sequence that ensures that all the electronics is operational before the flight software attempts to issue commands to the S/C
10. Maintain a very accurate clock that can be used to time tag data from instruments, and synchronize the flight software
11. Report limb crossings from the HCIs to instruments
C&DH System
Maintaining Spacecraft Health
1. Take physical measurements from the flight hardware monitors and log them in mass memory storage
2. Maintain counters on hazardous sub-systems. Energy hungry devices like the transmitter and the torque rods needs to be turned off is accidentally left on.
3. Ensure that instruments are operating nominally 4. Re-command instruments that fail to produce science data 5. Maintain S/C attitude via closed and open loop attitude control
algorithms 6. Execute stored commands.
C&DH System
Maintaining Spacecraft Health
7. Detect and handle software exceptions. An exception is a software anomaly that can potentially cause the flight software system to fail.
8. Re-initialize the software in response to severe memory corruption due to multiple SEUs
9. Take science data from instrument hardware buffers and move the data to mass storage memory before the data is over written.
10. Calculate spin period from limb crossings, and pass that information to the instruments
11. Synchronize the execution times of all software modules (very important)
C&DH System
Hardware Telemetry
Engineering and instrument data is continuously being generated. It is the flight software’s responsibility to package and store that data.
Hardware telemetry tasks:
1. Signal the flight computer when the instruments have new data 2. Report the state of all electronics and relays to the computer 3. Report the data from all S/C monitors to the computer
C&DH System
Software Telemetry Tasks
1. Read data from the hardware monitors and instruments and store in software buffers
2. Take data from the software telemetry buffers and wrap them into packets
3. Time tag the packets 4. Move telemetry packets from the flight computer to mass
storage memory 5. Prevent the mass storage memory from being overwhelmed
with too much data
C&DH System
Software Downlink
Software downlink tasks: 1. Turn the transmitter on via stored or realtime command 2. Send a unique bit pattern to the transmitter. This bit pattern
identifies the S/C that is transmitting the data. 3. Move telemetry packets from mass storage memory into the
computer 4. Wrap the telemetry packets into transfer frames
C&DH System
Software Downlink
5. Calculate cyclic redundancy checks (CRCs) on the telemetry packets, and append the CRCs onto the frames.
6. Move the transfer frames to hardware downlink buffers
7. Synchronize the rate at which frames are moved to the downlink buffers
8. If no data is available to move to the downlink buffers then send idle frames to the downlink buffer
C&DH System
Hardware Downlink
Hardware downlink tasks: 1. Establish a downlink carrier signal at a specified frequency 2. Move the transfer frames from the hardware downlink queues
to the transmitter 3. Transmit the transfer frames on the sub-carrier 4 . Signal the flight computer when the queues are empty.
C&DH System
Fault Protection and Safing
System must have the intelligence and autonomy to monitor and control itself to some degree throughout its useful life at a great distance from Earth.
Though ground teams also monitor and control the spacecraft, light time physically prohibits the ability to respond immediately to anomalies on the spacecraft.
Tightly constrained tracking schedules also limit the ability to detect problems and respond.
C&DH System
Fault Protection
Fault protection (FP) algorithms must ensure the ability to mitigate the impact of a mishap, and to re-establish the spacecraft's ability to contact Earth if an anomaly has caused an interruption in communications.
A spacecraft may have many different FP algorithms running simultaneously with the ability to request C&DH system to take action.
C&DH System
Safing
Safing involves shutting down or reconfiguring components to prevent damage either from within or from the external environment.
Automated, methodical search to re-establish Earth-pointing and regain communications.
Safing may temporarily disrupt ongoing science observations and require the flight team to perform additional work,
Safing provides strong and reliable protection for the spacecraft and its mission.
C&DH System
Fault Protection and Safing
Usually a minimal set of safing-like instructions is also installed in ROM (it was contained in 1 kbyte on Magellan) where it can hide from even the worst imaginable scenarios of runaway program execution or power outage.
More intricate safing routines (also called "contingency modes") and FP routines typically reside in CDS RAM, as well as parameters for use by the ROM code, where they can be updated as necessary during the life of the mission.
C&DH System
Command Loss Timer - CLT
One example of a fault-protection routine is the Command-Loss Timer, CLT.
This is a software timer running in C&DH that is reset to a predetermined value, for example a week, every time the spacecraft receives a command from Earth.
If the timer decrements all the way to zero, the assumption is that the spacecraft has experienced a failure in its receiver or other components in the command string.
The CLT fault protection response issues commands for actions such as swapping to redundant hardware in an attempt to re-establish the ability to receive commands.