Good and Bad are easy: trust it, or do not. The state that trips operators up is the one in between - Uncertain, sometimes labeled Questionable. A value carrying this flag is neither a confident reading nor an outright failure; it is the system saying a number is here, but treat it with suspicion. Because it is ambiguous, it is easy to ignore, and ignoring it is how a subtly wrong value slips into a control decision or a billing figure. This page explains what specifically triggers Uncertain, why it is genuinely different from Bad, and what an operator should actually do when they see it.
Uncertain quality code in one line: A Questionable or Uncertain quality code is the middle state between Good and Bad: a value is present and may be roughly right, but the system has a reason to doubt it. Typical triggers include a sensor reading over or under its range, a value that is stale because comms were restored but fresh data has not arrived, an engineering-unit clamp, or a device flag such as a DNP3 restart. An uncertain value should not be trusted for control decisions or billing.
Quality is not a simple pass or fail. Standards and SCADA systems define a middle tier - commonly called Uncertain, and in some systems Questionable - to describe a value the system can neither fully endorse nor fully reject. The value exists and is delivered, but it comes with a caveat: the circumstances around it mean it might not be accurate. That is a genuinely different message from Bad. Bad says do not use this at all, usually because the value is missing or the source is broken. Uncertain says here is a value, but be careful, because a reason to doubt it is attached.
The reason a distinct middle state exists is that real instruments and links produce situations that are neither clean nor catastrophic. A sensor that has just nudged past its calibrated range is still returning a number, and that number is roughly meaningful even if it is no longer precise - throwing it away entirely as Bad would lose useful information, but presenting it as Good would overstate its accuracy. Uncertain captures exactly that nuance. It preserves the value while warning that it sits in a gray zone, which is why treating Uncertain as if it were Good is the mistake operators most often make with it.
Several concrete conditions push a value into Uncertain. A sensor reading over-range or under-range is a classic one: the instrument has driven past the top or bottom of its measurable span, so it is still producing a number but that number is no longer a reliable measurement. An engineering-unit clamp does something similar - when a raw signal maps to a value beyond the configured limits, the system may pin it to the boundary and flag the result Uncertain to show it was capped rather than genuinely read. A stale value can also earn the flag: after a communication outage is restored, a system may serve the last known value while waiting for fresh data, marking it Uncertain to signal that it is a holdover, not a current reading.
Protocol-level device flags are another major source, and DNP3 is the common example. When an outstation restarts or is not yet fully online, it can set flags such as restart or offline against its points, and a well-behaved master translates those into Uncertain quality on the corresponding tags - the device is telling you it has just come up or is not confident in this point yet. The unifying theme across all these triggers is the same: a value is available and plausibly close to right, but a specific, identifiable condition undermines confidence in its exactness. That is what separates Uncertain from Bad, where the value cannot be trusted or obtained at all.
The correct operator response to Uncertain is caution, not comfort. An uncertain value can be watched for a sense of the general situation, but it should not be the basis for a control action or a commercial figure. Using an over-range or clamped reading to drive a setpoint could push a process the wrong way; using a stale or restart-flagged value in a custody-transfer or billing calculation could put a wrong number on an invoice. The safe practice is to treat Uncertain values as informational only for anything that must be exact, and to investigate why the flag is set - is a sensor drifting past range, did a device just restart, is the link still catching up after an outage.
This is precisely why carrying the flag faithfully all the way to the operator matters, and why a cloud platform's handling of it is not a technicality. It helps an operator when the system shows a value as Uncertain rather than silently presenting it as Good, because that visible caveat is what stops a questionable number from being trusted for control or billing. A cloud SCADA platform such as Merobix preserves the quality code with each value from the field device through history to the screen, so an over-range reading, a post-outage holdover, or a DNP3 restart flag arrives at the operator clearly marked as questionable. That lets someone respond appropriately - use it as a rough indicator, keep it out of exact calculations, and chase down the condition that made it uncertain - instead of unknowingly building a decision on a value the system already suspected.
Bad means the value cannot be trusted or obtained at all - the source is broken or the reading is missing - so it should not be used. Uncertain means a value is present and may be roughly right, but a specific condition, such as an over-range sensor or a post-outage stale value, undermines confidence in its accuracy. Bad says do not use it; Uncertain says use it only with caution and not for anything that must be exact.
Common triggers are a sensor reading over or under its measurable range, an engineering-unit clamp that pins a value to a configured limit, a stale last-known value served while comms recover after an outage, and protocol device flags such as a DNP3 restart or offline indication. In each case a value is available and plausibly close to right, but an identifiable condition reduces confidence in its exactness.
No - an uncertain value should not drive a control action or a commercial calculation. It can be watched as a rough indicator of the general situation, but for anything that must be exact, such as a setpoint or a custody-transfer figure, an uncertain reading could be materially wrong. Treat it as informational only and investigate why the flag is set.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.