MARS BIBLE — RISK & RESILIENCE
Contradictory sensors and control software: what should the system believe?
When two sensors disagree, the key question is no longer “which value should we read?” but “which measurement chain can still be trusted?”.
An autonomous base must distinguish sensor failure, wiring faults, calibration drift, software anomalies, and a real physical event. This chapter follows the decision from inconsistency detection through voting, isolation, degraded mode, and confirmation by an independent measurement.
1 — A measurement is not reality itself
A sensor converts a physical quantity into a signal. It has accuracy, noise, bias, drift, and operating range. Different values do not automatically mean multiple failures.
The first step is understanding each instrument’s normal uncertainty before declaring a conflict.
2 — Two-out-of-three voting is not enough by itself
A 2-of-3 vote can reject one outlier, but it fails when two sensors share the same defect or bad calibration.
Diversity of measurement principle can be more valuable than three identical copies.
3 — Software must be able to say “I do not know”
A robust estimator provides not just a value but confidence. When confidence collapses, the system can enter a safe mode rather than continue aggressive optimization.
Safety requires degraded states designed before the emergency.
4 — Example: three pressure sensors
If A = 101.2 kPa, B = 101.3 kPa, and C = 98.0 kPa, C looks suspicious. But if A and B share a frozen manifold, their agreement can mislead.
Check an independent sensor, expected system behavior, and correlated quantities such as flow or temperature.
5 — Command slowly when uncertain
Bad data turned into fast action can amplify the problem. Depending on risk, rate-limiting commands, holding a stable configuration, or requiring independent confirmation can be safer.
The choice depends on dynamics: explosive leakage permits less delay than a slow thermal drift.
6 — Preserve decision traceability
Raw values, quality flags, software versions, and commands must be logged. After an incident, engineers should reconstruct what the system believed and why it acted.
Without traceability, intermittent faults become extremely difficult to diagnose.
Compare a disagreement with known tolerance
LEARNING CALCULATION — ASSUMPTIONS ARE EXPLICIT
LEARNING ASSUMPTION: two sensors read 101.2 and 101.3 kPa; a third reads 98.0 kPa.
C minus mean(A,B) ≈ 98.0 − 101.25 = −3.25 kPa. If normal scatter is only ±0.2 kPa, the discrepancy is far larger than expected noise.
That triggers investigation, not the automatic conclusion “C is wrong”. A common cause might affect A and B.
Decision questions specific to this risk
- What uncertainty is normal for each sensor?
- Do agreeing instruments share power, manifold, or calibration?
- Which safe mode exists when state confidence collapses?
- Which independent quantity can confirm the diagnosis?
- Can logs reconstruct each command after the event?
The system must know when it no longer knows
When two critical sensors disagree, the worst response is to automatically choose the value that looks most plausible. A plausible value can still be wrong. The control system therefore needs an explicit uncertainty state: measurements are inconsistent, confidence falls, and some automatic actions become unavailable until an independent source resolves the conflict.
Health monitoring must cover not only the measured value but also the chain that produced it: power, communications, drift, update rate and consistency with other physical variables. The aim is not to manufacture truth by voting; it is to expose contradictions before they become unsafe commands.
Test software with realistic lies
A serious validation campaign does not feed software only clean data. It injects representative faults: frozen values, delayed data, abnormal noise, intermittent loss, slow drift or sensors that disagree during a maneuver. Engineers then observe whether the system detects the fault, enters a safe mode and explains its reasoning well enough for the crew.
On Mars, that capability must remain locally testable. A settlement cannot depend on an Earth team to reproduce every anomaly. Test benches, simulators and event logs allow scenarios to be replayed and help verify that a software update has not silently removed an older protection.
Main primary sources
Connect to other dossiers
When two instruments stop telling the same story
A sensor is never absolute truth. It has range, noise, possible drift, calibration history and failure modes. When two critical measurements diverge, the answer is not simply to average them: the system must ask which instrument remains credible, whether a real phenomenon could explain the difference, and which decisions remain safe while uncertainty persists.
A settlement therefore needs independent references, consistency tests and degraded modes. A physically impossible reading, implausibly fast change or contradiction with a third phenomenon can raise suspicion. Yet an over-aggressive algorithm can also reject a real emergency. Safety logic must be tested against both false positives and false negatives.
Software can be the common failure
Even three diverse sensors are insufficient if one software path misinterprets all of them. Unit errors, numeric saturation, bad calibration tables or defective updates can turn correct measurements into one shared wrong decision. Diversity must therefore include computation paths as well as instruments.
A Mars habitat should retain fallback ways to inspect raw data, use a simpler backup logic, rely on independent physical limits and freeze an automatic command that has become suspect. The goal is not complete manual control; it is keeping a way to verify what automation believes it knows.
Test disagreement before Mars
Tests should deliberately inject drifting, frozen, contradictory and intermittent sensors. Engineers then observe which alarm appears, which value is selected, which function is inhibited and how much time the crew has to understand the situation. An architecture tested only with perfect sensors has not truly tested autonomy.
Digital twins and crew simulations should also include incomplete and conflicting information, because real crises are often difficult not because information is absent but because confidence in it is uncertain.