AUC CubeSat Command 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. Command Payload Spacecraft Subsystems Science Data Command HK Data C&DH Command Science HK Data Communication Subsystem

SCIENCE & HOUSEKEEPIN G DATA

COMMANDS

Ground Station
Fig.1: C&DH System Operations

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

 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)
Table.1: C&DH Functional Requirements

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 I 2C 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.

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 predefined 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
C&DH

Software Function
Command Verification Command Distribution Data Collection Data Formatting Data Encoding Data & Command Storage Flight Plan Scheduling Flight Plan Execution Redundancy Management Anomaly Response (e.g. latchups) Error Detection & Correction Executive Task Device Drivers Run-time Kernel Sensor Data Processing Attitude Determination Attitude Control Battery Charge Control Power Management & Distribution OBC Watchdog
Table 2: Software Functions

Fault Protection

Operating System

ADCS

Power

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

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.

Subsystem Requirements Allocation

Functional Analysis

Functions Allocated to Hardware

Functions Allocated to Software

Hardware Definition

Software Definition

Circuit Design

Flow Charts of Modules

PCB Layout & Fabrication

Programming of Modules

PCB Assembly & Testing

Debugging

System Assembly, Integration & Testing

Operation

Disposal

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

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. I 2C 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.

Fig. 3: C&DH Design Process Example

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

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.
Circuit Design

PCB Layout

PCB Fabrication
Fig. 4: Hardware Design & Development Process

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

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.

Application Layer

Device Interface Layer

Low Level Drivers Layer

Fig. 5: Software Top-Down Design

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 I 2C serial bus connects all the spacecraft subsystems with each other. A master (in this case the MCU of the OBC) is the device

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.

Fig. 6: Cubesat Physical Domain

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,

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.

Fig. 7: C&DH Supporting Software Layers

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

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 majorityvoting 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 devices 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.

Fig. 8: Spacecraft Software Architecture

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

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.

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

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 Subsystem Level System Integration Level System Level (Application Level) (C&DH Level) (Subsystem Interface Level) (Spacecraft System Level)

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.

Fig. 10: C&DH Integration & Verification 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.