OPC UA PubSub

What is OPC UA PubSub?

OPC UA PubSub is the part of the OPC UA standard (Part 14, OPC 10000-14) that applies the publish/subscribe pattern, in which publishers send data without knowing who receives it and subscribers only process the messages they are interested in. PubSub is short for publish/subscribe: a general communication pattern that also underpins MQTT and DDS. OPC UA PubSub combines that pattern with the information model and security of OPC UA, and sends messages via UDP multicast, directly over Ethernet or through a broker such as MQTT or AMQP. The first version was released in February 2018 as part of OPC UA 1.04; the current version belongs to OPC UA 1.05.

🧠 What is the publish/subscribe pattern?

In the classic client/server model, a client keeps asking for data: the SCADA server reads registers from a PLC every second (polling), as is common with Modbus TCP. Publish/subscribe reverses that relationship. The source publishes on its own initiative, and consumers subscribe. Sender and receiver are therefore decoupled in three ways:

• In space - the publisher does not know the subscribers and does not need to maintain a connection per consumer
• In time - with a broker, sender and receiver do not have to be active at the same moment
• In number - an additional consumer costs the publisher no extra work

The pattern comes in two main forms:

• Broker-based - a central intermediary receives all messages and distributes them per topic. MQTT is the best-known example in OT; Apache Kafka and AMQP work the same way.
• Brokerless - publishers send messages straight onto the network, usually via multicast. DDS (Data Distribution Service) from the Object Management Group works like this: participants find each other through automatic discovery and exchange data via the RTPS protocol, with more than twenty configurable QoS policies covering reliability, history and more. DDS is, among other things, the middleware beneath ROS 2 in robotics.

OPC UA PubSub supports both forms. That is what makes it distinctive: the same information model works for fast machine-to-machine communication as well as for connecting to the cloud.

🔧 How does OPC UA PubSub work?

Part 14 separates what is sent (the message format) from how it is sent (the transport).

Configuration is hierarchical:

1. PublishedDataSet - which variables or events are published
2. DataSetWriter - turns a dataset into a DataSetMessage
3. WriterGroup - bundles the messages of several writers into one NetworkMessage, with a fixed publishing interval
4. PubSubConnection - ties everything to a transport address and a unique PublisherId
5. ReaderGroup and DataSetReader - on the subscriber side, filtering and decoding messages

To save bandwidth, PubSub uses key frames and delta frames. A key frame contains every field of a dataset; a delta frame only the fields that have changed. The KeyFrameCount parameter sets how often a complete message is sent. Subscribers that do not yet know the structure of the data receive it through DataSetMetaData messages.

🔄 What is the difference between OPC UA client/server and PubSub?

PubSub does not replace client/server. In practice you use client/server to configure a device and explore its address space, and PubSub to distribute the process data efficiently.

🔄 How does OPC UA PubSub compare with MQTT and DDS?

MQTT only transports bytes; the meaning of the data is not defined. That is why conventions such as MQTT Sparkplug B emerged. OPC UA PubSub over MQTT does provide a defined format with metadata and references to the OPC UA information model. Like OPC UA PubSub, DDS can run without a broker, but it comes from the defence, robotics and simulation world and has its own data model. In factories, OPC UA and MQTT are far more common; you mainly encounter DDS in robots and autonomous systems.

🏭 Where is OPC UA PubSub used?

• Controller-to-controller - PLCs from different vendors exchange cyclic data via UDP multicast; this is the foundation of OPC UA FX
• Deterministic networks - over TSN, PubSub gets bounded latency and low jitter, as needed for real-time control
• Edge to cloud - an edge gateway publishes machine data as JSON via MQTT to a cloud platform, MES or historian
• Unified Namespace - PubSub over MQTT can feed a UNS alongside or instead of Sparkplug B
• Alarm and event distribution - events reach multiple consumers without every system having to poll separately

🔐 How do you secure OPC UA PubSub?

Because there is no session between publisher and subscriber, security works differently from client/server. All members of a SecurityGroup share symmetric keys, which a Security Key Service (SKS) hands out. In the pull model, participants fetch the keys themselves over a secured OPC UA connection; in the push model, the SKS delivers them to the participants. Keys have a limited lifetime (KeyLifetime) and are replaced regularly.

