Message Oriented Middlewareas used in this document is any infrastructure supporting sending and receiving NetworkMessages between distributed applications. OPC UA does not define a Message Oriented Middleware, rather it uses protocols that allow connecting, sending and receiving data. The transport protocol mappings for PubSubare described in 7.3.

This document describes two general types of Message Oriented Middlewareto cover a large number of use cases. The two types, broker-less and broker-based middleware, are described in

With this option, OPC UA PubSubrelies on the network infrastructure to deliver NetworkMessagesto one or more receivers. Network devices – like network routers, switches, or bridges – are typically used for this purpose.

One example is a switched network and the use of UDP with unicast or multicast messages shown in Figure 13.


Figure 13– PubSub using network infrastructure

Advantages of this model include:

Figure 14depicts the applications, entities and messages involved in peer-to-peer communication using UDP as a protocol that does not require a Broker.


Figure 14– UDP Multicast overview

The PublishSubscribe Objectcontains a connection Objectfor each address like an IP multicast address. The connection can have one or more groups with DataSetWriters. A group can publish DataSetsat the defined publishing interval.

In each publishing interval, a DataSetis collected for a PublishedDataSetwhich can be a list of sampled data items in the PublisherOPC UA Address Space. For each DataSeta DataSetMessageis created. The DataSetMessagesare sent in a NetworkMessageto the IP multicast address.

OPC UA Applicationslike HMI applications would use the values of the DataSetMessagethat they are interested in.

An OPC UA Applicationthat maps data fields from UADP DataSetMessagesto internal Variablescan be configured through the DataSetReader Objectand dispatcher in the Subscriber. The configuration of a DataSetReaderdefines how to decode the DataSetMessage to a DataSet. The SubscribedDataSetdefines which field in the DataSet is mapped to which Variablein the OPC UA Application.

With OPC UA UDP there is no guarantee of timeliness, delivery, ordering, or duplicate protection. The sequence numbers in DataSetMessagesprovide a solution for ordering and duplicate detection. The reliability is improved by the option to send the complete DataSetin every DataSetMessageor with the option to repeat NetworkMessages.

Other transport protocol mappings used with the broker-less model could provide guarantee of timeliness, delivery, ordering, or duplicate protection.

This option assumes a messaging Brokerin the middle as shown in Figure 15. No application is speaking directly to other applications. All the communication is passed through the Broker. The Brokerroutes the NetworkMessages to the right applications based on business criteria ("queue name", "routing key", "topic" etc.) rather than on physical topology (IP addresses, host names).


Figure 15– PubSub using broker

Advantages of this model (partly depending on used Brokerand its configuration) include:

In addition, the Brokermodel is to some extent resistant to the application failure. So, if the application is buggy and prone to failure, the NetworkMessages that are already in the Brokerwill be retained even if the application fails.

Figure 16depicts the applications, entities and messages involved in typical communication scenarios with a Broker. It requires use of messaging protocols that a Brokerunderstands, like AMQP defined in ISO/IEC 19464:2014or MQTT defined in ISO/IEC 20922:2016. In this model the Message Oriented Middlewarewill be a Brokerthat relays NetworkMessagesfrom Publishersto Subscribers. The Brokermay also be able to queue messages and send the same message to multiple Subscribers.

Note that the Brokerfunctionality is outside the scope of this document. In terms of the messaging protocols, the Brokeris a messaging server (the OPC UA Publisher and the OPC UA Subscriberare messaging clients). The messaging protocols define how to connect to a messaging server and what fields in a message influence the Brokerfunctionality.


Figure 16– Broker overview

An OPC UA Publisherthat publishes data may be configured through the PubSub configuration model. It contains one connectionObjectper Broker. The Brokeris configured through an URL in the connection. The connection can have one or more groups which identify specific queues or topics. Each group may have one or more DataSetWritersthat format a DataSetas required for the messaging protocol. A DataSetcan be collected from a list of Eventfields and/or selected Variables. Such a configuration is called PublishedDataSet.

Each DataSetis sent as a separate DataSetMessageserialized with a format that depends on the DataSetWriter. One DataSetMessageformat is the JSON message mapping which represents the DataSetin a format which Subscriberscan understand without knowledge of OPC UA. Another DataSetMessageformat is the UADP message mapping.

Message confidentiality and integrity with the Brokerbased communication model can be ensured at two levels:

The Brokerlevel security requires all Publishersand Subscribersto have credentials that grant them access to the necessary queue or topic. In addition, all communication with the Brokeruses transport level security to ensure confidentiality. The security parameters are specified on the connection and group.

The message security provided by the Publisheris only defined for the UADP message mapping.

OPC UA Applicationsmay demand Quality of Service (QoS) for the transport of NetworkMessages. These QoS requirements have to be fulfilled by the broker-less Message Oriented Middlewareand therefore need to be mapped to concrete network technologies like TSN, Deterministic Networking (DetNet) or differentiated services (DiffServ). This mapping should be hidden to the application engineer from a PubSub perspective but may be monitored or configurable via the information model of OPC 10000-22.


Figure 17– Message Oriented Middleware providing QoS

QoS requirements of an OPC UA Applicationsshall be configurable with OPC UA means and without dependencies to the underlying network technology. Hiding network details from the application simplifies to migrate OPC UA Applicationsfrom one network technology to another or to interconnect OPC UA Applicationsover different network technologies.

QoS requirements can be fulfilled by different network mechanisms and may require different QoS control mechanisms in the network depending on the requested level of QoS.


Figure 18– Mapping of priority-based QoS

As shown in Figure 17and Figure 18the PriorityLabelfrom a WriterGroup, DataSetReaderor PubSubConnection TransportSettingswill be translated into actual values to be used on the wire. Together with the optional QosCategorythe PriorityLabelwill be present in the mapping table for the network interface used to transmit the data. If the combination of QosCategoryand PriorityLabelis not present in the mapping table, the communication cannot be established. The reference from the network interface to the mapping table is defined in OPC 10000-22.

Standard values for QosCategorywith the according required structures in the DatagramQosarray are defined in Table 102. This list can be extended by specifications built on top of OPC UA PubSub. Each QosCategorywill be described in detail by a list of measurable QoS KPIs like assured bandwidth or maximum latency in the parameter DatagramQos.