AUC CubeSatCommand and Data Handling Subsystem

Fady M. Morcos

1. System Definition:

The Command and Data Handling subsystem (C&DH) is responsible for running the

spacecraft in an ordered and ‘intelligent’ manner according to its flight program. It is the brain of

the satellite platform.

The C&DH is responsible for the overall management of the spacecraft's activities. The

system has two main functions: reception and execution of commands from the ground station,

and gathering payload and housekeeping data (HK data), to be transmitted to the ground station.

Moreover, the C&DH subsystem provides the main bus for the data exchange between all other

subsystems. The system manages three data streams, each critical to the spacecraft, and each

with distinctive characteristics. Those are:

• mission/scientific data from the payload

• housekeeping (HK) data from spacecraft subsystems

• commands from ground station

The C&DH has to be capable to store those data streams for two main reasons. The first is

that payload and HK data can only be transmitted when there is a communication link with a

ground station, which occurs once every several orbits, depending on spacecraft's orbit.

Furthermore some commands from ground have to be processed at later times, making it

necessary to store those commands, and execute them according to their time tags.

2. Functional Requirements:

The system receives commands from the communications subsystem, performs validation

and decoding of the commands, and distributes the commands to the appropriate spacecraft

subsystems and components. The C&DH also receives housekeeping data and science data from

the other spacecraft subsystems and components, and packages the data for storage or

transmission to the ground via the communication subsystem. The system must also provide

analog-to-digital conversion capabilities for any subsystem components generating analog

signals (e.g. temperature sensor), before being stored or sent to spacecraft bus. Figure 1

illustrates the command and data paths within the satellite, and between the satellite and the

ground station.

Other functions of the C&DH include maintaining the spacecraft clock, state-of-health

monitoring, and managing high-level fault protection and safing routines. In a centralized

architecture, the C&DH system is also responsible for the execution of attitude determination

and control algorithms, as well as power system management algorithms. In a distributed

architecture, however, each of the Attitude (ADCS), Power (EPS), and Communication (COMM)

subsystems has its own PIC controller dedicated to performing the respective subsystem's tasks.

C&DH Functional Requirements

Provide an operating system that controls the spacecraft

Assure and control the data exchange among spacecraft subsystems

Process Received Tele-Commands

Acquire Payload & Housekeeping Data

Provide storage for data and commands

ProvideA/D conversion capabilities

C&DHCommunication

Subsystem

Payload

SpacecraftSubsystems

GroundStation

Command

Science

HK Data

COMM-ANDS

SCIENCE & HOUSEKEEPINGDATA

Command

Command

HK Data

Science Data

Fig.1: C&DH System Operations

Maintain spacecraft clock

State-of-health monitoring

Manage fault protection and safing routines

Centralized Architecture:

Execute ADCS routines – (Sensor Data Acquisition, Attitude Determination, Attitude Control)

Execute EPS routines – (Power Management, Power Distribution)

Execute COMM routines – (Validation, Telemetry Stream Generation, Data Up/Downlink, Mod/Demodulation, En/Decapsulation, … etc)

3. Design Analysis:

The development of the C&DH subsystem requires both hardware and software solutions to

successfully perform all the above mentioned functional requirements.

3.1 Hardware

The hardware is composed of three main constituents:

OnBoard Computer (OBC)

◦ Controls the spacecraft operations in normal mode. It handles the exchange of data

between the payload, subsystems, memory and communication. It is responsible for the

decoding, encoding, and memory storage of commands, payload, and HK data. The

OBC is also responsible for managing fault protection and safing routines. Refer to

table. 1 for a full list of OBC functions.

System Bus

◦ Subsystems communicate with each other via the system bus. The bus assures the data

flow between the different spacecraft subsystems and components. The I2C bus by

Philips is the most commonly used onboard Cubesats. This two-wire bus has a data

wire, and a clock wire to synchronize transfers. Every component connected to the bus

has its own address, like a phone number, and can send/receive data or commands by

following a predefined protocol.

Table.1: C&DH Functional Requirements

External Memory

◦ Flash Memory provides space for payload data, HK data, and commands received from

ground/control station. Flash offers a great advantage over RAM in that it does not

loose stored data even when powered off. Flash memory is also used for storing flight

software and boot loader, as well as flight software updates from the ground station,

which is unachievable using PROM. However, Flash Memory is more prone to

radiation than PROM; thus it is recommended to also use PROM to store the original

boot loader and flight software. If space radiation corrupts the updated version of the

flight software on the Flash memory, the OBC can reset and use the original boot loader

