Exercises — Fault tolerance — fail-safe vs fail-operational
This page is a graded ladder. Work each problem before opening its Solution. Every symbol used here is built in the parent — if you feel lost, revisit the parent topic first.
Quick symbol refresher (so you never hit an undefined term):
Level 1 — Recognition
L1.1 — Which strategy?
For each system, name fail-safe or fail-operational, and give the one-line reason: (a) A gas boiler's flame sensor. (b) A pacemaker. (c) A factory conveyor E-stop. (d) A commercial jet's fly-by-wire.
Recall Solution
- (a) Fail-safe. If the flame sensor is unsure, cutting the gas valve is safer than pumping unlit gas. Loss of function (no heat) < incorrect function (gas leak/explosion).
- (b) Fail-operational. A pacemaker that shuts off = the heart may stop. It must keep pacing through faults, so it needs redundancy.
- (c) Fail-safe. E-stop de-energizes and clamps the belt. Stopped conveyor is safe; a runaway one is not.
- (d) Fail-operational. Losing flight control at cruise is catastrophic; the plane must keep flying with remaining computers.
Rule of thumb: ask "Is doing nothing safe?" If yes → fail-safe. If no → fail-operational.
L1.2 — Read the equation
The parent gives . In plain words, what are and , and which one do we want small?
Recall Solution
= rate of safe failures (detected, sent to safe state). = rate of dangerous failures (undetected, can cause harm). We want small — dangerous failures are the only ones that hurt people. Total is fixed by the hardware; the design goal is to shove as much of it as possible into the bucket (raise ).
L1.3 — Match the pattern to the count
Match: N+1, DMR, TMR to "2 units, cross-check", "3 units, majority vote", "one spare beyond what's needed".
Recall Solution
- DMR (Dual Modular Redundancy) → 2 units, cross-check (detect a disagreement, but can't tell which is wrong alone).
- TMR (Triple Modular Redundancy) → 3 units, majority vote (2 vs 1 identifies the liar).
- N+1 → one spare beyond the number actually needed.
See Redundancy patterns (N+1, TMR, DMR).
Level 2 — Application
L2.1 — MTTDf of a smoke detector
A detector has and safe failure fraction . Find and the Mean Time To Dangerous Failure in hours and in years ().
Recall Solution
. . In years: . Why the integral formula works: . The area under the survival curve is the mean lifetime — a wide, slow-decaying curve (small ) has huge area = long life.
L2.2 — Two-out-of-three reliability at a point in time
Three FCCs, each , flight time . Using (probability one unit has failed), compute and .
Recall Solution
, so . "At least 2 of 3 work" = NOT ("2 or 3 failed"). System fails only if fail: . Why drop ? It is — a millionth of the term. Keeping it changes no decimal that matters.
L2.3 — Deadline check
A fail-safe pressure controller must reach its safe state within . The watchdog fires every , and it takes at most missed kicks to declare a fault plus to open the vent valve. Does it meet the deadline?
Recall Solution
Worst case: fault occurs just after a kick, so up to passes before the first miss; then missed kicks to declare = ... but the standard count is from fault to declaration. Detection latency , then actuation : total . → meets the deadline (with margin). See Watchdog timers and health monitoring. Why margin matters: with only slack, any clock jitter or an extra missed kick blows the budget. A safe design targets margin, not a bare pass.
Level 3 — Analysis
L3.1 — When does TMR beat a single unit?
Single-unit reliability is . TMR is . Find the value of where the two curves cross (below which TMR wins). Look at the figure.

Recall Solution
Set : . Let (so ): Roots (, trivial) and . So the meaningful crossover is . Read the figure: for (early life, left of the crossing) TMR is above the single line — it's more reliable. For the extra components (3× the parts, 3× the failure exposure) drag it below. TMR buys early-life reliability, not longevity.
L3.2 — Why MTTF of TMR is only
Integrate from to to confirm , and explain why it's less than the single-unit .
Recall Solution
and . Single unit: . So TMR's average life is shorter (). Why: without repair, TMR degrades to a 2-of-3 that then can't survive the next failure; after the second failure it's dead. It trades away the long, thin tail (where a lone unit occasionally survives a long time) for a fat, safe early survival hump. Average-of-lifetime hides the whole point — early reliability is what safety cares about.
L3.3 — Diagnostic coverage lifts
A controller has raw . Adding a self-test raises detection so that goes from to . By what factor does MTTDf improve?
Recall Solution
Before: . After: . , so improvement factor . Interpretation: a 40× longer time between dangerous failures — without touching the hardware's raw quality, purely by making failures self-revealing. This is exactly why Safety Integrity Levels (SIL) reward high diagnostic coverage.
Level 4 — Synthesis
L4.1 — Design a hybrid strategy
An autonomous shuttle drives at in a pedestrian zone. Sketch a fault-tolerance architecture: which functions are fail-operational, which are fail-safe, and where you put redundancy vs. diversity.
Recall Solution
- Fail-operational (must keep working long enough to stop safely): steering + braking actuation, ego-localization, the "come to a controlled stop" trajectory planner. Use TMR or DMR+diverse-monitor so one compute fault doesn't drop control mid-manoeuvre. This is the minimal safe stop capability — it must survive one fault.
- Fail-safe (graceful shutdown is acceptable once stopped): the full autonomous driving stack (perception, routing). If it faults, degrade to the fail-operational "safe stop" lane, brake to a halt, hazard lights on.
- Redundancy vs diversity: use redundancy (identical units) for random hardware faults; use diversity (different sensors/algorithms — camera + LiDAR + radar; two independently-written planners) to beat common-mode software bugs that would kill all identical copies at once.
- Architecture in one line: fail-operational down to the minimal "controlled stop," then fail-safe by executing that stop. This "fail-degraded-then-safe" pattern is the industry norm for L4 vehicles. See Real-time scheduling with fault recovery for making the safe-stop task meet its deadline.
L4.2 — Choose the SIL
A machine's hazard causes serious injury; it's exposed constantly; escape is hard; the demand rate is low (a few operations/day). The risk graph points to SIL 3, which requires (average probability of failure on demand). Your single channel gives . Propose a fix and estimate the new PFD (assume independent channels multiply).
Recall Solution
Single channel PFD — far short of . Use 1oo2 (two independent channels, either can trip): a dangerous failure needs both to fail dangerously. If independent, . Still above . Add a third independent channel or improve each channel's PFD. E.g. three independent channels: ✓. Caveat / the real engineering: you cannot assume perfect independence — common-mode failures put a floor under the product (the β-factor model). So use diversity across channels, not clones. See Safety Integrity Levels (SIL).
Level 5 — Mastery
L5.1 — Diverse pair vs identical pair under common-mode
Two channels each have random-fault PFD . A common-mode fault (a shared bug/environment) hits both at once with probability , independent of the random faults. Model system dangerous-failure probability as (both random-fail, OR common-mode). Compute it for the identical pair. Then a diverse pair reduces to (different code, different sensor). Compute the diverse PFD and the improvement factor.
Recall Solution
Identical: . Note the common-mode term dominates () — the redundancy is being wasted because both copies share the same flaw. Diverse: . Improvement factor . Lesson: once you add redundancy, the residual risk is set by whatever the copies share. Diversity attacks that shared term — see Common-mode failures and diversity and Byzantine fault tolerance for faults where channels actively disagree.
L5.2 — Voter as a single point of failure
TMR relies on a voter. Suppose each channel has reliability and the voter has reliability . Write the true TMR-with-voter reliability, and state the condition on for the voter not to dominate the failure budget.
Recall Solution
The voter sits in series with the voted core: everything must survive AND the voter must survive. Because it's a series element, its failures add linearly () while the voted core's failures are quadratic (). For the voter not to dominate we need its linear term below the core's quadratic term: The deep point: a cheap, un-redundant voter can silently become the system's single point of failure — the very thing TMR was meant to remove. This is why safety-critical voters are themselves made simple, formally verified (see Formal verification of safety properties), or replicated. Verify the whole chain with Hardware safety mechanisms and Byzantine fault tolerance in mind.
Recall Self-test checklist
Ask "is doing nothing safe?" ::: yes → fail-safe; no → fail-operational ::: , the dangerous (undetected) failure rate When does TMR beat a single unit? ::: for (early life) ::: — less than a single unit's What sets residual risk after adding redundancy? ::: the common-mode term the copies share — attack it with diversity Why can a voter ruin TMR? ::: it's a series element; its linear failure rate can dominate the core's quadratic one