OPC UA traditionally uses a client-server communication model where clients request data from servers. While this works well for closed-loop industrial automation, it doesn't scale effectively for Industrial IoT scenarios involving thousands of devices and cloud platforms. This tutorial explains OPC UA PubSub—an extension that enables publish-subscribe communication—and demonstrates building an OPC UA over MQTT application using Node.js.

Understanding OPC UA PubSub is essential for architects designing scalable industrial IoT systems that connect factory equipment to cloud analytics platforms.

‍

‍

The Client-Server Model and Its Limitations

‍

Traditional OPC UA uses a request-response communication pattern. An OPC UA server exposes information about devices, machines, or processes. When an OPC UA client needs to retrieve or update information, it sends browse, read, write, or method call requests to the server, which responds accordingly.

This direct, synchronous communication between client and server works well in closed-loop command and control scenarios where the total number of connections remains relatively small.

However, Industrial IoT introduces different requirements. IoT architectures integrate data from many components across Operational Technology (OT) and Information Technology (IT) domains through centralized platforms like the cloud. In these scenarios, the client-server approach faces significant challenges:

Scalability Issues: As connected components increase rapidly, the client-server model cannot scale to meet connectivity demands. Each client requires an individual session with the server, consuming resources.

Integration Barriers: Smart devices and cloud-based analytics systems that don't understand OPC UA protocols struggle to access data from OPC UA-enabled production equipment. Bridging this gap requires additional gateway components.

These limitations prompted the OPC Foundation to develop a solution that better fits Industrial IoT architectures.

‍

Clarifying OPC UA Subscription Mechanisms

‍

Before explaining OPC UA PubSub, it's important to clarify potential confusion around subscription terminology.

The original OPC UA client-server specification includes a subscription feature for monitoring changes on servers. This is different from the Part 14 PubSub specification.

‍

Original Client-Server Subscriptions

‍

In the client-server model, each OPC UA client creates subscriptions to an OPC UA server:

Monitored Item Subscriptions: A client requests the server to monitor specific variables. When values change, the server pushes updates to the client.

Event Notifier Subscriptions: A client requests the server to watch for specific events. When events occur, the server sends notifications to the client.

However, these subscriptions still require individual sessions between each client and server—they remain strictly client-server communication, not true publish-subscribe.

When this tutorial mentions PubSub, it refers exclusively to the Part 14 PubSub specification, not the built-in subscription features of client-server communication.

‍

What is OPC UA PubSub

‍

OPC UA PubSub (Part 14 of the OPC UA specification) extends OPC UA to support publish-subscribe communication patterns instead of request-response patterns.

Rather than responding to individual client requests, an OPC UA server can push data to multiple data consumers who have subscribed to that data stream through an intermediary communication system.

This achieves the one-to-many and many-to-one communication essential for Industrial IoT with extremely low resource consumption. The sender no longer communicates with all participants individually—the intermediary handles distribution.

‍

Publishers and Subscribers

‍

In OPC UA PubSub:

Publishers: Devices or systems that send OPC UA information to an intermediary communication system. In particular, an OPC UA publisher sends data without knowing which subscribers receive it.

Subscribers: Systems that receive information from the intermediary. Subscribers express interest in specific data types without knowing which publishers produce it.

Due to the decoupled nature of publish-subscribe patterns, the number of subscribers doesn't influence how publishers produce data. Publishers simply publish; the middleware handles distribution.

‍

Cloud Platform Integration

‍

Most cloud platforms use publish-subscribe patterns for managing device-to-cloud and cloud-to-device messages. OPC UA PubSub enables OPC UA devices and applications to transmit factory floor data directly to cloud-hosted data services for analytics.

Importantly, OPC UA PubSub doesn't mean using an OPC UA client gateway that collects data from servers and publishes to the cloud. It means OPC UA servers implement PubSub functionality and publish information directly to cloud platforms.

‍

How OPC UA PubSub Works

‍

Like other OPC UA specifications, OPC UA PubSub is an abstract specification not bound to a particular messaging system. However, it provides specifications for communication parameters and transport protocol mapping.

This abstract definition allows OPC UA PubSub to transport different information types through different networks:

• Binary encoded messages over UDP
• JSON encoded messages using MQTT or AMQP
• Various combinations depending on requirements

‍

Message-Oriented vs Service-Oriented Communication

‍