stored on PROM to assure successful operation of the spacecraft.

All the above components will be mounted on a single PCB. The board also holds the

connectors for the payload and other subsystem boards. The PCB and components have to

comply with the size, mass and power constraints of the Cubesat. When choosing components

for the PCB, the rough space environment must also be taken in consideration, particularly

temperature and radiation. Space-tested, Commercially available Off The Shelf (COTS)

components are easily acquired through numerous vendors. Several recommendations from

veteran Cubesat builders are available, and documented in several online resources.

3.2 Software

The flight software is the core element of the C&DH subsystem. It brings the devices ‘to

life’ and utilizes their features. The program code has to accommodate the various mission

modes of the spacecraft, including boot mode, nominal mode and power save mode. During

boot, the micro-control-unit (MCU) of the OBC initializes the other devices and goes into a pre-

defined state. When all devices are initialized, the satellite is said to be in nominal mode, in

which the C&DH interacts with the payload, and all the spacecraft subsystems, namely ADCS,

EPS, and COMM. When in power save mode, the C&DH is turned off. No code will be executed

at this time. As soon as the Electrical Power System (EPS) switches from power save into normal

mode again, the boot procedure is passed through again.

The choice between a real-time operating system (RTOS), or a designated kernel to handle

satellite operations must be made. An RTOS, like VxWorks, enables the programmer to write

code on a highly abstractive level, which does not take into account the final hardware selection,

but rather concentrates on the functions to be carried out. The other way is to write designated

kernels dedicated to the chosen hardware configuration. In this case, the code is usually

furnished much better to the hardware on the lowest level, and the hardware resources can be

fully utilized. Also the code size will remain relatively small compared to an RTOS (however,

the programmer will have to write more lines of code since all low level routines have to be

written as well).1

The software does not only include the operational system of the C&DH, but it is a part of

all other subsystem as well. As mentioned above, in centralized architecture, the OBC will

manage and execute the different subsystem routines, while in distributed architecture, those

routines are executed via the PIC controller on the respective subsystem board. Table 2 below

lists the standard functions required of the different spacecraft modules.

System Software Function

C&DH Command VerificationCommand DistributionData CollectionData FormattingData EncodingData & Command StorageFlight Plan SchedulingFlight Plan Execution

Fault Protection Redundancy ManagementAnomaly Response (e.g. latchups)Error Detection & Correction

Operating System Executive TaskDevice DriversRun-time Kernel

ADCS Sensor Data ProcessingAttitude DeterminationAttitude Control

Power Battery Charge Control Power Management & DistributionOBC Watchdog

1 Scholz, Artur, Design and Development of a CDHS for a Pico Satellite, Aachen University of Applied Sciences

Table 2: Software Functions

4. The Design and Development Process *

Starting with requirement allocation and functional analysis, the design process will result in

a solution architecture, including both hardware and software. The output will describe the

system physically, and in terms of software on the lowest assembly levels, interfaces and

relationships between external and internal components. The subsequent development activities

then cover the production of the system. Figure 2 illustrates the entire subsystem life cycle.

4.1 Requirement Allocation

The first design step is the subsystem requirement allocation. The overall system is divided

into smaller functional blocks, with specific requirements. Although AUC Cubesat might be

composed of the same set of subsystems that another satellite has, the specific requirements of

the particular functional blocks might differ significantly according to the spacecraft mission

objectives. Generally, the requirements can be established by answering the question “What must

the subsystem achieve?”. For example, “C&DH needs to dispatch commands from the ground

station to the different spacecraft subsystems”

4.2 Functional Analysis

The next step is to translate the requirements defined in the previous step into functions.

This is done by finding the answer to the question “How can this requirement be achieved?”. In

other words, functional analysis provide proposed solutions to the questions asked in the

requirement allocation step. The team performs functional analysis to breakdown high-level

functions into lower-level function blocks, and to map low-level functions to physical or

executive components, thereby ensuring that each function has an acknowledged owner. This

also ensures that all necessary tasks and components are listed and that no unnecessary tasks or

components are requested. Building on the example stated above, “Besides the obvious need of

an MCU, the C&DH requires a system through which the different subsystems can communicate

with each other. The C&DH also requires a storage unit to store command, until ready for

transmission. Additionally, the C&DH system will be required to perform command verification

to ensure that it is a legitimate command, schedule the command for execution according to its

time tag, and prepare the data package to be channeled to the intended subsystem.”

* This section is highly influenced by the design process of the German CubeSat, Compass I.

Fig.2: C&DH Design & Development Life Cycle