Part 14 defines this group-key message security for the binary UADP encoding. JSON messages over MQTT have no signing or encryption of their own and depend on TLS between participant and broker and on the security of the broker itself. Because you then have to trust the broker, end-to-end security from publisher to subscriber is only possible with UADP.

Practical points of attention:

• Enable SignAndEncrypt - with SecurityMode None every message can be read and forged, enabling spoofing and a replay attack
• Protect the SKS - anyone who reaches the SKS can obtain the keys for an entire group
• Segment multicast traffic - keep it inside its own VLAN and zone in line with network segmentation and IEC 62443; multicast should never cross a firewall into the office network
• Broker variants - use TLS, per-client authentication and per-topic permissions on the broker
• Certificates - the SKS and its clients use X.509 certificates; organise their lifecycle with certificate management
• Monitoring - forward broker and SKS logs to a SIEM and watch for unknown PublisherIds or unusual message rates

🛠️ How do you set up OPC UA PubSub in practice?

1. Choose the transport per data flow - UDP or Ethernet for fast data within a cell, MQTT for flows to IT and the cloud
2. Choose the encoding - UADP for millisecond cycles, JSON when IT systems need to read the data directly
3. Design the datasets - group variables with the same interval in one WriterGroup and keep a UDP message within one MTU (at most 1,472 bytes of payload over IPv4) to avoid fragmentation
4. Prepare the network for multicast - subscribers join via IGMP; make sure switches support IGMP snooping, otherwise multicast floods the network
5. Set up security - SKS, SecurityGroups, key lifetime and certificates
6. Test with multiple vendors - check which profiles a device supports, because not every product implements every transport and encoding

❓ Frequently asked questions

What does PubSub mean?

PubSub is short for publish/subscribe, a communication pattern in which senders publish messages without knowing the receivers. Receivers subscribe to the data they need. MQTT, DDS and OPC UA PubSub are well-known industrial applications of this pattern.

Does OPC UA PubSub need a broker?

No, OPC UA PubSub works both with and without a broker. Without a broker, messages travel via UDP multicast or directly over Ethernet, which suits fast communication within a machine or cell. With a broker, OPC UA PubSub uses MQTT or AMQP, which is convenient for connections to IT and the cloud.

Is OPC UA PubSub the same as MQTT?

No, MQTT is a transport protocol that always requires a broker, whereas OPC UA PubSub is a specification that can use MQTT as one of its transports. OPC UA PubSub adds a fixed message format, metadata and the link to the OPC UA information model. The two therefore complement each other.

Is OPC UA PubSub suitable for real-time control?

OPC UA PubSub with UADP encoding over UDP or Ethernet is compact enough for fast cyclic communication. For guaranteed latency you combine it with TSN, as OPC UA FX does. Over a broker such as MQTT, OPC UA PubSub is not intended for hard real-time control.

How is OPC UA PubSub secured?

OPC UA PubSub secures messages with group keys distributed by a Security Key Service, using the modes None, Sign and SignAndEncrypt; this message security is defined for UADP. JSON messages via a broker depend on TLS and access rights on the broker. Network segmentation remains necessary as well, especially for multicast traffic.

What is the difference between OPC UA PubSub and OPC UA FX?

OPC UA PubSub describes how messages are published and received. OPC UA FX builds on it with information models, connection management and profiles, so that controllers and field devices from different vendors genuinely work together. PubSub is the transport mechanism; OPC UA FX is the agreement on what is exchanged.

📌 In summary

OPC UA PubSub brings the publish/subscribe pattern to OPC UA. Publishers send data without knowing the consumers, via UDP multicast, Ethernet or a broker such as MQTT. With UADP and TSN it suits fast field-level communication; with JSON and MQTT it connects to IT and the cloud. Security relies on group keys from a Security Key Service (UADP) or on TLS at the broker (JSON), and requires sound segmentation.

OPC UA PubSub combines the scalability of publish/subscribe with the information model and security of OPC UA, from the field level to the cloud.