Global – October 29, 2026 -- Industrial historians that store an OPC UA value and timestamp without the accompanying 32-bit StatusCode can pass stale, substituted, or Bad readings into averages, alarm reviews, and production calculations as ordinary process measurements.
StatusCode carries more than a Good, Bad, or Uncertain label
Every OPC UA DataValue can contain a value, timestamps, and a StatusCode. The severity class is Good, Uncertain, or Bad. The remaining bits can carry a specific subcode and information bits, such as monitored-item queue overflow, limit state, or changed semantics.
The SemanticsChanged bit can indicate that metadata such as engineering units changed and should be re-read before processing. A value of 100 is not comparable with the previous day's 100 if the unit or scale changed in between.
A flat pressure trend can hide a communication outage
In the source's example, a pressure transmitter normally reports around 5 bar. Communication to the device fails, but the historian path keeps writing a number without its quality status. The trend looks stable, the hourly average includes the number, and an investigator may conclude the process was steady during the outage.
The historian received a row, but only an incomplete representation of the measurement. Value, timestamp, and source quality belong together.
Uncertain data needs a use-specific policy, Bad data should not count as a normal sample
An Uncertain value may still show an operator direction or continuity. It may be unsuitable for custody transfer, compliance reporting, or a production total. The subcode and the business use determine the decision.
Bad values are not usable under OPC UA. Downstream calculations can exclude them, return a quality-aware result, or stop and flag the interval.
Preserve raw quality and document four decisions
Deleting every non-Good row at ingestion removes evidence of a source or communication fault. The source recommends preserving the received record and its quality, then applying rules in queries or curated datasets. Where practical, the raw StatusCode should be retained alongside any derived severity field.
Teams should document four points:
- Which source StatusCode field enters the collector.
- Which raw or derived quality field reaches historian storage.
- Which severities and subcodes each calculation accepts.
- How reports identify excluded, uncertain, or missing intervals.
Interpolated or carried-forward values should be marked as calculated or substituted. Policy should also cover late corrections: whether historical calculations are recomputed and how the change stays auditable.
Test one tag end to end before scaling to thousands
The recommended check records the source value, timestamp, full StatusCode, and readable status name with an OPC UA client. These are compared against the collector's raw record and the destination row. Where the server supports it, teams should create known Good, Uncertain, and Bad conditions in a controlled environment. An average that excludes Bad data should differ from an unfiltered average when the test window contains a Bad sample.
TDengine exposes an optional quality_col but does not confirm full decoding
TDengine TSDB-Enterprise supports OPC UA ingestion through taosX. Its OPC UA CSV mapping reference includes an optional quality_col field that names the column storing OPC quality. If the field is left empty, no quality column is added.
The documentation does not state that every StatusCode subcode and information bit is decoded into separate historian fields. The source advises inspecting the value the connector version actually writes, comparing it with the source StatusCode, and documenting any transformation before building quality filters.