When redundant channels disagree, a predefined voting rule, not an ad hoc choice, decides which wins

What it is

Voting logic produces one system output when redundant channels disagree, using a predefined rule such as majority vote (2-out-of-3), weighted selection, or a direct transition to a safe state. It is also doing something equally important: defining the condition under which a given channel is formally declared to have failed.

Why it happens

For discrete states, majority voting can directly tolerate a limited number of random faults — two channels out of three agreeing is trusted over the third. Continuous quantities (temperature, pressure) are far messier: three sensors will almost never report exactly the same number, so a tolerance band must be defined first, alongside handling for channels sampling at slightly different times and for the slow drift sensors normally exhibit. If the voting rule demands exact equality to call channels "in agreement," it will misclassify ordinary measurement noise as disagreement and manufacture false alarms; set the tolerance too loose, and a genuine discrepancy gets quietly averaged away. The rule's second responsibility — deciding whether a rejected channel is isolated, kept in a degraded role, or escalated to a human decision — is itself a design choice that must be made explicitly, not a byproduct of the voting logic.

Where it stops holding

A majority is not the same as correct: if two of three channels share the same common cause (a systematic bias in the same sensor batch under a particular environmental condition), those two matching wrong readings outvote the one correct reading, and the voter confidently accepts the wrong side. All channels can also share the same bias, in which case "high agreement" as the voting logic sees it is the most dangerous signal rather than the most reassuring one. A small misalignment in sampling time between channels can also manufacture apparent disagreement on a fast-changing quantity that is really just a timing mismatch, not a genuine discrepancy. Handing the decision to a human is limited by whatever evidence and time that person has — a human cannot be expected to react faster than the voting logic itself.

Applying it

Specify explicitly the number of channels required to vote, the allowed tolerance, the comparison time window, the default treatment when a channel is declared failed, and the rule for reintegrating a recovered channel back into voting.

• How to check: inject readings near the tolerance boundary, slow drift, sampling misalignment from communication delay, and a deliberately designed common-cause fault, and verify voting behaves as intended in each. The interface must show each channel's raw input, the accepted result, and the specific reason a channel was rejected — not just the number that came out of voting.

Related

• Same group: Y4.02.1 Redundant channels for fault tolerance · Y4.02.3 Voter as a single point of failure · Y4.02.4 Operator-visible sensor disagreement
• Nearby: Y4.06 Safety integrity levels · Y3.08 Setpoint and process-value comparison
• Search terms: Voting logic for discrepant channels · functional safety · safety-critical systems