Why a Dead Transmitter Still Reads a Valid Number, and How to Catch It

The failure that looks like normal data

Analog scaling turns a raw count into an engineering value, but it does not tell you whether the signal is trustworthy. A transmitter with a broken wire, a saturated loop, or a frozen output still produces a number. Once that number is scaled it looks exactly like a real measurement, and the operator, the alarm engine, and the historian all treat it as one.

Most analog trouble in the field is not a wrong scale factor. It is a fault the SCADA never detected because nobody configured it to look. What follows are the checks that separate a real reading from a plausible-looking fake, and where to put them so they fire before the value reaches an operator screen or a control loop.

Know the raw signal, not just the scaled value

You cannot detect a signal fault by looking at the engineering value alone. A level reading of 0.0 m could be an empty tank or a dead transmitter. The difference is only visible in the raw signal.

Before configuring any fault detection, write down the raw range for each analog input:

Signal type	Live zero / normal band	Fault indication
4-20 mA	4-20 mA is normal process	Below ~3.6 mA or above ~21 mA is out of range
0-10 V	0-10 V process	Rail-to-rail stuck value needs other checks
RTD / thermocouple	Sensor-specific	Open circuit reads full-scale or a driver fault code
Fieldbus / digital	Value plus quality code	Use the quality code, not a magnitude threshold

The single most useful property of a 4-20 mA loop is the live zero. Because a healthy signal never goes below 4 mA, a reading near 0 mA means a broken wire, a dead transmitter, or a lost loop power supply — not a real process value of zero. A 0-10 V or 0-20 mA signal throws that away: zero is both a valid measurement and a wire fault, so you lose the cheapest fault check you have. Prefer 4-20 mA on any input where knowing "the sensor is gone" matters.

Out-of-range and over-range detection

The first check is the simplest: is the raw signal inside the range the transmitter can legitimately produce?

Define two bands around the normal signal:

Under-range / broken wire: raw signal below the live zero (for 4-20 mA, below roughly 3.6 mA). This almost always means an open loop, not a low process value.
Over-range / saturation: raw signal above full scale (above roughly 20.5-21 mA). This means the process has exceeded the transmitter span, or the transmitter has failed high.

Those thresholds are not arbitrary. NAMUR NE 43 is the recommendation most transmitter vendors follow for signalling failure on a 4-20 mA loop: it reserves ≤3.6 mA for downscale (low) failure and ≥21 mA for upscale (high) failure, keeping the 3.8-20.5 mA band for the real measurement plus a little headroom. If your transmitters are configured to NE 43, use those exact edges for the fault bands instead of guessing — the device is already telling you which is a fault and which is a live reading.

Two mistakes are common here:

Clamping silently. Many drivers clamp the scaled value to the range limits. A pressure that has actually run off the top of the transmitter span shows as exactly 100% and looks like a normal high reading. Clamping without a flag hides the fault. Clamp if you must, but always set a separate over-range status the operator and alarms can see.
Alarming on the scaled value instead of the raw signal. If you only alarm on engineering units, a broken-wire 0 mA that scales to a plausible mid-range value (because of an offset in the scaling) never trips. Detect the fault on the raw signal, then decide what engineering value and quality to publish.

The output of this check is not a number. It is a quality decision: publish the value as good, or override it to bad/uncertain so downstream logic knows not to trust it. Feed that decision into the tag quality handling the rest of the system already uses.

Frozen and stuck values

A broken wire is easy. A transmitter that has locked onto its last value, or a communication path that keeps returning the same stale reading, is harder — the value is inside range and looks alive.

Two detections catch this:

Frozen-value / no-change timeout. If an analog that normally moves has not changed by more than the signal noise for longer than an expected interval, flag it as suspect. Pick the timeout from how the process actually behaves: a fast flow can be frozen in seconds, a slow tank level might legitimately hold for minutes. This is a real-world tuning knob, not a value you can derive on paper — set it from the live signal, not a guess.
Stale-data / timestamp age. For polled or event-driven sources, compare the value's timestamp against now. If the source stopped updating, the last value is still in memory and looks current. A stale check turns "the number stopped arriving" into an explicit bad quality, instead of a value that quietly ages.

