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.
A single Publishermay support multiple PublishedDataSetsand multiple DataSetWritersto one or more Message Oriented Middleware. A DataSetWriteris a logical component of a Publisher. See 18.104.22.168for 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.
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 DataSetFieldContentMask(see 22.214.171.124) controls which attributes of a value shall be encoded.
- The DataSetMessageContentMask(see 126.96.36.199.2) controls which header fields shall be encoded.
- The KeyFrameCount(see 188.8.131.52) greater than or equal to 1 controls whether a key frame or a delta frame DataSetMessageis to be created. A KeyFrameCountof 0 is used for non-cyclic PublishedDataSets,like PublishedEvents.
The resulting DataSetMessageis passed on to the next step together with the DataSetWriterId(see 184.108.40.206), the DataSetClassId(see 220.127.116.11), the ConfigurationVersionof the DataSetMetaData(see 18.104.22.168.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 22.214.171.124) defined on the PubSubConnection. The structure of this message is protocol specific. If the SecurityMode(see 126.96.36.199) requires message security, the SecurityGroupId(see 188.8.131.52) 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.
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.
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).
Once a DataSetMessagehas been selected as relevant, it will be forwarded to the corresponding DataSetReaderfor decoding into a DataSet. See 184.108.40.206for 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.
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.
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.
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 220.127.116.11.
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.
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.
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.
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 18.104.22.168.
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.
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 22.214.171.124and 126.96.36.199.
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.
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.
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.
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).
Advantages of this model (partly depending on used Brokerand its configuration) include:
- Publisherand Subscriberdo 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 Brokersor scalable Brokers.
- Publisherand Subscriberlifetimes do not have to overlap. The Publisherapplication can push NetworkMessages to the Brokerand terminate. The NetworkMessages will be available for the Subscriberapplication later.
- Publisherand Subscribercan use different messaging protocols to communicate with the Broker.
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.
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:
- transport security between Publishersor Subscribersand the Broker,or
- message security as end-to-end security between Publisherand Subscriber.
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.
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.
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.