OPC UA and MQTT: How Factory Data Reaches Your Analytics

Separate meaning from message transport

A temperature value of 75 needs a machine, sensor, unit, timestamp and quality context. Without them, the receiver cannot safely distinguish degrees Celsius from degrees Fahrenheit or a current reading from a buffered one.

OPC UA models industrial information and supports several communication patterns. MQTT distributes messages through topics and a broker. The OPC Foundation explicitly supports integration between them; its Cloud Initiative includes a 2026 reference architecture and an OPC UA over MQTT working group.

The existing industrial IoT guide covers the wider system. This guide focuses on preserving the data contract between collection and analysis.

Choose a supported pattern, not a slogan

An OPC UA client can read or subscribe to server data and pass it through an edge application. Alternatively, a supported OPC UA PubSub implementation can publish a defined dataset using MQTT. These are different integration designs; name the one your equipment and software actually support.

MQTT does not supply an industrial information model simply because its payload is JSON. A custom JSON contract can be useful, but it is not automatically compliant OPC UA PubSub. The OPC Foundation’s IIoT StarterKit gives a concrete compliant publisher example.

Confirm encoding, topic conventions, metadata versions and consumer compatibility before choosing an implementation. Do not assume a protocol checkbox in two products proves interoperability.

Specify what a receiver must know

Illustrative data contract for an analytics-only shaft counter: machine P-07 reports a cumulative accepted-unit count of 412 at a source timestamp of 10:15:00 UTC. An edge record arrives five seconds later. The arrival time must not replace the source time silently.

The fields below are a teaching contract, not a prescribed OPC UA wire format. A production implementation should retain the actual source status, versioning and identity provided by its documented model.

Test reconnects, duplicates and stale values

OASIS MQTT defines delivery quality levels. At-least-once delivery can produce duplicates. Even exactly-once protocol delivery is not a guarantee that your end-to-end database and business calculation process every real event exactly once.

A retained value can be delivered to a new subscriber long after its measurement time. Preserve source timestamps and define freshness; use supported expiry mechanisms where appropriate. Missing data should remain missing, rather than become a zero that looks like a stopped line.

An unchanged OPC UA value can retain an older source timestamp while the source remains healthy. Use appropriate acquisition status, server time or heartbeat evidence as well; an old change timestamp alone does not prove an outage.

Test cumulative-counter resets, reordered events, lost connections and invalid quality. Different failures need different handling rules.

1. Define one analytical use

   Start with a read-only measure and name its acceptable delay, validity and reporting boundary.

2. Document the contract

   Record asset IDs, data types, units, time semantics, quality, schema and event identity.

3. Test abnormal delivery

   Simulate disconnects, replay, duplicates, stale retained values, resets and invalid source status.

4. Reconcile with a trusted record

   Compare accepted-unit changes and time windows with an independently checked production record before expanding.

Keep control and safety outside the experiment

An analytics pipeline should not become a route for unreviewed machine commands. Access, certificates, authorization, network segmentation and supported security configurations need site ownership and competent review.

This example is not a deterministic control design. A cloud dashboard’s delivery delay and availability can be acceptable for trend analysis while unsuitable for a control or safety function. State that boundary explicitly.

Judge the pipeline by usable evidence

Track freshness, quality status, missing intervals, duplicates rejected and schema mismatches. Raw message count is a poor success metric if the same old value arrives many times.

Once the record is trustworthy, manufacturing analytics and production monitoring can answer the operational question. Start with one machine and one reconciled measure, then expand the contract deliberately.