Measuring the same thing through several independent channels keeps one random fault from deciding the outcome

What it is

Channel redundancy uses multiple independent sensing, computation, or actuation paths to measure or execute the same thing, so no single random fault alone decides a safety function's outcome. It does reduce sensitivity to single-point failure — but that benefit is not automatic. Redundancy only delivers on its promised reliability when the channels are sufficiently independent, faults are detectable, and the logic combining multiple channels into one judgment is itself correct.

Why it happens

Agreement across channels raises confidence in the result; disagreement reveals that at least one channel has gone wrong — that is the basic logic redundancy relies on, and it holds only if each channel's faults are independent random events. Physically separating installation, using separate power supplies, and choosing sensors from different vendors or implementations all exist to suppress the probability that a single common cause knocks out multiple channels at once. Conversely, if three "redundant" sensors are just three copies of the same model, mounted in the same location, fed from the same power line, and calibrated by the same procedure, they look like three independent channels but actually share nearly every cause that could fail them together — once ambient temperature exceeds a threshold, all three can drift in the same direction at once, and their agreement in that moment is an illusion, apparent redundancy rather than real redundancy.

Where it stops holding

Redundancy addresses random hardware faults; it does nothing for a systematic requirement error — if the requirement itself is wrong (mistakenly treating some signal as the safety criterion), all channels will consistently follow the wrong requirement, and their agreement hides the error instead of exposing it. Redundant systems also add complexity and maintenance touchpoints as channel count grows, which is itself a new source of faults, so channel count cannot be converted directly into a safety gain — how independent the channels really are and how good diagnostic coverage actually is both need specific evidence, not an inference from the number of channels alone.

Applying it

Document the power supply, installation environment, software version, communication path, and maintenance ownership for each channel separately, then perform fault-tree and common-cause analysis on top of that record to explicitly list causes that could take down multiple channels at once.

• How to check: inject single-channel faults, a deliberately designed common-cause fault (subjecting all channels to the same directional environmental stress simultaneously), and a latent fault (already present but not yet caught by any detection mechanism), and verify in each case whether the system correctly detects and isolates the faulty channel while preserving the residual function it should. All three types of test are needed — testing single-channel faults alone cannot expose an apparent-redundancy problem.

Related

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