OPC UA vs MQTT: Which IIoT Protocol Belongs in Your Architecture?

Why This Matters

Legacy plant networks ran Modbus RTU and PROFIBUS — protocols designed for deterministic PLC-to-device communication within a closed control network. IIoT expands the requirement: data must flow from PLCs to MES systems, cloud analytics platforms, digital twin applications, and mobile dashboards, often traversing firewalls and WAN links.

Two protocols dominate this newer layer: OPC UA and MQTT. Both run over TCP/IP and are firewall-friendly, but their design philosophies are fundamentally different.

OPC UA Deep Dive

What OPC UA Is

OPC Unified Architecture (OPC UA) is a platform-independent, service-oriented communication standard defined by the OPC Foundation and standardised as IEC 62541. It combines a client-server information model with a Publish/Subscribe transport added in version 1.04.

The key differentiator of OPC UA is its address space: a hierarchical namespace of Nodes that can represent variables (real-time values), objects (logical groupings), methods, events, and data types. This semantic layer means a client can discover what data is available, what units it's in, what the valid range is, and how it relates to other data — all programmatically, without reading documentation.

OPC UA Architecture

In the classic Client-Server model:

• An OPC UA Server runs on or alongside a PLC, DCS, or SCADA server. It exposes the address space via a TCP endpoint (default port 4840).
• An OPC UA Client (SCADA, MES, historian, data analytics platform) connects, browses the namespace, subscribes to nodes, and receives MonitoredItem change notifications.

The Pub/Sub model (OPC UA Part 14) allows an OPC UA Publisher to push data to a message-oriented middleware (MQTT or AMQP broker) without clients connecting directly to the server — better for cloud and bandwidth-constrained scenarios.

OPC UA Information Models

Standard companion specifications define information models for specific industries:

• OPC UA for Robotics (EUROMAP)
• OPC UA for CNC (umati / DIN SPEC 91357)
• OPC UA for PackML (packaging machines)
• OPC UA for ISA-88 batch
• OPC UA for AutoID (RFID, barcode)

These models mean a machine from any vendor that implements the companion spec exposes data in a standardised structure — a turnkey vendor-neutral integration.

MQTT Deep Dive

What MQTT Is

MQTT (Message Queuing Telemetry Transport) is a lightweight pub/sub messaging protocol originally developed by IBM for satellite-linked SCADA in the late 1990s. It is standardised as ISO/IEC 20922 and is the dominant protocol for IoT device-to-cloud communication.

MQTT Architecture

MQTT is broker-centric:

