BadSensorFailure
BadUnderlying device
BadSensorFailure means the device is fine but the sensor feeding the value has failed - a broken thermocouple, an open loop, a signal outside the valid input range. The value is not usable. Fix the instrument or the wiring; nothing on the OPC UA side will change the status.
What you actually see
One measurement goes bad while every other value from the same device stays Good, often with the raw signal sitting at an obvious under-range or over-range value.
Why it happens
- Open circuit or broken sensor wiringAnalogue input modules detect an open thermocouple, RTD or 4-20 mA loop and flag the channel. The device reports the channel as invalid rather than passing on the meaningless raw reading, and the server maps that to a sensor failure.
- Signal outside the valid input rangeA 4-20 mA loop reading below about 3.6 mA or above about 21 mA is out of the valid measurement band and is treated as a fault, not as a value. Under-range and over-range detection is exactly what this status exists for.
- Sensor failed in placeA drifted, shorted or physically damaged sensor can be detected by the transmitter's own diagnostics. Smart instruments carry self-checks and report the failure upstream, which the controller surfaces per channel.
- Configuration mismatch between sensor and input channelA channel configured for a different thermocouple type, a different RTD, or voltage instead of current will read implausibly and may trip the module's validity check. This looks like a sensor failure and is a configuration error.
- Loss of loop power or a failed barrierIn an intrinsically safe or externally powered loop, losing the power supply or a barrier module makes every sensor on that supply read as failed at once. The scope of the failure points at the shared component.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Establish the scopeIf exactly one measurement is bad, look at that sensor and its wiring. If several sensors sharing a supply, barrier or module went bad together, look at the shared component instead of at the instruments.
- Read the raw or scaled value if the server exposes itAn under-range or over-range raw reading tells you whether the loop is open, shorted or simply out of range. A raw value near zero on a 4-20 mA input is an open circuit; a value pinned at full scale is usually a short or a wiring error.
- Check the channel configurationVerify the sensor type, range and wiring mode configured on the input channel against the instrument actually installed. A recently replaced sensor of a different type is a frequent cause.
- Check the instrument's own diagnosticsSmart transmitters expose diagnostic status over their own protocol, and a device model in the OPC UA address space may expose it as a node. That is a more specific answer than the status code.
- Record the fault window rather than filling itStore the bad status in your historian so the period is excluded from calculations. Interpolating over a failed sensor produces confident, wrong numbers in every downstream metric.
- Do not compensate in the clientSubstituting a last known value or a modelled value in the client hides a genuine equipment fault. If substitution is a real requirement, do it in the server where it can be reported as a substituted value rather than as measured data.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| Siemens S7-1500 | Analogue input channel diagnostics for wire break and range violation surface per channel while the rest of the module keeps working. The diagnostic buffer names the channel, which is faster than tracing tags. |
| Ignition | The tag quality goes bad and, if history is configured to record quality, the fault window is visible in the trend as a gap rather than a flat line. Configure it that way before you need it. |
| KEPServerEX | Driver-level channel diagnostics identify wire break and range faults where the underlying protocol reports them. The status code alone does not distinguish an open loop from an over-range reading. |
| UaExpert | Watching the value and the status together in the Data Access View shows whether the raw signal is pinned at an end of scale, which is usually enough to distinguish an open circuit from a short. |
| asyncua (Python) | In a data change handler, branch on the status before doing arithmetic. A failed sensor delivers a DataValue whose Value may be a stale number that looks entirely plausible until you check the status. |
| OPC Publisher | The status is published with the value. Downstream, remember that a missing StatusCode in JSON means Good, so consumers should treat any present status field as a reason to exclude the sample. |
What it looks like in the log
MonitoredItem ns=2;s=Reactor.TC03 status BadSensorFailure
Analogue input channel 3: wire break detected, value invalid
Loop current 3.4 mA below valid range, channel flagged failedConfirm the fix
Replace or repair the sensor and confirm the tag returns to Good with a plausible value and an advancing SourceTimestamp, then check the historian shows the fault window as bad rather than as data.
Stop it happening again
Enable channel diagnostics on analogue input modules so faults are detected rather than read as values, and alert on sensor status transitions. Keep a record of channel configuration against installed instrument type so a replacement of the wrong type is caught at commissioning.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.