When sensors disagree, the operator should see it, even while the voting logic quietly picks a value

What it is

Sensor disagreement means redundant channels measuring the same quantity produce results beyond a preset tolerance. Even while automatic voting logic continues to output a usable control value, that disagreement should itself be presented to the operator as a signal of degraded confidence and uncertainty — not silently absorbed by the system while the operator still sees a number that looks entirely certain and unremarkable.

Why it happens

The problem with silent arbitration — the voting logic resolving disagreement internally while the interface shows only the final result — is that it hides a critical fact: some of the redundancy has already been consumed. An operator who cannot see this keeps assuming the same margin of protection as usual, while the system may actually be relying on a single functioning channel with no redundancy left for the next fault. Showing each channel's raw reading, the size of the discrepancy between them, and the basis for the accepted result helps an operator judge whether this disagreement looks more like one sensor drifting slowly, or several channels affected by a shared factor at once — two situations that point to entirely different next actions, the first perhaps needing a scheduled calibration, the second suggesting a more systemic problem underway. When there is a lot to show, a health summary can come first, expanding to per-channel detail only when needed, to avoid overload.

Where it stops holding

In fast protection loops needing millisecond response, waiting for human arbitration of a disagreement is simply not realistic; these cases still need automatic voting to make the call immediately, and presenting disagreement information there serves after-the-fact diagnosis rather than replacing real-time protective action. Also, listing every channel's raw, unprocessed reading can mislead an operator who does not know each channel's calibration history and known bias characteristics — the goal of this presentation is to support the operator's subsequent risk judgment and maintenance decisions, not to hand the system's own voting responsibility over to a person.

Applying it

Show the current disagreement range, which specific channel was rejected, the rule the current vote relied on, how much fault tolerance remains, and how the disagreement is trending over time, linked to the corresponding maintenance action, so the operator knows who to contact and what to do next after seeing a disagreement.

• How to check: test with an intermittent slow drift, a deliberately designed common bias, and a faulty channel recovering to normal, and verify whether operators can correctly understand the source and degree of current uncertainty from the interface — rather than equating "the system is still outputting a number" with "everything is fine."

Related

• Same group: Y4.02.1 Redundant channels for fault tolerance · Y4.02.2 Voting logic for discrepant channels · Y4.02.3 Voter as a single point of failure
• Nearby: Y1.05 Representing the normal state · Y4.06 Safety integrity levels
• Search terms: Operator-visible sensor disagreement · functional safety · safety-critical systems