The Command and Data Handling (CDH) system is often referred to as the “brain” of a spacecraft. This article outlines the functions of a CDH system and explains how they are critical to mission operations and data output.
It also discusses the reliability requirements of a CDH system and explores the solutions offered by Alén Space, a paying participant in the satsearch membership program, with whom the article was developed.
A spacecraft on a mission is typically acting as a system designed to acquire data through different sensors to be sent back to the remote user who commands and operates the system. This simple explanation works as a baseline for any spacecraft, whether a satellite in Low Earth Orbit (LEO) or a rover on the surface of Mars.
The remote users are usually the mission operators on the ground who are sending commands and receiving payload data. Therefore, the complete data handling architecture for a mission includes both space and ground segments.
The processing, storage, and handling of the data are all core components of the data handling architecture and mission success. In particular, in the CubeSat industry telemetry and payload data must be handled with care due to the limited memory available and the higher risks typically associated with the mission and hardware form factor (due to, for example, a lack of redundancies, reduced radiation shielding, smaller downlink windows, shorter mission lifetimes, and so on).
Command and Data Handling (CDH) systems in spacecraft are responsible for acquiring, processing, storing, formatting, and downlinking such data to the respective ground segment assets, as well as receiving and executing the commands from the mission operators.
In the next section we discuss the data handling architecture, including the space and ground segment, from the point of view of the entire system.
The Command and Data Handling (CDH) architecture encompass the functions of many systems such as:
- The payload sub-system,
- The Telemetry and Telecommunications (TT&C) sub-system,
- On-board computers (OBCs),
- Data storage units,
- Communications interfaces,
- On-board software packages and processing tools, and
- Ground station tracking and communications systems.
The complexity and interdependency of these sub-systems, for handling data onboard spacecraft, can be illustrated in the Space AVionics Open Interface aRchitecture (SAVOIR) Avionics System Reference Architecture shown in the image below:
Source: Terraillon, J.-L. (2016). Savoir: Reusing specifications to favour product lines (source).
The sub-systems listed in 1-6 above are all present onboard the spacecraft and form the space segment of the data handling architecture, described further below.
The on-board CDH architecture connects all of the sub-systems of the satellite, handling all the internal communication using the satellite bus and all external communication with other satellites or ground stations via the appropriate comms systems (e.g. external antennas).
The system architecture must include the TT&C sub-system as a core of the CDH chain, ensuring that all the attitude, housekeeping, and payload (if applicable) data is processed and sent to the right location. Typically, the data handling is controlled by the Telemetry Tracking and Command (TT&C) system or the on-board computer (OBC), and the data storage is handled by different types of memory and locations, depending on the function or importance of the data.
The data can be stored between different sub-systems, so is not limited by the OBC or TT&C memory. The storage architecture can also include different types of memory of varying sizes and functionality, for example, the payload can have more memory than the OBC. The memory architecture should also be set up to avoid bottlenecks with the use of in-orbit processing and compression algorithms and buffers.
Use of standard protocols, such as the CCSDS Space Packet Protocol (CCSDS 133.0-B-2) or ECSS PUS (ECSS-E-ST-70-41C), has increased the interoperability of different sub-systems in recent years. Additionally, these packet telemetry standards have enough flexibility to change the transmission requirements depending on the mission needs. Alén Space, for instance, has developed a Command and Data Handling Solution (CDH) to bring these strengths to the CubeSat sector.
Another important aspect is the maintenance of the software and databases to keep them up-to-date with new commands, software fixes, or even new capabilities. It is critical to ensure safe reboots of the OBC and the persistence in memory of the new updates. Next, let’s turn to the corresponding ground segment CDH considerations.
Ground segment CDH
The ground is the starting point of most commands, as well as the destination of the telemetry and valuable payload data. The ground segment can be an all-in-one ground station or dispersed between a ground station, the control center, and the end customer, within multiple geographical locations and timezones.
The data received by the ground stations must be demodulated and often decompressed by the ground segment architecture. After compulsory validation, the ground segment team can start with telemetry analysis and the delivery of the payload data. Usually, all the telemetry is connected to the Mission Control Software (MCS) in the control center, in which the commands for the mission are generated.
Ground Station of Deimos Engineering and Systems provided by Alén Space.
The ground station of Deimos Engineering and Systems, provided by Alén Space, is an example of a ground segment commercial-off-the-shelf (COTS) solution available on the commercial market.
The overall success of a mission operation depends on how much quality data can be downloaded from the spacecraft back to Earth during the space asset’s lifetime. As the brain of the spacecraft, the CDH sub-system requires utmost reliability for handling such valuable data.
Operational reliability takes into account all the systems, including the ground stations, protocols, and operational procedures. All the sub-systems across the platform must communicate with each other effectively and during multiple operational modes, including ground testing.
This must guarantee that all the faults are controlled and protections are designed for the three major effects of the space environment; Single Event Upsets (SEUs), Total Ionizing Dose (TID) damage, and latch-ups.
The reliability of the data transportation is critically linked with the sub-systems’ own reliability and the redundancies that are in place to recover from critical events. Additionally, the housekeeping and Fault Detection, Isolation, and Recovery (FDIR) logics are necessary for recovering from small and unexpected events, depending on the philosophy of the FDIR system and the platform in general. The aim is to maintain the satellite in a safe, and operational, mode, while also ensuring adequate situational awareness for transmitting error logs to the operations team.
When needed, the satellite can recover from an error with incremental steps, until the nominal mode of operation is reached. The recovery actions can be autonomous or on command, depending on the severity of the faults. Likewise, the execution of the commands for the satellite can be sent time-tagged for scheduling or executed live, depending on the mission’s operational procedures.
In the CubeSat space, high-risk approaches have been common due to lower costs, nevertheless, expectations are changing towards flight-proven hardware with more testing and reliability of the critical subsystems. A reliable CDH sub-system is also of greater importance as we progress into launching more deep space missions. Unlike an LEO mission, which can accommodate calculated risks, deep space missions require highly reliable sub-systems which can withstand harsh environments.
In the following section, an example of a deep space mission is presented to give a better understanding of the significance of a reliable CDH system for a mission’s success.
Command and Data Handling (CDH) system for a deep space mission
With the recent release of a number of remarkable deep space images, the James Webb Space Telescope (JWST) has already made a significant impact worldwide. So let’s take a look at the sub-system responsible for handling those valuable data, in such a harsh environment, and prepare them for downlinking.
The Integrated Science Instrument Module (ISIM) is the main payload on the JWST and houses aloof the primary data-gathering instruments.
The ISIM Command and Data Handling subsystem (ICDH), is located in region 3 of the ISIM and is responsible for commanding, telemetry, routing, and processing functions for all of the scientific instruments and the Fine Guidance sensor.
The ICDH coordinates the ISIM and other activities of the spacecraft. It also performs the formatting of captured data for each exposure before transferring it to the Solid State Recorder (SSR) for downlink. The ICDH also regulates the rate at which data can be written to the SSR and is equipped with software to analyze the data in portions for the target.
The JWST SSR has a storage capacity of 65 Gb for science data to be sent to Earth. The downlink of this data, from JWST to the ground, is scheduled every 12 hours for a duration of 4 hours. Find out more in the official JWST user documentation. The ISIM is protected by a 5-layer sunshield from the Sun’s radiation and the electronics are kept in a thermally controlled environment.
Now that we have taken a little detour to the LaGrange point of the solar system, let us come back to the system requirements of a CDH subsystem for a satellite orbiting the Earth.
The satellite market is growing fast and there is a greater demand for space data than ever. With such large amounts of data being transferred back to Earth every minute from orbiting satellites, it is inevitable that the requirements for the system handling them onboard are becoming increasingly complex.
The following list of system-level requirements are a great start point for assessing commercial CDH subsystems for different mission objectives:
- Power consumption,
- Fault tolerance and redundancy against SEUs, TID damage, and latch-ups,
- Resistance to radiation, extreme thermal cycles, and vacuum,
- Real-time operating system support,
- Telemetry data storage,
- Compatibility with different interface types,
- Downlink schedules to one/multiple ground stations, such as the duration of the downlink, frequency, and the data transfer rate,
- Data format for downlink
- AI-based on-board data processing (OBDP) for preliminary target acquisition checks, and
- Overall communication bandwidth.
For low-cost satellites, radiation-hardened space-qualified electronics may not be an affordable option. Sometimes size constraints can also be an issue in choosing a redundancy design. In such cases, special attention should be paid to ensuring protection against SEUs and latch-ups.
To help better understand these detailed system requirements in design, development, integration, and testing, Alén Space offers an easy-to-integrate data handling COTS solution for the CubeSpace market.
Alén Space is a Spanish satellite bus and sub-system manufacturer with more than 12 years of experience in the development of nanosatellites. The company offers satellite platforms, ranging from 1-12U, CDH systems, a turnkey solution for managing the ground segment, and ready-to-fly payloads for applications including:
- Automatic Identification System (AIS)
- Automatic Dependent Surveillance–Broadcast (ADS-B)
- Signals intelligence (SIGINT)
- Internet of Things (IoT)
- Software-defined Radio (SDR)
- Earth Observation (EO)
The company also offers end-to-end nanosatellite services to support various mission purposes such as scientific research, technology demonstration, aviation (ADS-B and aircraft tracking), maritime (AIS, VHF Data Exchange System (VDES), and ship tracking), and surveillance (SIGINT and spectrum monitoring).
The Alén Space team has worked on several projects with leading space organizations and agencies such as the European Space Agency (ESA), NASA, United Nations Office for Outer Space Affairs (UNOOSA), the Brazilian Space Agency (AEB), and the Spanish National Aerospace Agency (INTA).
Some recent key projects undertaken by Alén Space are:
- Alfa Cruz, a 1U class CubeSat mission, launched in 2022.
- Development of a payload for the 3B5GSAT, a 3U CubeSat, launched in 2021. It is the first CubeSat of the nanosatellite constellation by Sateliote.
- Development of payload, and handling launch and later operations for the Lume-1, a 2U class nanosatellite launched in 2018.
- Development and manufacture of SERPENS, a 3U class nanosatellite launched in 2015.
Next let’s take a closer look at Alén Space’s CDH expertise.
Alén Space has developed an integrated data handling solution for their platform and sub-systems, designed to handle all communications needs, from ground to space. The aim of this integration is to shorten the time to market for satellite operators.
The company offers a full range of solutions including Mission Control Software (MCS), the easy to install ground station (GS-Kit), and TRISKEL; an integrated OBC, TT&C, and onboard software (OBSW). TOTEM, an SDR, is also offered by the company for enabling image processing and data transmission, compliant with Digital Video Broadcasting – Satellite – Second Generation (DVB-S2) standards, to the ground terminal.
Alén Space’s data handling chain solution for CubeSats.
By integrating the onboard computer and the TT&C in one module, Alén Space has increased the volume available in the CubeSat while maintaining the flexibility and FDIR of the sub-systems.
TRISKEL is an easy to integrate system, based on the European Cooperation for Space Standardization (ECSS) and ESA Packet Utilization Standards (PUS) standards. A Watchdog is included for detecting SEUs and both the OBC and TTC radio interfaces feature independent Cortex-M7 microcontrollers.
The OBC has a real-time clock, a flash program memory of 2 MB, data storage of 1 Gb (NAND), and an external RAM of 8 Mb (MRAM). The internal RAM is 640 kB with 2 MicroSD storage slots. A magnetometer, a gyroscope, temperature and current sensors, and optional internal GNSS module are also available as part of the OBC.
The TRISKEL TT&C sub-system uses Ultrahigh Frequency (UHF) bands and half-duplex communication links with GFSK modulation, with data rates up to 19.2 kbps.
The core functions of the OBSW include event reporting, housekeeping, real-time forward control, onboard telemetry storage, and memory management. Additional services include FDIR for software and hardware, autonomous payload monitoring, and data collection, among a number of others.
Detailed information about the product TRISKEL including block diagrams, general characteristics, absolute maximum ratings, and mechanical layout can be found in the datasheet available here.
Reliability and robustness are basic necessities for any Command and Data Handling system which, as has been discussed in the article, plays a critical role in any spacefaring system.
So select the brain of your satellite with care, considering the size, power, cost, and radiation constraints of your individual mission. Plan the required memory architecture based on the specified downlink schedules and make sure to have a margin planned for data storage and handling in case of a missed pass.
Ensuring that your Command and Data Handling system talks and responds to all other sub-systems in any given best and worst-case scenario is also mandatory for the success of your mission. Hopefully this article will arm you with useful information to help select the most suitable CDH option.
To find out more about Alén Space’s expertise and portfolio, please click here to view their satsearch supplier hub.