Redundancy and Voting
How multiple channels combine into one trustworthy decision, and why more channels is not always safer.
Voting over channels
Redundant channels only help if a policy combines them safely. The classic scheme is triple modular redundancy with majority voting: three channels compute the same decision and the majority wins, tolerating any single fault. For protection functions the policy is often asymmetric - any channel may trip, but consensus is needed to continue - so a stuck-safe channel cannot block protection.
| Ch A | Ch B | Ch C | Trip? |
|---|---|---|---|
| 0 | 0 | 0 | 0 |
| 1 | 0 | 0 | 1 |
| 0 | 1 | 0 | 1 |
| 1 | 1 | 0 | 1 |
| 1 | 1 | 1 | 1 |
The table shows a fail-safe (1-out-of-3 to trip) protection vote: a single channel asserting trip is honored, which prevents a silent channel from masking a real fault. Control decisions instead use 2-out-of-3 majority so one noisy channel cannot cause spurious action.
def vote(channels, mode):
n = sum(channels)
if mode == 'protection': # fail-safe: any asserts -> act
return n >= 1
if mode == 'control': # majority
return n > len(channels) / 2
raise ValueError(mode)More is not free
Adding channels raises the odds that at least one is broken at any moment, so maintenance load grows and common-mode failure (shared power, shared fabric, shared design flaw) can defeat all channels at once. Good redundancy diversifies: different sensor principles, independent power, separate routing. Common-mode risk is called out explicitly in the diagnostics FMEA.
Voting is the decision layer above failover; failover switches which hardware runs, voting decides what the switched-together set concludes. Both feed the availability model as improvements to effective MTBF.