OPC UA Pub/Sub: MQTT vs UADP Transport Comparison (2026)

The industrial IoT landscape transformed when the OPC Foundation released OPC UA Part 14 (Pub/Sub) in 2018. For decades, OPC UA lived in a client-server request-response paradigm—efficient for supervisory control, clunky for continuous sensor streaming. Part 14 flipped the model. Now millions of data points can be published to thousands of subscribers with sub-millisecond determinism, bridging the gap between deep automation and cloud telemetry.

But Part 14 introduced a fork: OPC UA Pub/Sub MQTT vs UADP transport—two fundamentally different architectures. UADP (Unified Architecture Data Package) runs as binary-encoded UDP/IP multicast or Ethernet direct, paired with IEEE Time-Sensitive Networking (TSN) for hard real-time guarantees. MQTT uses a broker as a hub, speaks JSON or binary, runs over TCP, and plays nicely with IT infrastructure. Neither is objectively “better.” They’re tuned for different problems.

This post dissects both. We’ll map the message structures, measure latency budgets, compare security models, and show you decision trees to pick the right one for motion control, telemetry gateways, SaaS platforms, and edge analytics.

What this post covers:
– The OPC UA Pub/Sub architecture (Part 14 concepts).
– UADP deep dive: UDP multicast, TSN, binary encoding, sub-millisecond loops.
– MQTT deep dive: broker mediation, topic conventions, TLS, cloud integration.
– Head-to-head comparison: transport, determinism, security, scalability, operational burden.
– Trade-offs, failure modes, and vendor stack maturity.
– Decision tree for your deployment.
– FAQ and further reading.

OPC UA Pub/Sub: A Quick Refresher

OPC UA Pub/Sub (Part 14 of the OPC UA specification) inverts the traditional request-response model. Instead of a PLC polling a sensor every 100ms, the sensor broadcasts its data to anyone listening. This shift matters deeply for industrial IoT.

At the core sit four concepts:

PublishedDataSet — a logical group of typed variables (temperature, flow rate, setpoint). Defined once, published repeatedly.
DataSetWriter — a publisher endpoint that pushes a PublishedDataSet on a cadence (e.g., every 10ms).
WriterGroup — a collection of DataSetWriters that share transport and security parameters (e.g., all sent over the same UDP multicast group or MQTT topic prefix).
DataSetReader and ReaderGroup — mirror concepts on the subscriber side. Readers filter and decode the incoming stream; ReaderGroups coordinate with their parent transport.

The payload itself—the actual sensor values and timestamps—is wrapped in three layers:

DataSetMessage — typed fields with metadata (writer ID, sequence number, timestamp).
NetworkMessage — contains one or more DataSetMessages, adds security footers, writer group headers.
Transport payload — this is where the fork happens. The NetworkMessage is either serialized as UADP binary and pushed into UDP/Ethernet, or JSON-encoded and published to an MQTT topic.

Two encoding flavors exist: UADP binary (OPC-defined, compact) and JSON (human-readable, interoperable with any MQTT tool). Most performance-critical deployments use UADP binary over UADP transport; MQTT with JSON offers the broadest ecosystem.

Reference Architecture

A single OPC UA application (typically a PLC, motion controller, or gateway) publishes a PublishedDataSet. The WriterGroup forks the data onto two paths simultaneously:

Path A: UADP/UDP multicast — The NetworkMessage is UADP-encoded and sent as a UDP packet to a multicast address (e.g., 239.192.1.1:4840). Any subscriber on the same L2 segment (or with IGMP snooping bridging) receives it with < 5ms latency, deterministically.
Path B: MQTT/TCP broker — The same data is JSON-serialized and published to an MQTT topic (e.g., opcua/production-line-1/plc-1/data). The broker relays to any connected subscriber over TLS. Latency is now 50–500ms depending on broker load and network distance.

Both happen from the same logical source. Both can be consumed by OPC UA readers. The difference lies in guarantees and operational model.

UADP Transport Deep Dive

UADP is the native OPC UA encoding for Pub/Sub. It is a tightly packed binary format defined in Part 14 that encodes network and dataset messages into as few bytes as possible.

Message Structure

A UADP NetworkMessage has the following skeleton:

[NetworkMessage Header (1-2 bytes)]
  [GroupHeader, optional]
  [PayloadHeader, optional]
  [DataSetMessage 1]
    [sequence number, timestamp, fields...]
  [DataSetMessage 2]
    [...]
  [SecurityFooter, if encrypted]