Subsystem RequirementsAllocation

Functional Analysis

Functions Allocated to Hardware

Functions Allocated to Software

Hardware Definition Software Definition

Circuit Design

PCB Layout & Fabrication

PCB Assembly & Testing

Flow Charts of Modules

Programmingof Modules

Debugging

System Assembly, Integration & Testing

Operation

Disposal

4.3 Function Allocation

Once the system functions are well defined, they are partitioned and allocated to either

hardware components or software solutions. Many times, both hardware and software must be

used to implement a given function. By nature, software tends to be a more flexible solution, as

the designer can make changes, amendments, and updates even at late stages of the project, or

even after launch. Hardware, on the other hand, is very expensive to amend once manufactured.

However, in space, software is more susceptible to malfunctions, due to radiation, than hardware.

It is the decision of the design team how to allocate functions to maximize flexibility, while

minimizing malfunction threats. Building on our example, “To perform the previously stated

example requirement (see section 4.1), the C&DH will need to utilize both hardware and

software solutions. The required hardware components are: an MCU to perform all the data

management and manipulation, a bus system to connect the different subsystems together, and a

memory device to store the command until it is time for dispatching. On the software side, the

C&DH has to first verify that the uplinked command is legitimate, package and prepare the

command to be channeled through the system bus (according to system bus protocol), schedule

the command in the flight plan, store the command in the designated memory location, and

finally initiate and complete the command transfer process.”

4.4 Hardware and Software Definition

Following function allocation, hardware components are selected using trade studies, taking

into account cost, reliability, heritage, availability, … etc. Equivalently, the software structure

needs to be defined. Top-level flowcharts are also developed at this stage, serving as stepping

stones to the subsequent stages. Based on our example, “A specific MCU must be selected, the

bus system also needs to be chosen (e.g. I2C bus), a trade analysis between RAM and Flash

Memory as a candidate to store commands is performed, and a specific memory chip is selected.

The software architecture and interface between the different software modules are designed.

Flowcharts for the Command Verification, Storage, Scheduling and Distribution are also

created.” Figure 3 below depicts the process from Requirement Allocation to HW & SW

Definition.

4.5 Hardware Design & Development

After functions are properly allocated, and the hardware has been defined, the hardware design

and development process starts. This is one of the major tasks of the C&DH team. Figure 4

breaks down those tasks in details.

4.5.1 Circuit Design

The circuit design is the most time-consuming part of the hardware design process. The first

step is to determine how the different devices or components will work together. Then the signal

flow is determined, covering both internal interface and external interface signals (signals

Fig. 3: C&DH Design Process Example

between C&DH and other subsystems). Issues like data structure, physical connection, content

and compatibility must be taken into consideration. The result of the circuit design process

should be a set of schematics showing the logical interconnections between components within

the C&DH subsystem, along with the main bus and other subsystem connections.

4.5.2 PCB Layout

The circuitry created in the previous step needs to be translated into physical tracks. The

process also takes into account any constraints that might be affecting the design, including

mechanical constraints like board size and mounting methods, or points of attachments. Part

placement is also one of the most critical layout activities. The part placement process should try

to minimize radiation threats and extreme temperature variations, for example by placing high

heat emitting components next to low heat emitting components. The process is then followed by

routing, which is the process of laying down tracks to connect components on the PCB.

4.5.3 PCB Fabrication

Once the PCB design is completed, and the design is verified, the layouts can then be sent to

the fabrication or production. Once the board is fabricated, the components can be soldered in

place. The PCB is then inspected and tested for any points of failure.

4.6 Software Design and Development

There are two design approaches that are well established among software engineers,

structured programming and top/down design. Both are mutually important and only the

Circuit Design

PCB Layout

PCB Fabrication

Fig. 4: Hardware Design & Development Process

simultaneous use of both strategies can form an efficient synergy. Structured programming

brings more transparency into the code, which is highly appreciated by other developers wanting

to familiarize themselves with the existing code. It also facilitates later changes and

modifications that might be required to be uplinked to the satellite from the ground station. The

top/down design approach, on the other hand, focuses on the bigger picture first, then elaborates

the subsequent levels into finer details during the design activity.

The application layer covers the high level main application code. The low-level drivers

layer, on the other hand, allows higher-level computer programs to interact with hardware

devices onboard. Obviously, these driver routines are hardware specific, and can only be written

after the specific hardware has been selected. The device interface layer, residing between the

application layer and the low-level drivers, acts as logical representation of the hardware. It is

responsible for translating the functions of the application layer into device-specific functions.

5. Software Architecture

