OPC UA PubSub
OPC UA PubSub is a communication model within the OPC UA standard in which data is distributed using the publish-subscribe principle. A publisher sends messages, one or more subscribers receive them – without each receiver needing to establish its own client-server session with the sender.
The model complements the classic OPC UA client/server approach and is most useful where data needs to be distributed efficiently to many consumers simultaneously.
How OPC UA PubSub Works
PubSub uses NetworkMessages as message containers with DataSetMessages carrying the actual payload. Subscribers listen for incoming NetworkMessages on a connection – without establishing a direct connection to the publisher.
There are two fundamental operating modes: Brokerless transmits data directly, for example via UDP multicast to all receivers on the same OT network. Broker-based connects publishers and subscribers through a message broker such as MQTT or AMQP – the standard approach for OT-to-IT and cloud integrations.
Message Format: UADP or JSON
PubSub cleanly separates transport from message format. UADP (UA Datagram Protocol) is the binary, compact format – optimized for efficient transmission in OT environments with optional message-level security. JSON is more readable and suited for IT-facing integrations, but typically less latency-optimized than UADP in OT setups.
Transport Options: UDP, MQTT, AMQP
The OPC UA specification (Part 14) defines standardized transport mappings for OPC UA UDP including multicast, MQTT, and AMQP. PubSub data can be distributed directly within the OT network via multicast or forwarded to the cloud or IT systems through a broker – using the same OPC UA information model regardless of the chosen transport.
OPC UA PubSub vs. OPC UA Client/Server
Both models coexist in practice and address different needs. Client/server is the right choice for targeted queries, browsing the information model, and request/response scenarios such as retrieving diagnostics. PubSub is the right choice for scalable data distribution, telemetry streaming, and scenarios where many systems need the same data stream – SCADA, historian, and analytics in parallel, without point-to-point coupling.
For cloud-native MES architectures that want to integrate machine data without proprietary middleware, OPC UA PubSub over MQTT or AMQP brokers is a stable integration path: standardized on the OT side, open to IT and cloud systems on the other.
Project Checklist
Three questions define the right approach: first, brokerless (UDP) or broker-based (MQTT/AMQP) – depending on network boundaries, number of receivers, and cloud connectivity needs. Second, UADP or JSON – depending on efficiency requirements and IT integration needs. Third, security concept: key management via Security Key Server (SKS), certificates, network segmentation, and monitoring.
FAQ
What is the difference between OPC UA PubSub and MQTT Sparkplug B? Both use the publish-subscribe principle and can use MQTT as transport. OPC UA PubSub includes the OPC UA information model – data is semantically described and standardized. Sparkplug B is a more lightweight approach without an OPC UA information model but with explicit state management (Birth/Death). In practice, the two complement each other.
Can OPC UA PubSub replace the classic client/server model? No – and that is not the intent. Client/server remains essential for targeted queries and information model browsing. PubSub extends it for scalable data distribution. Many OPC UA implementations support both models in parallel.
Which transport is recommended for OT-to-cloud integrations? Broker-based PubSub over MQTT or AMQP is the common choice, because network boundaries remain controlled, cloud services expect standardized protocols, and the broker acts as a buffer and decoupling layer.
Is OPC UA PubSub already widely used in real projects? Adoption is growing, especially in combination with MQTT brokers for OT-to-IT integration. In many current brownfield projects, OPC UA client/server continues to run while PubSub is added for new data distribution requirements.