The header is a bitmask. Bit 0 signals “group header present”; bit 1 signals “payload header”; bit 7 indicates encryption. A typical 32-byte UADP message carrying four 32-bit sensor values, a timestamp, and a sequence number uses:

2 bytes header
2 bytes group ID (if applicable)
1 byte payload flags
4 bytes timestamp (milliseconds since epoch)
2 bytes sequence number
16 bytes payload (4 × 4-byte floats)
Total: ~27 bytes before any security footer.

An equivalent JSON message (with schema included) is 150–200 bytes. UADP is 6–10× smaller.

Transport: UDP/IP or Raw Ethernet

UADP messages travel in one of three ways:

UDP/IP multicast — standard router-friendly approach. Address range 224.0.0.0/4 (239.x.x.x for private). Requires IGMP snooping on managed switches to avoid flooding. Sub-5ms round-trip latency within a factory LAN.
UDP/IP unicast — one writer to many readers. Adds network overhead but works in any network. Latency similar to multicast.
Raw Ethernet + TSN (802.1Qci, 802.1Qch) — OPC Foundation Field Level Communications (FLC) initiative supports direct Ethernet frames (no IP layer). Paired with IEEE 802.1 Time-Sensitive Networking, this gives deterministic, sub-1ms latency with bounded jitter < 1µs for critical control loops. Requires TSN-capable switches and endpoints (automotive, robotics grade).

Determinism & TSN Integration

UADP + TSN is the only option in OPC UA Pub/Sub for hard real-time guarantees. TSN adds scheduling:

Time-Aware Shapers (802.1Qbv) — Reserve a time window in the switch for UADP traffic. During that window, no best-effort traffic is forwarded; only reserved packets.
Preemption (802.1Qbu) — High-priority UADP packets can interrupt best-effort frames mid-transmission, resuming after.
Per-Stream Filtering & Policing (802.1Qci) — Enforce per-source, per-destination rate limits to prevent runaway publishers.

A motion control loop using UADP+TSN can publish every 1ms, with jitter < 100µs, supporting reactive servo feedback at 1000 Hz. MQTT cannot touch this.

Security: DTLS & SecurityKeyService

UADP messages are encrypted with DTLS 1.2 (Datagram TLS) if the SecurityMode is not None. Unlike MQTT’s TCP-based TLS, DTLS runs over UDP and tolerates packet loss without connection drops.

Key distribution happens via a SecurityKeyService (also an OPC UA application). Publishers and subscribers connect to the KeyService, authenticate (X.509 or username/password), and receive a rotating symmetric key (e.g., AES-256 in GCM mode). The key changes every few minutes or on demand, ensuring that even if a key leaks, exposure is limited.

This mechanism is robust but rare in open-source stacks. open62541 (the most widely used OSS stack) supports DTLS encryption but not SecurityKeyService key rotation; production deployments often use Unified Automation’s .NET SDK or Siemens Industrial Edge runtime, which implement the full spec.

MQTT Transport Deep Dive

MQTT (Message Queuing Telemetry Transport) is a lightweight pub-sub protocol originally designed for wireless sensor networks. OPC UA Part 14 adopted it as an alternative transport for Pub/Sub, making OPC UA data accessible to any MQTT-aware system: Node-RED, AWS IoT Core, Azure IoT Hub, Kafka bridges, etc.

Topic Conventions & Payload

OPC UA Pub/Sub MQTT uses a defined topic structure:

opcua/{PublisherId}/{WriterGroupId}/{DataSetWriterId}/{fields}

Example:

opcua/urn:example:factory-1/plc-main/temp-sensor/value
opcua/urn:example:factory-1/plc-main/temp-sensor/timestamp

Each MQTT message carries one or more fields. The payload is either:

JSON — human-readable, schema-free, typically 100–300 bytes per publish.
UADP binary — same binary format as UDP UADP, but wrapped in MQTT. Payload ~27–60 bytes.

Most public deployments use JSON for observability. Bandwidth-constrained scenarios (10,000+ sensors to a cloud platform) prefer UADP binary in MQTT.

MQTT Broker: Single Point of Everything

The MQTT broker (Mosquitto, HiveMQ, EMQX, AWS IoT Core) sits in the middle. All publishers connect to it (TLS, username/password, X.509 client certs). All subscribers do the same. The broker holds the subscriptions and fan-outs on every publish.

