Visual walkthrough — Redundancy — TMR (triple modular redundancy), voting logic
This page builds the central TMR result — the formula
— from absolutely nothing. We start by asking "what does it even mean for a machine to work?" and end holding the picture of why three machines can beat one, and when they can't.
This is the visual companion to the parent topic. If you want the plain-language mirror, read the Hinglish note.
Step 0 — The model we are working in
WHAT. Fix, in one place, exactly what our three-machine system looks like — before touching any algebra.
WHY. Every formula on this page silently leans on these three assumptions. Writing them once, up front, means no step later has to sneak one in.
Step 1 — What "reliability " even means
WHAT. Zoom in on that one number everything rests on: ====, the reliability of a single module — the probability that one machine gives the correct output over the time window we care about.
WHY. We cannot talk about "three machines" until we can measure "one machine". Every later formula is just arithmetic on this single number, so it must be nailed down first. As a probability, can sit anywhere from to inclusive: means "never fails", means "always fails", and real modules live somewhere in between.
PICTURE. Think of each module as a weighted coin. It lands GOOD (correct output) with probability , and BAD (wrong or silent) with probability . The two slices of the coin must fill the whole circle — nothing else can happen.

For this whole derivation, treat as a fixed known number in — say . (Where that number comes from over time is a separate story handled in Fault Tolerance Fundamentals; here we just take it as given.)
Step 2 — What the voter demands: "at least 2 of 3"
WHAT. State the rule of the game precisely, and give the whole-system reliability its name. The TMR system outputs the right answer exactly when the majority is right — that means at least 2 of the 3 modules are GOOD.
WHY. The voter picks whatever value two or more modules agree on. So one bad module is harmless (the other two still form a majority). But two bad modules can outvote the lone good one. The magic line is therefore drawn between "2 good" (survive) and "1 good" (die).
PICTURE. A number line of "how many modules are GOOD": . Shade and green (system works), shade and pink (system fails). The whole derivation is: add up the probability of the green region.

Step 3 — Probability all three are GOOD
WHAT. Compute the first green piece: every one of the three modules is correct. (The names were fixed back in Step 0 — the little subscript is just a label picking out which of the three we mean.)
WHY. By the model of Step 0, the modules fail independently — one dying tells you nothing about the others — and that is exactly what lets us multiply probabilities. For independent events, "this AND that AND that" is the product of the individual chances.
PICTURE. Three GOOD coins in a row, labelled , , . Each contributes a factor ; laying them side by side multiplies.

Step 4 — Probability exactly two are GOOD
WHAT. Compute the second green piece: exactly two correct, exactly one broken.
WHY. This is the case TMR was built for — one machine lies, the other two mask it. Two things multiply into this probability: the chance of one specific pattern, and the number of patterns that look like "exactly one is bad".
PICTURE. There are three distinct ways to have exactly one BAD coin: the bad one can be , or , or . Each such row has probability — two GOOD (each ) and one BAD (that leftover slice ).

Step 5 — Add the two green pieces
WHAT. Sum the "3 good" piece and the "exactly 2 good" piece into the total reliability.
WHY. The two cases (all three good / exactly two good) cannot happen at the same time — they are mutually exclusive slices of possibility. For events that never overlap, the probability of "one OR the other" is just the sum. This is the payoff line of Step 2.
PICTURE. Two green bars stacking on top of each other to fill the "system works" region.

Step 6 — Simplify to the famous form
WHAT. Turn the sum into the clean textbook expression.
WHY. Cleaner algebra is easier to reason about, differentiate, and compare against . Nothing new is happening — just multiplying out and collecting like terms.
PICTURE. The messy expression on the left collapses, term by term, into the tidy one on the right.

Step 7 — Sanity check: does it actually help?
WHAT. Plug in a good module, , and compare TMR against a single machine.
WHY. A formula that doesn't beat the baseline is worthless. We must see the improvement, not just trust the algebra.
PICTURE. Two bars side by side: single module at , TMR taller at .

Step 8 — The dark side: when , TMR is worse
WHAT. Show the degenerate regime. Feed in a bad module, , and watch TMR lose.
WHY. The contract says cover every case — and this is the trap. If modules fail more often than they work, then two failures (which outvote the lone good module) become the common outcome. Redundancy amplifies unreliability instead of curing it.
PICTURE. The two curves (single) and (TMR) plotted together. They cross at exactly . Left of the crossing, TMR sits below the single line — the pink danger zone.

The one-picture summary
Every step collapses into one frame: three coins → count the GOOD ones → keep the "" region → add the two green slices → simplify → compare to the single-module line.

Recall Feynman retelling — say it back in plain words
Imagine one machine as a coin that lands "right" with probability . One coin, one chance — its reliability is just .
Now line up three such coins and let a referee (the voter) call the result "right" whenever at least two coins land right. There are only two ways to win: all three land right, or exactly two do.
All three right happens with probability , because independent coins multiply. Exactly two right can happen in three ways (any one of the three could be the odd one out), and each way has probability — two rights times one wrong. So that piece is .
Add the two winning pieces: . Multiply it out and it tidies up to . That single expression is TMR's reliability.
Test it: a good coin () gives — better than , so tripling paid off. A bad coin () gives — worse than , because two liars outvote one honest coin. The two curves cross at exactly . So the whole story is: redundancy multiplies whatever you already have — good modules get better, bad modules get worse.
Recall Quick self-test
The TMR formula in factored form ::: TMR only improves on a single module when ::: Why can we multiply for "all three good" ::: because the modules fail independently Where do the three copies of come from ::: the three ways to choose which single module is the bad one, The exact crossover value of where TMR equals a single module ::: (also and trivially)
Connects to
- Fault Tolerance Fundamentals — the broader family this belongs to.
- Common-Cause Failures — breaks the independence assumption of Step 3.
- Byzantine Fault Tolerance — what to do when a bad module lies cleverly instead of failing silent.
- Redundancy vs. Diversity — three identical modules share bugs; diversity fixes that.
- Watchdog Timers · Error Detection Codes · Safety-Critical Systems Standards — companion mechanisms in real systems.