UncertainEngineeringUnitsExceeded
UncertainValue range
UncertainEngineeringUnitsExceeded is not an error. The value is outside the EURange declared on the node, so the server hands it over with a warning rather than clamping or rejecting it. Either the process really is out of range or the declared range is wrong; check EURange before you blame the sensor.
What you actually see
A tag reports a value slightly beyond its declared limits with an uncertain status, most often at zero, at a maximum, or just past one end of the range.
Why it happens
- Process genuinely outside the declared rangeThe instrument can measure it, the node's declared range says it should not happen, and the server reports both facts. This is the case you want the status for: an out-of-range excursion that a clamping server would have hidden entirely.
- EURange configured wrongly on the nodeRanges are frequently copied from a template or left at a default that does not match the instrument. A pressure declared 0 to 10 bar on an instrument spanning 0 to 16 will report this status for a third of its working range, and the data is perfectly good.
- Scaling or unit mismatch between device and serverA value in kPa presented against a range in bar, or a raw count presented against an engineered range, produces values that overshoot by a constant factor. The status appears immediately at commissioning and points at the scaling configuration rather than at the process.
- Sensor drift or offset errorA drifting transmitter can push a reading past a range limit while the process is normal. This overlaps with the accuracy case, and the distinguishing feature is that the excursion is small, persistent and in one direction rather than following the process.
- Range narrower than the instrument's real spanEURange is sometimes set to the normal operating band rather than to the instrument span, so anything outside normal operation reports uncertain. That can be a deliberate choice, but it must be documented or every startup and shutdown transient looks like a fault.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read EURange and InstrumentRange before anything elseRead the EURange property on the node and, where present, the instrument range property. If the value is inside the instrument range but outside EURange, the declared range is the problem and no instrument work is needed.
- Check the engineering unitRead the EUInformation property and confirm its unit matches what the device is actually sending. Unit codes come from a standard code list, so a mismatch is objective rather than a matter of opinion, and a factor-of-ten or unit-family error explains most systematic overshoots.
- Correct the declared range or the scaling, whichever is wrongFix EURange in the server or device configuration to match the instrument span, or fix the scaling so the engineered value lands in the declared range. Both are configuration changes, and both are preferable to leaving a permanently uncertain tag that everyone learns to ignore.
- Keep the value if the range was the errorWhere the declared range was wrong, the historical data is good and should not be discarded. Where the process genuinely exceeded a correct range, the excursion is real and worth keeping too, flagged as an excursion rather than deleted.
- Alarm on the excursion, not on the status aloneOnce the range is right, this status is a useful process signal. Route it to the alarm system with the value and duration, and use it as a genuine out-of-range indication instead of treating it as a data quality nuisance.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | The Data Access View shows the value, and browsing the node's EURange and EngineeringUnits properties in the attribute pane immediately settles whether the range or the process is at fault. |
| opcua-commander | It reads EURange and EngineeringUnits and renders values with their unit and range, so an out-of-range value is visible against its declared limits without extra browsing. |
| asyncua (Python) | Read the EURange property alongside the value once at startup and cache it, then compare on every sample. That gives you the same judgement the server made and lets you log which side of the range was exceeded. |
| KEPServerEX | Scaling settings per tag determine the engineered value, and a mismatch between the scaling range and the declared range is the most common source of this status in a gateway project. |
| Ignition | Engineering low and high on the tag drive both display scaling and quality decisions, so review them alongside the server's EURange rather than assuming they agree. |
| Siemens S7-1500 | Where the server exposes analogue values from raw I/O, the scaling is in the PLC program. Confirm the program's scaling matches the declared range on the OPC UA node rather than checking only one side. |
What it looks like in the log
ns=3;s=Line1.Pressure value 11.4 status UncertainEngineeringUnitsExceeded, EURange 0 to 10
Value exceeds declared engineering range; check EURange configuration for ns=3;s=Line1.Pressure
EngineeringUnits kPa with EURange 0 to 10; suspected unit mismatchConfirm the fix
After correcting the range or the scaling, confirm the tag reports Good across its full working band including startup and shutdown transients, and confirm the value now agrees with an independent local reading.
Stop it happening again
Populate EURange and EUInformation from instrument data at commissioning rather than from templates, review them at handover, and treat a tag that reports this status continuously as a configuration defect to be fixed rather than an alarm to be suppressed.
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.