Normal should be reported by an active signal, not inferred from a screen's silence

What it is

A positive indication of normal operation is an explicit process state, heartbeat, or self-test result that reports "the plant is normal and the information path is working" — rather than letting operators infer normality from the absence of an alarm. Silence is ambiguous by itself: it can mean genuine normality, a lost connection, frozen data, a failed sensor, or a dead alarm processor, and none of these can be told apart from silence alone.

Why it happens

No alarm is an absence of evidence, not evidence of normality, and that is the whole reason positive indication exists: it encodes "the process is within range" separately from "the monitoring path itself is functioning." When both claims travel down the same channel, a display can look perfectly clear and still carry no diagnostic independence.

Most alarm systems run on a management-by-exception philosophy: stay quiet unless something is wrong, so operators are not interrupted by routine noise. That philosophy only holds if the alarm-processing chain itself can be trusted — and that assumption fails more often than it should. An alarm server outage, a configuration error, a network partition, an expired license, or a full alarm-history database can all suppress an alarm that should have fired, and these failures are typically silent precisely because the mechanism that would have reported them is the one that broke. Positive indication is not answering "is the process okay" — it is answering the layer above that: "is the thing responsible for judging whether the process is okay still alive." The alarm channel cannot answer that second question about itself.

Studying it

Fault injection can contrast normal operation, communication loss, data freeze, and alarm-processor failure, scoring whether operators classify each correctly — and, separately, whether their read on "process state" and their read on "monitoring health" stay in sync. The two often diverge: operators readily read "no alarm shown" as "process is fine" even when the monitoring layer itself is the thing that died. Design the heartbeat and the monitored process data to share a failure point in some trials and to be genuinely independent in others, so the study can tell whether participants actually treat the two as separate evidence or simply stop doubting once any green label appears.

Where it stops holding

An integrated sensor-transmitter that runs acquisition and self-test on the same chip and the same power rail cannot achieve a real separation between the tester and the tested; the honest label there is "limited self-test coverage," not full diagnostic independence. A power-on self-test that passed once says nothing about continuous health during operation — a device can fail well after boot, so a one-time pass should not leave a "self-test OK" label sitting on screen indefinitely; only a repeating, in-service self-test earns that. New operators tend to overcorrect the other way, treating the mere presence of a positive indicator as proof that nothing can be wrong — that is its own form of overtrust, and the display needs to guard against it rather than offering only a normal/abnormal binary.

Applying it

Design the heartbeat like a watchdog timer: the source writes an incrementing counter or timestamp on a fixed period, and if the front end sees no increment within the allowed window, it switches the display to unknown rather than holding the last green state. Across a multi-tier architecture (field device → RTU → SCADA → HMI), generate and forward a health bit at every tier independently — do not let the top layer fabricate one blanket "all normal" that erases each tier's traceability. Fault-injection testing should specifically target common-cause scenarios: cut power to a sensor and check whether its heartbeat drops at the same instant — if it shares the same power rail or bus, the "independent" heartbeat is not actually independent and needs physical separation. Use mean time to detect a silent failure, measured by repeated fault injections of different types, as the acceptance metric.

Related

• Same group: Y1.05.2 Ambiguity of static displays · Y1.05.3 Normalization during all-normal operation · Y1.05.4 Data freshness indication
• Nearby: Y4.02 Redundancy and voting · Y1.06 Detecting and highlighting anomalies
• Search terms: positive indication · common cause failure · watchdog timer · diagnostic coverage