Advantages:
– IT-friendly — firewall rules are simpler (inbound TCP 8883 or 443). No multicast magic.
– Scalable subscriptions — one publisher to millions of subscribers costs the broker CPU/RAM, not network bandwidth.
– Cloud native — cloud platforms (AWS, Azure, GCP) provide hosted MQTT brokers; easy hybrid deployment.
– Observability — broker logs every publish/subscribe, enabling audit trails and dashboards.

Disadvantages:
– Latency variability — broker processing time adds 10–50ms depending on load. Burst subscribes or big messages cause jitter.
– Single point of contention — if the broker saturates, all subscribers starve equally.
– Extra hop — TCP/IP round trip adds ~5–20ms network latency vs. LAN multicast.

MQTT QoS & Delivery Guarantees

MQTT offers three QoS levels:

QoS	Guarantee	Use Case
0	At most once (fire and forget)	Telemetry, non-critical sensor data
1	At least once (ack, retransmit if needed)	Sensor events, alarms
2	Exactly once (4-way handshake)	Financial transactions, mission-critical

OPC UA Pub/Sub MQTT typically runs QoS 1 for reliability without the overhead of QoS 2. Dropped messages trigger a re-subscribe; missed data points are lost, but connection state is recovered.

Security: TLS + SAS / X.509

MQTT connections are encrypted with TLS 1.2 or 1.3. Authentication uses:

Username/password — simple, common in edge deployments.
X.509 client certificates — strong, required for production SaaS platforms.
SAS tokens (Shared Access Signatures) — cloud platforms like Azure IoT Hub use SAS tokens, tied to device identity and rotating periodically.

OPC UA Pub/Sub MQTT leaves authentication to the broker implementation. There is no OPC-defined SecurityKeyService equivalent for MQTT; instead, the broker’s IAM system (OAuth2, LDAP, cert-pinning) handles it.

Direct Comparison: UADP vs MQTT

Transport Layer

Aspect	UADP	MQTT
Underlying protocol	UDP/IP or raw Ethernet	TCP/IP
Connection model	Stateless datagram	Stateful, persistent connection
Multicast/unicast	Both (multicast efficient, unicast flexible)	Broker-mediated (many-to-many via hub)
Firewall friendly	Multicast is restrictive; unicast is simpler	Very friendly (standard TCP)
Network diameter	LAN to WAN unicast; multicast LAN only	LAN to WAN (broker-mediated)

Winner: MQTT for cloud integration and firewall traversal. UADP for LAN-local, high-density, low-latency clusters.

Determinism & Latency

Aspect	UADP	MQTT
Sub-ms determinism	Yes (with TSN)	No (broker jitter)
Typical latency	1–5ms (LAN multicast); 0.1–1ms (TSN)	50–500ms (depends on broker)
Jitter	< 100µs (TSN); < 5ms (best-effort)	10–100ms common
Packet loss	Low (UDP in managed LAN)	Handled by MQTT retransmit
Real-time suitable	Yes (TSN)	Only for soft real-time (1–10s loops)

Winner: UADP for motion control, robotics, safety-critical. MQTT for supervisory, telemetry, non-critical feedback.

Encoding Overhead

Aspect	UADP binary	MQTT JSON	MQTT UADP binary
Typical message size	27–60 bytes	150–300 bytes	50–80 bytes
Overhead ratio	1× baseline	5–10×	2–3×
CPU cost to serialize	Low (bit packing)	Medium (JSON encoder)	Low (same as UADP)

Winner: UADP binary (native or in MQTT). MQTT JSON for observability, tooling integration.

Security Model

Aspect	UADP	MQTT
Encryption	DTLS 1.2 over UDP	TLS 1.2/1.3 over TCP
Authentication	X.509 or username/password	X.509 or SAS tokens
Key rotation	SecurityKeyService (symmetric key, < 5min)	Broker IAM (external)
Multicast security	Symmetric key shared among group	N/A (broker controls access)
Audit trail	Limited (app-level logging needed)	Broker logs all pub/sub

Winner: MQTT for audit/compliance. UADP for air-gap, deterministic security.

Scalability

UADP multicast:
– Publisher sends once; switches replicate.
– Bandwidth scales with number of publishers, not subscribers.
– 10,000 subscribers to one stream = one multicast message on the wire.

MQTT:
– Broker fan-out: for each publish, broker sends one message per subscriber.
– Bandwidth scales with publishers × subscribers.
– 1 publisher to 10,000 subscribers = 10,000 MQTT messages queued/transmitted.

For few publishers, many subscribers: UADP multicast wins (1:N efficiency). For many producers, few consumers: MQTT is fine.

Operational Complexity

