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. Figure 5illustrates a Publisherwith data collection, encoding and message sending.


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 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 have to exist to generate the OPC UA PubSubmessages.


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

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, the DataSetClassId(see, the ConfigurationVersionof the DataSetMetaData(see, 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 defined on the WriterGroup. The structure of this message is protocol specific. If the SecurityMode(see requires message security, the SecurityGroupId(see is used to fetch the SecurityPolicyand the security keys from the SKS (see 5.4.3). 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.


Figure 7– Subscriber details

To determine for which DataSetMessages and on which Message Oriented Middlewareto subscribe, the Subscriberhas 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 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.


Figure 8– Subscriber message reception sequence

The Subscriberhas 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 has to be 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.

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

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

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.


Figure 9– SecurityGroup Management Sequence

To secure NetworkMessages, the NetworkMessagesmust 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, Permissionsmust 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 PubSubgroups.

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 a SKS to Publishersand Subscribersis shown in Figure 11.


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

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.


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

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


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 specification 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 part 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 specification. 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 a connectionObjectper Broker. The Brokeris configured through an URL in the connection. The connection can have one or more groups which identity 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.