1. C&DH System COMMAND AND DATA HANDLING C&DH CDS MTM 3/13/03

2. C&DH System Mid-Term Project Reviews Sunday 16 Mar 5 pm-6 pm Group 1 Monday 17 Mar 10 am-11 am Group 2 Tuesday 18 Mar 3 pm -4 pm Group 4 Friday 21 Mar 3 pm-4 pm Group 3

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.

4. 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

5. C&DH System

9. SNOE C&DH System

10. C&DH System CASSINI CDS MAIN COMPUTER

11. 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

12. 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 0 0 0 0 1 1 1 1 0 0 0 0

13. 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

14. C&DH System Knock Mailman Bag Letter Envelope Have a nice day Have a nice day Mag Sync Code Sync Code S/C ID S/C ID P P Command Label Command Label Inst P P Mem Add Mem Add Value Command Packets Bill – Due Date Telegram – Urgent Letter – No Time Location for everything High Level – 28v relay Low Level – 5v logic Serial Digital - 01001010

15. 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

16. 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.

17. 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

18. 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

19. 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?

20. C&DH System Computer Throughput 100 wpm (600 characters/min) 2 8 =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/sec Each 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

21. 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

22. 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.

23. 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

24. 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.

25. 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)

26. 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

27. 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

28. 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

29. 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

30. 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.

31. 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.

32. 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.

33. C&DH System

34. 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.

35. 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.

36. 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.

37. C&DH System