COMMAND AND DATA HANDLING
C&DH CDS
MTM 3/13/03
C&DH System
Mid-Term Project Reviews
Sunday
 Monday
 Tuesday
 Friday

16 Mar 5 pm-6 pm Group 1
17 Mar 10 am-11 am Group 2
18 Mar 3 pm -4 pm Group 4
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
C&DH System
C&DH System
C&DH System
C&DH System
SNOE C&DH System
C&DH System
CASSINI CDS MAIN COMPUTER
C&DH System
General Overview

CDS receives and processes commands sent from Earth
–
–

Collects and packages information from all of the science
instruments and engineering subsystems for downlink.
–



High Level Discretes (commands): Latch Relay
Serial Digital Commands: realtime or stored
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
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
Command Packets
Bill – Due Date
Telegram – Urgent
Letter – No Time
Location for everything
Knock Mailman Bag Letter Envelope Mag
Sync
Code
S/C
ID
P
Command
Label
Mem
Add
High Level – 28v relay
Low Level – 5v logic
Serial Digital - 01001010
C&DH System
Value
Have a
nice day
Inst
P
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/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
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 semiconductors
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
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 Earthpointing 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 reestablish the ability to receive commands.
C&DH System
C&DH System