Message Oriented Middleware as 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 PubSub are described in 7.3.
This document describes two general types of Message Oriented Middleware to cover a large number of use cases. The two types, broker-less and broker-based middleware, are described in 5.4.5.2 and 5.4.5.3.
With this option, OPC UA PubSub relies on the network infrastructure to deliver NetworkMessages to 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:
- Only requires standard network equipment and no additional software components like a Broker.
- Message delivery is assumed to be direct without software intermediaries and therefore provides reduced latency and overhead.
- UDP protocol supports multiple subscribers using multicast addressing.
Figure 14 depicts 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 Object contains a connection Object for each address like an IP multicast address. The connection can have one or more groups with DataSetWriters. A group can publish DataSets at the defined publishing interval.
In each publishing interval, a DataSet is collected for a PublishedDataSet which can be a list of sampled data items in the Publisher OPC UA Address Space. For each DataSet a DataSetMessage is created. The DataSetMessages are sent in a NetworkMessage to the IP multicast address.
OPC UA Applications like HMI applications would use the values of the DataSetMessage that they are interested in.
An OPC UA Application that maps data fields from UADP DataSetMessages to internal Variables can be configured through the DataSetReader Object and dispatcher in the Subscriber. The configuration of a DataSetReader defines how to decode the DataSetMessage to a DataSet. The SubscribedDataSet defines which field in the DataSet is mapped to which Variable in the OPC UA Application.
With OPC UA UDP there is no guarantee of timeliness, delivery, ordering, or duplicate protection. The sequence numbers in DataSetMessages provide a solution for ordering and duplicate detection. The reliability is improved by the option to send the complete DataSet in every DataSetMessage or 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 Broker in the middle as shown in Figure 15. No application is speaking directly to other applications. All the communication is passed through the Broker. The Broker routes 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 Broker and its configuration) include:
- Publisher and Subscriber do not have to be directly addressable. They can be anywhere as long as they have access to the Broker.
- Fan out can be handled to a very large list of Subscribers, multiple networks or even chained Brokers or scalable Brokers.
- Publisher and Subscriber lifetimes do not have to overlap. The Publisher application can push NetworkMessages to the Broker and terminate. The NetworkMessages will be available for the Subscriber application later.
- Publisher and Subscriber can use different messaging protocols to communicate with the Broker.
In addition, the Broker model 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 Broker will be retained even if the application fails.
Figure 16 depicts the applications, entities and messages involved in typical communication scenarios with a Broker. It requires use of messaging protocols that a Broker understands, like AMQP defined in ISO/IEC 19464:2014 or MQTT defined in ISO/IEC 20922:2016. In this model the Message Oriented Middleware will be a Broker that relays NetworkMessages from Publishers to Subscribers. The Broker may also be able to queue messages and send the same message to multiple Subscribers.
Note that the Broker functionality is outside the scope of this document. In terms of the messaging protocols, the Broker is a messaging server (the OPC UA Publisher and the OPC UA Subscriber are messaging clients). The messaging protocols define how to connect to a messaging server and what fields in a message influence the Broker functionality.
An OPC UA Publisher that publishes data may be configured through the PubSub configuration model. It contains one connection Object per Broker. The Broker is 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 DataSetWriters that format a DataSet as required for the messaging protocol. A DataSet can be collected from a list of Event fields and/or selected Variables. Such a configuration is called PublishedDataSet.
Each DataSet is sent as a separate DataSetMessage serialized with a format that depends on the DataSetWriter. One DataSetMessage format is the JSON message mapping which represents the DataSet in a format which Subscribers can understand without knowledge of OPC UA. Another DataSetMessage format is the UADP message mapping.
Message confidentiality and integrity with the Broker based communication model can be ensured at two levels:
- transport security between Publishers or Subscribers and the Broker, or
- message security as end-to-end security between Publisher and Subscriber.
The Broker level security requires all Publishers and Subscribers to have credentials that grant them access to the necessary queue or topic. In addition, all communication with the Broker uses transport level security to ensure confidentiality. The security parameters are specified on the connection and group.
The message security provided by the Publisher is only defined for the UADP message mapping.
OPC UA Applications may demand Quality of Service (QoS) for the transport of NetworkMessages. These QoS requirements have to be fulfilled by the broker-less Message Oriented Middleware and 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 Applications shall 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 Applications from one network technology to another or to interconnect OPC UA Applications over 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 17 and Figure 18 the PriorityLabel from a WriterGroup, DataSetReader or PubSubConnection TransportSettings will be translated into actual values to be used on the wire. Together with the optional QosCategory the PriorityLabel will be present in the mapping table for the network interface used to transmit the data. If the combination of QosCategory and PriorityLabel is 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 QosCategory with the according required structures in the DatagramQos array are defined in Table 103. This list can be extended by specifications built on top of OPC UA PubSub. Each QosCategory will be described in detail by a list of measurable QoS KPIs like assured bandwidth or maximum latency in the parameter DatagramQos.