OPC UA client-server uses a service-oriented approach where participants communicate by providing services to each other—requests and responses.

OPC UA PubSub uses a message-oriented approach where participants communicate by exchanging messages through middleware:

• Publishers send messages to message-oriented middleware without knowing which components subscribe
• Subscribers express interest in data types without knowing which publishers produce the data
• Middleware coordinates sending and receiving messages between publishers and subscribers

The OPC UA PubSub specification doesn't define specific middleware implementations. Instead, it describes two types of middleware it supports.

‍

Brokerless Middleware Architecture

‍

In brokerless form, OPC UA PubSub relies on network infrastructure itself to deliver messages to receivers. The message-oriented middleware is the network infrastructure—routers, switches, and bridges.

Publishers and subscribers use datagram protocols like UDP or UADP (UDP multicast combined with UA binary encoding). Even though one-to-many message distribution is achieved, it's not through a third-party message broker. Instead, publishers multicast UA binary encoded messages using UDP.

‍

Brokerless Advantages

‍

Standard Network Equipment: Requires only standard network infrastructure with no additional software components like brokers

Reduced Latency: Message delivery is direct without software intermediaries, providing lower latency and overhead

Efficient Resource Usage: No broker resources consumed

‍

Brokerless Use Cases

Brokerless OPC UA PubSub using UADP (or future Ethernet APL) suits:

• Controller-to-controller communication
• Scenarios requiring frequent data exchange
• Production environments
• Robot control systems
• Applications where all participants are on the same local network

‍

Broker-Based Middleware Architecture

In broker-based form, the primary middleware component is a message broker. No application speaks directly to other applications—all communication passes through the broker, which routes messages based on business criteria.

Subscribers and publishers use standard messaging protocols like MQTT or AMQP to communicate with the broker. The broker distributes JSON encoded publisher messages to subscribed receivers.

The message broker can reside in the cloud or anywhere visible to both publishers and subscribers.

‍

Broker-Based Advantages

Location Independence: Publishers and subscribers don't need to be directly addressable. They can be anywhere with broker access.

Massive Scalability: Fanout architecture supports very large subscriber lists across multiple networks

Flexible Routing: Brokers can implement complex routing logic and even chain to other brokers

Cloud Integration: Natural fit for cloud-based analytics and monitoring platforms

‍

Broker-Based Use Cases

Broker-based OPC UA PubSub using MQTT or AMQP suits:

• Industrial IoT applications with hundreds or thousands of receivers
• Subscribers distributed across multiple networks or geographic locations
• Cloud-based analytics and monitoring systems
• Applications requiring message persistence and quality of service guarantees
• Scenarios where publishers and subscribers connect intermittently

‍

OPC UA PubSub Data Flow Architecture

Understanding the complete data flow from publisher to subscriber reveals how OPC UA PubSub works under the hood.

‍

Publisher-Side Process

PubSub Connection Creation: The first step defines transport protocol parameters—for example, MQTT protocol and broker URL address.

Dataset Collection: Data to be published is collected from the server's address space. This collection is called a dataset—a list of name-value pairs representing variable values or events. A dataset collector pulls this dataset from the OPC UA server's address space according to configuration.

Published Dataset Creation: The collected dataset is placed in a container called a published dataset. This container includes dataset metadata that describes the contents and semantics of the dataset, helping subscribers interpret published information the same way as the publisher.

Dataset Message Creation: A dataset writer component takes the dataset and creates a dataset message. The dataset writer refers to dataset metadata to structure the message correctly, matching field order in metadata with value order in messages. Each dataset message includes a dataset writer ID for identification.

Dataset Message Formats: Dataset messages can use different formats:

• JSON message mapping represents datasets in a format subscribers can understand without OPC UA knowledge
• UA binary encoding provides compact representation for bandwidth-constrained scenarios

Network Message Creation: A writer group component combines one or more dataset messages into a network message. Network messages include additional header information like publisher ID, group writer ID, and sequence numbers. This is the actual message transmitted to the middleware.

‍

Subscriber-Side Process

Network Message Reception: Subscribers receive network messages from the middleware (broker or network infrastructure).

Dataset Message Extraction: The subscriber extracts individual dataset messages from the received network message.

Dataset Interpretation: Using the dataset metadata, the subscriber interprets the dataset message fields, mapping them to local variables or processing logic.

Data Processing: The subscriber processes the received data according to its application logic—displaying on dashboards, storing in databases, triggering alerts, or feeding analytics engines.

