Avionics and onboard computing

Spacecraft avionics look obsolete by terrestrial standards and are not. The constraints are different, the failure consequences are different, and the resulting designs make sense only once radiation and unattended operation are taken into account.

The performance gap

The gap between a flight processor and a contemporary consumer part is roughly three orders of magnitude, and it is not closing. There are three reasons, and only one of them is radiation.

Radiation hardening costs performance directly. Hardened processes use larger feature sizes, silicon-on-insulator substrates and redundant transistor structures. All three trade speed and density for immunity.

The market is tiny. A flight processor sells in hundreds of units per year against hundreds of millions for a commercial part, so it cannot amortise a leading-edge process node. Unit prices in the hundreds of thousands of dollars follow from that, not from the silicon cost.

Qualification takes years. By the time a part is characterised, tested at a heavy-ion beam and flight-qualified, it is several generations behind. A mission that launches in 2030 selected its processor around 2024 from parts qualified years earlier.

The consequence is a growing split. Critical control functions run on hardened processors; high-throughput payload processing increasingly runs on commercial parts with fault tolerance built around them in architecture rather than silicon. See Edge computing in space.

Redundancy architectures

TMR masks a fault rather than detecting and recovering from it, which is why it is used inside a processor for register and logic protection rather than at box level, where three complete strings are rarely affordable.

Cross-strapping is the practice of allowing either processor string to drive either set of peripherals, so a failure in one unit does not force switching an entire chain. It substantially improves reliability and it substantially increases interface complexity, which is its own source of failures.

The critical limitation of all redundancy is common cause failure. Identical units fed identical inputs fail identically, and no amount of duplication helps. Ariane 5 flight 501 is the canonical demonstration: both inertial reference systems ran the same software, encountered the same unhandled conversion overflow at the same instant, and both failed. Redundancy protects against random hardware failure and does nothing against a design fault. See Fault tolerance and reliability.

Data buses

MIL-STD-1553 remains in use for command and control not despite its 1 Mbit/s rate but because of its determinism. Every transaction is initiated by a single bus controller on a fixed schedule, so the timing is analysable in a way a contention-based bus is not. For a control loop that must close within a guaranteed interval, predictability beats throughput.

Memory protection

Memory is the most upset-prone part of an avionics system, because it presents enormous cross-section to incident particles. Three mechanisms work together.

Error detection and correction

Hamming codes give single-error correction and double-error detection on every word. Reed-Solomon is used for larger blocks. Correction happens on read, transparently.

Scrubbing

A background task walks all of memory on a fixed cycle, reads each location and rewrites the corrected value. Without it, single-bit errors accumulate in rarely-read regions until a second hit makes them uncorrectable.

Configuration memory in FPGAs

An SRAM-based FPGA holds its logic definition in memory, so an upset there changes the circuit rather than the data. Configuration scrubbing is mandatory, or antifuse and flash-based parts are used instead.

Watchdog timers

A hardware counter that resets the processor unless software services it. The last line of defence against a hung system, and it must be hardware, because software cannot be trusted to detect its own failure.

The scrubbing interval is a real design parameter. Too slow and errors accumulate toward double-bit uncorrectables; too fast and the scrubber consumes memory bandwidth the application needs. It is set from the predicted upset rate for the orbit, which comes from the environment analysis described in Space radiation.

Flight software

Flight software is characterised less by algorithmic complexity than by the requirement to keep operating without supervision, recover from faults on its own, and be modifiable in flight by a radio link with minutes of delay and minutes of contact.

The architectural pattern these share is decomposition into components that communicate only through declared interfaces, with no shared mutable state. The motivation is not elegance but testability and in-flight patchability: a component with a narrow declared interface can be replaced by uplink without reasoning about the whole system.

The constraints that shape the code are unusual. Dynamic memory allocation after initialisation is typically forbidden, because heap fragmentation over a multi-year mission is unbounded and untestable. Recursion is avoided so stack depth is statically provable. Every loop has a fixed upper bound. These rules look severe from a terrestrial perspective and follow directly from the fact that nobody can restart the machine.

Safe mode is the terminal state of that diagram and its design is a systems decision rather than an avionics one. The vehicle must reach a configuration it can hold indefinitely with no ground contact: attitude that keeps the arrays illuminated and the radiators pointed away from the Sun, minimum power draw, and a low-gain antenna that does not require accurate pointing to be heard.

References

• Ley, W., Wittmann, K. and Hallmann, W. (eds.) Handbook of Space Technology, Wiley, 2009, chapter on onboard data handling.
• Eickhoff, J. Onboard Computers, Onboard Software and Satellite Operations, Springer, 2012.
• Holmes-Siedle, A. and Adams, L. Handbook of Radiation Effects, 2nd ed., Oxford University Press, 2002.
• Lions, J. L. et al. ARIANE 5 Flight 501 Failure: Report by the Inquiry Board, ESA, 1996.
• Bocchino, R. et al. “F Prime: An Open-Source Framework for Small-Scale Flight Software Systems”, SSC18-XII-04, Small Satellite Conference, 2018.
• Holt, J. et al. “core Flight System (cFS) Overview”, NASA Goddard.