Aspect	UADP	MQTT
Network config	IGMP snooping (if multicast); TSN optional	TCP, no special switches
Debugging	Packet captures, tcpdump, Wireshark	MQTT debug clients, broker UI
Monitoring	Limited (app-level)	Rich (broker dashboards)
Learning curve	Steep (TSN, multicast, binary encoding)	Moderate (MQTT well-understood)
Vendor variety	Few (Siemens, Unified Automation, open62541)	Many (HiveMQ, EMQX, AWS, Azure)

Winner: MQTT for ops familiarity and debugging. UADP for performance.

Trade-offs & Failure Modes

UADP Pitfalls

IGMP snooping misconfiguration — if switches don’t snoop IGMP, multicast floods the entire VLAN, crushing non-real-time traffic. Requires careful L2 planning.
SecurityKeyService not in open-source — open62541 can encrypt with DTLS but doesn’t implement symmetric key rotation. Production deployments on budget need to engineer a workaround or license Unified Automation.
Cross-subnet multicast — multicast does not route well across subnets. Unicast works but loses efficiency. MQTT has no such limitation.
Debuggability — UADP binary format is opaque to standard tools. You need OPC UA–aware packet analyzers or custom logging.
Mixed transport burden — if you have both UADP and MQTT publishers in the same system, subscribers must handle two encoding/transport stacks, or a gateway must translate.

MQTT Pitfalls

Broker as bottleneck — a single broker instance becomes a choke point. Clustering helps but adds complexity (dual networks, consensus overhead).
Latency tail — publish latency is unpredictable because it’s tied to broker load. SLAs are hard to guarantee.
Payload inflation — JSON encoding adds 5–10× overhead. For 10,000 sensors at 1Hz each, that’s 50–100 Mbps of network traffic vs. 5–10 Mbps with UADP binary. Cloud egress costs spike.
Ordering guarantees — MQTT does not guarantee ordering across multiple topics or subscriptions. If a reader is slow, messages may arrive out-of-order.
LAN performance not optimized — MQTT over TCP is wasteful for LAN-local subscribers that could use multicast. Every message traverses the full TCP stack.

Recommendations: Choose Based on Your Use Case

UADP: Hard Real-Time & Motion Control

Use UADP+TSN if:
– Control loop frequency > 100 Hz (servo, motion, robotics).
– Jitter budget < 5 ms.
– Latency budget < 10 ms.
– All subscribers are on the same factory LAN.

Example: A motion controller publishing joint angles every 1ms to 20 servo drives and a vision system. UADP multicast + TSN guarantees all drives see the data within 100µs, in lock-step.

Implementation path:
– Use Unified Automation OPC UA SDK or Siemens PLCSIM Advanced / Industrial Edge.
– Configure TSN on switches (Hirschfeld, Moxa, Phoenix Contact make TSN-capable managed switches).
– Validate with ETAS ISOLAR-A or Wireshark TSN plugin.

MQTT: Cloud Telemetry & Multi-Tenant SaaS

Use MQTT if:
– Data flows to the cloud (AWS, Azure, GCP).
– Subscribers are geographically distributed.
– You need per-subscriber fine-grained access control (cloud IAM).
– Observability and audit trails are regulatory requirements.
– Your team already knows MQTT (Node-RED, Kafka, InfluxDB integrations).

Example: A plant monitoring dashboard ingesting pressure, temperature, and energy from 100 factories. MQTT over TLS to AWS IoT Core, then Lambda → DynamoDB → Grafana. Latency is 200ms; jitter doesn’t matter because it’s supervisory.

Implementation path:
– Pick a cloud MQTT broker (AWS IoT Core, Azure IoT Hub, EMQX Cloud) or self-host Mosquitto/HiveMQ.
– Use OPC UA Pub/Sub MQTT adapters from your PLC vendor (Siemens S7-1500F has built-in).
– Wire up Node-RED or Python PAHO MQTT client for data transformation.

Hybrid: Multi-Transport Gateway

Use both if:
– LAN has deterministic UADP subscribers (motion, vision).
– Cloud has eventual-consistency MQTT subscribers (analytics, dashboards).
– You can run a gateway process to translate.

Example: Factory floor runs UADP for servo loops; gateway translates to MQTT for cloud. The gateway is a stateless relay that:
1. Listens on UADP multicast (UDP 239.192.1.1:4840).
2. Decodes NetworkMessages.
3. Re-publishes to MQTT broker as JSON.

Latency adds ~20–50ms (gateway processing), acceptable for cloud workloads.