‍

Practical Implementation: OPC UA Over MQTT with Node.js

Let's demonstrate building an OPC UA PubSub application that transmits OPC UA data over MQTT using Node.js. This example shows the broker-based approach with JSON encoding.

Setting Up the Environment

Install Node.js and the required OPC UA PubSub packages:

bash

npm install node-opcua
npm install mqtt

These packages provide the libraries needed to implement both OPC UA server functionality and MQTT communication.

‍

Creating the OPC UA Publisher

Build a publisher that reads sensor data and publishes it via MQTT:

1. Initialize OPC UA Server: Create an OPC UA server instance that exposes temperature sensor data in its address space.
2. Configure Dataset: Define which variables from the address space to include in the published dataset—in this case, the temperature sensor reading.
3. Setup MQTT Connection: Configure connection to an MQTT broker (for example, HiveMQ public broker or your own broker instance).
4. Implement Publishing Logic: Periodically read the temperature value from the OPC UA server address space, format it as a JSON dataset message, and publish to a specific MQTT topic.

‍

Creating the Subscriber

Build a subscriber that receives and processes the published data:

1. Connect to MQTT Broker: Establish connection to the same MQTT broker using MQTT client libraries.
2. Subscribe to Topic: Subscribe to the topic where temperature data is published.
3. Process Received Messages: When messages arrive, parse the JSON dataset message, extract the temperature value, and process it (display, store, trigger actions).

‍

Running the Application

Start the publisher application first—it begins reading sensor data and publishing to the MQTT broker. Then start the subscriber application. The subscriber connects to the broker, subscribes to the temperature topic, and begins receiving temperature updates.

Monitor the subscriber output to verify temperature values are successfully transmitted from the OPC UA publisher through MQTT to the subscriber. The data flows seamlessly even though the publisher and subscriber have no direct connection—the MQTT broker handles all routing.

‍

Integration Possibilities

From this foundation, you can extend the application to:

• Connect multiple subscribers to the same temperature data stream
• Add visualization dashboards that subscribe to the MQTT topic
• Store received data in time-series databases for historical analysis
• Implement alarm logic that triggers on temperature thresholds
• Integrate with cloud analytics platforms for advanced processing

‍

Choosing Between Brokerless and Broker-Based Approaches

Your application requirements determine which OPC UA PubSub approach to use:

Use Brokerless (UADP) when:

• All participants are on the same local network
• Minimizing latency is critical
• You need deterministic, real-time communication
• Deploying additional broker infrastructure is impractical
• Controller-to-controller communication is the primary use case

Use Broker-Based (MQTT/AMQP) when:

• Subscribers are distributed across multiple networks
• Connecting to cloud platforms for analytics
• Supporting hundreds or thousands of subscribers
• Participants connect intermittently or have variable availability
• Message persistence and quality of service guarantees are required

Many industrial architectures use both approaches—UADP for local control systems and MQTT for cloud connectivity.

‍

OPC UA PubSub and OPC UA Client-Server Together

OPC UA PubSub doesn't replace client-server communication—they serve different purposes and often work together:

Client-Server excels at:

• Interactive control and configuration
• Browse and discovery operations
• Method calls for controlling equipment
• Scenarios requiring acknowledgment and confirmation

PubSub excels at:

• High-volume data streaming
• One-to-many distribution
• Cloud platform integration
• Decoupled, scalable architectures

A complete OPC UA implementation might use client-server for control and configuration while using PubSub for telemetry streaming to analytics platforms.

‍

Summary

OPC UA PubSub extends OPC UA with publish-subscribe communication patterns essential for Industrial IoT scalability. By decoupling publishers from subscribers through message-oriented middleware, OPC UA PubSub enables one-to-many communication with minimal resource consumption.

The specification supports both brokerless architectures using UDP multicast for local real-time control and broker-based architectures using MQTT or AMQP for cloud integration and massive scalability. Publishers structure data into datasets with metadata that enables subscribers to interpret information correctly regardless of their OPC UA knowledge.

Practical implementations demonstrate how OPC UA servers can publish data directly to MQTT brokers, enabling cloud analytics platforms, mobile applications, and other non-OPC UA systems to consume industrial data streams. This bridges the gap between traditional industrial automation and modern IoT architectures, creating unified systems that span from factory floor sensors to cloud-based intelligence.

‍