OPC UA Pub/Sub decouples data producers from consumers, allowing a single publisher to transmit messages to multiple subscribers simultaneously without a central broker. This contrasts with the client-server model, using User Datagram Protocol (UDP) multicast or broker-based protocols like AMQP and MQTT to achieve the deterministic, low-latency communication required for high-speed industrial automation.
Glossary
OPC UA Pub/Sub

What is OPC UA Pub/Sub?
OPC UA Pub/Sub is an extension of the OPC Unified Architecture that enables scalable, broker-less, one-to-many or many-to-many data distribution using a publish-subscribe pattern, critical for high-throughput sensor data on the factory floor.
By mapping OPC UA's information model onto efficient transport protocols, Pub/Sub enables the direct integration of field-level devices and sensors with cloud analytics and Manufacturing Execution Systems (MES). This architecture is foundational for Industrial Internet of Things (IIoT) scalability, supporting time-sensitive networking (TSN) for hard real-time control and event-driven closed-loop manufacturing optimization.
Key Features of OPC UA Pub/Sub
OPC UA Pub/Sub extends the client-server model with a publish-subscribe pattern, enabling efficient, broker-less, one-to-many communication for high-throughput industrial IoT data.
Decoupled Publisher-Subscriber Model
Unlike the classic client-server model requiring direct, persistent connections, Pub/Sub decouples data producers (Publishers) from data consumers (Subscribers). Publishers send data to a logical topic without knowing the recipients. Subscribers express interest in a topic and receive data asynchronously. This loose coupling allows systems to scale independently, adding or removing sensors and applications without reconfiguring the entire network. It eliminates the point-to-point spaghetti architecture that plagues traditional SCADA integrations.
Transport Protocol Flexibility
OPC UA Pub/Sub is transport-agnostic, allowing architects to choose the best protocol for their infrastructure without changing the application logic. Two primary transports are defined:
- UADP (UA Datagram Protocol): A lightweight, binary protocol optimized for Layer 2 multicast on time-sensitive networks (TSN). Ideal for high-speed, controller-to-controller communication on the factory floor.
- MQTT (Message Queuing Telemetry Transport): A TCP-based protocol designed for cloud connectivity and constrained networks. It uses a central broker for store-and-forward messaging, enabling secure data egress to AWS IoT Core or Azure IoT Hub. This flexibility bridges the gap between deterministic shop-floor control and enterprise analytics.
Integrated Security Model
Security is not an afterthought; it is built directly into the Pub/Sub specification, mirroring the robust security of client-server OPC UA. The framework provides message-level security for confidentiality and integrity, independent of the transport layer. Key features include:
- Signing & Encryption: Messages can be digitally signed to prevent tampering and encrypted to prevent eavesdropping, using industry-standard algorithms.
- Key Management: A dedicated Security Key Service (SKS) distributes symmetric keys to authorized Publishers and Subscribers, ensuring only trusted nodes participate in the data exchange. This allows secure multicast even on shared Ethernet networks.
DataSetMetaData & Self-Description
To enable true plug-and-produce interoperability, Pub/Sub uses DataSetMetaData. Before sending raw data, a Publisher transmits a structured description of the data payload, including field names, data types, and engineering units. Subscribers use this metadata to dynamically interpret incoming messages without needing a pre-configured, static schema. This self-describing mechanism is critical for semantic interoperability, allowing a robot from Vendor A to understand a sensor from Vendor B without manual mapping, drastically reducing commissioning time.
High-Performance Data Encoding
For applications requiring minimal latency and maximum throughput, such as motion control, Pub/Sub specifies highly efficient binary encodings. UADP uses a compact binary format that avoids the overhead of XML or JSON. It supports raw encoding, where the payload is a direct binary dump of the system's memory structure, eliminating serialization overhead entirely. Combined with TSN, this enables deterministic delivery guarantees in the sub-millisecond range, making it suitable for hard real-time control loops that were previously the domain of proprietary fieldbuses.
Broker-less Multicast with TSN Integration
A defining feature for industrial automation is the ability to operate without a broker. Using UADP over UDP multicast, Publishers can send a single message that is simultaneously received by all interested Subscribers on the network segment. When combined with Time-Sensitive Networking (TSN), this becomes a deterministic, lossless communication channel. TSN guarantees bounded low latency and zero congestion loss, enabling the replacement of legacy hard-wired signal lines with a converged Ethernet network that carries both real-time control data and best-effort traffic.
Frequently Asked Questions
Clear, technical answers to the most common questions about the publish-subscribe extension for OPC Unified Architecture, designed for engineers and architects evaluating scalable industrial data distribution.
OPC UA Pub/Sub is an extension of the OPC Unified Architecture that enables scalable, broker-less, one-to-many or many-to-many data distribution using a publish-subscribe communication pattern. Unlike the client-server model, where each subscriber must establish a dedicated connection to the publisher, Pub/Sub decouples senders and receivers. A Publisher sends messages to a logical channel (a Topic), and any number of Subscribers listening to that topic receive the data without the publisher needing to know who they are. This is achieved by mapping OPC UA data to transport protocols like UDP multicast for local factory networks, AMQP or MQTT for cloud integration, or Time-Sensitive Networking (TSN) for deterministic, real-time delivery. The core mechanism involves configuring DataSet objects that define the payload structure, DataSetWriter objects that control the publishing behavior, and DataSetReader objects on the subscriber side that reconstruct the information model. This architecture dramatically reduces network overhead and configuration complexity in systems with hundreds of sensors broadcasting to multiple consumers.
OPC UA Client-Server vs. Pub/Sub
Architectural and operational differences between the traditional client-server model and the publish-subscribe extension in OPC UA, critical for selecting the appropriate data distribution pattern for industrial automation workloads.
| Feature | Client-Server | Pub/Sub | Pub/Sub with Broker |
|---|---|---|---|
Communication Pattern | Point-to-point, request-reply | One-to-many, unidirectional | Many-to-many via intermediary |
Connection Model | Stateful session with TCP | Connectionless (UDP) or connection-oriented | Broker-managed sessions |
Discovery Mechanism | FindServers/GetEndpoints services | Multicast DNS-SD or LDS-ME | Broker topic enumeration |
Data Encoding | UA Binary or XML | UA Binary, JSON, or UADP | Broker-native format with UA payload |
Transport Protocols | UA TCP (opc.tcp://) | UDP multicast, Ethernet TSN, AMQP, MQTT | AMQP, MQTT 3.1.1/5.0 |
Subscriber Filtering | MonitoredItem filters on server | DataSetClass and ContentFilter at subscriber | Broker topic routing with server-side filtering |
Security Model | Session encryption (UA Secure Conversation) | Message-level security (JSON Web Token, X.509) | Broker TLS + UA payload encryption |
Quality of Service | Guaranteed delivery via TCP | Best-effort (UDP) or broker QoS levels | Broker-defined QoS (0, 1, 2) |
Typical Use Case | Supervisory control, HMI data access | High-speed sensor multicast, TSN networks | Cloud integration, cross-site telemetry |
Scalability Ceiling | Limited by server connection pool | Unlimited subscribers per publisher | Broker clustering limits |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
OPC UA Pub/Sub does not operate in isolation. These related concepts form the critical infrastructure and architectural patterns that enable scalable, broker-less data distribution on the factory floor.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us