• Publishers connect to a broker and post messages to topics (hierarchical strings, e.g., plant/line1/conveyor/speed)
• Subscribers connect to the broker and subscribe to topics using wildcards (plant/line1/#)
• The broker routes messages from publishers to all matching subscribers

Decoupling publishers and subscribers is MQTT's strength: adding a new analytics consumer requires no changes to the publisher (PLC) or existing subscribers. The broker handles fan-out.

MQTT Quality of Service

MQTT defines three QoS levels:

• QoS 0 — At most once (fire and forget, no acknowledgement)
• QoS 1 — At least once (acknowledged, possible duplicates)
• QoS 2 — Exactly once (four-way handshake, no duplicates)

For industrial telemetry, QoS 1 is the typical choice: lightweight but reliable delivery. QoS 2 is used for command-and-control where duplicate actuation commands are dangerous.

MQTT Limitations for Industrial Use

• No payload standard — MQTT says nothing about payload format. JSON, binary, Protobuf, CSV — anything goes. This makes interoperability difficult without an agreed payload convention (see Sparkplug B below).
• No semantic model — MQTT has no concept of data types, engineering units, or data quality. A subscriber receiving 42.7 on topic sensor/temp has no way to know if that is °C or °F, what the sensor range is, or if the value is stale.
• No discovery — clients cannot programmatically discover what topics are available.

Side-by-Side Comparison

ISA-95 Layer Placement

The ISA-95 / Purdue model helps clarify where each protocol belongs:

OPC UA is the standard protocol for the Level 2–3 boundary (PLC to SCADA). MQTT is the standard for the Level 3–4 or plant-to-cloud boundary. This placement is endorsed by the German RAMI 4.0 reference model and NAMUR Open Architecture (NOA).

Using OPC UA and MQTT Together

The most robust IIoT architecture uses both protocols in their native domains:

1. PLC exposes data via an OPC UA Server (or OPC UA is built into the PLC natively — Siemens S7-1500, Beckhoff TwinCAT, B&R Automation Runtime)
2. A plant historian or SCADA subscribes to tags via OPC UA Client connection
3. An edge gateway or OPC UA Pub/Sub Publisher reads the OPC UA address space and publishes JSON payloads to an MQTT broker
4. Cloud analytics, dashboards, and AI/ML platforms subscribe to the MQTT broker

This keeps the high-value semantic model (OPC UA) intact for plant-level integration while using MQTT's lightweight transport for the cloud layer. The edge gateway decouples the cloud from the control network — changes to cloud consumers require no changes to PLC code.

Sparkplug B

Sparkplug B (Eclipse Foundation, open specification) is an attempt to fix MQTT's lack of payload standardisation for industrial use. It defines:

• A topic namespace: spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
• A payload encoding: Protocol Buffers (Protobuf) with defined metric names, data types, timestamps, and quality flags
• Birth/death certificates: NBIRTH (node birth) and DBIRTH (device birth) messages define all metrics before data flows — enabling dynamic discovery similar to OPC UA browsing
• Last Will and Testament (LWT): MQTT LWT is used to signal device disconnection (NDEATH)

Sparkplug B makes MQTT viable for structured industrial telemetry without a full OPC UA stack. Popular with Ignition (Inductive Automation) MQTT-based SCADA deployments. If you are building a pure-MQTT plant-to-cloud pipeline, Sparkplug B is strongly recommended over ad-hoc JSON topics.

Security

OPC UA Security

OPC UA has security baked into the specification. Each server–client connection uses a Security Policy:

• None — no security (acceptable only for isolated lab/testing)
• Basic128Rsa15 — deprecated, avoid
• Basic256 — deprecated, avoid
• Basic256Sha256 — current minimum for production
• Aes128_Sha256_RsaOaep / Aes256_Sha256_RsaPss — stronger, preferred for new deployments

Authentication uses X.509 certificates — both server and client hold certificates that are mutually validated. Combined with Sign and Encrypt message security mode, OPC UA connections are authenticated, tamper-evident, and confidential.

MQTT Security

MQTT itself has no built-in security; it relies on:

• TLS (port 8883) for transport encryption
• Username/password or client certificates for authentication
• Broker ACLs for topic-level access control

Running MQTT on port 1883 without TLS is common in development but should never be used in production industrial environments where the broker is reachable from the internet or an untrusted network.

Selection Guide

Frequently Asked Questions

Can OPC UA and MQTT be used together?

Yes — and this is the recommended IIoT architecture for many plants. OPC UA handles PLC-to-MES/SCADA communication within the plant (Levels 2–3), while MQTT transports data from the plant to cloud platforms or edge computing nodes. OPC UA over MQTT (Pub/Sub transport) also combines both protocols.

Is OPC UA encrypted by default?

OPC UA has built-in security: certificate-based authentication, signed and encrypted message modes (Basic256Sha256 policy). Security is optional in specification but should always be enabled in production. MQTT security depends on the broker — TLS transport (port 8883) and username/password or client certificates are best practice.

What port does OPC UA use?

OPC UA Client-Server uses TCP port 4840 by default. OPC UA over HTTPS uses port 443. OPC UA Pub/Sub over MQTT uses whatever port the MQTT broker is configured on (default 1883 unencrypted, 8883 with TLS).

What is Sparkplug B?

Sparkplug B is an open specification (Eclipse Foundation) that defines a structured payload format and topic namespace for MQTT in industrial applications. It adds birth/death certificates for device state management, consistent metric naming, and Protobuf encoding — solving MQTT's lack of standardised payload structure.