Exercises — Redundancy — TMR (triple modular redundancy), voting logic
This page is a self-testing ladder. Each problem is stated cleanly, then hidden behind a collapsible Solution callout — try it first, then reveal. We climb from recognising what TMR is (L1) up to mastering the reliability trade-offs and voter design (L5). Everything here builds on the parent TMR note — if a symbol looks unfamiliar, it was defined there, and we re-anchor it below when it matters.
Two symbols you must have firmly in hand before starting:
The master formula we lean on repeatedly:
Level 1 — Recognition
Exercise 1.1
Three modules output the binary values , , . What does a majority voter output?
Recall Solution
What we do: count how many of the three outputs are . Two ones () and one zero. A majority voter returns the value shared by at least two inputs. Two agree on , so the output is . The lone from is masked — hidden from the system.
Exercise 1.2
A single module has reliability . Without any formula, is a TMR system built from three such modules likely to be more or less reliable than one module? Give the one-line reason.
Recall Solution
More reliable. Because , each module is much more likely to work than to fail, so it is rare that two fail at once. The voter only needs two good modules, so it almost always sees a correct majority. (We prove the number in L2.)
Exercise 1.3
Which of these can TMR do? (a) mask one faulty module, (b) tell you which module failed, (c) tolerate two simultaneous faulty modules.
Recall Solution
Only (a).
- (b) is false: TMR masks faults, it does not diagnose them — you know someone disagrees, not who (add Watchdog Timers or self-checking pairs for that).
- (c) is false: if two of three go bad, they can outvote the one good module. TMR tolerates exactly one faulty module.
Level 2 — Application
Exercise 2.1
Each module has . Compute using .
Recall Solution
What we do: substitute into the master formula. Why it matters: the failure probability dropped from (single) to (TMR) — a improvement, bought with the hardware.
Exercise 2.2
Each module has . What is the TMR failure probability ?
Recall Solution
, and . Why this is the headline number: a single module fails with probability ; TMR fails with probability — about safer. The better your base modules, the more dramatically TMR pays off, because two-out-of-three simultaneous failures become astronomically rare.
Exercise 2.3
Three temperature sensors read , , . Apply exact majority voting. What is the output, and which reading is masked?
Recall Solution
What we do: look for two equal readings. . Two agree on , so output . The reading is masked — it is the outlier (likely a calibration/bias fault). The system proceeds with the trusted majority value.
Level 3 — Analysis
Exercise 3.1
Each module has . Compute and compare it to the single module. Explain the sign of the difference.
Recall Solution
, . Single module reliability is . Since , TMR is worse. Why: when each module fails more often than it works, so it is common for two modules to fail together and outvote the one good one. Redundancy amplifies unreliability instead of curing it. The figure below makes this crossover visual.
Reading the figure below. The horizontal axis is the single-module reliability (from to ); the vertical axis is the resulting system reliability. The violet straight line is what you get with one module (the baseline — system reliability just equals module reliability). The magenta curve is TMR. The two lines cross at the orange dashed line (the black dot). To the right of that dashed line the magenta curve sits above the violet line — TMR wins (shaded region "TMR helps"); to the left, magenta dips below violet — TMR loses (shaded "TMR hurts"). The violet square marks our worked point , comfortably in the winning region; this exercise's sits in the losing region.

