In OPC, every value travels with a quality code that says how much the value can be trusted, and that code is more than a simple good-or-bad flag. It splits into a major status, which places the value into one of a few broad buckets, and a substatus, which explains exactly why the value has the quality it does. Reading only the top-level status throws away the most useful part. This guide decodes the OPC quality code, walks through the substatus reasons a client actually encounters, and explains how software should react to each so that a value's trustworthiness is never silently lost.
OPC Quality Code Substatus in one line: An OPC quality code is a small piece of metadata attached to every value that describes how reliable it is. It has a major status of good, uncertain, or bad, and a substatus that gives the specific reason, such as last usable value, sensor failure, communication failure, or out of range. Reading both the major status and the substatus lets a client react correctly instead of treating every non-good value the same way.
The top level of an OPC quality code sorts every value into one of three broad states. Good means the value is trustworthy and can be used normally: the measurement chain is healthy and there is no known reason to doubt it. Bad means the value must not be relied on, because something in the chain has failed, and the number attached to it, if any, is not a valid representation of the process. Between them sits uncertain, sometimes described as questionable, which means the value may be usable but carries a known reason for doubt, so it should be treated with caution rather than trusted outright or discarded entirely.
The uncertain state is the one that is easiest to misuse, because it is neither a clean yes nor a clean no. A common mistake is for software to lump uncertain in with either good or bad and lose the nuance. Treating uncertain as good means a doubtful value silently drives a calculation, an alarm, or a control decision as if it were solid. Treating uncertain as bad means genuinely useful, if imperfect, data gets thrown away when it might have been the best available reading. The correct handling depends on the application, which is exactly why the state exists as a distinct category.
Crucially, the value and its quality are two separate things that must travel together. A value can look perfectly plausible, a reasonable-looking number in the expected range, and still carry a bad quality that says it is stale, held, or otherwise not real. Software that reads the number but ignores the quality will treat that plausible-looking value as truth. Preserving quality alongside the value, and actually checking it, is what prevents a comfortable-looking but meaningless number from being trusted.
The major status tells you how much to trust a value; the substatus tells you why it has that quality, and that reason is what lets a client respond intelligently. A bad quality accompanied by a communication failure substatus means the path to the device is down, so the last known value is simply out of date and will refresh when the link returns. A bad quality with a sensor or device failure substatus means the measurement source itself is broken, which is a maintenance problem rather than a network one. Same major status, very different real-world meaning and very different response.
Among the most useful substatus reasons is last usable value, which typically accompanies an uncertain quality. It signals that the current reading could not be obtained, so what is being reported is the last value that was known to be good, held over until fresh data arrives. This is honest and often helpful, but only if the client understands it: the number is real history, not a current measurement, and treating it as live data means acting on information that may be stale. Other common substatus reasons include out of range, meaning the value hit the limits of what the sensor or scaling can represent, and various indications that a value is being held, substituted, or has not yet been initialized.
The practical lesson is that a client should branch on the substatus, not just the major status. A communication failure and a sensor failure both read as bad, but a well-designed system reacts differently: it may keep displaying the last good value with a clear stale indicator during a comms failure, while flagging a sensor failure for maintenance and refusing to use the reading at all. An out-of-range uncertain value might still be shown but marked as pinned at a limit. Collapsing all of these into a single bad flag discards the very information that would let the system respond appropriately.
In a live SCADA system, quality codes are what keep operators from being misled by broken data. When a value goes bad because of a comms failure, the interface should show that the reading is stale rather than freezing on a plausible number that looks current, so an operator does not make a decision on data that stopped updating an hour ago. When a substatus points to a sensor failure, that is a signal to dispatch maintenance and to stop trusting that point entirely until it is fixed. The quality code is the difference between an interface that tells the truth about its own reliability and one that quietly presents stale or broken values as fact.
Quality also has to survive the whole journey from the field to a cloud historian, not just the live view. If a value arrives with a bad or uncertain quality, that quality should be stored right alongside it, so that anyone looking at the history later can see that a stretch of data was flagged rather than assuming it was solid. A historian that keeps the number but drops the quality produces a record that looks cleaner than reality, hiding the periods when the data was actually a held value, an out-of-range reading, or the product of a failed sensor. Preserving quality through storage is what keeps historical analysis honest.
For a cloud SCADA platform such as Merobix, carrying the OPC quality code through the entire pipeline is essential across every industry it serves, from oil and gas to water, power, and manufacturing. The value tells you what the process appeared to be doing; the quality and its substatus tell you whether to believe it and why. Keeping both together, all the way from the device to the dashboard and into the historian, means a comms failure is shown as stale rather than trusted, a sensor failure is surfaced for repair, and a held or out-of-range value is never mistaken for a fresh, valid measurement.
The major status is the broad verdict, placing a value into good, uncertain, or bad, which tells a client how much to trust it. The substatus is the specific reason behind that verdict, such as communication failure, sensor failure, last usable value, or out of range. The major status decides whether to use the value, while the substatus lets the client respond appropriately to the particular reason it is not fully good.
It means the system could not obtain a fresh reading, so it is reporting the last value that was known to be good, held over until new data arrives. It usually comes with an uncertain quality, signaling that the number is honest history rather than a current measurement. A client should treat it as potentially stale and indicate that clearly, not act on it as if it were live data.
Because a plain good-or-bad flag throws away the information a system needs to respond correctly. A comms failure and a broken sensor both read as bad, but one is a temporary network problem where the last value is simply out of date, and the other is a maintenance issue where the sensor itself is untrustworthy. The substatus is what lets software react differently to each instead of treating every non-good value the same way.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.