MARS BIBLE — REFERENCE DOSSIER
Avionics, flight software and FDIR: how a Mars spacecraft observes, decides and saves itself
Onboard computers, memory, data buses, clocks, real-time software, watchdogs, safe mode, redundancy, radiation, diagnosis and remote updates.
Why this dossier matters
Onboard computers, memory, data buses, clocks, real-time software, watchdogs, safe mode, redundancy, radiation, diagnosis and remote updates.
The goal is deliberately encyclopaedic: start from the simple principle, show useful interfaces and calculations, then continue through failures, testing, maintenance and Mars autonomy.
1. Avionics is the vehicle’s digital nervous system
Sensors, computers, memories, data buses, I/O, clocks and software connect almost every subsystem. Avionics does not fly the spacecraft alone; it transports and processes information used by navigation, thermal control, power, communications, life support and propulsion. A digital architecture failure can therefore disable mechanically healthy hardware. Mars adds autonomy because Earth cannot intervene at millisecond timescales when an anomaly appears.
2. Onboard computer: many time scales in one machine
An attitude loop must process measurements and command actuators within bounded time, while image compression can wait longer. Software therefore allocates tasks and priorities. Real-time primarily means that specified responses meet timing bounds, not simply that the processor is fast. CPU and memory resources are budgeted like watts and kilograms, with reserve for software growth.
3. Memory: preserve what enables recovery
Volatile memory supports current computation; non-volatile memory preserves software, parameters and data across power loss. Long missions need at least one known-good software image, configuration parameters and enough logs to diagnose failures. Error-correcting codes and scrubbing can mitigate some bit errors. Strategy must also address wear, logical corruption and bad updates.
4. Data buses: making equipment speak the same language
A data bus defines physical links, protocols, messages, addresses, speed, timing and error handling. Choice depends on determinism, data rate, distance, redundancy, simplicity and compatibility. A very fast bus may be pointless for a thermostat while a camera needs high throughput. Bus failure can isolate multiple healthy units, so network topology and redundancy are critical architecture issues.
5. Timestamping: without coherent time, data loses meaning
Acceleration samples, images and commands cannot be correlated correctly if their clocks disagree. Avionics therefore distributes time and timestamps events. This also supports diagnosis by reconstructing event order after a failure. Interplanetary missions distinguish onboard event time, radio transmit time and ground receive time, separated by substantial propagation delay.
6. Radiation: expect some bits to change
Radiation can create transient electronic errors and, depending on event and technology, more serious damage. Mitigation combines part selection, shielding, error correction, watchdogs, redundancy and reconfiguration. Safety should not rely on 'no error will occur'. The system must recognise inconsistent behaviour and recover to a controlled state. Radiation tolerance is therefore an architecture property, not only a chip property.
7. Flight software: make modes explicit
State machines define modes and allowed transitions. Initialization, cruise, manoeuvre, communications, sleep and safe mode do not permit the same commands. Transitions need clear conditions and timing. Behaviour that is difficult to describe is also difficult to test, so critical systems favour explicit, logged and verifiable rules.
8. Watchdogs and health: check more than CPU activity
A watchdog can reset a processor that stops responding, but software can continue executing while making wrong decisions. Health monitoring therefore also checks timing, plausible values, communications and cross-sensor consistency. Too sensitive creates false alarms; too permissive lets failures propagate. Thresholds and timing are safety design parameters.
9. FDIR: three different verbs
Detection recognises abnormal behaviour. Isolation identifies the likely failing function or component. Recovery selects an action: reconfigure, reset, switch to backup, disconnect a branch or enter safe mode. These are distinct steps. Poor isolation can remove healthy hardware, while overly aggressive recovery can turn a minor anomaly into a real loss of function.
10. Safe mode: the digital minimum for survival
Safe mode stabilises the vehicle using a reduced function set: favourable attitude, positive power, acceptable temperature and minimum communications. It should be simpler than nominal operation but is never independent of everything. Loss of its reference sensor, power or software can make safe mode unavailable, so its own dependencies must be analysed.
11. Remote updates: change the brain without losing the vehicle
Software may need correction after launch. Safe updating uses authentication, integrity checking, a backup image and rollback. The file must survive transfer errors and installation must not remove the ability to boot a known-good version. Mars latency makes local supervision valuable, and a settlement will need tools, compilers, keys, documentation and skills rather than permanent dependence on an Earth server.
12. Test rare combinations: where real surprises hide
Dangerous scenarios often combine events: a suspect sensor during a manoeuvre, a reset during communications loss, or a cold battery during reconfiguration. Simulation, software-in-the-loop and hardware-in-the-loop can inject those faults. Tests examine timing, transitions and logs, not only final outcomes. A campaign that tests nominal operation only mostly proves that the easy case works.
13. Ground command and autonomy: who is allowed to decide?
Software architecture defines which decisions require ground command, which can be autonomous and which need local human confirmation. Earth-Mars delay pushes more decisions onboard, but autonomy needs authority rules so recovery logic does not conflict with crew procedure and a delayed ground command does not arrive after the context has changed.
14. Cybersecurity: command authenticity and integrity
A spacecraft accepting commands must verify that they come from an authorised source and were not altered. Software updates need the same protection. Cybersecurity is broader than encryption: key management, domain separation, logging and recovery are also required. Mars infrastructure must continue locally when an Earth link or remote service is unavailable.
15. Artificial intelligence: useful, but bounded
AI methods can help analyse images, detect anomalies or optimise operations, but critical functions must remain testable, monitorable and bounded. A model that performs well on test data can encounter out-of-distribution cases. Architecture should define where AI advises, where it commands, what independent checks exist and how to fall back to simpler behaviour. Autonomy should not make the system impossible to understand during diagnosis.
16. Managing scientific and operational data
A spacecraft can generate more data than it can immediately transmit. Avionics must decide what to store, compress, duplicate or delete. Health and anomaly data may outrank some imagery, while unique science files may deserve redundant copies. Storage policy must also handle saturation so logs cannot consume all memory. On Mars, the same principles grow into an autonomous data-centre architecture with local archives, replication, priorities and the ability to operate for days or weeks with degraded Earth connectivity.
Cross-cutting deepening: what the simplified lesson must not hide
The following points complete the system view and connect this dossier to Space Academy lessons.
AM-09.05 — Onboard computer and data: compute, store, command and telemeter
The onboard computer is an orchestrator
It receives telemetry, executes commands, timestamps events, manages data buses, runs GNC algorithms, stores data and supports fault detection. Some functions are real-time while others are not. Computing architecture therefore assigns priorities, processors, memory and networks according to timing and failure consequences.
Volatile, non-volatile and survival data
RAM is fast but usually loses content without power. Non-volatile memory preserves code, parameters and recovery data. Long missions must protect reference software images and safe configurations. Radiation-induced bit errors are mitigated with error correction, scrubbing, redundancy and controlled reboot strategies.
Data buses are shared roads
Sensors, actuators and computers exchange data through links and protocols. Rate, latency, determinism, topology and fault tolerance matter. A faster bus is not automatically better if it adds complexity or power. Network failure can make healthy equipment unreachable.
Time is navigation and diagnostic data
Measurements cannot be fused correctly when timestamps are wrong. Clock drift can affect navigation, communications, sequencing and anomaly reconstruction. Vehicles therefore maintain and distribute time references while accounting for onboard, ground-reception and propagation times.
Radiation means designing for transient errors
Energetic particles can temporarily flip bits or disturb circuits without permanent destruction. The system combines suitable parts, shielding, redundancy, voting, corrected memory, watchdogs and reconfiguration. The goal is not zero errors but recovery or safe behaviour when errors occur.
Observability makes failures diagnosable
Structured logs record events, key values, mode changes, resets and bus messages. Logging itself must be managed so memory and communications are not overwhelmed. Good observability lets engineers reconstruct the causal chain of an anomaly.
Distributed computing and Mars autonomy
Local controllers can reduce wiring and isolate faults but complicate synchronisation, software updates and diagnosis. Mars maintenance must also preserve configuration files, programming tools, firmware versions and replacement compatibility. Avionics therefore has a digital logistics chain as well as hardware.
Open the corresponding Space Academy lesson
AM-09.06 — Flight software, watchdog, FDIR, redundancy and safe mode
Flight software as a state machine
Robust spacecraft software makes modes and transitions explicit: initialization, nominal operation, manoeuvre, communications, safe mode and recovery. Commands may be valid in one mode and forbidden in another. Explicit state machines make rare paths visible and testable.
Watchdog: monitor the monitor
A watchdog expects evidence that software or a processor is alive and may trigger reset or reconfiguration when that evidence stops. Poor design can cause needless resets or miss logically incorrect behaviour, so the monitored condition must be defined carefully.
FDIR: detect, isolate, recover
Fault Detection, Isolation and Recovery are separate questions. Detect asks whether something is wrong; isolate asks where the likely cause is; recovery asks how to continue or become safe. Acting too quickly on a false alarm can create a real failure, while acting too slowly can propagate damage.
Safe mode is survival, not mission performance
Safe mode deliberately reduces objectives to preserve essential power, thermal state, attitude and minimum communications. It still depends on hardware and software, so designers must analyse which faults could prevent safe mode itself.
Redundancy and common software faults
Two computers running identical code may make the same wrong decision when the design error is shared. Hardware redundancy and design diversity solve different problems. A deliberately simpler backup function may sometimes be more robust but costs additional development and verification.
Test rare combinations before flight
Critical problems often occur in uncommon combinations. Software-in-the-loop and hardware-in-the-loop testing can inject sensor faults, communications loss, resets and timing problems. A campaign that tests only nominal operation gives false confidence.
Updating software far from Earth
Remote updates need validated images, robust transfer, backup copies and rollback. Mars latency increases the value of local autonomy. A settlement also needs programming tools, signatures, procedures and compatibility records as part of its technical maintenance capability.
Primary NASA sources
These references provide documentary guardrails; they do not make the prospective choices on this page an official NASA architecture.