OPC UA PubSub Explained: How It Works vs Client/Server
OPC UA PubSub explained — how publish/subscribe differs from client/server, transports (MQTT, UDP), when to use it, and its role in many-to-many IIoT data flows.
OPC UA PubSub is the publish-subscribe communication model defined in Part 14 of the IEC 62541 OPC UA specification. Instead of a client opening a session and polling a server for data, a publisher broadcasts DataSet messages onto a transport channel — MQTT broker, AMQP broker, or raw UDP/Ethernet — and any number of subscribers consume those messages without the publisher ever knowing who they are. The result is decoupled, many-to-many data flow purpose-built for IIoT, cloud integration, and controller-to-controller communication at scale.
OPC UA has always been more than a single protocol. The same standard that gives you a PLC server you can browse with UaExpert also gives you a streaming pub/sub engine that can feed a cloud data lake, a unified namespace, and a historian simultaneously — all from one PLC configuration. Understanding when and how to use each model is increasingly core knowledge for controls engineers working on Industry 4.0 projects.
What Is OPC UA PubSub?
OPC UA PubSub is a standardized publish-subscribe mechanism that is fully part of the OPC UA specification (IEC 62541-14). It is not a separate protocol or a bolt-on extension — it shares the same information model, security framework, and DataType system as OPC UA client-server. The difference is entirely in how data moves.
In PubSub, data is packaged into NetworkMessages — self-describing binary or JSON payloads that carry one or more DataSetMessages. A DataSetMessage maps to a PublishedDataSet, which is a named collection of OPC UA variable nodes on a device (for example, all process values from a mixing skid). Publishers emit these messages at a configured rate or on change. Subscribers receive them, decode them using the shared information model, and act on the values — with no request-response handshake involved.
Key terms you will encounter:
| Term | What it means |
|---|---|
| Publisher | Device or application that sends NetworkMessages (e.g., a PLC edge device) |
| Subscriber | Application that receives and processes NetworkMessages (e.g., a cloud historian) |
| PublishedDataSet | Named group of OPC UA nodes whose values are published together |
| DataSetMessage | The encoded payload for one PublishedDataSet inside a NetworkMessage |
| NetworkMessage | The outer envelope — one or more DataSetMessages plus header, sent over a transport |
| WriterGroup | Configures how and when a publisher sends (transport, message interval, encoding) |
| DataSetReader | Subscriber-side configuration — which publisher, which DataSet, what to do with data |
| Message-Oriented Middleware (MOM) | A broker like MQTT or AMQP that sits between publishers and subscribers |
The specification defines two encoding formats for NetworkMessages: UADP (a compact binary format optimized for low-overhead transport) and JSON (human-readable, easier to debug, slightly larger). Both carry full semantic context — EU ranges, engineering units, status codes, timestamps — inherited from the OPC UA information model.
Client/Server vs PubSub: The Two OPC UA Communication Models
OPC UA supports two distinct communication patterns and they solve different problems. Neither replaces the other; modern IIoT architectures often use both simultaneously.
OPC UA Client-Server
The client-server model is the original OPC UA communication pattern. A client opens a secure channel and session to a server (typically embedded in a PLC or gateway), then:
- Reads attribute values from nodes in the server's address space
- Writes values back to the server
- Subscribes to MonitoredItems — the server detects changes and sends notifications to the client (this is "subscriptions" within client-server, which is different from PubSub)
- Calls Methods on the server
- Browses the address space to discover available data
The critical characteristic is the point-to-point session. Each client maintains its own TCP connection to each server. The client drives the interaction. If the client goes offline, data stops flowing to that consumer.
OPC UA PubSub
PubSub inverts the relationship. The publisher does not know its consumers. It writes to a transport channel — a broker topic or a multicast address — and moves on. Subscribers independently declare interest and receive data.
| Characteristic | Client-Server | PubSub |
|---|---|---|
| Connection model | Point-to-point TCP session | Decoupled via broker or multicast |
| Who initiates data flow | Client requests / subscribes | Publisher pushes on schedule or change |
| Fan-out (1 source → N consumers) | Requires N sessions on the server | One publisher, unlimited subscribers |
| Consumer awareness | Server knows each connected client | Publisher has no knowledge of subscribers |
| Latency model | Configurable monitoring interval | Configurable publish interval, can be deterministic with TSN |
| Scalability | Limited by server session count | Scales horizontally at the broker |
| Addressability (browse, read, write) | Yes — full address space access | No — subscribers receive pushed data only |
| Control commands / writes | Yes | Not directly (PubSub is read/push only) |
| Typical use case | SCADA polling, HMI, commissioning tools | Cloud data pipelines, historian feeds, controller-to-controller |
The practical takeaway: use client-server when you need to read or write individual tags, browse the device, or send commands. Use PubSub when you need to fan out process data to many consumers efficiently, or when you are integrating with cloud and broker-based infrastructure.
How OPC UA PubSub Works
Understanding PubSub mechanics requires tracing data from its source to its consumer.
Step 1 — Define the PublishedDataSet
On the publisher (typically a PLC or edge gateway), an integrator configures a PublishedDataSet: a named list of OPC UA nodes to include. For example, a mixing reactor skid might have a dataset called ReactorSkid_01_ProcessValues containing temperature, pressure, flow rate, and agitator speed nodes. These map directly to the OPC UA address space variables on the same device.
Step 2 — Configure a WriterGroup
A WriterGroup defines the outbound channel and cadence:
- Which transport to use (MQTT broker at
mqtt://broker.plant.local:1883, UDP multicastopc.udp://239.0.0.1:4840, etc.) - How often to publish (the PublishingInterval — e.g., 500 ms)
- Which encoding to use (UADP binary or JSON)
- Security settings
Inside the WriterGroup, one or more DataSetWriters each map to a PublishedDataSet. Each DataSetWriter has its own DataSetWriterId — a numeric identifier that subscribers use to tell messages apart when multiple datasets travel over the same broker topic.
Step 3 — The Publisher Emits NetworkMessages
At each PublishingInterval, the publisher assembles a NetworkMessage: a binary or JSON envelope containing the header (PublisherId, WriterGroupId, sequence number, timestamp) and one or more DataSetMessages. For UADP, the header is compact — typically a few dozen bytes — making it efficient on constrained networks.
The publisher pushes the NetworkMessage to the transport. For MQTT, it publishes to a configured topic (e.g., opcua/plant/line1/skid01). For UDP multicast, it sends to the configured multicast group. The publisher's job ends there.
Step 4 — The Broker Fans Out (Broker-Based Transports)
When using an MQTT or AMQP broker, the broker holds the message and delivers it to every subscriber that has declared interest in that topic. This is where the fan-out happens — the publisher wrote once, and the broker delivers to ten, a hundred, or a thousand subscribers transparently.
Step 5 — Subscribers Decode DataSetMessages
Each subscriber configures one or more DataSetReaders specifying:
- The transport channel to listen on
- The PublisherId and DataSetWriterId of the publisher it is interested in
- A matching SubscribedDataSet — the target variables or DataSet fields to populate
When a NetworkMessage arrives, the subscriber filters it by PublisherId and WriterGroupId, then hands each DataSetMessage to the matching DataSetReader, which decodes the fields and writes the values to a local data store, historian, or variable binding.
Transports: Broker-Based vs Broker-Less
OPC UA PubSub deliberately separates the message format from the transport. The same NetworkMessage can ride over entirely different network stacks depending on the use case.
Broker-Based Transports: MQTT and AMQP
MQTT is by far the most common PubSub transport in industrial deployments today. It is lightweight, widely supported, and integrates naturally with cloud platforms (AWS IoT Core, Azure IoT Hub, HiveMQ, EMQX, Mosquitto). A PLC configured as an OPC UA PubSub publisher can connect to an MQTT broker and publish NetworkMessages to structured topics. Cloud subscribers, historians, and analytics platforms subscribe to those topics and receive OPC UA-structured payloads with full engineering-unit and timestamp context.
AMQP (Advanced Message Queuing Protocol) is used in enterprise integration scenarios, particularly where guaranteed delivery, message queuing, and transaction support are required. It is less common at the field level but well-suited for plant-to-enterprise integration.
The defining property of broker-based transport is decoupling: publisher and subscriber do not need to be online simultaneously. The broker buffers messages and delivers them when the subscriber reconnects. This makes MQTT-based OPC UA PubSub resilient to intermittent cloud connectivity — a common requirement at the edge.
Broker-Less Transports: UDP Multicast and TSN Ethernet
For controller-to-controller communication within the same network segment, OPC UA PubSub can run without any broker over UDP multicast or raw IEEE 802.3 Ethernet frames. This is where the protocol's determinism story becomes relevant.
UDP multicast allows a PLC to broadcast process data directly to all devices listening on a multicast group address with very low overhead. There is no TCP handshake, no session, no broker. Latency is bounded by the network hardware and switch configuration.
Time-Sensitive Networking (TSN) extends this further. TSN is a set of IEEE 802.1 Ethernet amendments (802.1Qbv, 802.1Qbu, 802.1CB, among others) that add time-synchronization, scheduled traffic shaping, and frame preemption to standard Ethernet. OPC UA PubSub over TSN can achieve sub-millisecond, jitter-controlled cycle times suitable for motion control and fast closed-loop applications — use cases that previously required proprietary fieldbuses like PROFINET IRT or EtherCAT.
| Transport | Broker Required | Typical Latency | Best For |
|---|---|---|---|
| MQTT | Yes | 10–200 ms (broker round-trip) | Cloud integration, UNS, historian |
| AMQP | Yes | 10–100 ms | Enterprise integration, queued delivery |
| UDP Multicast | No | < 5 ms (LAN) | Controller-to-controller, field-level fan-out |
| OPC UA PubSub + TSN | No (managed switches) | < 1 ms | Deterministic control, motion, fast loops |
When to Use OPC UA PubSub
PubSub is the right choice in four categories of scenario.
1. Many-to-many data distribution
When process data from a single PLC or skid needs to reach five different consumers — a cloud historian, a real-time dashboard, an MES, a quality system, and an AI analytics platform — client-server requires five separate sessions. The PLC must handle five concurrent clients, which strains its session count limit and creates O(N) load. With PubSub, the PLC publishes once; all five consumers subscribe independently. Adding a sixth consumer requires zero changes on the publisher.
2. Cloud and Unified Namespace integration
The unified namespace architectural pattern centralizes all plant data into a single MQTT broker hierarchy. OPC UA PubSub over MQTT is the natural on-ramp: PLCs publish semantically-rich OPC UA DataSet messages to the broker, and any IT or OT system subscribing to the namespace receives fully-described, contextualized data — not raw tag values but process values with engineering units, timestamps, and quality codes inherited from the OPC UA information model. This is the architecture driving most greenfield IIoT projects in 2026.
3. Edge-to-cloud with unreliable connectivity
A field device on a cellular or satellite link cannot maintain a persistent TCP session to a cloud OPC UA client reliably. With MQTT-based PubSub, the PLC publishes when connected; the broker queues messages; cloud subscribers receive them when connectivity restores. The publisher is fire-and-forget — no session maintenance, no reconnection logic in the PLC application.
4. Deterministic controller-to-controller communication
When two PLCs on the same TSN-capable Ethernet segment need to exchange process data with bounded, deterministic latency — for example, a press feeder coordinating with a transfer robot — OPC UA PubSub over TSN provides the mechanism without proprietary fieldbus dependencies. Both devices share the same OPC UA information model, and the exchange uses standard IEEE 802.1 Ethernet.
When to stay with client-server instead:
- You need to write values to a PLC (PubSub is read/push only)
- You need to browse an unknown device's address space at commissioning time
- You need to call Methods on the server
- You have a single SCADA or HMI that polls a handful of PLCs and does not need fan-out
OPC UA PubSub vs MQTT Sparkplug B
OPC UA PubSub over MQTT and Sparkplug B occupy overlapping territory — both use MQTT as a transport and both aim to bring structure to industrial data. Understanding the difference matters when choosing an architecture.
Sparkplug B is an MQTT application-layer specification from the Eclipse Foundation that defines a standardized topic namespace (spBv1.0/{group}/{message_type}/{edge_node_id}/{device_id}), a Protobuf payload schema, and state-management semantics (Birth/Death Certificates, Last Will and Testament). It was designed specifically for MQTT-native IIoT and is lighter to implement on resource-constrained devices.
OPC UA PubSub is part of the broader IEC 62541 OPC UA standard. Its payloads carry the full OPC UA information model — DataTypes, Engineering Units, Value Ranks, Status Codes — and its security model extends OPC UA's certificate-based authentication. It is more expressive but also heavier, and implementation requires an OPC UA stack.
In practice, many architectures use both: a Sparkplug-enabled MQTT broker as the unified namespace backbone for lightweight edge devices, and OPC UA PubSub for higher-capability PLCs that already run an OPC UA server and need rich semantic payloads. For a detailed side-by-side, see the MQTT Sparkplug vs OPC UA comparison.
The Controls Engineer's View: PubSub in Practice
The traditional polling pattern looks like this: a SCADA system opens a session to each PLC, subscribes to MonitoredItems, and the server sends change notifications back. This works well for one-to-one relationships but does not scale to cloud-era data volumes and consumer counts.
With OPC UA PubSub, the flow inverts. The PLC — or an OPC UA-capable gateway sitting in front of legacy hardware — is configured with a PublishedDataSet containing the relevant process variables. A WriterGroup points at the plant's MQTT broker with a 1-second publish interval. The broker topic might be opcua/plant/line3/skid12/processvalues.
From that point, every consumer on the network — the cloud historian, the real-time OEE dashboard, the ML inference service, the energy management system — subscribes to that topic. Each gets the same DataSet message: temperature, pressure, flow, agitator speed, with timestamps and status codes, at 1-second resolution. Adding or removing a consumer is a broker configuration change, not a PLC configuration change.
For IIoT and PLC integration projects, this shift from pull to push dramatically simplifies the data infrastructure. The PLC is no longer a server handling concurrent sessions; it is a data source broadcasting to an open channel. The broker handles the fan-out, buffering, and delivery.
Compare this to the alternative: a polling SCADA with a direct OPC UA client-server connection to the same PLC, plus a separate historian client session, plus an MES adapter session, plus a cloud connector. Each session consumes PLC resources. Each consumer's polling rate creates independent load. The PLC must be sized for the maximum concurrent session count. PubSub collapses that fan-out complexity to a single outbound connection.
For the PLC communication protocols landscape more broadly, OPC UA PubSub represents the convergence of OT data semantics with IT messaging infrastructure — the point where an IEC 62541-compliant information model rides an IETF-standard protocol (MQTT or AMQP) to a cloud-native data platform.
Frequently Asked Questions
What is OPC UA PubSub?
OPC UA PubSub is the publish-subscribe communication model defined in IEC 62541-14. Publishers send DataSet messages containing OPC UA variable values to a transport channel — MQTT broker, AMQP broker, or UDP multicast — without knowing who the subscribers are. Subscribers independently receive and decode those messages. It enables one-to-many and many-to-many data distribution without requiring point-to-point sessions between every producer and consumer.
How is OPC UA PubSub different from client-server?
In OPC UA client-server, a client opens a TCP session to a server, and the client drives all interactions — reads, writes, method calls, and monitored item subscriptions. In PubSub, the publisher pushes data to a transport channel on its own schedule with no knowledge of consumers. The key differences are: PubSub scales to unlimited subscribers without additional load on the publisher; PubSub uses a broker or multicast rather than direct TCP sessions; and PubSub cannot write values back to the publisher (it is push-only). Client-server is better for control and bidirectional interaction; PubSub is better for high fan-out data distribution.
Does OPC UA PubSub use MQTT?
OPC UA PubSub supports MQTT as one of its transport options, alongside AMQP, UDP multicast, and TSN Ethernet. When using the MQTT transport, the publisher connects to a standard MQTT broker and publishes OPC UA NetworkMessages (in UADP binary or JSON encoding) to configured topics. This makes OPC UA PubSub fully compatible with MQTT broker infrastructure including cloud platforms like AWS IoT Core and Azure IoT Hub. MQTT is the most widely deployed transport for OPC UA PubSub in IIoT architectures.
When should you use OPC UA PubSub?
Use OPC UA PubSub when: multiple consumers need the same process data (many-to-many fan-out); you are integrating PLCs with cloud platforms or a unified namespace over MQTT; you need resilient edge-to-cloud data flow over unreliable connectivity; or you need deterministic controller-to-controller communication over TSN Ethernet. Continue using client-server when you need to write values to devices, browse unknown address spaces, or call methods on a server.
