OPC UA Pub/Sub extends the traditional client-server OPC UA model with a publish-subscribe communication pattern. This enables one-to-many data distribution, scalable telemetry architectures, and integration with non-OPC-UA systems via MQTT and AMQP transport protocols. This guide covers practical Pub/Sub configuration for industrial deployments.
Pub/Sub vs Client-Server Architecture
The traditional OPC UA client-server model establishes a one-to-one (or one-to-few) connection pair: a client opens a secure channel to a server, requests data, and receives responses. This pattern works well for HMI-to-controller and SCADA-to-PLC communication, where a known set of consumers reads from a known set of producers. However, it becomes inefficient when data must reach many subscribers simultaneously: each additional subscriber requires a separate TCP connection and dedicated bandwidth on the server.
OPC UA Pub/Sub decouples publishers from subscribers through a message-oriented middleware layer. A publisher sends data messages to a message broker (for MQTT or AMQP) or directly onto the network (for UDP multicast) without knowing which subscribers will consume them. Subscribers receive messages by subscribing to topics or multicast groups. This 1:N model delivers three key advantages:
- Scalability: Adding subscribers does not increase load on the publisher. Thousands of subscribers can consume the same data stream.
- Latency: UDP multicast offers the lowest possible latency (~sub-millisecond) for real-time control loops because there is no connection handshake or broker overhead.
- Loose coupling: Publishers and subscribers can be added, removed, or replaced without reconfiguring each other. This is essential for cloud integration, edge analytics, and dynamic system topologies.
Configured Dataset vs Published Dataset
The OPC UA Pub/Sub specification (IEC 62541-14) defines two key concepts for data organisation:
Configured Dataset is a template that defines which Variables are to be published and how often. It is created and stored on the publisher side, typically during engineering time. For example, a "Pump Status Dataset" might include pump speed, discharge pressure, motor current, bearing temperature, and run hours, with a sampling interval of 100 milliseconds.
Published Dataset is the runtime instance of a Configured Dataset: the actual data snapshot that is serialised and transmitted at each publish cycle. The Published Dataset header includes metadata such as a dataset writer ID, sequence number, timestamp, and optional status information. Subscribers use this metadata to detect data loss, ensure ordering, and synchronise time.
Example: A PLC configured with an "Analog Inputs" dataset (four 4–20 mA channels sampled at 50 ms) publishes a DataSetMessage every 100 ms over MQTT. The message payload contains the current raw counts and scaled engineering values, along with quality flags. An edge gateway subscribes to this MQTT topic and forwards the data to a cloud historian.
Transport Protocol Selection
| Protocol | Topology | Latency | Best For | Examples |
|---|---|---|---|---|
| UDP Multicast | LAN, 1:N directly | < 1 ms | Real-time control, high-speed peer-to-peer | Controller-to-controller, fast I/O sharing |
| MQTT | WAN, broker-mediated | 10–100 ms | Cloud/edge IoT, telemetry | AWS IoT Core, Azure IoT Hub, EMQX, Mosquitto |
| AMQP | Enterprise, broker-mediated | 10–50 ms | Enterprise messaging, transactional data | RabbitMQ, ActiveMQ, Azure Service Bus |
UDP multicast is ideal for time-critical data distribution within a single plant network. It requires network switches with IGMP snooping to avoid flooding all ports. The 1:N efficiency comes from the network layer itself handling replication, so even 100 subscribers place minimal load on the publisher.
MQTT is the preferred choice for sending OPC UA data beyond the plant firewall. The broker decouples publisher and subscriber lifecycles: a cloud application can subscribe and receive the latest value even if it was published hours ago (retained messages). MQTT Sparkplug extends this with state management and birth/death certificates for industrial use cases.
AMQP excels in enterprise environments where message delivery guarantees, transactions, and routing flexibility are required. It supports sophisticated exchange types (direct, topic, fanout, headers) and can integrate with existing enterprise service buses.
Security Considerations for Pub/Sub
Pub/Sub introduces a different threat model than client-server. Key security measures include:
- Authentication: MQTT supports username/password, X.509 certificates, and OAuth 2.0. For UDP multicast, network-level isolation (VLANs, ACLs) is typically used since there is no built-in authentication.
- Encryption: MQTT over TLS (port 8883) encrypts the entire broker connection. AMQP supports TLS natively. UDP multicast messages can be encrypted using AES-256-GCM at the application layer via OPC UA security mechanisms.
- Message signing: OPC UA Pub/Sub supports asymmetric and symmetric signing of DataSetMessages to prevent tampering and replay attacks.
- Key management: For large-scale deployments, a PKI infrastructure is essential to issue, renew, and revoke certificates for publishers and subscribers. The OPC UA Global Discovery Server (GDS) can automate certificate lifecycle management.
Configuration Example: PLC Publisher to Cloud Subscriber
Consider a Siemens S7-1500 PLC publishing process data to Azure IoT Hub via MQTT:
- On the PLC, create a Configured Dataset named "ProcessData" containing reactor temperature, pressure, and valve position.
- Configure a PubSub connection with the MQTT broker URL (e.g.,
mqtts://myhub.azure-devices.net:8883). - Set the publish interval to 500 ms. Each Published Dataset includes the current values, a sequence number, and a UTC timestamp.
- On the cloud side, deploy an OPC UA MQTT subscriber application that connects to the same broker, subscribes to the topic
opcua/pubsub/+/ProcessData, and writes incoming values to a time-series database. - Verify message delivery: the subscriber checks that sequence numbers are contiguous (gap indicates a lost message). Retained messages allow late-joining subscribers to receive the last known value immediately.
ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.
References & Further Reading
- OPC UA Part 14: PubSub — IEC 62541-14 — Official OPC Foundation specification for publish-subscribe communication, covering UDP multicast, MQTT, and AMQP transport protocol mappings.
- OPC Foundation — OPC UA Overview and Architecture — Official technical overview of OPC UA architecture, comparing client-server and Pub/Sub communication patterns for industrial automation.
- OASIS MQTT — Message Queuing Telemetry Transport Standard — Official MQTT protocol specification (OASIS Standard), the primary transport protocol for OPC UA Pub/Sub deployments over wide-area networks.
- OASIS AMQP — Advanced Message Queuing Protocol Standard — Official AMQP 1.0 specification, an alternative transport protocol for OPC UA Pub/Sub in enterprise messaging environments.
- OPC Foundation — Companion Specifications Directory — Official directory of OPC UA companion specifications that leverage Pub/Sub for industry-specific information models and data integration.