Summary
The AVEVA Adapter for MQTT currently allows a custom field to be defined for mapping the timestamp from a JSON payload. We request the same capability for data quality: a configurable data selection property that identifies which payload field carries quality, and maps its value to the PI Data Archive quality (Good, Questionable/Uncertain, Bad) when data is written through OMF.
Background / Problem
MQTT has no standard quality attribute, but many custom publishers (industrial gateways, edge platforms, OPC UA-to-MQTT bridges, Sparkplug-style and custom JSON payloads) include a quality or status value alongside each value and timestamp. Today the adapter has no way to consume it, so:
Every value is treated as good, even when the source flagged it as bad or uncertain.
Downstream PI consumers (PI Vision, PI AF analytics, Seeq, reporting, GxP/regulated data reviews) cannot distinguish trustworthy data from stale, substituted, or failed readings.
Customers must build workarounds, such as splitting quality into a separate PI tag or pre-processing payloads outside the adapter, which adds complexity and points of failure.
Proposed solution
Add an optional quality mapping property to the MQTT data selection configuration, alongside the existing timestamp field mapping:
Quality field path: A JSON path (or field name) in the payload that contains the quality value, consistent with how the timestamp field is specified.
-
Mapping standard: Interpret the value using the current OPC UA specification for status codes (OPC UA Part 4 / Part 8), where the severity bits define the category:
Good: 0x00xxxxxx
Uncertain: 0x40xxxxxx
Bad: 0x80xxxxxx
Accepted input formats: Numeric StatusCode (e.g., 0, 0x80000000), and ideally simple string values ("Good", "Uncertain", "Bad").
Output: Map to the corresponding PI quality state on the OMF egress (Good, Questionable, Substituted/Bad as applicable), including the ability to write a Bad/system-state value for failed readings.
Default behavior: If the quality field is absent or not configured, behavior is unchanged (backward compatible). The adapter should define and document what happens for unrecognized values (for example, default to Uncertain and log a warning).
Who benefits
Any customer ingesting MQTT data from sources that publish quality or status, especially regulated manufacturing (GxP) environments where data integrity and quality flags must be preserved end-to-end from source to historian.
Business value
Preserves source data quality through to the historian and downstream analytics.
Eliminates custom pre-processing and additional tags.
Aligns MQTT ingestion with the quality handling already available in OPC UA-based collection.
Supports data integrity expectations in validated systems.
Example payload
json
{ "tag": "Reactor01.Temp", "value": 72.4, "timestamp": "2026-09-29T14:32:10Z", "quality": 0}
With quality mapped, a value of 0 is written as Good, 0x40000000 as Uncertain, and 0x80000000 as Bad.
