BadOutOfService
BadMaintenance state
BadOutOfService means the source has been deliberately taken out of service, typically for maintenance or because a function block was disabled. It is an intentional state, not a fault. Find who or what set it, and treat the period as excluded data rather than as an equipment failure.
What you actually see
A tag goes bad at a moment that correlates with maintenance work rather than with any equipment or network event, and it returns to Good when the work finishes.
Why it happens
- Maintenance mode set on the device or loopMany instruments and control blocks have an explicit out-of-service or maintenance state so that calibration and testing do not disturb the control strategy or raise spurious alarms. The status is the intended signal that the value should not be used.
- Function block disabled in the control strategyA DCS or PLC function block taken out of service stops producing a valid output. The OPC UA server exposes the block's output with its status, so the tag correctly reports that the source is not operational.
- Alarm or condition suppressed and the value with itAlarm suppression and out-of-service handling are related in Part 9 alarm models. Placing a condition out of service can also mark the associated value out of service, so a shelving action in the alarm system shows up on the data side.
- Simulation or forcing mode enabledWhere a channel or block is forced to a simulated value, some devices mark the value out of service rather than presenting a simulated number as measured data. That is the honest behaviour, and it is what makes the status appear during commissioning.
- Server or channel deliberately disabledA gateway channel disabled by an operator, or a device removed from scan, produces this status for everything under it. It is distinguishable from a communication failure only by knowing that someone did it on purpose.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Establish whether this was intentionalCheck maintenance records, the operator log and any change window in progress. This status is far more often a person doing their job than a fault, and treating it as an outage wastes time.
- Read the associated state or mode nodeWhere the model exposes a mode, state or health variable next to the value - and companion-specification device models normally do - read it. It names the state explicitly instead of leaving you to infer it from the value's status.
- Check the alarm system for suppression or shelvingIn a Part 9 alarm implementation, look at the condition's enabled, suppressed and out-of-service flags. An operator action there explains a data-side status that otherwise looks unexplained.
- Look for forcing or simulation on the channelForced I/O and simulated blocks are usually visible in the engineering tool. Any force left in place after commissioning is a defect in its own right and worth clearing regardless of the status code.
- Exclude the period downstreamOut-of-service data must not feed availability, performance or quality calculations. Propagate the status so the analytics layer can exclude the window explicitly instead of averaging over it.
- Restore service and confirmOnce maintenance completes, verify the status returns to Good rather than assuming it did. Blocks left out of service after a job is finished are a common cause of missing data that nobody notices for weeks.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| Ignition | The tag shows bad quality; if the historian stores quality the out-of-service window is visible in the trend. Combining the tag history with the alarm journal usually identifies the operator action that caused it. |
| UaExpert | The Data Access View shows the status, and browsing to the sibling state or mode variable of the same object usually confirms the reason within a couple of clicks. |
| KEPServerEX | A device or channel disabled in the project, or removed from scan, produces this class of status for all its tags. Check the project state before investigating the network. |
| asyncua (Python) | Branch on the status in your data change handler and emit an explicit out-of-service marker downstream rather than dropping the sample. A dropped sample is indistinguishable from a collector outage later. |
| OPC Publisher | The status is carried with the value, so a downstream consumer can distinguish maintenance from failure - but only if it inspects the status. In JSON encoding, Good is omitted, so any present status is worth acting on. |
| Prosys | Subscription views show status per item. Comparing a group of items in one view makes it obvious whether a whole block went out of service or a single value did. |
What it looks like in the log
MonitoredItem ns=4;s=FIC101.PV status BadOutOfService
Function block set to out of service by operator action
Channel disabled in configuration; tags reporting out of serviceConfirm the fix
After maintenance, confirm the tag returns to Good with an advancing SourceTimestamp and that any associated condition is back in service in the alarm system.
Stop it happening again
Expose and monitor the mode or state node next to every critical measurement so out-of-service is a reported state rather than an inferred one, and add a check that flags anything still out of service at the end of a maintenance window.
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.