The Publisheris the PubSubentity that sends NetworkMessagesto a Message Oriented Middleware. It represents a certain information source, for example, a control device, a manufacturing process, a weather station, or a stock exchange.

Commonly, a Publisheris also an OPC UA Server. For the abstract PubSubconcepts, however, it is an arbitrary entity and should not be assumed to be an individual or even a specific network node (an IP or a MAC address) or a specific application. A Publishermay consist of one or more network nodes sending messages and management node(s) responding to discovery probe messages and providing an OPC UA Serverfor configuration and diagnostics.

Figure 5illustrates a Publisherwith data collection, encoding and message sending.

image008.png

Figure 5– Publisher details

A single Publishermay support multiple PublishedDataSetsand multiple DataSetWritersto one or more Message Oriented Middleware. A DataSetWriteris a logical component of a Publisher. See 5.4.1.2for further information about the DataSetwriting process.

If the Publisheris an OPC UA Server, it can expose the Publisherconfiguration in its AddressSpace. This information may be created through product-specific configuration tools or through the OPC UA defined Methods. The OPC UA Information Modelfor PubSubconfiguration is specified in Clause 9.

Figure 6illustrates the process inside a Publisherwhen creating and sending messages and the parameters required to accomplish it. The components, like DataSetcollection or DataSetWritershould be considered abstract. They may not exist in every Publisheras independent entities. However, comparable processes need to exist to generate the OPC UA PubSubmessages.

image009.png

Figure 6– Publisher message sending sequence

The sending process is guided by different parameters for different logical steps. The parameters define for example when and how often to trigger the sending sequence and the encoding and security of the messages. The PubSub communication parameters are defined in Clause 6.

The first step is the collection of data (DataSet) to be published. The configuration for such a collection is called PublishedDataSet. The PublishedDataSetalso defines the DataSetMetaData. Collection is a generic expression for various different options, like monitoring of Variablesin an OPC UA Server AddressSpace, processing OPC UA Events, or for example reading data from network packets. In the end, the collection process produces values for the individual fields of a DataSet. The two concrete PublishedDataSetoptions with standard OPC UA configuration are PublishedDataItemsfor Variablebase collection and PublishedEventsfor Eventbased collection.

In the next step, a DataSetWritertakes the DataSetand creates a DataSetMessage. DataSetMessagesfrom DataSetWritersin one WriterGroupcan be inserted into a single NetworkMessage. The creation of a DataSetMessage is guided by the following parameters:

The resulting DataSetMessageis passed on to the next step together with the DataSetWriterId(see 6.2.4.1), the DataSetClassId(see 6.2.3.3), the ConfigurationVersionof the DataSetMetaData(see 6.2.3.2.5), and a list of values that match the configured propagated fields.

Next is the creation of the NetworkMessage. It uses the data provided from the previous step together with the PublisherId(see 6.2.7.1) defined on the PubSubConnection. The structure of this message is protocol specific. If the SecurityMode(see 6.2.5.2) requires message security, the SecurityGroupId(see 6.2.5.3) is used to fetch the SecurityPolicyand the security keys from the SKS (see 5.4.4). This information is used to encrypt and/or sign the NetworkMessageas required by the SecurityMode.

The final step is delivery of the NetworkMessageto the Message Oriented Middlewarethrough the configured Address.

Subscribers are the consumers of NetworkMessagesfrom theMessage Oriented Middleware. They may be OPC UA Clients, OPC UA Serversor applications that are neither Clientnor Serverbut only understand the structure of OPC UA PubSubmessages. Figure 7illustrates a Subscriberwith filtering, decoding and dispatching of NetworkMessages.

image010.png

Figure 7– Subscriber details

To determine for which DataSetMessages and on which Message Oriented Middlewareto subscribe, the Subscriberneed to be configured and/or use discovery mechanisms.

Subscribers shall be prepared to receive messages that they do not understand or are irrelevant. Each NetworkMessageprovides unencrypted data in the NetworkMessageheader to support identifying and filtering of relevant Publishers, DataSetMessages, DataSetClassesor other relevant message content (see 5.3).

If a NetworkMessageis signed or signed and encrypted, the Subscriberwill need the proper security keys (see 5.3.5) to verify the signature and decrypt the relevant DataSetMessages.

