1 — The concrete scene
A sensor reports a physically impossible value. Software must decide whether it is a real hazard, failed sensor or transient, then choose a safe response.
The key point is never to isolate this subject from the rest of the spacecraft. A local change often moves mass, power, heat, data, software, testing or risk elsewhere in the system.
2 — Essential words, explained before using them
Before calculating, we define every word that will be used next. The goal is for the symbol to come after the idea, never before it.
- State
- Logical configuration allowing certain actions.
- Watchdog
- Monitor expecting a sign of life.
- FDIR
- Fault Detection, Isolation and Recovery.
- Redundancy
- Additional means able to take over a function.
- Common cause
- Dependency able to defeat multiple channels.
- Safe mode
- Simplified state prioritising survival and diagnosis.
3 — See the architecture before calculating
Detection
Thresholds, consistency, voting and timeouts.
Isolation
Identify likely region, not merely raise an alarm.
Recovery
Retry, restart, switch or disable.
Safe mode
Reduce complexity to preserve power, thermal control and communication.
4 — Formulas, only when they answer a question
A formula is useful only if we know which question it answers, what every symbol means, and which units must be used.
Here, understanding the system matters more than one equation. We reason with states, interfaces, margins and success criteria.
5 — What units and margins mean
Thresholds keep the monitored unit; timeouts use s or ms. Logic should state value, duration and applicable state.
6 — Three concrete demonstrations, calculated step by step
Timeout
Exceedance 0.2 s, logic requires 2 s.
0.2 s observed
2 s required
0.2<2: no trigger
Sensor vote
21.0 °C; 21.3 °C; 85 °C.
Two close
One far away
85 °C channel is suspect, root cause not proven.
Degraded mode
Two computers, one lost.
Before=2 channels
After=1 channel
Function maintained, further fault tolerance lost.
7 — Deepening: what the simplified diagram hides
State machines
Explicit transitions reduce implicit behaviour.
False alarms
Too sensitive and too permissive are both risks.
Diversity
Identical copies can share the same design error.
Restart
A coherent state must be restored after reboot.
Validation
Simulation and hardware-in-the-loop test rare cases.
8 — Application to an Earth-Mars spacecraft
On an Earth-Mars transit, long duration turns a small weakness into cumulative risk: ageing, drift, consumption, cycles and maintenance become as important as nominal performance.
Communication delay forces the vehicle and possibly the crew to diagnose and reconfigure locally. Design must therefore remain observable, understandable and testable in degraded modes.
9 — Reference dossier: what a real project must still consider
This section deliberately goes beyond the introductory calculation. It connects the concept to interfaces, failures, testing, duration and maintenance so the lesson can serve as a reference chapter rather than a revision card.
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.
10 — Common traps and bad intuitions
- Thinking two identical copies remove common cause.
- Using restart as universal response.
- Creating a safe mode never tested end-to-end.
11 — Guided exercises
Question : What question comes before choosing hardware?
Question : Why is a nominal result insufficient?
12 — What to remember
- Explain the topic in simple words before symbols.
- Connect at least four interfaces with other subsystems.
- Redo the three numerical examples without reasoning gaps.
- Identify at least three limits or failure modes absent from the ideal calculation.
13 — NASA sources for further study
Primary institutional sources used to check the lesson structure. Teaching-number examples are identified as such.