Implementation: open62541 or Unified Automation SDK with custom bridging logic in C/C++, Node.js, or Python.

Vendor & Open-Source Stack Status (2026)

Mature Implementations

Vendor	Platform	UADP	MQTT	TSN	License
open62541	C/POSIX	✓	✓	—	MPL 2.0
Unified Automation	.NET/C++/Java	✓	✓	✓	Commercial
Eclipse Milo	Java	✓	✓	—	EPL 1.0
Siemens Industrial Edge	Linux containers	✓	✓	✓	Commercial
AWS IoT SiteWise	Managed	—	✓	—	AWS service
Beckhoff TwinCAT	Windows/Linux	✓	✓	✓	Commercial

open62541 (BSD, most-used OSS):
– Supports both UADP and MQTT transports.
– UADP encoding/decoding is complete; no SecurityKeyService.
– MQTT client built on Paho.
– Suitable for prototypes and educational deployments; production needs vendor support for TSN & key rotation.

Unified Automation (commercial):
– Tier-1 implementation; full Part 14 including SecurityKeyService & TSN.
– Available for C++, .NET, Java. Extensive examples.
– High cost ($5k–$50k licenses) but worth it for mission-critical deployments.

OPC Foundation FLC (Field Level Communications) Initiative (2021+):
– Defines TSN profile for OPC UA Pub/Sub.
– Working group includes Siemens, Beckhoff, Moxa, Hirschfeld.
– Reference implementations on GitHub (early stage as of 2026).

Adoption Trends

UADP adoption in manufacturing: strong in discrete automation (automotive, robotics). Soft real-time control (process, utilities) still prefers modbus or proprietary.
MQTT adoption in IoT: dominant in cloud-connected deployments. Every major cloud platform offers MQTT; ecosystems (Node-RED, Telegraf, Kafka) integrate easily.
Hybrid deployments growing: large multi-site operations run UADP locally, MQTT to cloud.

FAQ

What’s the difference between OPC UA Pub/Sub and OPC UA Classic (request-response)?

OPC UA Classic (Part 4) is client-server. A client (SCADA, HMI) polls a server (PLC) for values. Round-trip latency is 10–100ms; bandwidth scales with polling frequency. Pub/Sub (Part 14) inverts this: the server publishes asynchronously, and clients subscribe. No polling. Latency is 1–1000ms depending on transport. Pub/Sub is more efficient for high-frequency, many-to-many data flows; Classic is simpler for occasional, request-driven reads.

Can I run OPC UA Pub/Sub over WebSockets?

Not natively in Part 14. WebSockets are TCP-based, so technically you could tunnel UADP or MQTT over WS for browser compatibility. Some vendors (e.g., Unified Automation) offer WebSocket bridges. For true browser integration, MQTT over WebSocket is standard (most cloud brokers support it).

Does AWS IoT support OPC UA Pub/Sub?

AWS IoT Core is an MQTT broker, so OPC UA Pub/Sub over MQTT works seamlessly. AWS IoT SiteWise (their industrial data platform) has connectors for OPC UA Classic (request-response) but not yet native Pub/Sub support. You can bridge manually with Lambda or EC2 gateway instances.

What’s the latency budget for UADP+TSN in a control loop?

Typical: 1 ms publish + 0.5–1 ms TSN transmission + 0.5 ms subscriber processing = 2–3 ms total. For 1 kHz servo loops, you have 1 ms budget; UADP+TSN fits with margin. For 10 kHz loops, you need custom real-time extensions (not standardized in OPC UA yet).

How do I secure UADP key distribution?

Run a SecurityKeyService (another OPC UA app) that publishers and subscribers authenticate to. The service maintains a symmetric key per group, rotating it every few minutes. This is the OPC Foundation recommendation but rare in OSS. Alternatives: (1) pre-share keys in configuration (air-gap security model); (2) use TLS at the network level (IPSec between subnet pairs) instead of UADP-level encryption.

OPC UA Pub/Sub over MQTT vs MQTT Sparkplug B — which do I pick?

Sparkplug B is a MQTT payload schema (JSON-based) for IIoT, popular with Node-RED and MQTT Brokers (EMQX, HiveMQ). OPC UA Pub/Sub MQTT is OPC’s native schema. Sparkplug B is simpler, better for non-OPC systems. OPC UA Pub/Sub MQTT offers richer type information and integration with OPC UA servers. If your ecosystem is already Sparkplug (Ignition, Kepware), stay there. If you’re building OPC UA–native architecture, use OPC UA Pub/Sub.