Once a DataSetMessagehas been selected as relevant, it will be forwarded to the corresponding DataSetReaderfor decoding into a DataSet. See 5.4.2.2for further information about this DataSetreading process. The resulting DataSetis then further processed or dispatched in the Subscriber.

If the Subscriberis an OPC UA Server, it can expose the reader configuration in its AddressSpace. This information may be created through product-specific configuration tools or through the OPC UA defined configuration model. The OPC UA Information Modelfor PubSubconfiguration is specified in Clause 9.

Figure 8illustrates the process inside a Subscriberwhen receiving, decoding and interpreting messages and the parameter model required for accomplishing it. As for the Publisher, the components should be considered abstract.

image011.png

Figure 8– Subscriber message reception sequence

The Subscriberneed to select the required Message Oriented Middlewareand establish a connection to it using the provided Address. Such a connection may simply be a multi-cast address when using OPC UA UDP or a connection to a message Brokerwhen using MQTT or AMQP. Once subscribed, the Subscriberwill start listening. The sequence starts when a NetworkMessageis received. The Subscribermay have configured filters (like a PublisherId, DataSetWriterIdor a DataSetClassId) so that it can drop all messages that do not match the filter.

Once a NetworkMessagehas been accepted, it is decrypted and decoded. The security parameters are the same as for the Publisher.

Each DataSetMessageof interest is passed on to a DataSetReader. Here, the DataSetMetaDatais used to decode the DataSetMessagecontent to a DataSet. The DataSetMetaDatain particular provides the complete field syntax including the name, data type, and other relevant Propertieslike engineering units. Version information that exists in both the DataSetMessageand theDataSetMetaDataallows the Subscriber to detect version changes. If a major change occurs, theSubscriberneeds to get an updated DataSetMetaData.

Any further processing is application-specific. For example, an additional dispatching step may map the received values to Nodesin the SubscribersOPC UA AddressSpace. The configuration for such a dispatching is called SubscribedDataSet. The two concrete SubscribedDataSetoptions with standard OPC UA configuration are TargetVariablesand SubscribedDataSetMirror. The configuration of TargetVariablesallows the dispatching of DataSetMessagefields to existing Variablesin the SubscribersOPC UA AddressSpace. The configuration of SubscribedDataSetMirroris used if the received DataSetfields should be represented as Variablesin the SubscribersOPC UA AddressSpacebut the Variablesdo not exist and must be created as part of the Subscriberconfiguration.

An OPC UA Applicationcan be pre-configured to send messages as a Publisherbut commonly it is required to configure the information to be included into messages and also the frequency the messages are sent.

Subscriberscan use discovery mechanisms to find Publishersand to get the DataSetMetaDatanecessary to understand the messages. One example are HMI applications where the configuration can be done inside the Subscriber. But if the Subscriber is a device, it is expected that a configuration tool is required to configure the Subscriberfunctionality in the device.

The PubSubConfigurationDataTypeand the other configuration Structuresdefined in Clause 6can be used to prepare an offline PubSubconfiguration that can be stored in a binary file using the UABinaryFileDataType. Such a configuration can be used to configure Publishersand Suscribersif they do not have a online configuration interface or are configured through product-specific configuration tools.

If Publishersand Suscribersare also OPC UA Servers, they can provide the PubSubconfiguration Information Modeldefined in Clause 9. This model can be used by generic PubSubconfiguration tools.

A typical use case is controller to controller or machine to machine communication where both communication partners have a pre-configured list of input and output data Variablesand a generic configuration tool establishes the communication by selecting the Variablesto be published in the Publisherand then configures the Subscriberto receive the messages from the Publisherand to select the target Variablesin the Subscriber.

A Security Key Service(SKS) provides keys for message security that can be used by the Publisherto sign and encrypt NetworkMessagesand by the Subscriberto verify the signature of NetworkMessagesand to decrypt them.

The SKS is responsible for managing the keys used to publish or consume PubSub NetworkMessages. Separate keys are associated with each SecurityGroupIdin the system. The GetSecurityKeys Methodexposed by the SKS shall be called to receive necessary key material for a SecurityGroupId. GetSecurityKeyscan return more than one key. In this case the next key can be used when the current key is outdated without calling GetSecurityKeysfor every key needed. ThePubSubKeyServiceTypedefined in 8.2specifies the GetSecurityKeys Method.

