The Publisher is the PubSub entity that sends NetworkMessages to 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 Publisher is also an OPC UA Server. For the abstract PubSub concepts, 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 5 illustrates a Publisher with data collection, encoding and message sending.
A single Publisher may support multiple PublishedDataSets and multiple DataSetWriters to one or more Message Oriented Middleware. A DataSetWriter is a logical component of a Publisher. See 5.4.1.2 for further information about the DataSet writing process.
If the Publisher is an OPC UA Server, it can expose the Publisher configuration in its AddressSpace. This information may be created through product specific configuration tools or through the OPC UA defined Methods. The OPC UA Information Model for PubSub configuration is specified in clause 9.
Figure 6 illustrates the process inside a Publisher when creating and sending messages and the parameters required to accomplish it. The components, like DataSet collection or DataSetWriter should be considered abstract. They may not exist in every Publisher as independent entities. However, comparable processes have to exist to generate the OPC UA PubSub messages.
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 PublishedDataSet also defines the DataSetMetaData. Collection is a generic expression for various different options, like monitoring of Variables in 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 DataSetWriter takes the DataSet and creates a DataSetMessage. DataSetMessages from DataSetWriters in one WriterGroup can be inserted into a single NetworkMessage. The creation of a DataSetMessage is guided by the following parameters:
- The DataSetFieldContentMask (see 6.2.3.2) controls which attributes of a value shall be encoded.
- The DataSetMessageContentMask (see 6.3.1.2.2) controls which header fields shall be encoded.
- The KeyFrameCount controls whether a key frame or a delta frame DataSetMessage is to be created.
The resulting DataSetMessage is passed on to the next step together with the DataSetWriterId (see 6.2.3.1), the DataSetClassId (see 6.2.2.2), the ConfigurationVersion of the DataSetMetaData (see 6.2.2.1.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.6.1) defined on the WriterGroup. The structure of this message is protocol specific. If the SecurityMode (see 6.2.4.2) requires message security, the SecurityGroupId (see 6.2.4.3) is used to fetch the SecurityPolicy and the security keys from the SKS (see 5.4.3). This information is used to encrypt and/or sign the NetworkMessage as required by the SecurityMode.
The final step is delivery of the NetworkMessage to the Message Oriented Middleware through the configured Address.
Subscribers are the consumers of NetworkMessages from the Message Oriented Middleware. They may be OPC UA Clients, OPC UA Servers or applications that are neither Client nor Server but only understand the structure of OPC UA PubSub messages. Figure 7 illustrates a Subscriber with filtering, decoding and dispatching of NetworkMessages.
To determine for which DataSetMessages and on which Message Oriented Middleware to subscribe, the Subscriber has to be configured and/or use discovery mechanisms.
Subscribers shall be prepared to receive messages that they do not understand or are irrelevant. Each NetworkMessage provides unencrypted data in the NetworkMessage header to support identifying and filtering of relevant Publishers, DataSetMessages, DataSetClasses or other relevant message content (see 5.3).
If a NetworkMessage is signed or signed and encrypted, the Subscriber will need the proper security keys (see 5.3.5) to verify the signature and decrypt the relevant DataSetMessages.
Once a DataSetMessage has been selected as relevant, it will be forwarded to the corresponding DataSetReader for decoding into a DataSet. See 5.4.2.2 for further information about this DataSet reading process. The resulting DataSet is then further processed or dispatched in the Subscriber.
If the Subscriber is 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 Model for PubSub configuration is specified in clause 9.
Figure 8 illustrates the process inside a Subscriber when 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 Subscriber has to select the required Message Oriented Middleware and 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 Broker when using MQTT or AMQP. Once subscribed, the Subscriber will start listening. The sequence starts when a NetworkMessage is received. The Subscriber may have configured filters (like a PublisherId, DataSetWriterId or a DataSetClassId) so that it can drop all messages that do not match the filter.
Once a NetworkMessage has been accepted, it has to be decrypted and decoded. The security parameters are the same as for the Publisher.
Each DataSetMessage of interest is passed on to a DataSetReader. Here, the DataSetMetaData is used to decode the DataSetMessage content to a DataSet. The DataSetMetaData in particular provides the complete field syntax including the name, data type, and other relevant Properties like engineering units. Version information that exists in both the DataSetMessage and the DataSetMetaData allows the Subscriber to detect version changes. If a major change occurs, the Subscriber needs to get an updated DataSetMetaData.
Any further processing is application-specific. For example, an additional dispatching step may map the received values to Nodes in the Subscribers OPC 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 Publisher to sign and encrypt NetworkMessages and by the Subscriber to verify the signature of NetworkMessages and to decrypt them.
The SKS is responsible for managing the keys used to publish or consume PubSub NetworkMessages. Separate keys are associated with each SecurityGroupId in the system. The GetSecurityKeys Method exposed by the SKS shall be called to receive necessary key material for a SecurityGroupId. GetSecurityKeys can return more than one key. In this case the next key can be used when the current key is outdated without calling GetSecurityKeys for every key needed. The PubSubKeyServiceType defined in 8.2 specifies the GetSecurityKeys Method.
The GetSecurityKeys Method can be implemented by a Publisher or by a central SKS. In both cases, the well-known NodeIds for the PublishSubscribe Object and the related GetSecurityKeys Method are used to call the GetSecurityKeys Method. The PublishSubscribe Object is defined in 8.4.
The SetSecurityKeys Method is typically used by a central SKS to push the security keys for a SecurityGroup into a Publisher or Subscriber. The Method is exposed by Publishers or Subscribers that have no OPC UA Client functionality. The Method is part of the PublishSubscribeType defined in 9.1.3.2.
The SKS is the entity with knowledge of SecurityGroups and it maintains a mapping between Roles and SecurityGroups. The related User Authorization model is defined in OPC 10000-3. The User Authorization model defines the mapping of identities to Roles and the mechanism to set Permissions for Roles on a Node. The Permissions on a SecurityGroup Object is used to determine if a Role has access to the keys for the SecurityGroup.
An example for setting up a SecurityGroup and the configuration of affected Publishers and Subscribers is shown in Figure 9.
Figure 9 – SecurityGroup Management Sequence
To secure NetworkMessages, the NetworkMessages must be secured with keys provided in the context of a SecurityGroup. A SecurityGroup is created on a SKS using the Method AddSecurityGroup.
To limit access to the SecurityGroup and therefore to the security keys, Permissions must be set on the SecurityGroup Object. This requires the management of Roles and Permissions in the SKS.
To set the SecurityGroup relation on the Publishers and Subscribers, the SecurityGroupId and the SKS EndpointDescriptions are configured in a PubSub groups.
The Publisher or Subscriber use 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 Publishers and Subscribers is shown in Figure 11.
Figure 10 – Handshake used to pull keys from SKS
To pull keys, the Publisher or Subscriber creates an encrypted connection and provides credentials that allow it access to the SecurityGroup. Then it passes the identifier of the SecurityGroup to the GetSecurityKeys Method that verifies the identity and returns the keys used to secure messages for the PubSubGroup. The GetSecurityKeys Method is defined in 8.4.
The access to the GetSecurityKeys Method may use SessionlessInvoke Service calls. These calls typically use an Access Token that 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 Publisher or Subscriber and provides credentials that allow it to provide keys for a SecurityGroup. Then it passes the identifier of the SecurityGroup and the keys used to secure messages for the SecurityGroup to the SetSecurityKeys Method. The SetSecurityKeys Method is defined in 9.1.3.3.
Access to the SKS can be managed by an Authorization Service as shown in Figure 12.
Figure 12 – Handshake with a Security Key Service
The SKS is a Server that exposes a Method called GetSecurityKeys. The Access Token is used to determine if the calling application is allowed to access the keys. One way to do this would be to check the Permissions assigned to the SecurityGroup Object identified by the GetSecurityKeys Method arguments. Publishers and Subscribers can request keys if the Access Token they provide is mapped to Roles that have been granted Permission to Browse the SecurityGroup Object.
Message Oriented Middleware as 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 PubSub are described in 7.3.
This part describes two general types of Message Oriented Middleware to cover a large number of use cases. The two types, broker-less and broker-based middleware are described in 5.4.4.2 and 5.4.4.3.
With this option, OPC UA PubSub relies on the network infrastructure to deliver NetworkMessages to one or more receivers. Network devices – like network routers, switches, or bridges – are typically used for this purpose.
One example is a switched network and the use of UDP with unicast or multicast messages shown in Figure 13.
Figure 13 – PubSub using network infrastructure
Advantages of this model include:
- Only requires standard network equipment and no additional software components like a Broker.
- Message delivery is assumed to be direct without software intermediaries and therefore provides reduced latency and overhead.
- UDP protocol supports multiple subscribers using multicast addressing.
Figure 14 depicts the applications, entities and messages involved in peer to peer communication using UDP as a protocol that does not require a Broker.
Figure 14 – UDP Multicast Overview
The PublishSubscribe Object contains a connection Object for each address like an IP multicast address. The connection can have one or more groups with DataSetWriters. A group can publish DataSets at the defined publishing interval.
In each publishing interval, a DataSet is collected for a PublishedDataSet which can be a list of sampled data items in the Publisher OPC UA Address Space. For each DataSet a DataSetMessage is created. The DataSetMessages are sent in a NetworkMessage to the IP multicast address.
OPC UA Applications like HMI applications would use the values of the DataSetMessage that they are interested in.
An OPC UA Application that maps data fields from UADP DataSetMessages to internal Variables can be configured through the DataSetReader Object and dispatcher in the Subscriber. The configuration of a DataSetReader defines how to decode the DataSetMessage to a DataSet. The SubscribedDataSet defines which field in the DataSet is mapped to which Variable in the OPC UA Application.
With OPC UA UDP there is no guarantee of timeliness, delivery, ordering, or duplicate protection. The sequence numbers in DataSetMessages provide a solution for ordering and duplicate detection. The reliability is improved by the option to send the complete DataSet in every DataSetMessage or with the option to repeat NetworkMessages.
Other transport protocol mappings used with the broker-less model could provide guarantee of timeliness, delivery, ordering, or duplicate protection.
This option assumes a messaging Broker in the middle as shown in Figure 15. No application is speaking directly to other applications. All the communication is passed through the Broker. The Broker routes the NetworkMessages to the right applications based on business criteria ("queue name", "routing key", "topic" etc.) rather than on physical topology (IP addresses, host names).
Figure 15 – PubSub using broker
Advantages of this model (partly depending on used Broker and its configuration) include:
- Publisher and Subscriber do not have to be directly addressable. They can be anywhere as long as they have access to the Broker.
- Fan out can be handled to a very large list of Subscribers, multiple networks or even chained Brokers or scalable Brokers.
- Publisher and Subscriber lifetimes do not have to overlap. The Publisher application can push NetworkMessages to the Broker and terminate. The NetworkMessages will be available for the Subscriber application later.
- Publisher and Subscriber can use different messaging protocols to communicate with the Broker.
In addition, the Broker model is to some extent resistant to the application failure. So, if the application is buggy and prone to failure, the NetworkMessages that are already in the Broker will be retained even if the application fails.
Figure 16 depicts the applications, entities and messages involved in typical communication scenarios with a Broker. It requires use of messaging protocols that a Broker understands, like AMQP defined in ISO/IEC 19464:2014 or MQTT defined in ISO/IEC 20922:2016. In this model the Message Oriented Middleware will be a Broker that relays NetworkMessages from Publishers to Subscribers. The Broker may also be able to queue messages and send the same message to multiple Subscribers.
Note that the Broker functionality is outside the scope of this specification. In terms of the messaging protocols, the Broker is a messaging server (the OPC UA Publisher and the OPC UA Subscriber are messaging clients). The messaging protocols define how to connect to a messaging server and what fields in a message influence the Broker functionality.
An OPC UA Publisher that publishes data may be configured through the PubSub configuration model. It contains a connection Object per Broker. The Broker is 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 DataSetWriters that format a DataSet as required for the messaging protocol. A DataSet can be collected from a list of Event fields and/or selected Variables. Such a configuration is called PublishedDataSet.
Each DataSet is sent as a separate DataSetMessage serialized with a format that depends on the DataSetWriter. One DataSetMessage format is the JSON message mapping which represents the DataSet in a format which Subscribers can understand without knowledge of OPC UA. Another DataSetMessage format is the UADP message mapping.
Message confidentiality and integrity with the Broker based communication model can be ensured at two levels:
- transport security between Publishers or Subscribers and the Broker or
- message security as end-to-end security between Publisher and Subscriber.
The Broker level security requires all Publishers and Subscribers to have credentials that grant them access to the necessary queue or topic. In addition, all communication with the Broker uses transport level security to ensure confidentiality. The security parameters are specified on the connection and group.
The message security provided by the Publisher is only defined for the UADP message mapping.