5.5.26 · D3Embedded Systems & Real-Time Software

Worked examples — Fault tolerance — fail-safe vs fail-operational

3,177 words14 min readBack to topic

This page is a drill sheet. The parent note gave you the formulas; here we hit every kind of input those formulas can face — the tiny, the huge, the "what if a number is zero", the trick question. Work each one before you read the steps.

Every example is broken into exactly three numbered steps (setup → core computation → finish), each with its own "Why this step?", so the rhythm never changes.


Two names you must not confuse

Before the matrix, pin down two acronyms this page uses side by side:


The scenario matrix

Before any numbers, let us list what can vary in a fault-tolerance problem, so we never meet a case we did not rehearse.

The two engines of this whole topic are:

Every symbol here was earned in the parent note. If any feels unfamiliar, pause and re-read it — we build on top now.

Here is the grid of case classes this topic can throw at you:

# Case class What is being stressed Covered by
A (almost all failures detected) fail-safe upper limit Ex 1
B (nothing detected) — degenerate division by the whole ; no benefit Ex 2
C / middling detection realistic industrial value Ex 3
D TMR early life ( small) where redundancy wins Ex 4
E TMR long run () — limiting value the surprising MTTF result Ex 5
F TMR vs single unit crossover when redundancy stops helping Ex 6
G Real-world word problem (choose a strategy) judgement, not arithmetic Ex 7
H Exam twist: mixing "2-out-of-3" the wrong way catching a sign/counting error Ex 8

We now walk A → H, one example per cell. Related machinery lives in Redundancy patterns (N+1, TMR, DMR), Safety Integrity Levels (SIL), and Watchdog timers and health monitoring — link out when a step leans on them.


[!example] Example 1 — Cell A: near-perfect detection ()

Statement. A pressure sensor fails at rate per hour. Diagnostics catch of failures and drive the valve to a safe (closed) state. Find MTTDf and say how many years that is.

Forecast: Guess first — will detecting 99% of failures buy you a little safety or a lot? Hold that number in your head.

  1. Split the failure rate. The dangerous slice is . Why this step? Only undetected failures are dangerous — detected ones already steered you safe. So we throw away 99% of before we even start.

  2. Invert to get the mean time. MTTDf . Why this step? For a constant-rate process, mean-time-to-event is exactly the reciprocal of the rate (this is the from the parent note).

  3. Convert to years. Divide by hours/year. Why this step? A rate in "per hour" gives a time in hours; humans reason in years, so we rescale by the hours in a year to make the "1141-year" safety claim legible. The unit conversion never changes the physics, only the readout.

Verify: Undetected fraction went from to — a shrink of — so MTTDf grew over the "detect nothing" baseline of h. Units: . ✓ Detection is enormously powerful — see Ex 2 for the opposite extreme.


[!example] Example 2 — Cell B: the degenerate case

Statement. Same sensor, /h, but the diagnostics are disconnected: . What is MTTDf now?

Forecast: With zero detection, does the formula blow up, break, or just give a plain number?

  1. Plug . . Why this step? Every failure is now dangerous — there is no safe branch at all. The system is no longer "fail-safe"; it is just a bare component, so MTTDf collapses onto plain MTTF.

  2. Invert. Why this step? Same reciprocal-of-rate rule as Ex 1 — but now the rate is the whole , because nothing was subtracted off.

  3. Convert to years. . Why this step? The formula does not divide by zero — the danger divided by only becomes infinite when , not . At MTTDf simply equals the raw MTTF , a finite, legible number of years.

Verify: Compare to Ex 1: turning detection off drops MTTDf from to — exactly the factor we gained before, now surrendered. ✓ The true blow-up () means "a system that never fails dangerously" — an idealisation, so the math correctly sends MTTDf to only there.


[!example] Example 3 — Cell C: realistic middling detection

Statement. An industrial actuator: /h, and typical self-test coverage . Find and MTTDf in years.