Recall, the C&DH is required to interface with all the hardware and software solutions

onboard on the satellite. Since the Cubesat project is divided among several developer groups, a

highly modular design is desirable. Interfaces between modules need to be clearly defined to

allow different parts of the software to communicate efficiently with each other. As mentioned

before, the I2C bus by Philips is selected for the system bus. The physical domain of the

spacecraft subsystems is shown in figure 6. As shown, the I2C serial bus connects all the

spacecraft subsystems with each other. A master (in this case the MCU of the OBC) is the device

Application Layer

Device Interface Layer

Low Level Drivers Layer

Fig. 5: Software Top-Down Design

that initiates a data transfer on the bus and generates the clock signals to permit transfers. The

addressed device is considered a slave. An I2C protocol needs to be designed on top of the I2C

bus. The complete protocol should include: Start Communication, Address, R/W, Acknowledge

Bit, Header, Error Check (e.g. CRC Checksum), Data or Command, Stop Communication.

Header include the length of data packages, and the specific module contacted in the slave.

5.1 Software Elements

5.1.1 Boot Loader

A few moments after orbit insertion, the satellite is powered-up, marking the beginning of its

mission in space. This is one of the most critical moments in the mission's lifetime. At this

moment, the C&DH runs the boat loader, which configures the OBC, locates and initializes all

the different spacecraft subsystems and peripheral devices, and finally loads and starts the

spacecraft's OS or designated kernels. This process is repeated every time the OBC is restarted,

Fig. 6: Cubesat Physical Domain

as the spacecraft comes out of power save mode, or as a result of a latch-up. If an error occurs

during the boot sequence, the OBC should be designed to automatically reboot using a redundant

software version, thus making the Boot sequence more reliable.

On every start, the OBC should check if there is software updates in Flash memory, or not.

If there is, the boot sequence is executed using the Flash version, if not, the original version is

loaded from PROM. When booting from Flash, a check needs to be done to make sure data is not

corrupted. A watchdog timer should also be implemented during the start-up process. If the OBC

finishes the boot-up sequence, it resets the timer, indicating that the boot sequence was

successful. If the watchdog timer times out, it means that there is a problem in the boot sequence,

and that the current boot-up had failed. In this case, the power unit should turn off the OBC and

restart it. The new boot sequence should then be carried out from a different boot sequence

version. This prevents the the boot loader to enter a “boot loop”, which lets the OBC

continuously boot from a broken operating program.

5.1.2 Hardware Support

5.1.2.1 Hardware Abstraction Layer

A Hardware Abstraction Layer (HAL) is a low-level software that supplies a simple

interface to access hardware features, giving programs direct access to hardware resources. This

will allow application software developers on the Cubesat to write device-independent

applications by providing standard OS calls to hardware. With hardware abstraction, the

programer can write a code that tells the operating system what a given device should do, and the

operating system gives the proper instructions. This means that programmers do not need to

know how the individual devices work, and their program code will be compatible with any

device.

5.1.2.2 Device Drivers

The C&DH should provide the driver software that is used for accessing hardware

components. These create the interface between the OBC hardware, and the C&DH software. A

device driver is a piece of code that allows the operating system or user application to set up,

access and utilize a specific hardware or peripheral device. Drivers are very useful since they

allow an application to access the features of the OBC without any low-level knowledge, such as

registers, protocols and timings. Figure 7 below shows the progression of the different software

layers in the C&DH system.

As shown above, the software driver's interaction with the hardware platform is done

through the Hardware Abstraction Layer. This isolates the driver's implementation from the

hardware platform variations. A driver implementation typically interacts with the hardware

peripheral it is controlling through sequences of register reads and register writes. The

implementation of the HAL translates the read and write requests into the bus transactions

relevant to the hardware platform. This enables programmers to seamlessly reuse code even

when the hardware platform changes.2

5.1.3 Error Detection/Error Correction

The harsh radiation environment of space takes its own toll on the spacecraft. Radiation

particles from solar or galactic origins bombard the spacecraft, posing threats to the onboard

electronics. Because of the short orbital lifetime of cubesats, the total ionizing dose effects are

negligible and can be ignored. However, there is another major source of concern, namely, Single

Event Phenomena (SEP). In this phenomenon, a single particle can penetrate the surface of the

2 Acal Technology, www.acaltechnology.com

Fig. 7: C&DH Supporting Software Layers

spacecraft, targeting electronic components, causing malfunctions. The three major effects of

SEP, in the order of probability of occurrence are:

