The voter that reconciles redundant channels is itself one piece of hardware that can fail

What it is

The voter concentrates several redundant channels into one final decision, and that concentration is itself implemented by specific hardware, software, and a body of requirement logic — so the voter going wrong, whether through hardware damage, a software defect, or a mistaken requirement, can become a new, common single point of failure. Three fully reliable channels can still have all their redundancy benefit cancelled out if the single step that combines them is wrong.

Why it happens

A centralized voter typically shares one power supply, one clock source, one body of parsing code, and one output path — meaning a single wrong threshold or timing defect inside the voter acts on every input channel at once, unlike a channel-level fault that affects only one path. This is an easily overlooked architectural blind spot: designers often pour effort into keeping three input channels independent while treating the single logic step that combines them as an obviously correct "last step" — when in fact that step is the most concentrated point in the entire redundant architecture. Monitoring the voter itself, distributing voting logic across independent implementations, or implementing the voting algorithm diversely in different ways are all techniques to reduce this concentration risk, but each introduces its own new problem — if multiple voting implementations disagree, deciding whose result should finally be trusted needs yet another layer of arbitration.

Where it stops holding

Not every architecture has a single physical voter you can point to — in some designs, the "voting" function is distributed across each actuator's local logic, or implicit in a communication protocol's arbitration rule, and reviewing voter risk in those cases cannot focus only on a single piece of visible voting hardware. Also, cross-checking with two or three voting implementations only helps if those implementations are genuinely diverse; if they replicate the same flawed logic, what looks like multiple voting is really sharing the same error with a single voter, and delivers no real independence.

Applying it

Treat the voting function itself as a distinct item in fault-tree analysis and safety integrity allocation, and specifically review its requirement definition, timing logic, numeric overflow handling, and what failure state it should output if the voter itself fails.

• How to check: inject a stuck voter, a deliberately incorrect majority decision, and out-of-order arrival of input data, and verify whether the system falls back on a bypass or degraded path. Specifically check whether that bypass or degraded path itself introduces a risk larger than the voter fault it is meant to cover — do not assume "there is a backup logic" automatically means "safer."

Related

• Same group: Y4.02.1 Redundant channels for fault tolerance · Y4.02.2 Voting logic for discrepant channels · Y4.02.4 Operator-visible sensor disagreement
• Nearby: Y4.06 Safety integrity levels · Y4.01 Fail-safe and fail-operational strategies
• Search terms: Voter as a single point of failure · functional safety · safety-critical systems