Clause 5describes the general OPC UA PubSub concepts.

The DataSetconstitutes the payload of messages provided by the Publisherand consumed by the Subscriber. The DataSetis described in 5.2. The mapping to messages is described in 5.3. The participating entities like Publisherand Subscriberare described in 5.4.

The abstract communication parameters are described in Clause 6.

The mapping of this model to concrete message and transport protocol mappings is defined in Clause 7.

The OPC UA Information Modelfor PubSubconfiguration in Clause 9specifies the standard Objectsin an OPC UA AddressSpaceused to create, modify and expose an OPC UA PubSubconfiguration.

Figure 2provides an overview of the PublisherandSubscriberentities. It illustrates the flow of messages from a Publisherto one or more Subscribers. The PubSubcommunication model supports many other scenarios; for example, a Publishermay send a DataSetto multiple Message Oriented Middlewareand a Subscribermay receive messages from multiple Publishers.


Figure 2– Publisher and Subscriber entities

Publishersand Subscribersare loosely coupled. They often will not even know each other. Their primary relation is the shared understanding of specific types of data (DataSets), the publish characteristics of messages that include these data, and the Message Oriented Middleware.

The “messages” in Figure 2represent NetworkMessages. Each NetworkMessageincludes header information (e.g. identification and security data) and one or more DataSetMessages(the payload). The DataSetMessagesmay be signed and encrypted in accordance with the configured message security. A Security Key Serveris responsible for the distribution of the security keys needed for message security.

Each DataSetMessageis created from a DataSet. A component of a Publishercalled DataSetWritergenerates a continuous sequence of DataSetMessages. Syntax and semantics of DataSetsare described by DataSetMetaData. The selection of information for a DataSetin the Publisherand the data acquisition parameters are called PublishedDataSet.DataSet, DataSetMetaDataand PublishedDataSetare detailed in 5.2.

Publishersand Subscribersare typically configured through a configuration tool. The configuration can be done through a generic OPC UA PubSubconfiguration tool using the PubSubconfiguration Information Modeldefined in Clause 9or through product-specific configuration tools. To support the PubSubconfiguration Information Model, Publishersand Subscribersmust be also OPC UA Server.

NOTE The PubSub directory is an optional entity that allows Publishersto advertise their PublishedDataSetsand their communication parameters. This directory functionality is planned for a future version of this document.

A DataSetcan be thought of as a list of name and value pairs representing an Eventor a list of Variable Values.

A DataSetcan be created from an Eventor from a sample of Variable Values. The configuration of this application-data collector is called PublishedDataSet. DataSetfields can be defined to represent any information, for example, they could be internal Variablesin the Publisher, Eventsfrom the Publisheror collected by the Publisher, network data, or data from sub-devices.

DataSetMetaDatadescribed in 5.2.3defines the structure and content of a DataSet.

For publishing, a DataSetwill be encoded into a DataSetMessage. One or more DataSetMessagesare combined to form the payload of a NetworkMessage.

Figure 3illustrates the use of DataSetsfor publishing.


Figure 3– DataSet in the process of publishing

A PublishedDataSetis similar to either an Event MonitoredItemor a list of data MonitoredItemsin the Client Server Subscriptionmodel. Similar to an Event MonitoredItem, a PublishedDataSetcan select a list of Event fields. Similar to data MonitoredItems, the PublishedDataSetcan contain a list of Variables.

A DataSetdoes not define the mechanism to encode, secure and transport it. A DataSetWriterhandles the creation of a DataSetMessagefor a DataSet. The DataSetWritercontains settings for the encoding and transport of a DataSetMessage. Most of these settings depend on the selected Message Oriented Middleware.

The configuration of DataSetsand the way the data is obtained for publishing can be configured using the PubSubconfiguration model defined in 8.2or with vendor-specific configuration tools.

