In PubSub the participating OPC UA Applications with their roles as Publishers and Subscribers are decoupled. The number of Subscribers receiving data from a Publisher does not influence the Publisher. This makes PubSub suitable for applications where location independence and/or scalability are required.

The following are some example uses for PubSub:

• Configurable peer to peer communication between controllers and between controllers and HMIs. The peers are not directly connected and do not even need to know about the existence of each other. The data exchange often requires a fixed time-window; it may be point-to-point connection or data distribution to many receivers.
• Asynchronous workflows. For example, an order processing application can place an order on a message queue or an enterprise service bus. From there it can be processed by one or more workers.
• Logging to multiple systems. For example, sensors or actuators can write logs to a monitoring system, an HMI, an archive application for later querying, and so on.
• OPC UA Servers representing services or devices can stream data to applications hosted in the cloud. For example, backend servers, big data analytics for system optimization and predictive maintenance.

PubSub is designed to be flexible and is not bound to a particular messaging system. All components and activities are first described abstractly in this clause and do not represent a specification for implementation. The concrete communication parameters are specified in 6. The concrete transport protocol mappings and message mappings are later specified in 7.

Defined with these abstraction layers, PubSub can be used to transport different types of information through networks with different characteristics as illustrated with two examples:

• PubSub with UDP transport and binary encoded messages may be well-suited in production environments for frequent transmission of small amounts of data. It also allows data exchange in one-to-one and one-to-many configurations.
• The use of established standard messaging protocols (e.g. AMQP or MQTT) with JSON data encoding supports the cloud integration path and readily allows handling of the information in modern stream and batch analytics systems.

In PubSub the participating OPC UA Applications can assume the roles Publisher and Subscriber. Publishers are the sources of data, while Subscribers consume that data. Communication in PubSub is message-based. Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what Publishers there are.

Message Oriented Middleware is software or hardware infrastructure that supports sending and receiving messages between distributed systems. The implementation of this distribution depends on the Message Oriented Middleware.

Figure 1 illustrates that Publishers and Subscribers only interact with the Message Oriented Middleware which provides the means to forward the data to one or more receivers.

Figure 1 – Publish Subscribe Model Overview

To cover a large number of use cases, OPC UA PubSub supports two largely different Message Oriented Middleware variants. These are:

• A broker-less form, where the Message Oriented Middleware is the network infrastructure that is able to route datagram-based messages. Subscribers and Publishers use datagram protocols like UDP.
• A broker-based form, where the core component of the Message Oriented Middleware is a message Broker. Subscribers and Publishers use standard messaging protocols like AMQP or MQTT to communicate with the Broker. All messages are published to specific queues (e.g. topics, nodes) that the Broker exposes and Subscribers can listen to these queues. The Broker may translate messages from the formal messaging protocol of the Publisher to the formal messaging protocol of the Subscriber.

PubSub and Client Server are both based on the OPC UA Information Model. PubSub therefore can easily be integrated into OPC UA Servers and OPC UA Clients. Quite typically, a Publisher will be an OPC UA Server (the owner of information) and a Subscriber is often an OPC UA Client. Above all, the PubSub Information Model for configuration (see 6.2.2) promotes the configuration of Publishers and Subscribers using the OPC UA Client Server model.

Nevertheless, the PubSub communication does not require such a role dependency. I.e., OPC UA Clients can be Publishers and OPC UA Servers can be Subscribers. In fact, there is no necessity for Publishers or Subscribers to be either an OPC UA Server or an OPC UA Client to participate in PubSub communications.