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.
A single Publishermay support multiple PublishedDataSetsand multiple DataSetWritersto one or more Message Oriented Middleware. A DataSetWriteris a logical component of a Publisher. See 188.8.131.52for 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.
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 DataSetFieldContentMask(see 184.108.40.206) controls which attributes of a value shall be encoded.
- The DataSetMessageContentMask(see 220.127.116.11.2) controls which header fields shall be encoded.
- The KeyFrameCount controls whether a key frame or a delta frame DataSetMessageis to be created.
The resulting DataSetMessageis passed on to the next step together with the DataSetWriterId(see 18.104.22.168), the DataSetClassId(see 22.214.171.124), the ConfigurationVersionof the DataSetMetaData(see 126.96.36.199.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 188.8.131.52) defined on the WriterGroup. The structure of this message is protocol specific. If the SecurityMode(see 184.108.40.206) requires message security, the SecurityGroupId(see 220.127.116.11) 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.
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 18.104.22.168for 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 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.
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 22.214.171.124.
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 a 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.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.
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 126.96.36.199.
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.
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 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.
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:
- transport security between Publishersor Subscribersand the Brokeror
- 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.