C&DH System

COMMAND AND DATA HANDLINGC&DH CDS

MTM 3/13/03

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

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

– 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

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.

C&DH System