Forecast: 60% coverage sounds decent — will it clear the "1000-year" bar from Ex 1?

  1. Dangerous rate. . Why this step? of failures slip through undetected, so we keep only that slice of .

  2. MTTDf in hours. . Why this step? Reciprocal-of-rate again — the single move that turns any dangerous rate into a mean time.

  3. Convert to years. . Why this step? Rescale hours to years for a human-readable safety horizon, exactly as in Ex 1.

Verify: Only years — far below Ex 1's . Lesson: below you are barely in the safe game; the Safety Integrity Levels (SIL) tables demand very high for exactly this reason. Units check: h. ✓


[!example] Example 4 — Cell D: TMR early life (redundancy's home turf)

Statement. Three identical flight computers, /h. Evaluate at (early in the mission). Compare a single unit's survival to the TMR survival.

Forecast: Three copies instead of one — how much smaller does the failure chance get?

Figure — Fault tolerance — fail-safe vs fail-operational
Figure (Ex 4): reliability (vertical, survival probability) versus dimensionless age (horizontal). The chalk-blue curve is a single unit ; the chalk-pink curve is the TMR system. The dashed yellow line marks the evaluation point , where the pink dot () sits clearly above the blue dot () — the vertical gap between the dots is the reliability that redundancy buys early in life.

  1. Single unit. . Why this step? One component survives with the bare exponential — this is the chalk-blue baseline curve in the figure, our yardstick to beat.

  2. TMR exact. Use the master formula with : Why this step? First term = all three alive; second term = exactly one dead but the two survivors still out-vote it. This is the chalk-pink curve sitting above the blue one at the dashed line — that height difference is what redundancy bought.

  3. Read off the failure chances. Single fails ; TMR fails . Why this step? "Reliability" is survival probability, so the failure chance is one minus it — the number a safety case actually cares about. We compute both so the win is stated in the language ("chance of losing the box") that engineers argue over.

Verify: and ; the ratio improvement. ✓ This is the whole point of Redundancy patterns (N+1, TMR, DMR) — big wins where is small.


[!example] Example 5 — Cell E: the long-run limit (the surprise)

Statement. For the same TMR system, compute the MTTF (mean time to failure of the whole voted system) as a multiple of . Is it bigger or smaller than a single unit?

Forecast: Three components — surely the average lifetime is longer than one? Bet on it, then read.

Recall The reliability we are integrating (from Ex 4)

Same curve plotted in the Ex 4 figure — no need to flip back.

  1. Integrate the reliability. MTTF is the area under ; first expand the product into clean exponentials: Why this step? Mean lifetime = area under the survival curve (the same identity used for MTTDf in Ex 1). We expand first so every term is a pure exponential we can integrate with one rule.

  2. Integrate term by term. Use for any positive constant (here ): Why this step? Each exponential decays to zero, so its total area is just the reciprocal of its decay rate — that single fact does all three integrals at once.

  3. Combine over . Put all three fractions on the common denominator and add: Why this step? The three pieces have denominators , , ; is their least common multiple, so rewriting each over lets us add the numerators directly and collapse to a single clean fraction.

Verify: — TMR's mean lifetime is shorter than a single unit's ! Why? With no repair, TMR has more components that can accumulate the two failures needed to kill it, and the voter itself is unforgiving late in life. Redundancy helps early (Ex 4), not on average lifetime. See Ex 6 for the crossover point. ✓


[!example] Example 6 — Cell F: where does TMR stop helping?

Statement. Find the time (as a multiple of ) where TMR reliability equals a single unit's — beyond which redundancy is actually worse.

Forecast: Somewhere between "early" and "forever" the two curves must cross. Guess: before or after ?

Figure — Fault tolerance — fail-safe vs fail-operational
Figure (Ex 6): the same two curves as Ex 4 but over a longer age range — reliability (vertical) versus (horizontal), chalk-blue = single unit, chalk-pink = TMR. The dashed yellow line marks the crossover at , where the yellow dot sits on both curves at once. Left of it the pink (TMR) curve is higher (redundancy wins); right of it the blue (single) curve is higher (TMR is now worse).

  1. Set them equal with a substitution. Let (so , decreasing in ), giving Why this step? Substituting turns the exponentials into a plain polynomial we can solve by hand — no calculator needed.

  2. Reduce to a quadratic. Simplify , then divide by : Why this step? Every term contains , and for any finite time, so dividing by is legal and drops the cubic to a quadratic we recognise.

  3. Solve and back-substitute. or . Discard (that is , trivially equal); take : Why this step? The quadratic gives both intersection heights; only is the meaningful crossover, and undoing the substitution with the natural log recovers the actual time.

Verify: Just before (Ex 4 was at ) TMR led — consistent. In the figure the curves meet exactly at , then blue overtakes pink. ✓ Real systems avoid the "worse" region by adding repair/replacement (Real-time scheduling with fault recovery) so they never sit past .


[!example] Example 7 — Cell G: pick the strategy (word problem)

Statement. You design the controller for a drawbridge over a shipping canal. If the controller faults, which strategy — fail-safe or fail-operational — and why?

Forecast: Think: what is the worst outcome of doing nothing vs doing something wrong?

  1. Ask: is loss-of-function safe or dangerous? If the bridge simply stops moving and stays put, no ship is crushed and no car drives into a gap. Why this step? This is the single decision rule of the whole topic — before any redundancy math (Common-mode failures and diversity aside), you first classify whether doing nothing lands you in a safe state.

  2. Compare the two failure costs. Doing nothing (bridge frozen) = traffic delay. Doing something wrong (bridge opens under a car / closes on a ship) = catastrophe. Why this step? Fail-safe is correct precisely when no-action is cheaper than wrong-action; here the two costs are wildly asymmetric, which decides the design.

  3. Commit to fail-safe and spell out the mechanism. On any detected fault → clamp the bridge in its current position, drop the road barriers to RED, sound the alarm, and require a human reset before motion resumes. Why this step? We turn the judgement into hardware: spring-loaded brakes that engage on power loss (just like the railway signal relay in the parent note's Example 1) guarantee the safe state even if the software is dead, so no code defect can move the bridge unsafely. That physical default is what makes the choice trustworthy, not just the reasoning.

Verify: Contrast with an aircraft where freezing controls kills everyone — that one must be fail-operational. Same decision rule, opposite answer, because there "doing nothing" is the catastrophe. ✓ No arithmetic here, but the judgement is the exam's real target.


[!example] Example 8 — Cell H: the exam twist (counting done wrong)

Statement. A student writes: "TMR fails only if all 3 units fail, so ." With per-unit failure probability over the mission, find the correct and how badly the student's shortcut misjudges the risk.

Forecast: Is "all three" the right count, or is it "two or more"? This is the classic slip — decide before reading on.

  1. State the true failure condition. A majority voter loses when it can no longer form a majority — that happens at 2 or more failed units, not 3. Why this step? Two bad units already out-vote the one good one, so the system is dead the moment the second failure lands. Counting only "all 3 bad" ignores every "exactly 2 bad" arrangement and therefore undercounts the ways to fail.

  2. Evaluate with . Why this step? Plugging the number shows the "exactly 2" term () dwarfs the "all 3" term () by three orders of magnitude — the piece the student threw away is essentially the entire answer.

  3. Compare to the student's shortcut. The student's , so their estimate is Why this step? Quantifying the error turns a subtle miscount into a safety-critical number: a design signed off on that is really has under-budgeted its risk by roughly 3000×.

Verify: Dominant term swamps , so ignoring the "exactly 2" case throws away 99.97% of the real risk. This matches the parent note's A320 figure ( per flight). ✓


[!recall]- Rapid self-test

What is the difference between MTTDf and MTTF?
MTTDf = mean time to a dangerous (undetected) failure (fail-safe metric); MTTF = mean time to any failure (reliability metric). They coincide when .
What makes MTTDf blow up to infinity — or ?
(all failures detected ⇒ zero dangerous rate).
At , what does MTTDf equal?
Just MTTF — finite, no benefit.
TMR MTTF as a multiple of ?
shorter than a single unit.
At what do the TMR and single-unit reliability curves cross?
.
Correct TMR failure probability in terms of per-unit ?
, not .
Drawbridge controller — which strategy?
Fail-safe (freezing is safer than wrong motion).