OPC UA Pub/Sub is a communication pattern within the OPC UA standard that allows data to flow from publishers to subscribers without requiring a direct connection between them. A publisher sends data to a message broker or network bus. Any number of subscribers receive that data independently. No handshake. No dedicated session. No request-response cycle.
This is fundamentally different from the original OPC UA Client/Server model, where a client explicitly connects to a server, opens a session, and requests data. Pub/Sub decouples the data source from the data consumers — the publisher does not need to know who is listening, and subscribers do not need to know where the data originates.
OPC UA defines two distinct Pub/Sub mechanisms:
1. Classic Subscriptions (Part 4, IEC 62541-4) — the original OPC UA mechanism where a client subscribes to a server and receives change notifications. Requires a session. The server pushes data to the client. This has been part of OPC UA since the beginning.
2. Part 14 Pub/Sub (IEC 62541-14) — the newer, broker-based or connectionless mechanism introduced in 2018. No session required. Publishers send data to a message broker (MQTT, AMQP) or directly to the network (UDP multicast). Subscribers receive data from the broker or network. This is what most engineers mean today when they say “OPC UA Pub/Sub.”
This article covers both — starting with the classic model, then the Part 14 extension that makes OPC UA suitable for IIoT, cloud, and TSN applications.
Table of Contents
Part 1: Classic OPC UA Subscriptions (IEC 62541-4)
Why Subscriptions Exist
The naive approach to reading data from an OPC UA server is polling: the client calls the Read service repeatedly to get the latest value of a node. This works but wastes bandwidth and server resources when values change infrequently. It also creates latency — the client only learns about a change after its next poll.
OPC UA Subscriptions solve this by inverting the pattern. The client tells the server: “watch these items, and notify me when they change.” The server does the watching and pushes notifications to the client. The client just needs to keep sending Publish requests to collect whatever the server has queued.
MonitoredItems: The Foundation
Before a subscription can send anything, the client creates MonitoredItems. Each MonitoredItem watches one attribute of one node — typically the Value attribute of a Variable node (a sensor reading, a register value, a setpoint).
Each MonitoredItem has its own:
SamplingInterval — how often the server reads the underlying attribute to check for changes. Set to 0 for the server’s fastest rate. Set to -1 to inherit the subscription’s PublishingInterval. This is independent of how often notifications are actually sent to the client.
QueueSize — how many notifications the server buffers per MonitoredItem if they can’t be sent immediately. Set to 1 for most applications (only the latest value matters). Set higher for items where every change must be captured.
DiscardOldest — if the MonitoredItem queue overflows, whether to discard the oldest (true) or newest (false) notification.
MonitoringFilter — optional filter that suppresses notifications unless a meaningful change occurs. The DataChangeFilter is the most common: it has a deadband parameter (absolute or percentage) that suppresses notifications when the value change is below the deadband threshold. A pressure transmitter with a 0.5% deadband will only send a notification when pressure changes by more than 0.5% of full scale — preventing flooding the network with insignificant fluctuations.
MonitoringMode has three states: Sampling (server samples the item but does not queue notifications), Reporting (server samples and queues notifications), Disabled (no sampling at all). This lets the controller pause monitoring of non-critical items during certain machine states without deleting and recreating them.
The Subscription Model
A Subscription groups MonitoredItems and controls when their queued notifications are sent to the client. Key parameters from IEC 62541-4:
PublishingInterval — the subscription’s heartbeat. The server attempts to send a NotificationMessage to the client at each publishing cycle. Typical values: 100 ms to 5000 ms depending on process requirements.
MaxKeepAliveCount — the maximum number of consecutive publishing cycles with no notifications before the server sends a keep-alive message. A keep-alive confirms the subscription is still alive even when no data has changed. If MaxKeepAliveCount = 10 and PublishingInterval = 1000 ms, a keep-alive is sent after 10 seconds of silence.
LifetimeCount — the maximum number of consecutive publishing cycles with no Publish request received from the client before the server auto-deletes the subscription. The standard requires LifetimeCount ≥ 3 × MaxKeepAliveCount. This protects the server from accumulating abandoned subscriptions. The lifecycle: if the client disappears without cleaning up, the server automatically recovers resources after LifetimeCount × PublishingInterval milliseconds.
MaxNotificationsPerPublish — limits the number of notifications in a single NotificationMessage. Prevents one overflowing subscription from consuming the entire network bandwidth in one message.
Priority — when a client has multiple subscriptions, the server uses priority to decide which subscription gets to use the next Publish request first. Useful for ensuring safety-critical subscriptions are serviced before diagnostic subscriptions.
The Publish Mechanism
The client drives the data flow by sending Publish requests to the server. These are not requests for specific data — they are empty requests that say “I’m ready to receive whatever you have.” The server queues them and uses them to send notifications when available.
The flow per IEC 62541-4 Section 5.13:
- Client sends multiple Publish requests ahead of time (typically 2–3 queued at the server)
- Server’s publishing timer fires at each PublishingInterval
- Server checks its MonitoredItems for queued notifications
- If notifications exist: server dequeues one Publish request and returns a NotificationMessage containing the notifications
- If no notifications exist: server checks the keep-alive counter; if reached, sends a keep-alive message using one Publish request
- Client acknowledges received NotificationMessages by including the sequence number in the next Publish request
- Server removes acknowledged messages from its retransmission queue
Sequence numbers are 32-bit unsigned integers, incremented by 1 for each NotificationMessage sent. The first message always has sequence number 1. Sequence numbers never reset during the subscription lifetime — meaning sequence number gaps indicate missed messages. The client can request retransmission of any specific sequence number using the Republish service.
Subscription States
IEC 62541-4 Table 79 defines five subscription states:
| State | Description |
|---|---|
| CLOSED | Not yet created or terminated |
| CREATING | Being initialized |
| NORMAL | Cyclically checking for notifications; keep-alive counter not used |
| LATE | Notifications or keep-alive ready, but no Publish request queued — waiting for next request |
| KEEPALIVE | Checking for notifications each cycle; counting down keep-alive counter |
The LATE state is important for troubleshooting. If the client is slow sending Publish requests — network congestion, CPU overload, application bug — the subscription enters LATE and queues Publish requests internally until the client catches up. If this persists long enough, the LifetimeCounter expires and the subscription is auto-deleted.
Notification Types
Three notification types can appear in a NotificationMessage:
DataChangeNotification — the most common. Contains a list of MonitoredItemNotifications, each with a client handle (identifies which MonitoredItem changed), the new DataValue (value + quality + timestamp), and optionally diagnostic information.
EventNotificationList — carries OPC UA Events. Events are not periodic data samples — they are records of things that happened: alarms triggered, conditions changed, audit entries generated. Each event contains a set of fields defined by the EventFilter the client configured on the MonitoredItem.
StatusChangeNotification — carries a StatusCode indicating a state change in the subscription itself. The most important: Bad_Timeout, which means the server is about to auto-delete the subscription because no Publish requests have arrived.
Part 2: OPC UA Part 14 Pub/Sub — The Broker Model
Why Part 14 Was Needed
The classic subscription model is powerful but has a fundamental constraint: it requires a stateful session between client and server. Every subscriber must individually connect to every server it wants data from. In a factory with 200 OPC UA servers and 50 consuming applications, that’s potentially 10,000 individual client/server connections — each with its own session overhead, security handshake, and keep-alive traffic.
IEC 62541-14 (Part 14) was released in 2018 to address three new use cases:
Cloud and IIoT: A sensor on the factory floor needs to send data to an Azure IoT Hub or AWS IoT Core. No direct TCP connection can be maintained reliably across firewalls and WAN links. MQTT over TLS to a broker is the standard pattern. OPC UA needs to ride on top of that.
Many-to-many at scale: In large industrial installations, a single data value may need to reach dozens of consumers. Instead of 50 separate subscriptions from 50 clients, one publisher sends to a broker, and all 50 subscribe to the broker’s topic.
Real-time fieldbus replacement (TSN): For controller-to-controller communication replacing traditional fieldbuses, a connectionless UDP multicast approach is needed — lightweight, low-latency, with no broker overhead. Part 14 defines this as the UADP over Ethernet transport.
The Part 14 Architecture
Three roles:
Publisher — the data source. An OPC UA server, a sensor, a PLC. The publisher reads data from its information model and encodes it as OPC UA messages, then sends them to a broker or network without caring who receives them.
Subscriber — the data consumer. Any application that connects to the broker and subscribes to topics, or listens on the network for multicast messages. The subscriber decodes received messages and uses the data.
Message Broker (optional) — an intermediary like an MQTT broker (Mosquitto, HiveMQ, Azure IoT Hub) or AMQP broker (RabbitMQ, Azure Service Bus). The broker handles routing, queuing, and fan-out. It decouples publisher and subscriber in time and space — the subscriber doesn’t need to be online when the publisher sends, and the publisher doesn’t need to know which subscribers exist.
Key Concepts
DataSet — the fundamental unit of data in Part 14. A DataSet is a named collection of fields, where each field maps to a node/attribute in the OPC UA information model. It is the OPC UA equivalent of a PROFINET IO data image or an EtherNet/IP assembly. The publisher samples all fields at once (atomically) and sends them together — ensuring data consistency.
DataSetWriter — the entity that takes a DataSet, applies encoding (UADP or JSON), and passes it to the transport layer for sending. Each DataSetWriter has a configurable PublishingOffset and PublishingInterval.
WriterGroup — groups multiple DataSetWriters that share the same transport channel (same MQTT topic or same UDP multicast address and port). All DataSetWriters in a group send together on the group’s PublishingInterval.
DataSetReader — on the subscriber side, reads and decodes incoming messages and extracts a specific DataSet from them.
ReaderGroup — groups DataSetReaders that receive from the same transport channel.
PublishedDataSet — the configuration in the publisher that defines which OPC UA nodes are included in a DataSet and how they are sampled.
Message Encoding: UADP and JSON
Part 14 defines two encoding formats:
UADP (UA Binary Datagram Protocol) — a compact binary format designed for high-performance, low-overhead applications. Used primarily with UDP multicast for real-time fieldbus applications and with TSN. UADP messages can be optimized to be very small — in the most compact configuration, they contain only a header identifying the publisher and DataSet version, followed by raw field values with no field names, no type metadata, and no framing overhead. The subscriber must have prior knowledge of the DataSet structure (the DataSet metadata) to decode the values. This is the OPC UA equivalent of a PROFIBUS DP cyclic I/O frame — dense and fast, but requires pre-configuration.
JSON encoding — a human-readable text format used primarily with MQTT and AMQP for cloud and IIoT applications. JSON messages include field names, making them self-describing and easy to consume by cloud services, databases, and analytics platforms. More verbose than UADP but universally supported.
Transport Layers
Part 14 defines three transport bindings:
MQTT (Message Queuing Telemetry Transport) — the standard IoT messaging protocol. Publishers send to MQTT topics; subscribers subscribe to topics. The MQTT broker handles routing and fan-out. MQTT over TLS provides encryption and authentication. Used for cloud integration, IIoT, and wide-area applications. Default QoS level 1 (at least once delivery) for most OPC UA Pub/Sub use cases.
OPC UA defines a convention for MQTT topic naming: opcua/<PublisherId>/<WriterGroupName>/<DataSetWriterName> — though implementations vary.
AMQP (Advanced Message Queuing Protocol) — an enterprise messaging protocol providing stronger delivery guarantees, message acknowledgment, and transaction support compared to MQTT. Used in enterprise integration scenarios with systems like Azure Service Bus, RabbitMQ, or IBM MQ. More overhead than MQTT but more reliable in high-throughput, mission-critical scenarios.
UDP Multicast (UADP over Ethernet/IP) — connectionless, no broker required. The publisher sends UADP messages to an IP multicast address. All subscribers on the network segment that have joined the multicast group receive the message simultaneously. Zero broker overhead. Used for real-time, low-latency machine-to-machine communication on local industrial networks — the direct fieldbus replacement use case.
OPC UA Pub/Sub + TSN
The combination of OPC UA Part 14 (UADP over Ethernet) with TSN (Time-Sensitive Networking, IEEE 802.1Qbv/802.1AS) is the long-term vision for replacing traditional deterministic fieldbuses like PROFIBUS and EtherCAT with a single standard Ethernet infrastructure.
TSN provides:
- IEEE 802.1AS — clock synchronization across all network nodes to sub-microsecond accuracy
- IEEE 802.1Qbv — time-aware traffic shaping: specific time windows reserved for OPC UA UADP frames, guaranteeing deterministic forwarding
- IEEE 802.1CB — frame replication and elimination for seamless redundancy
OPC UA Part 14 + TSN means: a publisher configured with a specific PublishingOffset sends its UADP frame at exactly the right microsecond. TSN switches forward it in the reserved time window. The subscriber receives it with deterministic latency. The entire communication chain, from PLC output to field device input, operates with guaranteed timing — matching or exceeding the determinism of PROFIBUS DP or EtherCAT, on standard Ethernet hardware.
This is the “OPC UA FLC” (Field Level Communications) vision that the OPC Foundation has been pursuing since 2018.
Client/Server vs. Pub/Sub: When to Use Which
| Criterion | Client/Server (Part 4) | Pub/Sub Part 14 |
|---|---|---|
| Connection | Stateful session required | Connectionless / broker-mediated |
| Topology | 1:1 (one client per server) | 1:N (one publisher, many subscribers) |
| Data flow | Pull (client sends Publish requests) | Push (publisher sends autonomously) |
| Latency | Low (direct connection) | Low–medium depending on transport |
| Reliability | High (session with retransmit) | Transport-dependent |
| Cloud integration | Difficult (requires TCP to server) | Native (MQTT/AMQP) |
| Real-time fieldbus | Not suitable | Yes (UADP + TSN) |
| Configuration complexity | Low–medium | Medium–high |
| Bandwidth efficiency | Good | Excellent (UADP binary) |
| Best for | SCADA, HMI, historian, configuration | IIoT, cloud, fieldbus, large-scale monitoring |
In practice, both are used together. The classic Client/Server model with subscriptions handles all the engineering, parameterization, diagnostics, alarm management, and historical access — tasks that need bidirectional, confirmed communication. The Part 14 Pub/Sub model handles the high-frequency, one-way data streaming to cloud platforms, analytics engines, and real-time consumers that don’t need a two-way session.
A typical Industry 4.0 architecture has both: an OPC UA server on every machine, with a SCADA system using Client/Server subscriptions for control and monitoring, while simultaneously a cloud connector uses MQTT Pub/Sub to stream the same data to Azure or AWS for analytics.
Key Numbers
| Parameter | Value |
|---|---|
| IEC Standard (subscriptions) | IEC 62541-4:2011 |
| IEC Standard (Pub/Sub) | IEC 62541-14:2022 |
| Sequence number size | 32-bit unsigned integer |
| First sequence number | Always 1 |
| Max sequence number before rollover | 4,294,967,295 (≈4 billion) |
| Minimum LifetimeCount | ≥ 3 × MaxKeepAliveCount |
| Notification types | DataChangeNotification, EventNotificationList, StatusChangeNotification |
| Part 14 encoding formats | UADP (binary), JSON |
| Part 14 transports | MQTT, AMQP, UDP multicast |
| Security (MQTT) | TLS 1.2/1.3 + OPC UA application-level security |
| TSN standard for clock sync | IEEE 802.1AS |
| TSN standard for time shaping | IEEE 802.1Qbv |
Common Mistakes and Misconceptions
“OPC UA Pub/Sub replaces Client/Server.” No. They are complementary. Client/Server handles bidirectional, confirmed, session-based communication. Pub/Sub handles scalable, one-way data streaming. Most real deployments use both.
“I can use the same MQTT topic for multiple DataSets from the same publisher.” You can, but it complicates subscribers. Best practice is one WriterGroup per MQTT topic, with clear topic naming that reflects the data hierarchy.
“OPC UA security doesn’t apply to Pub/Sub.” Wrong. Part 14 defines a Security Key Service (SKS) that distributes group keys for encrypting and signing UADP messages. MQTT transport uses TLS. Both mechanisms together provide end-to-end security for Pub/Sub data streams.
“Pub/Sub is only for cloud.” No. UADP over UDP multicast (no broker) is specifically designed for real-time machine communication on local networks — including the TSN-based fieldbus replacement use case.
“The PublishingInterval in Part 14 is the same as the sampling interval.” Not necessarily. The publisher has a separate sampling rate for reading OPC UA node values. The PublishingInterval controls how often the WriterGroup sends. Both need to be configured appropriately for the application.
Summary
OPC UA Pub/Sub in its two forms covers the entire spectrum of industrial data communication. The classic subscription model (Part 4) provides reliable, session-based push notifications for monitoring, SCADA, and control applications — with precise control over sampling rates, deadbands, event filtering, and retransmission. The Part 14 Pub/Sub extension takes OPC UA beyond the factory floor into IIoT, cloud, and fieldbus-replacement territories — using MQTT and AMQP for scalable cloud integration, and UADP over Ethernet with TSN for real-time deterministic machine communication.
Together, they make OPC UA the only industrial communication standard that works coherently from a 2 kB microcontroller sensor to an enterprise cloud analytics platform, with consistent data modeling, security, and semantics at every layer.