On-board computer and data handling (OBC/CDH)

Definition

The on-board computer (OBC) and its command and data handling (C&DH) functions form the nervous system of a spacecraft. They validate and execute telecommands from the ground, collect and frame telemetry from the subsystems, store payload data, keep time and manage the operating modes[1]. In small satellites most of these functions run on one microcontroller on one board. Heavy computation such as image processing moves to a separate payload computer, an FPGA or, increasingly, a system-on-chip (SoC)[2].

Architecture

In a centralized architecture one OBC drives every subsystem directly. In a distributed one each subsystem has its own microcontroller, and the OBC talks to them over a data bus, which makes it easier to isolate a fault. I²C, SPI, UART or RS-485 and CAN are the common on-board buses of small satellites; larger systems use high-speed serial networks such as SpaceWire[2]. The PQ9 interface proposed for PocketQubes standardizes an RS-485 bus with a few unregulated power lines[3].

flowchart TB
  subgraph OBC["Flight computer"]
    direction LR
    WDT["Independent watchdog"] --> MCU["MCU and RTOS"]
    MCU --- MEM["FRAM and Flash"]
  end
  OBC <-->|"I²C, CAN"| EPS["EPS"]
  OBC <-->|"UART"| TRX["Transceiver"]
  OBC <-->|"I²C, SPI"| ADCS["ADCS"]
  OBC <-->|"SPI"| PL["Payload"]

Operating modes

One of the most important decisions of the flight software is which mode the spacecraft is in. After separation it waits out the launch-provider timer, deploys its antennas and starts a beacon. It drops into safe mode when the battery voltage falls, after a watchdog reset or when no ground contact has been made for a long time: payloads switch off, and only the beacon, telecommand reception and, if needed, detumbling keep running.

stateDiagram-v2
  state "Start-up" as Boot
  state "Safe mode" as Safe
  state "Nominal" as Nominal
  state "Payload operations" as Payload
  [*] --> Boot : separation
  Boot --> Safe : deployments done
  Safe --> Nominal : ground command, battery sufficient
  Nominal --> Payload : scheduled task
  Payload --> Nominal : task complete
  Nominal --> Safe : low battery or reset
  Payload --> Safe : fault

Processors

Low-power 1P and 1U designs favour the FRAM-based MSP430 and the Arm Cortex-M4 STM32 families. Radiation-tolerant Cortex-M7 parts such as the SAMV71Q21RT keep the software ecosystem of commercial microcontrollers while improving single-event robustness. FPGAs with Arm cores, such as the Zynq-7000, serve image compression and software-defined radio processing.

Memory

Flash offers density but limited and slow writes; MRAM endures eight orders of magnitude more write cycles[2]. Frequently written configuration and counters therefore live in FRAM or MRAM, bulk payload data in Flash.

Flight software

The industry has largely converged on real-time operating systems and lightweight Linux distributions. NASA’s cFS was designed for homogeneous single-node avionics and is not the best fit for very constrained computing; F Prime fixes most of the architecture at compile time and can be extended to distributed systems with extra effort[2]. F Prime also ran the flight software of the Ingenuity Mars helicopter.

Telemetry design

Telemetry is the only window into the spacecraft, so its content deserves as much design as any subsystem. Grizu-263A, a 1P, packed 31 fields into each frame (identification and time, one temperature, 14 currents and voltages from seven INA-type monitors, and nine IMU channels) and sent five frames every 10 s[4]. Its formats were published without encryption, and a decoder written in Kaitai Struct[5] was added to the SatNOGS database, so every station in the network decoded the frames automatically[6]. Published formats turn a worldwide amateur network into an extension of the mission’s own ground segment.

Command and frame formats

Missions in amateur bands mostly carry frames in AX.25, which any ground-station network can decode. Agency and commercial missions use the CCSDS packet and frame standards. In both cases telecommand authentication belongs in the design from the start, so that an unauthorized transmitter cannot command the spacecraft; amateur-band missions still need a reliable transmitter shut-down command, which coordination requires.

Radiation

Electronics in orbit face two kinds of radiation effects. The total ionizing dose (TID) accumulates over the mission and is measured in krad. Single-event effects (SEE) happen when one particle deposits enough charge: an upset (SEU) flips a bit without damage, whereas a latch-up (SEL) can burn the part unless the current is limited[2]. In LEO, single events increase markedly over the South Atlantic Anomaly, where the trapped-proton flux is concentrated.

Manufacturers of commercial OBCs declare TID tolerances of roughly 10 to 300 krad(Si)[2]. These figures depend on the component test conditions; the dose a mission needs must be computed separately from orbit, duration and shielding. The space environment entry gives the context.

Fault tolerance

Common measures in small satellites are independent watchdog timers, selective power cycling and software fault isolation, to which ECC memory, regular scrubbing and redundancy can be added. Every measure that increases reliability and fault tolerance costs complexity[2]. Even simple cross-checks help: on Grizu-263A, a loss of communication between the radio and the computer made the radio send an error code straight to the EPS, so the fault could be handled without the computer[4]. Critical timers deserve a hardware path independent of the main processor; the radiation-induced reset of KickSat-1’s master clock shifted its whole mission timeline (see ChipSat).

Power

The reference 1P power budget allows 15 mW on average for the flight computer, which means the processor spends most of its time asleep. Wake-up time, interrupt latency and the ability to switch peripherals off one by one matter as much as clock speed when choosing a part.

Software updates

Updating software in orbit needs dual images, integrity checks and automatic fallback, so that a faulty image cannot lose the spacecraft. Frameworks such as cFS support software updates after the spacecraft is in orbit[2].