I was talking about OPC UA PubSub at the OPC Day Finland 2021. The speech is available at YouTube, and the slides are also available, but I decided to write about it, too. The topic is important and needs more attention, so that we can all understand it correctly.

I have defined the article in parts:

1. OPC UA Client/Server Model - quick run through to remind what OPC UA is traditionally about
2. OPC UA Publisher/Subscriber Model - what this new model is and how is it better
3. PubSub Scenarios - where is it better
4. PubSub Demos - how did we try it out ourselves
5. Conclusions

I have added screenshots from the presentation and you can click the images to get to that part in the video, if you wish to hear me explaining it as well. There are animations in the videos, which hopefully help to break the complicated topics to easier digestable parts.

1. OPC UA Client/Server Model

Client/Server Model is the traditional communication model in OPC UA. It’s based on the idea that there is a passive Server component that is exposing data for other applications that act as Clients. The Client applications can access data and information from the Server via a few standardised services.

The #1 thing that the client has to do, is to open a connection to the Server. It needs a connection address and (skipping a few details) it will then create a Session to the Server. The Session contains a security context, which includes optional encryption and authentication parameters - to identify the Client application and user in the Server. The Client can also identify the Server and decide if it allows communication with it.

After the Session is established, the Client application can request a few standard services from the Server. The services are:

1. (Connect and Create Session)
2. Browse AddressSpace - to find out what is available from the Server
3. Read - Variable values or Meta Data
4. Write - Variable values - and sometimes even Meta Data
5. Call Methods
6. Read History - for variables and events
7. (Close Session and Disconnect)

So finally, when the Client is done, it will Close the Session and Disconnects.

Client/Server Subscriptions

The Client/Server model also contains a Subscription model. In this model, each Client can create any number of Subscriptions to the Server. Each Subscription can include MonitoredItems for Variables and EventNotifiers (Object Nodes with the EventNotifier attribute set).

After the subscription is created, the Client will start calling Publish to the Server and the Server responds with NotificationMessages. The NotificationMessage may contain DataChanges and Events, respective to the type of the MonitoredItems.

Client/Server Pros & Cons

The Client/Server model has been used successfully in typical SCADA scenarios and it thrives when the number of connections between different applications is not very high. If you have tens or hundreds of devices (i.e. Servers) that need to be constantly connected - or similar number of Clients that need to connect to any Server, you may end up in trouble with resources, since every connection and subscription needs house keeping and they cause separate traffic in the network.

Traditionally, OPC UA was not designed to enable any deterministic communication or communication over unreliable networks. But it enables synchronous service calls that receive immediate results or confirmations to actions, which can be very important for the applications.

Security is also flexible and you can define rules per application and user - even per variable, if necessary.

2. Publisher/Subscriber Model

The PubSub model is radically different to the Client/Server model, but in the OPC UA context, there are similarities.

In the PubSub model, we have a Publisher component, which can define DataSets that contain Variables or EventNotifiers. The Publisher will then publish DataSetMessages, which contain DataChanges or Events, respectively. So the data that is transmitted is similar to the Client/Server Subscriptions. Only it is arranged in a bit different manner.

The messages are published into a Network, where Subscribers can listen to them and filter what they need.

So, contrary to the Subscriptions in the Client/Server model, the sender defines in Datasets what will be sent, instead of the receiver. Otherwise, the data in the DatasetMessages is basically the same as in NotificationMessages (although in a different format).

The model scales, since there can be in theory, any number of Publishers and any number of Subscribers. They are all connected to the same Network, but not to each other, which is the main improvement over the Client/Server model.

PubSub Networks

OPC UA defines two different Network types for PubSub.

1. Local Network - which can use UDP Broadcast (or Unicast in some cases) or Ethernet APL. The messages are optimized binary UADP, which is defined in the OPC UA specifications. So, only OPC UA Subscribers can interpret the messages.

2. Message Queue Broker - which can be an MQTT or AMQP broker, in practice. In this case, the messages are typically JSON messages, although UADP can be used for improved performance. The OPC Foundation has defined a standard content structure for the messages, but basically any JSON subscriber can interpret them.

PubSub Security

Security in PubSub is a bit more complicated and not so fine-grained as it is in Client/Server.

In the Local network, you will need an additional component, Security Key Server, to which all publishers and subscribers connect and which provides shared keys for them, so that they can encrypt and decrypt messages. There is no authentication, unless the Key Server authenticates the applications.

In Broker networks, security is based on SSL/TLS, which the brokers may enable for the transport. They can also define application level authentication.

In both models, there is no ruling per data item that could be applied to only some receivers from some senders. It’s all or nothing for everybody that can join the network, in principle.

PubSub Pros & Cons

So, the PubSub model solves the scalability problem, and therefore MQTT has already been very popular and successful in many (non-OPC UA) applications, where you need to connect thousands of data providers, such as small sensors or remote meters over unreliable connections to central monitoring. The industry has come up with new ideas how to actually use it in larger contexts. Now OPC UA adds some standardised formats for the message contents and a standard way to map OPC UA data to it, which should turn out beneficial. New standardisation is still underway and it’s not yet defined how the rich OPC UA Information Models, for example, will map to MQTT in the best way.

On the other hand, OPC UA uses the PubSub model to enable very fast communication in the local networks and once the networks become deterministic and fast through Ethernet TSN and APL technologies, we can foresee real-time communication possibilities over OPC UA PubSub. And this is what the OPC UA Field Level Communication (FLC) Initiative is all about and what the new Field Exchange (FX) specification can make available.

3. PubSub Scenarios

The world is slowly moving from Industrie 3.0, which was based the well-known automation pyramid to Industrie 4.0, where all components in the factory are connected to the production network. Moreover, the product itself can also carry information about itself and there can be access to the production information from anywhere in the world. The Client/Server Model has been very suitable for the old world, where the number of smart components (i.e. computers) and there connections was small. In the new world the connectivity issue may explode, when the number of components that want to produce and consume information to the shared network increases. The PubSub model should be more suitable for the new world, but at least in the meantime, we will be using both to complement each other.

In practice, PubSub can and will be combined with the Client/Server model in most cases. This enables adding Publisher to a Server, Subscriber to a Client or any other combination.

The two main PubSub scenarios that have been envisioned initially were the Synchronized Servers and Edge-to-Cloud scenario.

In the Synchronized Servers we have two or more OPC UA Servers that mirror each others data in their address spaces. The UDP Broadcast works especially well for this in a local network, and via real-time networks, it might be usable for distributed control, although it is still lacking a proper method call interface.

4. PubSub Demos

We have created three public demonstrations about PubSub:

1. Connecting OPC UA Publisher to Azure with MQTT
2. Connecting OPC UA Publisher to Amazon AWS IoT with MQTT
3. Manufacturing Gateway Demo

You can check the details from the blog posts that are linked. The video also gives you a quick overview of them.

5. Conclusions

So, we still need the OPC UA Client/Server model, to be able to communicate “synchronously” in a typical SCADA scenario.

The PubSub model enables much better scalability and improves communication performance, which makes it a good candidate for real-time communication and plays a major role in the OPC UA Field Level Commmunication (FLC) initiative and the new Field Exchange (FX) standard.

Georg Biehler gave an excellent speech at the same OPC Day Finland 2021 about OPC UA Field Exchange (FX), so check that out next!