Exercise 3.2
Find the value of where (the "crossover" reliability where TMR neither helps nor hurts, other than the trivial endpoints and ).
Recall Solution
What we do: set and solve. Factor the quadratic: . Interpretation: the interesting crossover is — exactly the orange dashed line in the figure above. Above it TMR helps (); below it TMR hurts. This is the critical-threshold claim from the parent note, now derived rather than asserted.
Exercise 3.3
Three analog outputs are , , . Compare the average voter with the median voter. Which masks the fault?
Recall Solution
First, the key idea: for quantitative (real-valued) outputs, the median is the direct generalization of majority voting. Binary majority picks the value that "most" modules share; when values are continuous and rarely match exactly, the median picks the middle value, which by construction lies with the cluster that at least two modules landed near — the same "trust the majority, discard the lone dissenter" logic, just measured by position instead of exact equality.
Average: (to 2 dp). The wild drags the answer far from the two sane readings. Median: sort to , take the middle . The outlier is ignored entirely. Why median wins: the median only cares about ordering, not magnitude, so a single arbitrarily large fault cannot move it beyond one position. The average is a sum, so one huge value poisons it. For fault masking, use the median.
Level 4 — Synthesis
Exercise 4.1
Design the Boolean majority gate for binary inputs . Write the expression, then verify it against the input row .
Recall Solution
What we do: the output is iff at least two inputs are . Each pair agreeing on is an AND term; "any pair" is an OR: Verify on : Correct — two ones present, so majority is . (Here is logical OR and juxtaposition is AND.)
Exercise 4.2
The voter itself is a physical component with reliability . The three modules each have . Assuming the system works only if (the module majority holds and the voter works), write and evaluate the full system reliability.
Recall Solution
What we do: two independent things must both succeed — the majority of modules, and the voter. Independent successes multiply. Why this matters: the voter is a single point of failure — if it dies, all the module redundancy is worthless. That is exactly why real TMR voters are hardened or themselves triplicated. Notice : the voter can only subtract reliability.
Exercise 4.3
You have modules with . Would you rather (a) build TMR from three of them, or (b) spend the same effort making one module reach ? Justify numerically.
Recall Solution
TMR path: . Better-single path: by assumption. Since , the better single module wins here on pure reliability — and it uses hardware and power instead of . Nuance: TMR still buys you tolerance to transient faults (cosmic-ray bit-flips) that improving one module cannot, because you cannot screen out a random future event. So the honest answer is: fix base reliability first (parent-note advice), then add TMR for the residual transient risk you can't design away.
Level 5 — Mastery
Exercise 5.1
Two of the three modules share a hidden common-cause defect: with probability they both fail together (a single correlated event knocks out and at once). To keep the arithmetic clean, we make the modelling assumptions explicit: apart from that shared event, and have negligible independent failure probability, and fails independently with probability . Under these stated assumptions, estimate the probability the system loses its majority.
Recall Solution
State the model first (this is the point of the exercise):
- Common-cause event fires with and kills both and .
- By assumption have no other failure route, so if does not fire, both are healthy.
- fails independently with .
What we do: the majority is lost when two or more modules fail.
- If fires (prob ): and are both down → two failures → majority already lost, regardless of .
- If does not fire (prob ): under our stated assumption are healthy, so at most is down — only one failure → majority survives.
Therefore majority is lost iff fires: The lesson: a common-cause coupling completely dominates the design — it single-handedly caps reliability at , no matter how good the independent failure rate is (had we included small independent failures for , the answer would rise only slightly above , so the conclusion is robust). This is why Common-Cause Failures and Redundancy vs. Diversity matter: identical triplicated modules share identical flaws. Real safety systems use diverse implementations to break the correlation.
Exercise 5.2
Compare TMR against 5-modular redundancy (5MR) with per-module . 5MR survives if at least of modules work. Compute and state the qualitative gain.
Recall Solution
What we do: sum the binomial probabilities for "3 work", "4 work", "5 work" out of , with , . Recall . So 5MR pushes failure probability from down to — roughly safer, at the cost of hardware and a voter that tolerates two faults instead of one. Diminishing returns: doubling hardware from 3 to 5 did not double the safety margin.
Exercise 5.3
A mission needs system failure probability below . Your modules have . Does plain TMR meet the requirement? If yes, by how much margin; if no, what do you change?
Recall Solution
From Exercise 2.2, , so Requirement is . Since , plain TMR does NOT meet it — it misses by roughly . What to change (in order of leverage):
- Raise base : even a modest improvement is cubed-ish in effect. Try : , failure — easily passes.
- Go to 5MR (Ex. 5.2 style) if you cannot improve modules.
- Do not ignore the voter and common-cause terms — those, per Ex. 4.2 and 5.1, can dominate and silently blow the budget. Always fold them in before certifying against Safety-Critical Systems Standards.
Recall Quick self-quiz (reveal after finishing)
The TMR crossover reliability below which redundancy hurts ::: The majority-gate Boolean expression ::: Why median beats average as an analog voter ::: median ignores gross outliers; average is poisoned by them The component that is a single point of failure in TMR ::: the voter What caps reliability regardless of module count ::: common-cause (correlated) failures