OPC UA over MQTT: Bridging Industrial Automation and IIoT Cloud Platforms

As industrial organizations push data from the shop floor to the cloud for analytics, AI, and enterprise integration, a critical question emerges: how do you connect OPC UA's rich, semantically structured data to the lightweight, publish-subscribe world of IIoT platforms? The answer is OPC UA PubSub over MQTT — a capability defined in Part 14 of the OPC UA specification that has become a cornerstone of modern IIoT architecture.

Why MQTT Matters in Industrial Contexts

MQTT (Message Queuing Telemetry Transport) was designed for constrained environments where bandwidth is limited and connections may be unreliable. Its publish-subscribe model means devices push data to a central broker, and any subscribed client can receive it — without the overhead of individual client-server sessions. This makes MQTT ideal for:

  • Edge-to-cloud data transport across variable-quality networks
  • Aggregating data from many devices to a single broker
  • Integration with cloud platforms like AWS IoT, Azure IoT Hub, and HiveMQ
  • Lightweight deployments on embedded Linux devices and gateways

The Problem with "Plain" MQTT in Industry

Standard MQTT sends raw payloads — bytes with no inherent meaning. Without a common semantic layer, every device vendor defines its own data format, making integration an expensive custom-engineering exercise. You know a value changed, but you don't know what it represents, what its engineering unit is, or whether it's valid.

How OPC UA PubSub Solves This

OPC UA PubSub introduces standardized message encoding on top of MQTT. Publishers (edge devices, gateways, PLCs) send data as OPC UA NetworkMessages — structured payloads that include:

  • NodeId: the unique identifier of the data item in the OPC UA address space
  • Value, StatusCode, and Timestamps: quality and timing metadata
  • Data type information: so consumers know exactly what they're receiving

Messages can be encoded in UADP (binary, compact) or JSON (human-readable, cloud-friendly) format, giving architects flexibility based on bandwidth and integration requirements.

Sparkplug B: The Practical Alternative

Before OPC UA PubSub was widely available, the industry widely adopted Sparkplug B — a specification developed by Eclipse Foundation that also defines a semantic layer on top of MQTT. Sparkplug B remains popular, especially in brownfield IIoT deployments, and many edge platforms support it natively. OPC UA PubSub and Sparkplug B serve similar goals, and today some tools bridge between the two.

Architecture Pattern: Edge Gateway Model

A common deployment pattern for OPC UA over MQTT looks like this:

  1. Field Level: PLCs and devices communicate via OPC UA Client-Server (or native protocols) to an edge gateway
  2. Edge Gateway: Collects OPC UA data and republishes it as OPC UA PubSub messages over MQTT to a broker
  3. MQTT Broker: Routes messages to cloud or on-premises subscribers
  4. Cloud/Enterprise: Subscribing applications process structured OPC UA data for analytics, dashboards, or ERP integration

Security Considerations

OPC UA PubSub over MQTT inherits security from both layers:

  • Transport security: TLS 1.2/1.3 for the MQTT connection
  • Message security: OPC UA message signing and encryption (optional but recommended)
  • Authentication: MQTT username/password or certificate-based client authentication

Getting Started

Many modern OPC UA SDKs and edge platforms support PubSub natively, including Unified Automation, Eclipse Milo (open source Java), and commercial gateways from vendors like Kepware, Softing, and Prosys. The OPC Foundation also provides a free Reference Implementation and companion specifications for specific industries (e.g., machinery, robotics) that extend the base PubSub model.

For teams beginning their IIoT journey, OPC UA over MQTT represents the most standards-aligned, future-proof path to connecting the shop floor with the cloud — without sacrificing the semantic context that makes data genuinely useful.