Question bank — Redundancy — TMR (triple modular redundancy), voting logic

False. Only when each module's reliability $R>0.5$; below that, two flaky modules outvote the one good one more often than all three succeed, so $R_{\text{TMR}}<R$.

True. $R_{\text{TMR}}=R^2(3-2R)=0.25\times 2=0.5=R$, so the crossover point is precisely $R=0.5$ — the grey and blue curves in Figure 2 cross there, they don't just touch.

False. Two failures leave only one working module, which cannot form a majority; the voter has no 2-out-of-3 agreement and the system fails or halts.

False. It only tells you a minority disagreed; you know someone is wrong but not who without extra diagnostics like Watchdog Timers or comparison logic.

True. If the voter is a plain unreplicated circuit, its failure defeats all three modules at once — which is why voters are hardened or themselves replicated.

False. It is an assumption. Shared power supplies, clocks, or identical software bugs cause Common-Cause Failures that hit all three at once, breaking the independence the math relies on.

False. Identical software has identical bugs; all three produce the same wrong answer and the voter happily passes it. This needs design diversity, not mere replication.

True. Both discard the disagreeing minority: majority for binary values, median for continuous values — the median is the "middle vote" that outliers can't drag away.

Wrong. OR passes through a single faulty 1; the voter output $V$ must be a majority gate $V=M_1{M}_2+M_2{M}_3+M_1{M}_3$ (products = AND, bind first; $+$ = OR) so $V$ is 1 only when at least two agree.

Wrong for fault masking. Averaging lets one wild outlier skew the result (100,100,1000 → 400); the median (→100) ignores the faulty value entirely.

Only partly. That's a fail-incorrect fault; the voter masks it as long as just one module lies, but if two independently produce different wrong values, majority breaks — harder than fail-silent behaviour.

Not certain. The two agreeing modules could share a common-cause fault and be wrong together while the lone module is right — agreement is not proof of correctness.

Wrong. Analog noise means good sensors never match to the last bit; you need approximate voting within a tolerance window, else valid readings falsely "disagree".

Wrong. Too-large tolerance masks real faults by treating genuinely diverged values as agreement; tolerance must balance sensor noise against fault magnitude.

Wrong. Three-way disagreement is a consensus failure; a correct voter returns no-decision (or halts), because there is no majority to trust.

Wrong. Reliability is $R^2(3-2R)$, not $3R$. At $R=0.9$ you get $0.972$, not $2.7$ — reliability is a probability capped at 1, and the gain is far smaller than "3×".

An even count can tie (e.g. 2 vs 2), giving the voter no majority; an odd count guarantees one side always outnumbers the other for a single-value comparison.

The voter's output $V$ reveals only the majority value, not which inputs disagreed; without recording the minority you lose the information needed to diagnose the culprit.

A fail-silent module simply drops out, leaving a clean 2-out-of-2 majority; a fail-incorrect module actively injects a wrong value the voter must out-vote, and coordinated wrong values can defeat it — the essence of Byzantine Fault Tolerance.

Bit comparison is a fixed, fast, gate-level operation with predictable delay; floating-point equality is slower and subject to representation quirks unsuitable for tight real-time deadlines.

The derivation multiplies $R\times R\times R$ assuming independent failures; correlation means one event knocks out several modules together, so the true reliability is far lower than the formula predicts.

There are $\left(\genfrac{}{}{0ex}{}{3}{2}\right)=3$ different modules that could be the single failing one, so three distinct scenarios share that probability; "all correct" is a single scenario, so it needs no such count.

Identical copies share identical design flaws; diverse implementations fail differently, so they attack the common-cause and common-bug weaknesses that plain redundancy leaves wide open — see Redundancy vs. Diversity.

You physically run three copies of the computation, so hardware area, energy, and cost roughly triple; the reliability gain is bought with those resources, not conjured.

It outputs their agreed value as $V$ — a fail-silent third module still leaves a valid 2-of-2 majority, which is exactly the single-fault case TMR is built to survive.

Treat it as insufficient quorum — a lone survivor cannot form a 2-out-of-3 majority, so the voter must NOT blindly accept it; it should signal loss of redundancy and (in safety-critical use) halt or hand off to a safe state.

The voter masks that cycle instantly; the healthy pair carries the output, and the glitching module recovers next cycle — masking a transient is TMR's everyday job.

A single root event (shared power dip, common clock fault, identical software bug) can flip two or three modules the same way at once; the voter then sees a false "majority" of wrong values and confidently outputs garbage — the $R^2(3-2R)$ math no longer applies because it assumed independence, so real reliability collapses toward that of the shared component. This is why Common-Cause Failures must be engineered out, not just voted around.

Both approach 1, and the gap shrinks to zero — near-perfect modules gain almost nothing from voting, since there is little failure left to mask.

It approaches 0 (dominated by $3R^2$), and does so faster than the single module's $R$, confirming TMR is strictly worse for very unreliable parts.

Report no-consensus and raise an alarm; fabricating a "middle" value would hide a genuine multi-fault condition the operator must know about.

You need a way to combine the three voter outputs — pushing the single-point-of-failure question up one level — often resolved by driving separate actuators or a final hardened comparator.