• Single Event Upsets: This is a logic reversal process, where the radiation particle strikes the hardware component, flipping a single bit from 1 to 0, or vice versa. This can result in numerous side effects, such as erroneous calculations, command and data corruption, erratic software execution, and operation setting changes. Several approaches can be utilized to detect and correct these types of error. Possible solutions include including redundant memory devices, using majority-voting logic, employing hamming codes, and employing checksum algorithms.

• Single Event Latch-up: A latch-up event results in an abnormally high current-flow through a device. This current-flow can be several orders of magnitude larger than the device’s typical operating range, thus it generates an enormous amount of internal heat. Power-cycling the device (turning off the device, then back on) is the only feasible remedy for clearing a latch-up condition. If not promptly performed, permanent damage to the device can result from the excessive heat. The C&DH design must be able to detect high current-flow through each board and cycle power accordingly. Using current monitors, each board within the spacecraft monitors its current-flow. If the current-flow into a board rises above a predetermined reference level, the current monitor signals the OBC via the I2C bus. The OBC determines the board that needs to be reset and provides a reset signal to the EPS, which in turn cycles the power to the board/device. Since the OBC is equally susceptible to latch-ups, the EPS must employ a watchdog timer to monitor the OBC's power, and subsequently cycles power to the entire satellite.3

• Single Event Burnout: This causes a permanent failure to the device. This is very uncommon, and can only be minimized by the proper shielding and hardening techniques. (No software algorithms or subsystem commands can fix it, or avoid it).

5.1.3 System Architecture Modules

As mentioned before, the software architecture is expected to be highly modular, which

means that each module is responsible for performing a specific function on board of the

3 Jensen, J.,C. M. Swenson, Command and Data Handling Subsystem Design for the Ionospheric Observation Nanosatellite Formation (ION-F)

spacecraft. For example, the attitude determination and control algorithms are grouped in one

module, let's call it the ADCS Module. Similarly, the power management and distribution

routines are grouped in another module, EPS Module. Figure 8 presents the spacecraft software

architecture, depicting the different modules onboard the satellite, and the different threads

forming each module.

To facilitate the interface between the different software modules, the C&DH hosts a Flight

Manager (FLT_MNGR) program that controls all the tasks of the spacecraft. FLT_MNGR plays

a central role in data distribution. All spacecraft application modules interface with each other

through the FLT_MNGR. This simplifies the communication paths between the different

modules, and makes the module integration process much more robust.

For instance, the main functions of the C&DH are based on a flight plan, which is a time

scheduler that specifies the execution of tasks or commands onboard of the satellite. Commands

Fig. 8: Spacecraft Software Architecture

are usually transmitted to the satellite via the ground station. Once received, the COMM module

performs command validation, demodulation, and decapsulation of data packets. They are then

forwarded to the FLT_MNGR, which in turn channels the commands to the Flight Plan (FLP)

module. FLP module then schedules the tasks for execution, and saves them in the designated

location on flash memory. Note that drivers for all the different devices will need to be integrated

in the architecture to assure proper interaction with all system devices. Figure 9 shows an

exploded view of the driver architecture onboard of the spacecraft.

6. Integration & Verification

According to several Cubesat team developers, most of the problems occur where the

software meet the hardware. The integration and verification of the C&DH has four main levels:

• Software Level (Application Level)• Subsystem Level (C&DH Level)• System Integration Level (Subsystem Interface Level)• System Level (Spacecraft System Level)

Fig. 9: Application, Driver & Hardware Level Exploded View

The levels and their location in the flow are illustrated in figure 10.4 Note that every time

software is changed, the integration and verification loop has to return to the beginning of the

test flow.

There is a tendency among programmers to use their own programming style, and not to

stick to a specified project format. This practice translates into undesirable redundancies,

inefficient executions, and a hectic interface and integration process. Following a unified coding

format can save the team tremendous time and effort throughout the project lifetime. Keeping up

to date documentation of the design process, design decisions, flowcharts, and detailed system

architecture is also critical to the success of the C&DH team.

Remember, no individual decisions can be taken on this project. One small decision can

have a domino effect on the whole system. Close interaction among team members, as well as

between other subsystem teams will eliminate critical problems on subsystem level, and system

integration level, respectively. Structured meetings will be scheduled to allow all project team

members to interface with each other, and discuss any pending design decisions or

recommendations.

4 Vaartjes, B., R. J. Hamann, R. Amini, Integration and Verification of a Command and Data Handling Subsystem for Nano-Satellite Projects with Critical Time Constraints: Delfi-C3.

Fig. 10: C&DH Integration & Verification Flow