MARS BIBLE — RISK & RESILIENCE
Software anomaly during an Earth-Mars communications blackout: decide without remote help
A critical software anomaly becomes more dangerous when delay or blackout prevents immediate intervention from Earth.
The challenge is not merely to fix software: the system must remain safe while diagnosis is incomplete and Earth expertise is temporarily out of reach.
1 — Delay changes control organization
Earth teams can analyze, but cannot run second-by-second emergency loops with tens of minutes round-trip delay.
Vehicle or settlement must detect, protect, and stabilize locally.
2 — Safing: preserve before optimizing
Safe mode reduces nonessential functions and places the system in a known state as far as possible.
The goal is not nominal mission performance but preservation of power, thermal control, communications, and integrity.
3 — Backup software must be truly independent
An identical copy with the same defect is not diversity. A previous version, simplified path, or independent controller can provide different defense depending on architecture.
Configuration management must identify exactly which version is running.
4 — Sensors can make diagnosis ambiguous
If both software and sensors are suspect, cross-measurements and consistency checks are needed.
One alarm should not automatically cause an irreversible action without appropriate logic.
5 — Log for Earth without waiting for Earth
Event data must be preserved so remote teams can reconstruct chronology later.
Immediate decisions belong to local protections and crew.
6 — Return gradually
After stabilization, re-enabling one function at a time reduces the chance of reintroducing the anomaly.
Return to nominal state must be tested procedure, not a full blind restart.
Combined scenario — software doubts its sensors while Earth is silent
The most dangerous case is not always a computer that stops completely. Software may keep running while receiving inconsistent measurements. If Earth-Mars communications are unavailable at the same time, the crew cannot wait for a remote team to settle the diagnosis.
The first requirement is to separate “I do not know” from “I know this is dangerous.” A well-designed system must be able to declare uncertainty, preserve raw data, and enter a safe state without converting every doubtful sensor into an irreversible command.
The second requirement is configuration traceability. Operators must know which software version is running, which parameter tables are loaded, what changes were made, and which fallback package was validated. Rolling back is safe only if the older version remains compatible with the current hardware state.
The third requirement is comparison across independent chains. A pressure reading can be checked against flow, temperature, or a physically different sensor. The aim is not blind majority voting but identifying which set of measurements remains consistent with system physics.
Finally, every local action should leave a history that can be analyzed when communications return: logs, timestamps, human decisions, and before/after states. Without that memory, Earth teams cannot reconstruct the event or remove its root cause.
What an autonomous mode must allow without Earth assistance
Autonomous mode should first preserve vital functions inside a conservative envelope. That may mean reduced performance, prohibited maneuvers, or shutting down nonessential equipment rather than immediately chasing nominal output.
It must also provide a control path the crew can understand. Operators cannot decide well if the interface hides software assumptions. Excluded sensors, active thresholds, and disabled automation should be visible.
A third barrier is controlled restoration: save state, verify software-package integrity, return to a known configuration, then reintroduce functions one at a time. An all-at-once restart makes diagnosis harder and can recreate the failure.
The system should tolerate periods without perfect external timing or remote data. Decisions that depend on unavailable Earth information must be identified in advance, with a local substitution or hold rule.
Finally, drills should combine software anomalies and communications loss. Testing “software fails” and “the link fails” separately does not prove the crew can handle both at once.
Teaching calculation — make margin visible
TEACHING ASSUMPTION: one-way delay=20 min. A question to Earth needs at least ~40 min for a reply, excluding analysis and transmission overhead.
If an irreversible threshold is reached in 8 min, waiting for Earth is physically impossible: local protection must act first.
Add only 5 min for ground analysis and minimum response becomes ~45 min. This is why autonomy and safing are not optional luxury features.
Questions never to forget
- Which safe state can be reached without Earth confirmation?
- Which backup software version shares the same code or libraries?
- Which independent sensors confirm the anomaly?
- How many minutes remain before the first irreversible threshold?
- Which data must be preserved for delayed analysis?