Last month we covered the electrical architecture of the Command Module. This month we will take a look at the software. The software of the Command Module is responsible for running and executing tasks onboard the CubeSat, therefore it has to be robust and reliable in its execution to minimize any potential failures and it has to be extremely efficient as well.
The Command Module runs with two classes of software, each on its own processor:
– Flight Software, running on the real-time processing unit (RPU)
– Mission Software, running on the application processing unit (APU)
An easy way to tell them apart is that the flight software is a simple but thoroughly tested machine that is fast and hard to fool, therefore very robust. The mission software is more like a person onboard the spacecraft that can reason through complex situations and act on behalf of the operators on Earth. Both are built for a different purpose and handle different tasks.
Some decisions are simple enough to be handled by a single IF statement. For example, if a device draws more current than a predefined threshold, the flight software disables it immediately. Other decisions need reasoning. If you turn on the camera and the ADCS (Attitude determination and control system) starts reading strange magnetometer values, that is not a simple threshold check. The mission software flags the anomaly and tries to resolve it. If it cannot, it logs the event and notifies operators on Earth.
The divide in tasks is straightforward. Fast, deterministic actions belong to the flight software, while more complex reasoning belongs to the mission software.
Command Module Software Hierarchy
Mission Planning: The South Atlantic Anomaly
A good example is the South Atlantic Anomaly, a region with higher radiation exposure compared to most other spots in orbit.
The mission software tracks the spacecraft’s position and detects that it is approaching the anomaly region. Then, it:
1) Calculates the timing: about 15 minutes to enter, 20 minutes inside, and another 15 minutes to clear it.
2) Sends power-off commands to as much equipment as possible to reduce the effects of radiation.
3) Tells the RPU to wake the APU back up in 50 minutes.
4) Shuts itself down.
The flight software keeps a simple internal timer running through the event. When the timer expires, it wakes the mission software, which brings the rest of the platform back online and runs predetermined tests to confirm the equipment is safe. Any issues are logged and reported to Earth on the next communication pass.
The same approach works when operators send up a warning about aurora activity (hazardous to satellite operation), along with its estimated location and duration. The flight software can turn equipment on and off, but it cannot track the spacecraft’s position, project it forward, and identify a hazardous path. That is the mission software’s job.
Mission Software
The mission software runs on the more capable APU and handles mission execution rather than system safety. It decides what the spacecraft does: planning activities, scheduling communication passes over ground stations, managing payload operations, and running data processing and algorithms. It can also coordinate with external systems, such as other CubeSats in the same orbit, for data transfer or joint observations.
This is the higher-level layer. It plans ahead and runs multi-step operations over longer time scales, from hours to days. Without it, every command would have to come from Earth. With it, the spacecraft can make data-informed decisions on its own.
Configuring and Supervising the Programmable Logic
The mission software also configures, commands, and supervises the Programmable Logic (PL), also called the FPGA (Field-Programmable Gate Array). This includes loading the FPGA bitstream during startup (for example via FSBL (First Stage Bootloader), U-Boot (Universal Bootloader), or the operating system), configuring PL IP cores over AXI-Lite interfaces, controlling processing pipelines, and managing high-level data movement such as DMA transfers, buffers, and descriptors. It also monitors PL status and performance. Essentially it is responsible for every part of the Programmable Logic system, from booting it to controlling and handling it during uptime.
This fits the mission software because it runs on embedded Linux, which provides driver support, memory management, and abstractions suited to this kind of configuration and control. Where needed, the flight software can still place the PL into a safe state, such as a reset or power isolation, to protect the overall system.
The flight and mission software layers are kept separate because they have different requirements and different purposes. The flight software has to be simple, fast, and reliable so it can guarantee safety. The mission software has to be flexible enough to plan and run complex operations. Combining both into one program could compromise both, if an error were to occur on one subsystem. By giving each its own processor and role, the flight software keeps the spacecraft safe while the mission software runs the mission.
This has been a high-level overview of the Command Module software, and there is a lot more to say about each layer. In the coming month we will look at them one at a time and introduce what they do in depth. Stay tuned!
Big thank you to the Command Module software team for their work and input!
Leave a Reply