BadDeviceFailure

BadUnderlying device

What you actually see

Tags from one device or one I/O module go bad while the rest of the server stays healthy, and the device itself is showing a fault indication.

Why it happens

• The device reports an internal faultDrives, instruments and smart devices carry self-diagnostics. When the device flags a fault, a server that maps device diagnostics into OPC UA status reports a device failure rather than fabricating a value. The status is the device speaking, not the server guessing.
• I/O module fault or missing moduleA failed, removed or unconfigured I/O module makes the channels behind it invalid. The controller keeps running and answering, so the OPC UA server is fine and only the affected channels degrade.
• Power or wiring fault at the field levelLoss of field power to a sensor loop, a broken wire on an analogue input or a blown fuse produces a diagnostic the module reports upward. The value at the tag becomes meaningless, which is what the bad status is telling you.
• Device in a fault or safe state after a tripAfter a protective trip, many devices hold their outputs and mark their process values invalid until acknowledged and reset. This produces a persistent device failure status that will not clear from the OPC UA side at all.
• Server mapping any device error to a generic failureSome servers collapse several distinct device errors into this one code. The specific reason is then only visible in the device's own diagnostic data, which is why the status alone rarely tells you what is wrong.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Confirm the fault is at the device, not at the linkIf other tags from the same device are Good, the communication path is fine and the device is reporting a genuine fault. If every tag from that device is bad and the pattern started at one instant, look at communication first.
2. Read the device's own diagnostic nodesWhere the server exposes a device model, browse for diagnostic, health or state variables next to the process value. A companion-specification device model typically has an explicit health or state node that names the fault.
3. Check the physical deviceFault LEDs, drive fault codes, module status in the engineering tool. The status code came from the equipment, so that is where the actionable information is.
4. Look at the module and channel levelWhere a group of adjacent channels failed together, suspect the module or its power supply rather than the individual sensors. The address pattern of the failing tags is a strong clue.
5. Record the status through your pipelineKeep the status alongside the value in your historian or time-series store. A period marked bad is diagnostically valuable; the same period stored as a plausible-looking number is actively harmful.
6. Do not reconnect the client to clear itDropping and recreating the session, the subscription or the monitored item changes nothing, because the status originates below the OPC UA layer. Reconnect loops triggered by device faults only add load.

Where it shows up, by tool and stack

What it looks like in the log

MonitoredItem ns=3;s=Drive1.ActualSpeed status BadDeviceFailure
Device reported internal fault; process values marked invalid
Channel diagnostics: module fault on slot 4, associated tags degraded

Confirm the fix

Clear the device fault and confirm the tag returns to Good with an advancing SourceTimestamp. A value that returns but keeps a frozen timestamp means the fault cleared in the status only.

Stop it happening again

Subscribe to the device's health or diagnostic nodes as well as its process values, so a fault is reported as an event rather than inferred from bad quality. Alert on status transitions per device, not per tag.

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.