The GetSecurityKeys Methodcan be implemented by a Publisheror by a central SKS. In both cases, the well-known NodeIdsfor the PublishSubscribe Objectand the related GetSecurityKeys Methodare used to call the GetSecurityKeys Method. The PublishSubscribe Objectis defined in 8.3.2.

The SetSecurityKeys Methodis typically used by a central SKS to push the security keys for a SecurityGroupinto a Publisheror Subscriber. The Methodis exposed by Publishersor Subscribersthat have no OPC UA Clientfunctionality. The Methodis part of the PublishSubscribeTypedefined in 9.1.3.2.

The SKS is the entity with knowledge of SecurityGroupsand it maintains a mapping between Rolesand SecurityGroups. The related User Authorizationmodel is defined in OPC 10000-3. The User Authorizationmodel defines the mapping of identities to Rolesand the mechanism to set Permissionsfor Roleson a Node. The Permissionson a SecurityGroup Objectis used to determine if a Rolehas access to the keys for the SecurityGroup.

An example for setting up a SecurityGroupand the configuration of affected Publishersand Subscribersis shown in Figure 9.

image012.png

Figure 9– SecurityGroup management sequence

To secure NetworkMessages, the NetworkMessagesshall be secured with keys provided in the context of a SecurityGroup. A SecurityGroupis created on a SKS using the Method AddSecurityGroup.

To limit access to the SecurityGroupand therefore to the security keys, Permissionsshall be set on the SecurityGroup Object. This requires the management of Rolesand Permissionsin the SKS.

To set the SecurityGrouprelation on the Publishersand Subscribers, the SecurityGroupIdand the SKS EndpointDescriptionsare configured in a PubSubgroup.

The Publisheror Subscriberuse keys provided by an SKS to secure messages exchanged via the Message Oriented Middleware. The handshake to pull the keys from a SKS is shown in Figure 10. The handshake to push the keys from an SKS to Publishersand Subscribersis shown in Figure 11.

image013.png

Figure 10– Handshake used to pull keys from SKS

To pull keys, the Publisheror Subscribercreates an encrypted connection and provides credentials that allow it access to the SecurityGroup. Then it passes the identifier of the SecurityGroupto the GetSecurityKeys Methodthat verifies the identity and returns the keys used to secure messages for the PubSubGroup. The GetSecurityKeys Methodis defined in 8.3.2.

The access to the GetSecurityKeys Methodmay use SessionlessInvoke Servicecalls. These calls typically use an Access Tokenthat is retrieved from an Authorization Service. Both concepts are defined in OPC 10000-4.

image014.png

Figure 11– Handshake used to push keys to Publishers and Subscribers

To push keys, the SKS creates an encrypted connection to a Publisheror Subscriberand provides credentials that allow it to provide keys for a SecurityGroup. Then it passes the identifier of the SecurityGroupand the keys used to secure messages for the SecurityGroupto the SetSecurityKeys Method. The SetSecurityKeys Methodis defined in 9.1.3.3.

If the initial pull or push fails, the affected PubSubcomponents like WriterGroupor DataSetReaderstay in the PreOperationalstate. If the updates fail and the PubSubcomponents do not have up to date key material, the state of the affected components change to Error. For both pull and push, the Clientexecuting the key exchange needs to retry the key exchange at a faster rate than the key lifetime.

Access to the SKS can be managed by an Authorization Serviceas shown in Figure 12.

image015.png

Figure 12– Handshake with a Security Key Service

The SKS is a Serverthat exposes a Methodcalled GetSecurityKeys. The Access Tokenis used to determine if the calling application is allowed to access the keys. One way to do this would be to check the Permissionsassigned to the SecurityGroup Objectidentified by theGetSecurityKeys Methodarguments. Publishersand Subscriberscan request keys if the Access Token they provideis mapped to Rolesthat have been granted Permissionto Browsethe SecurityGroup Object.

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 5.4.5.2and 5.4.5.3.

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.

image016.png

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.

image017.png

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).

image018.png

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.

image019.png

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.

image020.png

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.

image021.png

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.