UncertainSubstituteValue
UncertainSubstitution
UncertainSubstituteValue is not an error. Somebody configured a fallback value and the server is now serving it because the real one is unavailable. The number is fictional but plausible, which makes it the most dangerous status in this family. Never let a substitute into a calculation, and find who configured it.
What you actually see
A tag reports a suspiciously round or default-looking number - zero, a nominal setpoint, a mid-range value - with an uncertain status, and it does not change at all.
Why it happens
- Fail-safe substitute configured on the device or blockInstruments, drives and function blocks often allow a substitute or fail-safe value so that a control strategy has something defined to work with when a measurement is lost. The server exposes it honestly with this status. From a data collection point of view it is a made-up number with a warning label attached.
- Server-side default value for an unavailable tagGateway servers can be configured to return a default rather than a bad status for tags whose source is unreachable, usually to keep a legacy client happy. That configuration decision propagates a fabricated value into every consumer downstream, including analytics that were never part of the original conversation.
- Simulation or forcing left enabled after commissioningForced I/O and simulated blocks are frequently marked as substitute values rather than presented as measurements. Commissioning teams enable them legitimately; the defect is when they survive into production, which is common and often undetected for months.
- Safe state applied on communication lossA control block instructed to adopt a safe state when its input is lost will present that state as a substitute. This overlaps with the last-usable-value case, and the distinction matters: a held value was once real, a substitute never was.
- Redundancy switchover defaultDuring a switchover between redundant sources, a configured default can fill the gap until the new source is serving. Short-lived, but a counter or a rate that takes a substitute value for a few seconds can distort a fine-grained calculation.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Treat the value as absent, not as dataThis is the strongest rule in this family. A held value at least happened once; a substitute never did. Discard it, mark the interval as no-data, and make sure no averaging, totalising or rate calculation can see it.
- Find where the substitute is configuredLook in three places in order: the instrument or block fail-safe setting, the OPC UA server's tag configuration for a default-on-failure option, and any forcing or simulation state in the engineering tool. The status tells you a substitute exists; only the configuration tells you which one.
- Read the associated mode or state nodeWhere the model exposes a mode, state or health variable next to the value, read it. Companion-specification device models normally carry one, and it names the condition explicitly instead of leaving you to infer it from a suspicious number.
- Prefer a bad status over a substitute for analytics feedsWhere you control the server configuration, turn off default-on-failure for tags feeding data collection. An explicit bad status is unambiguous; a substitute requires every consumer downstream to be status-aware, and one of them will not be.
- Sweep for leftover forcing and simulationMake a check for tags reporting substitute values part of your commissioning sign-off and of a periodic audit. Any tag still substituting after a job is finished is a defect regardless of whether anyone has complained.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| KEPServerEX | Tags can be configured to return a default value on device failure. Auditing that setting across a project is the direct way to find every source of this status in a gateway. |
| Ignition | The tag shows an uncertain quality overlay while displaying the substitute number. Storing quality in the historian is what lets you find and exclude these intervals in a report afterwards. |
| UaExpert | Browsing to the sibling state, mode or health variable of the same object usually confirms the reason within a couple of clicks and is faster than reading the server's configuration. |
| asyncua (Python) | Branch on the uncertain status class and raise the substitute case louder than the stale case in your logs, because a substitute is more likely to corrupt a result silently. |
| OPC Publisher | The substitute value and its status are both published. A downstream rule that only checks for missing messages will never see it, so the status check has to be explicit in the consumer. |
| Beckhoff TwinCAT | Forced variables and simulated inputs in the runtime can surface with a substitute or uncertain indication depending on configuration. Check the forcing state in the engineering tool before investigating the data path. |
What it looks like in the log
ns=2;s=Boiler.Pressure value 0 status UncertainSubstituteValue
Substitute value applied for tag Line2.Rate after device failure
Forced value active on ns=4;s=Machine.CycleTimeConfirm the fix
Clear the substitute at its source and confirm the tag reports Good with a value that moves and a SourceTimestamp that advances, then confirm any historical window that carried the substitute is excluded from reports rather than averaged.
Stop it happening again
Turn off default-on-failure for tags that feed analytics, audit for active forcing and simulation at the end of every commissioning job and periodically thereafter, and make any substitute status an alarm rather than a log line.
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.