Both checks have the same trap: a genuinely steady process can trip a frozen-value alarm. Tune the deadband and the timeout together against the real signal, and give operators a way to see why a point went suspect so a legitimately calm process is not mistaken for a dead sensor.

Rate-of-change and noise checks

Beyond stuck values, two signal-shape checks catch faults that pass the range test:

Rate-of-change / spike rejection. If a value jumps further between samples than the process physically can, it is almost certainly noise, a grounding problem, or a bad conversion, not a real step. Flag or reject the sample rather than passing a spike into control and trends. Set the limit from process physics — a tank level cannot rise a metre in one scan.
Excessive noise. A signal bouncing far more than usual often means a wiring, shielding, or grounding problem developing before the loop fails outright. It rarely warrants an alarm, but it is worth trending so a maintenance tech can catch a loose terminal early.

Keep these checks honest: a real process transient must be allowed through. The point is to reject the physically impossible, not to smooth away real events. When in doubt, flag and pass rather than silently discard — a rejected real event is worse than a flagged noisy one.

Where to put the checks

The same fault can be detected in several places, and where you put it decides whether the whole system benefits or just one screen.

At the transmitter. Modern smart transmitters report their own diagnostics (open sensor, out of spec) over HART or fieldbus. This is the earliest and most specific detection — use it where the signal path carries it.
In the PLC / RTU. Detecting range, freeze, and rate faults in the controller means the control logic itself can react — hold the last good value, fail to a safe state, or inhibit a loop. This is the right place for anything that affects control.
In the SCADA / historian. SCADA-side checks are the safety net for signals whose controller does no diagnostics, and the place to drive quality codes on trends, alarms, and reports.

The lazy mistake is putting the check only in the SCADA HMI, where it colours one faceplate but the PLC control loop keeps using the bad value. Put fault detection as close to the control decision as the signal allows, and let SCADA add the operator-facing quality on top — do not rely on SCADA alone for a fault that control needs to know about.

What a detected fault should do

Detecting the fault is half the job. The response has to be defined per point, and it is a real engineering decision, not a default:

Publish bad/uncertain quality, so every consumer — HMI, alarms, trends, derived tags, control — knows the value is not trustworthy. This is the minimum and it is non-negotiable.
Decide the substituted value. Hold last good, force to a safe value, or leave it and rely on quality. Holding last value is convenient but dangerous for control — a frozen level that a pump keeps trusting can overflow a tank. Choose per point based on what the value drives.
Alarm appropriately. A signal fault is a maintenance condition, not a process alarm. Route it so it is visible to the people who fix instruments, without burying the process alarms operators must act on.
Log it for maintenance. Broken wires and drifting transmitters are physical failures. A record of when a point went bad and came back is how the instrument problem gets fixed instead of repeatedly worked around.

Commissioning checklist

Walk each analog input, not just a representative sample. This pairs naturally with a full analog loop check, where you already have a calibrator on the loop to inject each of these states.

Record the raw signal type and normal band for every analog input, and confirm 4-20 mA where a broken-wire indication matters.
Verify under-range (broken wire) detection by disconnecting the loop and confirming the point goes bad, not to a plausible zero.
Verify over-range detection by driving the signal past full scale and confirming a visible over-range status, not a silent clamp to 100%.
Confirm the fault decision drives tag quality that HMI, alarms, trends, and derived tags all honour.
Set frozen-value timeouts and rate-of-change limits from the real signal behaviour, and confirm a steady process does not false-trip.
Decide and document the substituted value per point — hold, force safe, or leave — based on what the value controls.
Confirm signal-fault alarms route to maintenance, separate from operator process alarms.
Confirm the fault clears and quality returns to good when the signal is restored, and that the event is logged.

The goal is that no analog reading on an operator screen is ever a fault in disguise. A good value shows as good, a dead sensor shows as dead, and control never quietly trusts a number that stopped meaning anything.