A pressure sensor has been reporting a constant value of 6.42 bar for hours. The trend in the dashboard looks completely stable. In reality, however, communication with the sensor failed ten minutes ago and the edge gateway is merely continuing to display the last known value. For a user, a historian or an automated analysis, both situations initially look identical: there is a numerical value of 6.42 bar. From a measurement point of view, however, they are fundamentally different.
This is exactly why an industrial data point should not consist of a measured value alone. In addition to value and unit, the relevant timestamp and information about the usability of the value should at least be part of the data model. A quality status such as Good, Uncertain or Bad enables higher-level systems to distinguish whether a value was measured normally, is only trustworthy to a limited extent, or may no longer be used at all for the intended evaluation.
This principle is implemented particularly consistently in OPC UA. There, a data value contains a StatusCode whose basic quality levels are Good, Uncertain and Bad. If the same measured value is transmitted via MQTT to a historian or cloud platform, however, this semantics does not exist automatically. The project itself must define which quality information is transmitted in the payload and how it is interpreted by downstream applications.
A robust IIoT data model therefore does not only answer the question “What is the measured value?”, but also “When was it acquired and under which conditions may it be used?” Only the combination of value, time and quality turns a number into a reliable industrial data point.
Why is the measured value alone not sufficient?
In traditional measuring chains, it is often taken for granted that a displayed value is also a currently valid measured value. In a networked IIoT architecture, however, there may be a long data chain between the sensor and the user. A field device supplies data to a PLC or an IO-Link master, an edge gateway takes over this information, and it is then transmitted via OPC UA or MQTT to a broker, historian, dashboard or cloud application.
At each of these points, a condition may arise in which a number is still available, but its significance has changed. Communication with the sensor may have failed, a field device may report an internal diagnostic fault, a value may be outside its valid measuring range, or an application may deliberately use a substitute value. Likewise, a value may have been measured correctly from a technical point of view but transmitted only several minutes later from a local buffer.
If only the number is passed on, these differences are lost. A downstream system can then no longer determine whether 6.42 bar was actually measured at the current time, was taken over from a previous cycle, or is only still available as the last known value due to a fault. Particularly in automated reports, energy KPIs, condition monitoring or machine-learning applications, such seemingly small losses of information can later lead to significant misinterpretations.
What do Good, Uncertain and Bad mean?
The three quality levels should not be understood merely as traffic-light colors. They describe the usability of a data value. A Good value can be used under the intended conditions. Uncertain means that a value is available, but its usability is limited or at least questionable. Bad means that the value should not be used as a valid measured value for the actual measurement task.
| Quality status | Basic meaning | Typical example | Application response |
|---|---|---|---|
Good |
Value has been acquired normally and is suitable for the intended use | Sensor is operating correctly, communication is available, value is within the valid range | Display, store and evaluate normally |
Uncertain |
Value is available, but its significance is limited | Measuring range limit reached, substitute value used or accuracy restricted | Keep the value visible, but mark it and use it cautiously depending on the application |
Bad |
Value cannot be used as a valid current measured value | Sensor fault, communication failure or no valid value available | Do not use unmarked in calculations; make the fault condition visible |
These three levels are a good starting point for many applications, but they are often not sufficient on their own for a professional data architecture. Wherever possible, a specific reason should also be transmitted. A Bad status caused by a communication failure is operationally different from a Bad status caused by an internal sensor fault. Likewise, Uncertain can mean that a value can still be used, but comes from a substitute method or lies outside the specified accuracy, for example.
Which fault conditions should influence the quality status?
The quality status should be generated as close as possible to the actual cause of the fault. If the field device itself detects a sensor fault, this diagnostic information should not be lost on its way to the cloud. If, on the other hand, only the gateway detects that no new data is arriving, the edge layer must be able to change the status accordingly.
| Situation | Appropriate basic status | Additional information |
|---|---|---|
| Measurement and communication operating correctly | Good |
Normal operation |
| Measured value reaches or exceeds the specified range | Uncertain or, depending on the application, Bad |
Out of range / limit exceeded |
| Sensor reports an internal fault | Bad |
Sensor failure / device failure |
| Communication with the field device is interrupted | Bad |
No communication / not connected |
| Last known value is held | Do not leave unchanged as Good |
Mark as last usable value or stale data |
| Substitute value is used manually or automatically | Usually Uncertain |
Substituted / local override |
| Device is intentionally in maintenance | Bad or dedicated maintenance status |
Out of service / maintenance |
It is important that these rules are already defined during the engineering phase. If every PLC, gateway and cloud application decides independently when a value is Good or Bad, the same status can end up having different meanings. A company-wide standardized quality model, by contrast, makes it much easier to reuse data.
Why do timestamp and quality status belong together?
A quality status can only be interpreted completely together with its time reference. Suppose a sensor provides a valid pressure value of 6.42 bar at 10:15:42. At 10:15:45, communication fails. If the gateway continues to display the last value afterwards, it must remain clearly recognizable that this value was originally acquired at 10:15:42.
If a new current timestamp were generated during every gateway cycle instead, the old value could appear as though it were still being freshly measured. The quality status Bad would indicate the fault, but the history would still be unnecessarily misleading. This becomes particularly problematic if downstream applications do not consistently evaluate the status.
For this reason, a distinction should be made wherever possible between the time at which the measured value was actually acquired and later processing or transmission times. For process history, the original measurement time is generally decisive. With store-and-forward, a data packet transmitted one hour later must not suddenly appear as though the measured value it contains was only generated when the connection was restored.
Quality status in OPC UA
OPC UA treats data quality as an integral part of a data value. In addition to the actual value, time information and a StatusCode can be transmitted. The top-level quality classification of this StatusCode distinguishes between Good, Uncertain and Bad. More detailed status information is also available to describe communication, device or measuring-range problems more precisely.
This is a major advantage over data models in which only a number is transmitted. An OPC UA client can not only read 6.42 bar, but can simultaneously determine whether this value is suitable for the intended processing. A historian can continue to record a Bad value without treating it like a normal process value in averages or KPIs.
When moving from OPC UA to another protocol, this information should not be lost. If, for example, an edge gateway reads an OPC UA data point with a detailed StatusCode and then publishes only the bare numerical value via MQTT, a significant part of the original data model has been removed.
Transmitting Good, Bad and Uncertain via MQTT
MQTT transports messages but does not automatically define how the quality of a measured value must be represented in the application payload. This is exactly why a binding payload schema must be defined for an MQTT architecture. A compact data model could, for example, include not only the value, but also the unit, original measurement time and quality status.
Example:
{"value":6.42,"unit":"bar","quality":"Good","sourceTimestamp":"2026-09-01T10:15:42.250Z"}
In the event of a communication failure, the same payload should not simply be published again as Good with a new timestamp. Depending on the architecture, a Bad status with a fault reason can be transmitted instead, or the process value can be set to null if no usable value is available at all.
{"value":null,"unit":"bar","quality":"Bad","reason":"NoCommunication","sourceTimestamp":"2026-09-01T10:15:45.000Z"}
If the last known value is deliberately transmitted as well, this should also be clearly recognizable:
{"value":6.42,"unit":"bar","quality":"Uncertain","reason":"LastUsableValue","sourceTimestamp":"2026-09-01T10:15:42.250Z"}
The exact field names are project-specific. What matters less is whether the field is called quality, status or qualityCode, but rather that its meaning is documented and implemented consistently in all participating systems.
Mapping status information from field devices meaningfully
Not every field device directly provides a quality value named Good, Uncertain or Bad. An IO-Link sensor, for example, can provide process data together with diagnostic and status information. A HART device may provide its own device status and diagnostic information. A PLC may additionally detect communication faults or invalid input ranges.
The task of the edge or integration system is then to map this different information to a common higher-level model. If, for example, an IO-Link pressure sensor reports an internal device fault, the gateway can generate quality = Bad and reason = DeviceFailure. If, on the other hand, only a warning condition is detected in which the measured value remains usable to a limited extent, mapping it to Uncertain may be more appropriate.
This translation should not be created spontaneously during programming. A mapping document should define which field-device diagnosis produces which IT/OT status. This makes it possible to understand later why a particular data point was stored as Bad in the historian and what technical cause was behind it.
Why the last valid measured value can become dangerous
Holding the last valid value is technically useful in many control and visualization systems. A display does not immediately jump to zero during a brief communication interruption and trends remain visually smoother. This behavior only becomes problematic if the held value is not clearly identified as such.
A pressure of 6.42 bar may remain on the screen for ten seconds, ten minutes or several hours after a sensor failure. Without additional information, a person cannot tell that this value has not been updated at all since the failure. An automated application can detect it even less if it processes only the numerical field.
The data quality should therefore change as the value ages or when communication loss is detected. Whether a last value is passed on as Uncertain or immediately set to Bad depends on the application. For a slowly changing tank level, a value that is only a few seconds old may still be informative. For a fast safety function, the same strategy would be completely unsuitable. The boundary between “still usable to a limited extent” and “no longer usable” is therefore part of the process requirement.
Quality during offline buffering and store-and-forward
A communication failure between the edge gateway and the cloud does not automatically mean that the local measured values are bad. If communication from the sensor to the gateway continues to operate correctly, the gateway can continue to acquire valid Good values with the correct original timestamp and store them locally.
When the cloud connection is later restored, these data can be transmitted retrospectively. Their quality still remains Good because the actual measurement was valid at the time. Only the transmission time is later. This clearly illustrates why data quality and transport status should be treated separately.
The situation is different if communication between the field device and edge gateway had already failed. In this case, no new valid process values are generated during that period. A later reconnection must not hide the gap by copying the last value retrospectively across the entire time period.
How historians, dashboards and analytics should respond
A quality status only has practical value if the receiving systems actually evaluate it. A dashboard can, for example, continue to display an Uncertain value but mark it visually in a different way. With Bad, it should be recognizable that no valid current process value is available. The historian can still store the data record so that the fault can later be traced.
For calculations, it must also be defined which quality levels may be included. A daily average calculated from pressure data should not automatically contain values that were marked as Bad during a communication failure. Uncertain values should also be deliberately included or excluded depending on the KPI.
The same applies to machine learning and condition monitoring. If historical data are exported without filtering, a last value held for hours may look like an unusually stable process phase. Quality information should therefore be retained right through to the analytics data set and not removed during export.
Practical example: pressure measurement loses communication
An IO-Link pressure sensor measures an outlet pressure of 6.42 bar at a pumping station. The edge gateway acquires the process value, sensor status and timestamp and publishes the data to an MQTT broker. During normal operation, this may look as follows:
value = 6.42 bar | quality = Good | sourceTimestamp = 10:15:42
At 10:15:45, the connection between the IO-Link master and the sensor is interrupted. The gateway still has the last measured value, but at the same time recognizes that no valid new process data are arriving. If it continued to publish 6.42 bar every five seconds with Quality Good and a new timestamp, this would create a completely false process history in the historian.
Instead, the status is set to Bad and NoCommunication is transmitted as the reason. The dashboard can continue to display the last known value as information, but clearly marks it as no longer currently valid. The historian records the failure state, but does not use the corresponding values for normal process averages.
At 10:18:12, the connection is available again. The next regularly acquired value is 6.57 bar and receives Quality Good again. The history therefore clearly shows that no valid new pressure values were available between 10:15:45 and 10:18:12.
Quality therefore does not describe whether a number is present in the data packet. It describes whether that number may be used for the respective measurement task under the known conditions.
Systematically planning a quality model
- Define which information is transmitted for each data point: at minimum value, unit, relevant timestamp and quality status.
- Clearly define Good, Uncertain and Bad: The same level must have the same basic meaning in PLC, edge, historian and cloud.
- Add fault reasons: Do not treat communication faults, sensor faults, measuring-range violations, substitute values and maintenance states merely as an unspecified Bad.
- Map field-device diagnostics to the central model: Document mapping for IO-Link, HART, Modbus, OPC UA and other sources.
- Define stale-value and last-value behavior: Determine how long an old value may still be displayed and how its quality changes.
- Separate transport faults from measurement faults: A failed cloud connection does not automatically make locally buffered, correctly measured values Bad.
- Define the behavior of downstream systems: Dashboards, alarms, historians and analytics must know how to handle Uncertain and Bad.
Common mistakes
- Transmitting only the numerical value: Downstream systems can no longer distinguish whether the value is current, substituted or invalid.
- Continuing to send the last value as Good during a communication failure: This creates an apparently valid but false process history.
- Using transmission time as measurement time: Buffered data then receive the wrong time reference.
- Treating every warning condition immediately as Bad: This removes the important intermediate level Uncertain.
- Storing all faults only as “Bad”: Without a reason, it is difficult to determine later whether the sensor, communication or configuration was affected.
- Discarding OPC UA quality information during MQTT mapping: A structured data value then becomes only an unqualified number.
- Storing quality in the historian but ignoring it during evaluations: Bad values can still enter averages, KPIs or models.
- Generating quality logic only in the cloud: The cloud often no longer has access to all field-level diagnostic information that was available at the edge.
IIoT sensor technology and edge integration
For a reliable quality model, it is not a single communication protocol that is decisive, but the entire data chain from the field device to the higher-level system. Sensors and intelligent field devices should make available diagnostic information digitally wherever possible. PLCs, IO-Link masters and edge gateways must take over this information, standardize it and pass it on together with the value and timestamp.
A concrete example is the IDS350 electronic pressure sensor with IO-Link interface. In addition to the actual process value, diagnostic, status and additional device information can be transferred to the higher-level system via IO-Link. This information can then be mapped to a standardized data-quality model in an edge system.
For brownfield and IIoT architectures, an industrial edge platform can combine different field sources, scale values, manage timestamps and quality information, and transmit selected data via OPC UA, MQTT or HTTPS to further IT/OT systems. The exact functions available depend on the gateway, software and project configuration.
Suitable components and integration solutions can be found under IIoT solutions at ICS Schneider. A specific field device with digitally available diagnostic and status information is the IDS350 with IO-Link interface.
Conclusion
In a modern IIoT architecture, an industrial measured value consists of more than just a number. Without information about time and quality, a technically available value can easily be interpreted as current and valid even though the sensor has failed, a substitute-value strategy is active or the data are already outdated.
The quality levels Good, Uncertain and Bad provide an understandable basic structure. Good identifies normally usable data, Uncertain values with limited significance, and Bad values that should not be used as valid measurements. For diagnostic purposes, a specific status reason should additionally be retained.
OPC UA provides this quality information directly as part of the data value. If MQTT is used instead, a corresponding quality field must deliberately be included in the application’s own payload schema. When mapping between protocols, existing status information must not be lost.
The time reference is equally important. After a communication failure, a last valid value must not appear like a current measured value simply because new timestamps continue to be assigned. Conversely, correctly buffered Good values at the edge may retain their original quality status if only the cloud connection has failed.
For reliable IIoT measurement data, the following therefore applies: transmit value, unit, original measurement time and quality status together, clearly define the meaning of Good, Uncertain and Bad, retain detailed fault reasons and ensure that dashboards, historians and analytics actually take this information into account.
FAQ: Good, Bad and Uncertain in IIoT measurement data
What does Good mean for a measured value?
Good means that the measured value was acquired normally under the intended conditions and can be used for the intended processing.
What does Uncertain mean?
Uncertain means that a value is available, but its quality or usability is limited. Depending on the cause, it may still be informative, but it should not be processed in the same way as a Good value without further consideration.
What does Bad mean?
Bad identifies a value that should not be used as a valid measured value. Typical causes include sensor faults, communication failures or the complete absence of a valid process value.
Are Good, Bad and Uncertain part of MQTT?
No. MQTT defines the transport of messages, but not a general quality model for industrial measured values. Quality, status, timestamp and fault reason must therefore be defined in the respective payload or data model.
How is data quality transmitted in OPC UA?
OPC UA uses a StatusCode as part of the data value. Its basic quality levels distinguish between Good, Uncertain and Bad, while additional status information can describe the specific condition in greater detail.
Should the last measured value still be transmitted when the status is Bad?
That depends on the data model. A last known value may still be informative, but it must not appear unmarked as a current Good value. Alternatively, the process value can be set to null and the last valid value stored separately.
Is an old measured value automatically Bad?
Not necessarily. A correctly measured value that was subsequently buffered locally can remain Good if its original measurement time is preserved. An old value that is merely held because the sensor has failed, on the other hand, must be marked accordingly.
Which is more important: quality status or timestamp?
Both pieces of information complement each other. The status describes the usability of the value, while the timestamp shows when it was actually acquired. Only together can the data point be interpreted reliably.
Should Bad values be stored in the historian?
Yes, this can be very useful. It makes it possible to trace when a measuring point was faulty. However, Bad values should not automatically be treated like valid process values for averages, KPIs and other calculations.
Which specific field device is suitable as an example for an IIoT quality model?
The IDS350 with IO-Link interface is a suitable example because diagnostic and status information can be transmitted digitally to a higher-level system in addition to process data. An edge gateway can then map this information to a standardized quality model for OPC UA, MQTT or other IT/OT systems.