DataSetscan be individual for a Publisheror they can be derived from a DataSetClass. Such a DataSetClassacts as template declaring the content of a DataSet. The DataSetClassis identified by a globally unique id – the DataSetClassId(see

The DataSetMetaDatais identical for all PublishedDataSetsthat are configured based on this DataSetClass. The DataSetClassIdshall be in the corresponding field of the DataSetMetaData.

When all DataSetMessagesof a NetworkMessageare created from DataSetsthat are instances of the same DataSetClass, the DataSetClassIdof this class can be provided in the NetworkMessageheader.

DataSetMetaDatadescribes the content and semantics of a DataSet. The structure description includes overall DataSetattributes (e.g. name and version) and a set of fields with their name and data type. The order of the fields in the DataSetMetaDatashall match the order of values in the published DataSetMessages.

The DataSetMetaDataTypeis defined in

Example description (simplified, in pseudo-language):

Name: Temperature-Sensor Measurement

Fields: [1] Name=DeviceName, Type=String

[2] Name=Temperature, Type=Float, Unit=Celsius, Range={1,100}

Subscribersuse the DataSetMetaDatafor decoding the values of a DataSetMessageto a DataSet.Subscribersmay use name and data type for further processing or display of the published data.

Each DataSetMessagealso includes the version of the DataSetMetaDatathat it complies with. This allows Subscribersto verify if they have the corresponding DataSetMetaData. The related ConfigurationVersionDataTypeis defined in

DataSetMetaDatamay be specific to a single PublishedDataSet or identical for all PublishedDataSetsthat are configured based on a DataSetClass(see 5.2.2).

There are multiple options for Subscribersto get the initial DataSetMetaData:

There are multiple options to exchange the DataSetMetaDatabetween Publisherand Subscriberif the configuration changes.

The term message is used with various intentions in the messaging world. It sometimes only refers to the payload (the application data) and sometimes to the network packet that also includes protocol-, security-, or encoding-specific data. To avoid confusion, this document formally defines the term DataSetMessage to mean the application data (the payload) supplied by the Publisherand the term NetworkMessage to mean the message handed off and received from a specific Message Oriented Middleware.DataSetMessages are embedded in NetworkMessages. Figure 4shows the relationship of these message types.


Figure 4– OPC UA PubSub message layers

The transport protocol-specific headers and definitions are described in 7.3.

Subclauses 5.3.2to 5.3.4provide an abstract definition of DataSetMessageandNetworkMessage. The concrete structure depends on the message mapping and is described in 7.2.

A DataSetMessagefield is the representation of a DataSetfield in a DataSetMessage.

A DataSet field contains the actual value as well as additional information about the value like status and timestamp.

A DataSetfield can be represented as a DataValue, as a Variantor as a RawDatain the DataSetMessagefield. The representation depends on the DataSetFieldContentMaskdefined in

The representation as a DataValueis used if value, status and timestamp are included in the DataSetMessage.

The representation as Variantis used if value or bad status should be included in the DataSetMessage.

The representation as RawDatais the most efficient format and is used if a common status and timestamp per DataSet is sufficient.

A DataSetMessageis created from a DataSet. It consists of a header and the encoded fields of the DataSet.

Depending on the configured DataSetMessageContentMask, a DataSetMessagemay exist in different forms and with varying detail.DataSetMessagesdo not contain any information about the data acquisition or information source in the Publisher.

Additional header information includes:

DataSetWriterIdIdentifies theDataSetWriterand indirectly the PublishedDataSet.

Sequence numberA number that is incremented for each DataSetMessage. Can be used to verify the ordering and to detect missing messages.

TimestampA timestamp describing when the data in this DataSetMessagewas obtained.

VersionVersion information about the configuration of the DataSetMetaData.

StatusStatus information about the data in this DataSetMessage.

Keep aliveWhen no DataSetMessagesare sent for a configured time period, a keep alive DataSetMessageis sent to signal the Subscribersthat the Publisheris still alive.

DataSetMessagesare either sent cyclicly or acyclicly in a publishing interval. Acyclic DataSetsare sent as event DataSetMessages. Cyclic DataSetscan create at most one DataSetMessagesper interval. Acyclic DataSetscan create multiple event DataSetMessagesper interval.

For cyclic DataSets, some encodings differentiate between key frame DataSetMessages and delta frame DataSetMessages. A key frame DataSetMessageincludesvalues forall fields of the DataSet.A delta frame DataSetMessageonly contains the subset that changed since the previous DataSetMessage.

A key frame DataSetMessageis sent after a configured number of DataSetMessages.

The DataSetMetaDataas data contract defines the fields contained in the DataSetMessage. The header settings for DataSetMessageand NetworkMessagedefine the communication contract between Publisherand Subscriber.

A heartbeat DataSetMessageis a key frame that only contains header information. It is used to indicate that the Publisheris still alive without sending payload. A heartbeat DataSetMessageis not created from a DataSet.

The NetworkMessageis a container for DataSetMessagesand includes information shared between DataSetMessages. This information consists of:

PublisherIdIdentifies the Publisher.

Security dataOnly available for encodings that support message security. The relevant information is specified in the message mapping.

Promoted fieldsSelected fields out of the DataSetalso sent in the header.

PayloadOne or more DataSetMessages.

The payload, consisting of the DataSetMessageswill be encrypted in accordance with the configured message security. Individual fields of a DataSetMessagecan be marked as being “promoted fields”. Such fields are intended for filtering or routing and therefore are never encrypted. How and where the values for promoted fields are inserted depends on the NetworkMessageformat and the used protocol. The NetworkMessageheader is not encrypted to enable efficient filtering.

Message security in PubSubconcerns integrity and confidentiality of the published message payload. The base concepts for OPC UA security are defined in OPC 10000-2. The level of security can be:

  • No security
  • Signing but no encryption
  • Signing and encryption

Message security is end-to-end security (from Publisherto Subscriber) and requires common knowledge of the cryptographic keys necessary to sign and encrypt on the Publisherside as well as validate signature and decrypt on the Subscriberside.

The keys used for message security are managed in the context of a SecurityGroup. The basic concepts of a SecurityGroupare described in 5.3.7.

This standard defines a general distribution framework for cryptographic keys. This framework is introduced in 5.4.4.

All parameters that are relevant for message security are described in 6.2.5. These parameters are independent of any Brokerlevel transport security.

The message security for PubSubis independent of the transport protocol mapping and is completely defined by OPC UA.

The transport security is specific to the transport protocol mapping.

When using a broker-based middleware (see, confidentiality and integrity can be ensured with the transport security between Publishersand the Brokeras well as Subscribersand the Broker. The Brokerlevel security in addition requires all Publishersand Subscribersto have credentials that grant them access to a Brokerresource.

Transport security may be hop-by-hop security with some risk of man-in-the-middle attacks. It also requires trusting the Brokersince the Brokercan read the messages. Combining transport security with message security reduces this risk.

A SecurityGroupis an abstraction that represents the message security settings and security keys for a subset of NetworkMessagesexchanged between Publishersand Subscribers. The security keys are used to encrypt and decrypt NetworkMessagesand to generate and check signatures on a NetworkMessage.

A Security Key Service(SKS) manages SecurityGroupsand maintains a mapping between Rolesand their access Permissionsfor a SecurityGroup. This mapping defines if a Publisheror Subscriberhas access to the security keys of a SecurityGroup. The SKS is described in more detail in 5.4.4.

A SecurityGroupis identified with a unique identifier called the SecurityGroupId. It is unique within the SKS. A Publisherfor its PublishedDataSetsneeds to know the SecurityGroupId. For Subscribersthe SecurityGroupIdis distributed as metadata together with the DataSetMetaData. The metadata for a SecurityGroupIdincludes the EndpointDescriptionof the responsible SKS. Publishers and Subscribers use the EndpointDescriptionto access the SKS and the SecurityGroupIdto obtain the security keys for a SecurityGroup.

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.


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 need 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 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, 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 PubSubConnection. 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.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.


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

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


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.


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

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.


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

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.