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 avionics and FDIR define recoverability
Avionics and flight software: foundations of onboard decision-making
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.
Critical interfaces and system consequences that are easy to miss
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.
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.
Engineering deep dive — build an onboard brain that is verifiable, reconfigurable and able to doubt itself
Computer redundancy matters only if channels can genuinely disagree safely. Two identical computers producing different answers create a problem: which one is right? Three channels can vote, but three identical copies running the same software on the same data can share one common bug. Hardware redundancy handles some random component failures well; it is weaker against specification and software common causes. Architecture must distinguish those categories.
Domains can be separated: nominal computation, independent monitoring, simple protective logic and backup command. A less sophisticated backup may be more credible precisely because it shares less code. The objective is not processor count. It is preventing one mistake from removing every barrier.
Voting also has to handle uncertainty. Sensors never match perfectly. The system needs tolerances, drift detection and rules for excluding channels. Naive majority voting can preserve two sensors ageing together and reject the only healthy one. Physical consistency with other measurements can provide another line of evidence.
Modes should represent mission states, not merely software labels. “Nominal,” “safe” and “maintenance” should specify which functions operate, which commands are allowed, which resources have priority and how transitions occur. A bad transition can be more dangerous than either state. Two subsystems can otherwise believe they are in incompatible modes.
The vehicle therefore needs global state logic or at least coherent interface contracts. On entry to safe mode, attitude, power, thermal control, communications and propulsion must converge on a compatible configuration. A subsystem waiting for a command from a computer that has already been isolated can block recovery.
Transitions should be tested in both directions. Programs often prove entry into safe mode more thoroughly than return. A Mars vehicle may remain degraded for hours or days. Restart must consider temperature, battery charge, stored data and real mechanism state.
Remote software update requires a credible rollback. A multi-year mission will probably discover software defects or new needs. Forbidding updates is unrealistic; uncontrolled changes are dangerous. The system should support signed images, a known-good bank, staged installation and automatic rollback if health checks fail.
Software behaviour also depends on parameters, calibration tables, sensor models and FDIR thresholds. Those data need the same version discipline as executable code. Knowing the program version while losing track of the threshold table does not constitute configuration control.
Communications delay strengthens the case for local test capability. Before activation on the primary chain, new software can run on a redundant processor, replay recorded telemetry and compare outputs. The spacecraft becomes partly its own integration laboratory.
Cybersecurity becomes a safety function. On a remote vehicle, a malicious command and an accidentally corrupted command can produce the same physical outcome. Authentication, integrity and key management therefore belong in command architecture from the beginning. Security cannot be bolted on without affecting availability and control paths.
Protection mechanisms must also avoid fatal lockout. An expired key or desynchronized clock should not make emergency commanding impossible. Recovery roles and procedures are needed without creating a permanent backdoor. The security/availability trade is severe when no technician can physically reach the system.
At settlement scale, networks need segmentation: life-critical control, administration, research, personal use and industry. Universal connectivity is convenient but expands attack paths and common causes. A Mars town will need cyber architecture resembling terrestrial critical infrastructure.
Useful AI should be contained by verifiable invariants. AI can assist diagnosis, planning and anomaly classification without receiving unlimited authority. Life-critical functions can be protected by invariants — pressure, temperature, energy, attitude or separation limits that an AI proposal cannot violate. A deterministic safety layer can validate an action before execution.
Provenance matters. If the AI recommends shutting down a pump, operators need the measurements and assumptions behind that recommendation. A fluent explanation is not enough; the reasoning should point back to system state, events and applicable safety rules so humans can detect stale or invalid inputs.
Finally, AI must be removable from the control path. The vehicle should preserve a simpler functional core even at reduced performance. Robustness does not require perfect AI. It requires AI failure not to become vehicle failure.
Making software upgradable without making the vehicle unpredictable
Separate safety-critical functions from rapidly evolving ones. A Mars spacecraft needs software that can evolve over years, but every update creates regression risk. Robust architecture separates safety kernels such as mode management, essential protections and critical interfaces from functions that may change more frequently. This does not make the kernel immutable; it gives it a stricter modification cycle with stronger evidence and testing.
Configuration management has to include software, parameters, models and calibration data. Saying that a vehicle runs “version 7” is not enough if a sensor table or FDIR threshold changed independently. The executed configuration must be reconstructible and comparable with the validated one.
Make rollback a normal function. An update that passes ground testing may fail in an unexpected operational configuration. The system therefore needs rollback to a previous version and a safe mode able to boot a minimum set of functions. Data created after an update must remain compatible or be convertible; otherwise software rollback may restore the program while making its own recent state unreadable.
Remote updates should be transactional where practical: verified transfer, installation into an inactive partition, test, controlled switch and monitoring. A communications loss halfway through the process must not leave the computer in an ambiguous partial state.
Constrain AI with invariants and explicit authority. AI can help classify anomalies, search procedures or suggest diagnoses. It should not gain implicit authority merely because its language sounds confident. Critical functions need verifiable invariants: pressure limits, forbidden zones, valve states, thermal envelopes, minimum reserves and actions that require human approval.
This permits powerful models without confusing recommendation with command. Logs should preserve the observation, the proposed action, the authority that decided and the action actually executed. Later analysis can then distinguish sensor error, poor recommendation, inadequate human validation and faulty execution.
Verification cases and operational margin
Qualify changes with representative regression campaigns. A critical update should be tested against a library of scenarios drawn from system history: nominal startup, biased sensor, missing data, reboot during a maneuver, network saturation, lost actuator and combined faults. The expected result is not merely “test passed” but traceable behavior: selected mode, alarms, prohibited commands and final state. The library grows after every important incident.
As hardware ages, some tests also need values near operational limits rather than ideal inputs. Software that is robust with new sensors may become unstable with slow drift. Validation should therefore incorporate margins actually observed in the fleet. On Mars, software qualification and hardware maintenance eventually share the same health data.
The same principle applies to configuration data sent from Earth. A new threshold, calibration table or reconfiguration rule can alter critical behavior and therefore deserves the same verification discipline as software. A change package should carry an identifier, rationale, compatible versions, executed tests, rollback procedure and approving authority. This prevents a settlement from accumulating small undocumented adjustments that become impossible to reconstruct months later.
Make avionics a decision system that can explain and recover
A measurement is not yet a truth
A sensor delivers a voltage, count, frequency, or data packet. Avionics must turn that observation into a physical quantity, attach time, quality, and uncertainty, then decide whether it is consistent with other evidence. This chain matters on a Mars mission because the crew cannot ask Earth to resolve every ambiguity immediately. Software should distinguish missing data, suspect data, an out-of-range value, and disagreement among sensors.
Data fusion should not erase disagreement. An average temperature from three probes may appear reassuring while one probe is drifting slowly. Residuals, trends, and health indicators should remain available. A useful alarm is not merely “high temperature”; it can show which sensor diverged, for how long, and whether the change is consistent with flow and thermal power. Explanation shortens human diagnosis.
Time is itself a critical measurement. If two computers timestamp the same event differently, root-cause analysis can reverse the apparent sequence. Networks therefore need to monitor synchronization, clock drift, and the quality of distributed time. A Mars mission can tolerate minutes of Earth delay; it cannot tolerate its own systems being unable to tell which local event preceded another by milliseconds.
FDIR: detect, isolate, and recover without hiding uncertainty
FDIR stands for Fault Detection, Isolation and Recovery. Detection says that something is no longer consistent. Isolation finds the fault boundary. Recovery selects a configuration that restores a function or at least stops the situation from becoming worse. The steps should remain conceptually separate because fast detection does not guarantee correct isolation, and recovery launched from a wrong diagnosis can deepen the failure.
Consider an apparent pump loss. Motor current falls to zero and measured flow decreases. The cause could be the pump, contactor, power feed, current sensor, flow sensor, or software command. FDIR should seek independent evidence before declaring the pump failed. Automatic switch-over to a redundant unit can be appropriate when the consequence of a wrong decision is small; it can be dangerous when both channels share an upstream fault.
Recovery should be reversible when uncertainty remains high. Safe mode, power limiting, inhibiting an action, or switching to a simpler estimator can buy time. The objective is not always immediate restoration of nominal performance. It is often to preserve a state in which the crew retains enough power, data, and authority to understand what happened.
Software authority needs visible boundaries
As a vehicle moves farther from Earth, software autonomy becomes more valuable. Autonomy does not mean that software should be able to do anything. Each automated function needs an authority envelope: entry conditions, permitted actions, limits, maximum duration, and criteria for returning control. Those boundaries protect against both a bad state estimate and a software defect.
Voting mechanisms also need careful interpretation. Three computers running identical software can outvote one isolated hardware failure, yet all remain vulnerable to a shared specification or coding error. Diversity can come from different physical sensors, independent monitoring algorithms, or a deliberately simpler backup chain. It costs verification effort but reduces the chance that one wrong assumption dominates every channel.
On a crewed system, operators need to know when automation acts and why. “Reconfiguration complete” is not enough if nobody knows which sensor triggered the action, which functions were lost, or how to reverse the change. Event logs, configuration state, and decision explanations are therefore safety interfaces.
Update software without creating a common-cause failure
A long mission will need bug fixes, parameter changes, or algorithm improvements. Updating software should nevertheless be treated as a hazardous operation: verify the received image, authenticate it, preserve a rollback version, confirm configuration compatibility, and limit the scope of change. A vehicle should never depend on one freshly installed image to preserve every life-critical function.
A robust arrangement separates the active partition, a known-good image, and configuration data. An update can be installed offline, checked, then activated during a window in which rollback remains possible. If a computer does not restart correctly, an independent mechanism should be able to select the previous image. That capability matters when communications delay prevents the ground from guiding recovery second by second.
NASA software engineering and software assurance standards are useful because they emphasize traceability, criticality classification, verification, and independence proportional to risk. They do not remove the need to adapt the reasoning to a Mars context: long isolation, evolving configuration, a small operations team, and hardware that cannot easily be replaced.
Test avionics by injecting faults, not only perfect cases
An FDIR system should be challenged with stuck sensors, plausible-but-wrong values, delayed packets, partial reboots, bus losses, and concurrent failures. Fault injection measures detection time, isolation quality, and recovery stability. A system may handle every fault correctly in isolation and become unstable when two alarms arrive during a reconfiguration.
Testing should cover false positives as well. An oversensitive detector can trigger unnecessary switchovers, consume redundant hardware life, or saturate crew attention. Suppose a detector produces one false trigger every 30 days on average. Over a 240-day transit, the expectation is 240 / 30 = 8 false events. Even when each event is individually safe, eight interruptions can become an operational burden. FDIR performance therefore includes false-alarm rate and the cost of associated recovery.
Finally, tests must preserve the evidence needed for investigation. A circular log that is too small can overwrite the seconds before a fault. Unsynchronized clocks make traces ambiguous. Telemetry that stores only the final state cannot explain a transition. The ability to learn from an anomaly begins with the ability to record what actually happened.
Avionics case study: three sensors do not guarantee three truths
Minutes before a trajectory correction, three attitude sensors produce slightly different information. Two agree; the third drifts slowly. Majority voting could reject it immediately. The better first question is whether the two agreeing sensors share the same reference, algorithm, or disturbance. A majority is evidence only when independence has been examined.
Software can compare measurements with a dynamic prediction and with evidence from a different physical principle, such as a star measurement versus inertial propagation. It computes residuals, watches their evolution, and attaches quality to each observation. If the two majority sensors drift together because of a shared timing problem, the third sensor may be the only one describing reality. The evidence chain should preserve provenance rather than collapsing three observations into one value too early.
Suppose allowed attitude error is 0.20° during the maneuver. Two estimates differ by 0.08°, while a third is 0.23° away. The third exceeds the limit, but avionics still has to determine whether it is truly wrong or using a different reference. A conservative rule may inhibit the maneuver until independent evidence confirms the dominant estimate. The cost is delay; the benefit is avoiding an impulse executed with poorly known orientation.
Degraded mode needs to remain operable. Crew can reduce estimator complexity, freeze selected automatic updates, and request an additional star acquisition. Software then exposes which sources are used, which are rejected, and why. If the mission eventually has to maneuver with reduced precision, remaining uncertainty is passed to trajectory planning so that a later correction can absorb the dispersion.
Post-event analysis should not stop at the sensor declared failed. It examines clocks, buses, power, temperature, software versions, and calibration history. A common cause discovered later can change voting logic across the vehicle. The anomaly then becomes architecture knowledge rather than merely a part replacement.
The case illustrates the difference between automation and robust autonomy. Automation applies a rule. Robust autonomy retains enough context to recognize when the rule may no longer be trustworthy, slow the decision, and seek different evidence. On a Mars spacecraft, the ability to doubt correctly can be as important as computation speed.
Avionics turns imperfect measurements into executable decisions
Interplanetary avionics is more than an onboard computer. It includes processors, memory, data networks, sensor acquisition, actuator interfaces, clocks, flight software and diagnostic functions. NASA describes avionics as the command-and-data infrastructure upon which spacecraft operation depends. For Mars, autonomy is the defining requirement: a critical alarm cannot wait for a specialist on Earth to decide whether a sensor or the physical system has failed.
Measurements contain noise, bias and missing data. Flight software must distinguish a real physical transition from a bad measurement. Plausibility checks, sensor comparison, state estimation and time filtering all matter. A temperature sensor that instantly jumps from 20 to 120 °C while neighbouring measurements remain stable does not automatically prove a fire; ignoring it can still be fatal. Context and trend are part of the decision.
FDIR: detect, isolate and recover without creating a second failure
FDIR means Fault Detection, Isolation and Recovery. The logic must avoid both inaction and overreaction. Recovery may restart software, isolate an electrical branch, select another sensor, freeze a command or enter safe mode. Safe mode is not simply shutdown: it must maintain a survivable attitude, power and thermal state, preserve diagnostic data and provide a path back to controlled operation.
Safe mode itself can become hazardous if it assumes power, thermal geometry or communication resources that are no longer available. Off-nominal states therefore need the same architectural scrutiny as nominal modes.
Radiation tolerance is built from parts through software
Electronic systems face total ionizing dose and single-event effects. A strategy may combine qualified components, redundant processing, error-correcting memory, scrubbing, watchdogs and restart capability. No one measure protects against every cause. A memory protected against bit flips can still fail through power loss or common software defects.
If a particular protected memory population experienced one corrected event every 200 hours on average, a 6,000-hour transit would imply an order of magnitude of 6,000 ÷ 200 = 30 corrected events if the rate remained constant. This is not a mission prediction; it illustrates why a low event rate does not mean zero events on a long flight. Corrected events should be logged and trended as health data.
Flight software must evolve without erasing a validated configuration
NASA teams use frameworks such as core Flight System and development processes that connect requirements, models and automated testing. A Mars vehicle may require updates, but updates need rollback. The spacecraft must know the active version, verify package integrity, retain a recovery image and preserve a minimal boot path if installation fails.
Software flexibility must not justify fragile hardware. Safety-critical functions benefit from independent protection where practical. Software is powerful for reconfiguration and diagnosis, but it can also create common causes across several functions.
The event log becomes a reliability instrument
An autonomous vehicle should record not only alarms but context: pre- and post-event measurements, commands, mode changes, software version and recovery outcome. Over months, this history helps expose intermittent failures and update risk models. That is the difference between a machine that merely operates and a system that can learn from its own technical history.
Flight software must be able to explain what it believes to be true. An autonomous system is not reliable merely because it runs more algorithms. Reliability improves when estimates, assumptions and modes are observable. If avionics declares a sensor failed, crew should be able to see which symptoms drove the conclusion, which source replaces it and what additional uncertainty follows. Otherwise a sound automatic decision may look like a malfunction and be overridden.
FDIR—fault detection, isolation and recovery—must distinguish physical anomaly from data anomaly. A stuck sensor, delayed message, corrupt packet and real temperature excursion can look similar. Plausibility checks use redundancy, models and temporal coherence. Yet a model that is too rigid can reject a genuine unexpected phenomenon; autonomy needs an “unknown” state rather than a forced diagnosis.
Software configuration becomes critical on multi-year missions. An update may fix one defect while changing timing, memory, communications and interactions. The spacecraft should retain a previous version, integrity evidence, rollback procedure and change description. An interplanetary link does not make Earth-origin updates equivalent to updating a consumer computer.
Radiation events create transient faults. Memory can use error correction and scrubbing; computers can compare state and restart partitions. Repeated automatic reset, however, can hide persistent hardware damage. Logs need event frequency, location and context so operations can change modes rather than merely reboot.
Software testing must include the physical system it controls. Simulation may verify thousands of cases without discovering that a real valve takes two seconds longer to move when cold. Hardware-in-the-loop, fault injection and timing scenarios connect code assurance to assumptions about the world.
For Mars, the deepest issue is authority during communications loss. Software must protect the vehicle while crew retains mission responsibility. Escalation rules should state which actions are automatic, which require confirmation and which are forbidden without independent evidence. This is the technical constitution of autonomy.
Time, buses and cybersecurity are part of flight-control integrity. Distributed avionics need a coherent notion of time. If two sensors timestamp the same physical event with clocks separated by tens of milliseconds, a control or diagnostic algorithm can infer the wrong sequence. Clock synchronization, holdover and explicit time quality therefore belong to data integrity.
Data buses also fail in more ways than “working” or “dead.” Congestion can increase latency, a noisy node can flood traffic, and one malformed message can trigger software paths repeatedly. Network health monitoring should track error counters, timing and traffic distribution so degraded communication is detected before complete loss.
Watchdogs need careful scope. A processor can execute instructions while its application is logically stuck; a simple heartbeat may say “alive” while useful work has stopped. Independent reasonableness checks—command progress, sensor change, queue age—can reveal this class of failure.
Cybersecurity affects safety because commands create physical consequences. Authentication and integrity checks protect against unauthorized change, while secure boot and configuration records protect software state. Yet security mechanisms must remain operable during contingency and offline periods; a certificate or key process that requires Earth at the wrong time can disable recovery.
Artificial intelligence should be bounded by authority and verification. A learned model may help prioritize telemetry, detect unusual patterns or propose diagnoses. Life-critical action should still be constrained by explicit rules, independent measurements and the ability to fall back to simpler deterministic control. AI is most valuable when it reduces human search without becoming an unobservable single point of decision.
Long-duration avionics therefore needs both adaptability and conservatism: software must evolve, but every change preserves traceability, rollback and a known safe state. That balance is what makes remote maintenance credible across interplanetary distance.
Case study: three sensors do not necessarily provide three independent truths. Three pressure sensors monitor one loop. Two show a slow decrease while the third stays stable. Simple majority voting would reject the third. But if the two agreeing channels share power and analog conditioning, one common drift can fool the vote. FDIR must know real channel independence rather than count values.
Software seeks other evidence: flow, valve position, temperature, pump power and dynamic model behavior. If these corroborate the pressure decrease, confidence grows. If they contradict the two sensors, the state should remain ambiguous. Keeping multiple hypotheses is safer than converting uncertainty into a confident wrong action.
Time matters. A slow leak allows seconds or minutes of cross-checking; rapid depressurization requires immediate conservative response. FDIR thresholds therefore incorporate rate and consequence, not one generic algorithm.
Suppose a recent software update changed calibration for the two sensors. Configuration history becomes diagnostic evidence. The system can compare pre- and post-update behavior, restore old parameters or isolate the new function. Without version records, crew would search only for hardware failure.
After recovery, data are preserved for analysis. The goal is not only avoiding recurrence but improving discrimination among causes. Autonomous Mars missions accumulate local knowledge of real vehicle behavior, feeding better models and procedures.
Data management and observability decide whether autonomous operations remain auditable. A long Mars mission can generate more telemetry than is practical to send continuously to Earth. Flight software must decide which data remain onboard, which are summarized and which receive priority. The policy should preserve enough raw evidence to reconstruct anomalies rather than keeping only processed conclusions.
Event logs need synchronized timestamps, configuration identifiers and causal context. A message saying “pump fault” is weak evidence if it does not record sensor values, command state and software version. Storage architecture should support both real-time control and later forensic analysis.
Compression can create hidden trade-offs. Lossy image or waveform compression may be acceptable for routine monitoring but destroy subtle evidence during an anomaly. Systems can preserve higher fidelity around detected events or allow crew to mark periods for protected storage.
Autonomy also needs confidence reporting. An algorithm that estimates a leak location or component health should communicate uncertainty and evidence quality. Crew can then distinguish a strong diagnosis from a tentative hypothesis and choose whether to commit to an irreversible action.
Onboard models need configuration awareness. A digital twin representing a valve that was replaced with a different model can produce misleading predictions unless updated. The maintenance database and the autonomy model should therefore share controlled configuration data.
This observability is a safety feature. When Earth cannot immediately inspect the system, crew and software need a common, inspectable history of what happened and why the vehicle acted. Autonomy becomes trustworthy when decisions leave evidence.
Processor redundancy can use different strategies: cold spare, hot redundant lanes, lockstep comparison or functionally diverse computers. Each trades power, fault coverage and complexity. The architecture should explain which faults it is designed to tolerate rather than simply claiming 'redundant computers.'
Communications loss should be part of routine software testing. Timers, queued commands and data expiration can behave differently after hours of disconnection. Testing long outages reveals assumptions that short laboratory network interruptions never expose.
Crew interfaces should also preserve manual paths for essential functions while preventing accidental conflicting commands. Manual does not mean unprotected; interlocks, rate limits and confirmation can allow human authority without bypassing every safety boundary.
Partitioning can limit software fault propagation. Safety-critical control may run in protected partitions separated from science or crew applications, with controlled communication between them. This allows some software to evolve without giving every change the ability to disrupt vehicle survival functions.
Resource exhaustion is another failure mode. Memory leaks, growing log files or message queues may take days to become dangerous. Health monitoring should therefore include free memory, storage use, queue age and processor margin. Long missions expose slow software faults that short tests may never reveal.
Independent reset paths need careful design. A watchdog that depends on the processor it is meant to recover can fail silently. Hardware supervisors or separate lanes can provide stronger recovery, but reset must preserve enough state for diagnosis and avoid cycling endlessly through the same fault.
Autonomous planning should operate within explicit resource envelopes. Software may reorder activities to save time or energy, but it should not quietly consume emergency power, thermal margin or propellant. Cross-system constraints need machine-readable limits and human-readable explanations.
Command authority should be visible in every mode. Ground, crew and autonomous software may all be able to request actions, but arbitration rules determine which source wins during conflict. Those rules should be testable and recorded, especially when a safe-mode computer takes control from the primary flight software.
Sensor calibration data need the same protection as executable code. Losing or corrupting calibration can turn healthy hardware into misleading telemetry. Configuration backups should therefore include coefficients, alignment matrices, thresholds and provenance, with checks that restoration matches the physical sensor installed.
Long missions also need software obsolescence planning. Development tools and ground simulators can evolve while the flown system remains fixed. Preserving build environments, test vectors and documentation allows engineers years later to reproduce a problem rather than guessing how an old binary was created.
Verification evidence should survive software evolution. When a module changes, engineers need to know which tests must be repeated and which assumptions remain valid. Traceability from requirement to test prevents a small patch from silently invalidating a safety argument built years earlier.
Fault injection is particularly useful for FDIR. Simulated stuck values, delayed messages, memory errors and actuator mismatches can reveal whether detection thresholds and recovery logic produce the intended vehicle state. The purpose is not only to prove recovery but to find cases where the recovery action is worse than the original fault.
Crew training should include uncertainty and contradictory data. Real anomalies rarely arrive with one clean alarm. Practicing ambiguous sensor sets, partial communications and changing software state teaches operators to use evidence hierarchy instead of chasing the first plausible diagnosis.
Onboard autonomy also depends on a trustworthy boot chain. After a power loss, the vehicle must know which image to start, how integrity is checked and what happens if the preferred software is corrupt. A protected recovery image, minimal communications path and independently stored configuration can turn severe software damage into a recoverable event instead of a dead computer.
Data buses should have degraded modes. If a high-rate network segment fails, a low-rate command and health channel may still preserve control. This is analogous to emergency electrical distribution: not every service survives, but the system keeps the information needed to make safe decisions. Network architecture and flight-software architecture should be designed together.
Human override itself requires design evidence. An override should clearly state which automated protections are being suspended, how long the override remains active and how normal authority is restored. Hidden or persistent override states are dangerous because the next crew member may assume protections still exist.
The most valuable software on a Mars vehicle may ultimately be the software that helps maintain all the other software: diagnostics, configuration comparison, test harnesses, log analysis and controlled update tooling. Long-duration missions need an onboard engineering environment capable of understanding change without weakening the certified safety core.
A final resilience layer is procedural independence. Essential software recovery instructions, cryptographic recovery material and hardware access procedures must be available onboard even if the normal documentation server or network segment is unavailable. Recovery should not depend on the same infrastructure being repaired. This principle sounds simple, but it separates a genuinely self-recovering deep-space avionics system from one that assumes Earth support is always reachable.
From measurement to action: build a digital chain of evidence
Mars-mission avionics must do much more than keep software running. It has to construct a defensible picture of vehicle state from imperfect measurements, decide which information is trustworthy, detect inconsistencies, select an action, and preserve enough evidence for crew and ground teams to reconstruct what happened. That evidence chain becomes critical when radio delay prevents Earth from confirming every urgent decision.
The first challenge is observability. A sensor does not always measure the quantity operators care about directly. Pressure, temperature, current or acceleration may be used to infer equipment state. Two sensors can agree and still share the same bias. Critical functions therefore benefit from genuinely independent evidence: an inertial position estimate can be compared with optical navigation, while a valve position switch can be checked against the hydraulic consequence that should follow the commanded motion.
FDIR — Fault Detection, Isolation and Recovery — is often compressed into three words, but each is a different engineering problem. Detection means deciding that observations are no longer compatible with expected behavior. Isolation means identifying the likely cause or at least a bounded fault region without replacing good hardware. Recovery means returning the mission to a safe state, sometimes with reduced capability. Confusing those steps creates diagnostic failures in which the recovery logic becomes a second fault.
Majority voting is not enough when errors share a cause
Three identical sensors are often presented as an obvious solution: two similar values outvote the third. That reasoning only works when failures are sufficiently independent. Three sensors from the same lot may drift under the same radiation or thermal environment; three channels may use the same analog-to-digital converter; three computers can execute the same software defect. Diversity has to be analyzed at the level of causes, not simply item count.
A numerical example illustrates the difference between redundancy and fault coverage. Suppose one sensor has a 0.001 probability of being unavailable during a particular interval. With three independent sensors and a two-out-of-three requirement, simultaneous loss would be very unlikely. But if a common-cause event has a 0.0005 probability of disabling all three, that term can dominate the remaining risk. A fourth identical sensor barely changes it. The design has to attack the common cause — power, software, connector, environment, procedure, or measurement principle.
Diagnosis must also represent uncertainty. Turning every measurement into true/false too early discards information. It is often more useful to retain quality states such as valid, suspect, unavailable, outside calibrated range, not synchronized, or inconsistent with an independent source. That allows the system to become cautious without pretending it already knows the cause.
Time is data: clocks, latency, and the order of events
A complex anomaly is reconstructed like an investigation. To determine whether a voltage sag caused a computer reset or the reset caused a bus transient, events need coherent timestamps. If each unit has a drifting clock and synchronization is not maintained, the logs become ambiguous exactly when they matter most.
Required precision depends on dynamics. A pyrotechnic sequence, propulsion event or high-rate data bus may demand fine timing; a thermal drift lasting hours does not. Time architecture should therefore distinguish mission elapsed time, internal synchronization, science timestamps and the civil time presented to the crew. Conversion between them without losing provenance is an avionics function.
Earth–Mars delay adds another time scale. A command arriving from Earth reflects the ground’s knowledge of vehicle state several minutes earlier. Flight software should decide whether the command is still compatible with the current state. Some commands are safer when bound to conditions or execution windows rather than applied blindly upon arrival.
Update flight software without turning every correction into a wager
A vehicle operating for years will need software changes: bug fixes, new modes, sensor replacements, improved diagnostics, and adaptation to locally changed hardware. Safety therefore cannot mean “never update.” It means make change reversible, attributable and testable. A strong architecture separates the active image, a previous known-good image, configuration parameters, and operational data that must survive software replacement.
Rollback should be tested as a normal function. If a new image boots but behaves unexpectedly, the crew should be able to restore a previous release without depending on unavailable ground tools. The procedure also has to address data formats and parameters written by the newer software. Restoring an executable while leaving incompatible configuration behind is not a real rollback.
NASA’s current software framework emphasizes life-cycle engineering, requirements management, verification and validation. NASA-STD-8739.8B adds systematic software assurance, software safety and independent verification and validation. For a Mars vehicle, the operational conclusion is that the ability to modify software must travel with evidence showing what changed, what was tested, and what remains uncertain.
Safe mode should preserve the ability to understand the vehicle
A safe mode that is too minimal can survive while making diagnosis impossible. The spacecraft should retain enough telemetry, event logs, sensing and command authority to determine why it entered the mode. At the other extreme, keeping too many functions alive consumes energy and leaves unnecessary software active while the problem is not understood. Safe mode is therefore a compromise between simplicity, survival and observability.
Entry rules should be explainable. One isolated alarm does not always deserve the same response as a coherent combination of indicators. Logic can use persistence, independent confirmation and mode-dependent thresholds. A suspicious pressure reading during quiet cruise and the same reading during an engine operation need not produce identical actions.
A useful scenario is an intermittent loss of the main data bus for thirty seconds. Which functions continue on a backup path? Which devices hold their last command? Which actuators move to a defined safe state? How does the system prevent a burst of stale commands when the main bus returns? Those answers belong simultaneously to hardware architecture, flight software and operations.
Primary references include NASA-HDBK-2203 — Software Engineering Handbook, NPR 7150.2D — Software Engineering Requirements, NASA-STD-8739.8B — Software Assurance and Software Safety, and NASA requirements addressing FDIR for critical functions. Probabilities and availability numbers in this extension are explicit teaching assumptions rather than a declared design for a particular spacecraft.
Case study — make FDIR an evidence chain
A 50 Hz loop has period τ = 1/f = 0.02 s, or 20 ms. A watchdog tripping after two missed deadlines therefore detects a stalled task in about 40 ms. Here f is frequency and τ period. That speed is useful only if restart does not reload an already corrupted state.
An implausible sensor may justify comparison with other observables rather than an immediate computer switch. Two redundant computers sharing the same corrupted table can make the same mistake.
The campaign injects frame loss, memory bit flips, frozen sensors, timing drift and incomplete restart, then requires a deterministic detection–isolation–reconfiguration–verification timeline.
Cybersecurity and safety meet when software controls the physical world
On a Mars spacecraft, a configuration mistake and a hostile action can produce similar symptoms: unexpected commands, inconsistent data, denied service, or a changed parameter. Cybersecurity therefore cannot remain an administrative layer. It becomes part of safety whenever software can move a valve, shed a load, or alter the state estimate.
Least privilege limits what a service may do. Software that compresses imagery has no reason to reconfigure a life-critical bus. A maintenance interface can be powerful yet available only in a defined mode with authentication and logging. Separation reduces both the error surface and the attack surface.
Keys and certificates are themselves critical inventory. They expire, can be compromised, and may need replacement during a long mission. Renewal should not depend on an instantaneous Earth connection. The vehicle needs a root of trust, recovery mechanisms, and a policy for isolating a suspect device without losing the entire function.
A software update should also preserve evidence. Who authorized the image? Which version was installed before? Which hash was checked? Which parameters changed? What minimum test ran after reboot? An intervention that cannot be reconstructed later is an operational weakness even when it appears to succeed.
Cybersecurity degraded mode deserves design attention. If part of the internal network is isolated, life-critical functions should continue through minimal interfaces. A vehicle in which every function depends on one directory, central server, or unique key can turn a digital incident into a general failure. Segmentation and local command paths are therefore safety choices.
The practical rule is simple: every important digital authority should have a verifiable origin, limited scope, an audit trail, and a revocation path. That discipline makes automation more explainable and prevents a highly connected architecture from giving one software error too much physical power.
When avionics needs to say “I do not know”
A mature autonomous system does not turn every uncertainty into a categorical decision. It must sometimes report that a state is not sufficiently observable, that a sensor is no longer trustworthy, or that an estimator assumption has been violated. Expressing uncertainty prevents software from inventing precision and gives the crew an opportunity to slow an operation.
The representation can be simple: estimated value, uncertainty interval, contributing sources, and quality. When a critical action depends on a variable, the threshold should not ignore uncertainty. If an operational limit is 100 units and the estimate is 96 ± 8, declaring the state safely below the limit would be misleading because the interval crosses the forbidden region. The system can request another observation or choose a more conservative action.
Caution has to be balanced against paralysis. A vehicle that refuses every action whenever data are imperfect would be unusable. Degraded modes therefore define which decisions may proceed with weaker evidence, which margins are added, and which actions remain prohibited. Software authority contracts as confidence falls.
The objective is autonomy that hides neither its sources nor its doubts. That improves diagnosis, strengthens lessons learned, and helps the crew distinguish a machine that actually knows something from a machine that merely produces a number.
Sources and references
Primary references
NASA Small Spacecraft Avionics, May 2026; Core Avionics & Software Technologies; and JSC Software & Autonomous Subsystems.
Primary NASA sources
These references provide documentary guardrails;
- NASA - 2026 State-of-the-Art: Small Spacecraft Avionics
- NASA Systems Engineering Handbook
- NASA - 2026 State-of-the-Art of Small Spacecraft Technology
- NASA - 2026 State-of-the-Art: Ground Data Systems and Mission Operations
- NASA NTRS — Fault Detection and Diagnosis in Spacecraft Electrical Power Systems — autonomous diagnosis and fault tolerance
- NASA Moon to Mars — Autonomous Systems and Data Systems — autonomy, data and commanding