1 Scope

This part of OPC Unified Architecture (OPC UA) defines the PubSub communication model. It defines an OPC UA publish subscribe pattern which complements the client server pattern defined by the Services in OPC 10000-4. See OPC 10000-1 for an overview of the two models and their distinct uses.

PubSub allows the distribution of data and events from an OPC UA information source to interested observers inside a device network as well as in IT and analytics cloud systems.

This document consists of

a general introduction of the PubSub concepts,

a definition of the PubSub configuration parameters,

mapping of PubSub concepts and configuration parameters to messages and transport protocols,

and a PubSub configuration model.

Not all OPC UA Applications will need to implement all defined message and transport protocol mappings. OPC 10000-7 defines the Profile that dictate which mappings need to be implemented in order to be compliant with a particular Profile.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

OPC 10000-1: OPC Unified Architecture - Part 1: Overview and Concepts

3 Terms, definitions and abbreviated terms

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, and OPC 10000-4, as well as the following apply.

3.1.1 Action

an operation that is executed by a Responder when it receives a request message sent by a Requestor

3.1.2 DataSetClass

template declaring the content of a DataSet

3.1.3 DataSetMetaData

data describing the content and semantic of a DataSet

3.1.4 DataSetReader

entity receiving DataSetMessages from a Message Oriented Middleware

3.1.5 Untitled

3.1.6 DataSetWriter

entity creating DataSetMessages from DataSets and publishing them through a Message Oriented Middleware

3.1.7 Untitled

3.1.8 Requestor

an entity that initiates an Action by sending a request to a Responder

3.1.9 Responder

an entity that executes an Action when a request is received from a Requestor

3.1.10 Untitled

3.1.11 PublishedDataSet

configuration of application-data to be published as DataSet

3.1.12 SecurityGroup

grouping of security settings and security keys used to access messages from a Publisher

3.1.13 SubscribedDataSet

configuration for dispatching of received DataSets

3.2 Abbreviated terms

• AMQP Advanced Message Queuing Protocol

• AS Authorization Service

• CTL Certificate Trust List

• DSCP Differentiated Services Code Point

• DTLS Datagram Transport Layer Security

• HMI Human Machine Interface

• IGMP Internet Group Management Protocol

• MIME Multipurpose Internet Mail Extensions

• MLD Multicast Listener Discovery

• MQTT MQ Telemetry Transport

• MTU Maximum Transmission Unit

• PCP Priority Code Point

• QoS Quality of Service

• SKS Security Key Service

• TSN Time Sensitive Networking

• UA Unified Architecture

• UADP UA Datagram Protocol

• UDP User Datagram Protocol

• URI Uniform Resource Identifier

• URL Uniform Resource Locator

• VID VLAN Identifier

4 Overview

4.1 Fields of application

In PubSub the participating OPC UA Applications with their roles as Publishers and Subscribers are decoupled. The number of Subscribers receiving data from a Publisher does not influence the Publisher. This makes PubSub suitable for applications where location independence and/or scalability are required.

The following are some example uses for PubSub:

Configurable peer-to-peer communication between controllers and between controllers and HMIs. The peers are not directly connected and do not even need to know about the existence of each other. The data exchange often requires a fixed time-window; it may be point-to-point connection or data distribution to many receivers.

Asynchronous workflows. For example, an order processing application can place an order on a message queue or an enterprise service bus. From there it can be processed by one or more workers.

Logging to multiple systems. For example, sensors or actuators can write logs to a monitoring system, an HMI, an archive application for later querying, and so on.

OPC UA Servers representing services or devices can stream data to applications hosted in the cloud. For example, backend servers, big data analytics for system optimization and predictive maintenance.

4.2 Abstraction layers

PubSub is designed to be flexible and is not bound to a particular messaging system. All components and activities are first described abstractly in Clause 5 and do not represent a specification for implementation. The concrete communication parameters are specified in Clause 6. The concrete transport protocol mappings and message mappings are specified in Clause 7.

Defined with these abstraction layers, PubSub can be used to transport different types of information through networks with different characteristics as illustrated with two examples:

PubSub with UDP transport and binary encoded messages may be well-suited in production environments for frequent transmission of small amounts of data. It also allows data exchange in one-to-one and one-to-many configurations.

The use of established standard messaging protocols like MQTT with JSON data encoding supports the cloud integration path and readily allows handling of the information in modern stream and batch analytics systems.

4.3 Decoupling by use of middleware

In PubSub the participating OPC UA Applications can assume the roles Publisher and Subscriber. Publishers are the sources of data, while Subscribers consume that data. Communication in PubSub is message-based. Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what Publishers there are.

Message Oriented Middleware is software or hardware infrastructure that supports sending and receiving messages between distributed systems. The implementation of this distribution depends on the Message Oriented Middleware.

Figure 1 illustrates that Publishers and Subscribers only interact with the Message Oriented Middleware which provides the means to forward the data to one or more receivers.

To cover a large number of use cases, OPC UA PubSub supports two largely different Message Oriented Middleware variants:

a broker-less form, where the Message Oriented Middleware is the network infrastructure that is able to route datagram-based messages. Subscribers and Publishers use datagram protocols like UDP;

a broker-based form, where the core component of the Message Oriented Middleware is a message Broker. Subscribers and Publishers use standard messaging protocols like MQTT to communicate with the Broker. All messages are published to specific queues (e.g. topics, nodes) that the Broker exposes and Subscribers can listen to these queues. The Broker may translate messages from the formal messaging protocol of the Publisher to the formal messaging protocol of the Subscriber.

4.4 Synergy of models

PubSub and Client Server are both based on the OPC UA Information Model. PubSub therefore can easily be integrated into OPC UA Servers and OPC UA Clients. Quite typically, a Publisher will be an OPC UA Server (the owner of information) and a Subscriber is often an OPC UA Client. Above all, the PubSub Information Model for configuration (see 9) promotes the configuration of Publishers and Subscribers using the OPC UA Client Server model.

Nevertheless, the PubSub communication does not require such a role dependency. I.e., OPC UA Clients can be Publishers and OPC UA Servers can be Subscribers. In fact, there is no necessity for Publishers or Subscribers to be either an OPC UA Server or an OPC UA Client to participate in PubSub communications.

More details on how Subscriptions in the Client Server communication model compare to PubSub are described in Annex C.

5 PubSub Concepts

5.1 General

Clause 5 describes the general OPC UA PubSub concepts.

The DataSet constitutes the payload of messages provided by the Publisher and consumed by the Subscriber. The DataSet is described in 5.2. The mapping to messages is described in 5.3. The participating entities like Publisher and Subscriber are 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 Model for PubSub configuration in Clause 9 specifies the standard Objects in an OPC UA AddressSpace used to create, modify and expose an OPC UA PubSub configuration.

Figure 2 provides an overview of the Publisher and Subscriber entities. It illustrates the flow of messages from a Publisher to one or more Subscribers. The PubSub communication model supports many other scenarios; for example, a Publisher may send a DataSet to multiple Message Oriented Middleware and a Subscriber may receive messages from multiple Publishers.

Publishers and Subscribers are 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 2 represent NetworkMessages. Each NetworkMessage includes header information (e.g. identification and security data) and one or more DataSetMessages (the payload). The DataSetMessages may be signed and encrypted in accordance with the configured message security. A Security Key Server is responsible for the distribution of the security keys needed for message security. In addition, the transport may supply security for certain protocol mappings.

Each DataSetMessage is created from a DataSet. A component of a Publisher called DataSetWriter generates a continuous sequence of DataSetMessages. Syntax and semantics of DataSets are described by DataSetMetaData. The selection of information for a DataSet in the Publisher and the data acquisition parameters are called PublishedDataSet. DataSet, DataSetMetaData and PublishedDataSet are detailed in 5.2.

Publishers and Subscribers are typically configured through a configuration tool. The configuration can be done through a generic OPC UA PubSub configuration tool using the PubSub configuration Information Model defined in Clause 9 or through product-specific configuration tools. To support the PubSub configuration Information Model, Publishers and Subscribers must be also OPC UA Server.

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

5.2 DataSet

5.2.1 General

A DataSet can be thought of as a list of name and value pairs representing an Event or a list of Variable Values.

A DataSet can be created from an Event or from a sample of Variable Values. The configuration of this application-data collector is called PublishedDataSet. DataSet fields can be defined to represent any information, for example, they could be internal Variables in the Publisher, Events from the Publisher or collected by the Publisher, network data, or data from sub-devices.

DataSetMetaData described in 5.2.3 defines the structure and content of a DataSet.

For publishing, a DataSet will be encoded into a DataSetMessage. One or more DataSetMessages are combined to form the payload of a NetworkMessage.

Figure 3 illustrates the use of DataSets for publishing.

A PublishedDataSet is similar to either an Event MonitoredItem or a list of data MonitoredItems in the Client Server Subscription model. Similar to an Event MonitoredItem, a PublishedDataSet can select a list of Event fields. Similar to data MonitoredItems, the PublishedDataSet can contain a list of Variables.

A DataSet does not define the mechanism to encode, secure and transport it. A DataSetWriter handles the creation of a DataSetMessage for a DataSet. The DataSetWriter contains settings for the encoding and transport of a DataSetMessage. Most of these settings depend on the selected Message Oriented Middleware.

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

5.2.2 DataSetClass

DataSets can be individual for a Publisher or they can be derived from a DataSetClass. Such a DataSetClass acts as template declaring the content of a DataSet. The DataSetClass is identified by a globally unique id – the DataSetClassId (see 6.2.3.3).

The DataSetMetaData is identical for all PublishedDataSets that are configured based on this DataSetClass. The DataSetClassId shall be in the corresponding field of the DataSetMetaData.

When all DataSetMessages of a NetworkMessage are created from DataSets that are instances of the same DataSetClass, the DataSetClassId of this class can be provided in the NetworkMessage header.

5.2.3 DataSetMetaData

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

The DataSetMetaDataType is defined in 6.2.3.2.3.

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}

Subscribers use the DataSetMetaData for decoding the values of a DataSetMessage to a DataSet. Subscribers may use name and data type for further processing or display of the published data.

Each DataSetMessage also includes the version of the DataSetMetaData that it complies with. This allows Subscribers to verify if they have the corresponding DataSetMetaData. The related ConfigurationVersionDataType is defined in 6.2.3.2.6.

DataSetMetaData may be specific to a single PublishedDataSet or identical for all PublishedDataSets that are configured based on a DataSetClass (see 5.2.2).

There are multiple options for Subscribers to get the initial DataSetMetaData:

The Subscriber is an OPC UA Client and is able to get the necessary configuration information from the PubSub configuration model (see 9.1.4.2.1) provided by the Publisher or from a configuration server.

The Subscriber supports the OPC UA configuration Methods defined in the PubSub configuration model.

The Subscriber receives the DataSetMetaData as NetworkMessage from the Publisher. This may require an option for the Subscriber to request this NetworkMessage from the Publisher.

The Subscriber is configured with product-specific configuration means.

There are multiple options to exchange the DataSetMetaData between Publisher and Subscriber if the configuration changes.

The DataSetMetaData is sent as a NetworkMessage from the Publisher to the Subscriber before DataSetMessages with changed content are sent. The used Message Oriented Middleware should ensure reliable delivery of the message. The mapping for the Message Oriented Middleware defines a way for the Subscriber to get the DataSetMetaData. The Subscriber goes to an error state if it has not received the new DataSetMetaData that matches the ConfigurationVersion of the received DataSetMessage.

The Subscriber is automatically updated via the OPC UA configuration Methods defined in the PubSub configuration model when the DataSet in the Publisher is updated.

The Subscriber is an OPC UA Client and is able to obtain the update from the Publisher or a configuration server via the information exposed by the PubSub configuration model.

The Subscriber is updated with product-specific configuration means when the DataSet in the Publisher is changed.

5.3 Messages

5.3.1 General

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 Publisher and the term NetworkMessage to mean the message handed off and received from a specific Message Oriented Middleware. DataSetMessages are embedded in NetworkMessages. Figure 4 shows the relationship of these message types.

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

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

DataSetMessages are just one of the possible MessageTypes transported within a NetworkMessage. The different MessageTypes are defined in 7.2.

5.3.2 DataSetMessage field

A DataSetMessage field is the representation of a DataSet field in a DataSetMessage.

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

A DataSet field can be represented as a DataValue, as a Variant or as a RawData in the DataSetMessage field. The representation depends on the DataSetFieldContentMask defined in 6.2.4.2 and the message mappings defined in 7.2.

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

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

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

5.3.3 DataSetMessage

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

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

Additional header information includes:

DataSetMessages are either sent cyclicly or acyclicly in a publishing interval. Acyclic DataSets are sent as event DataSetMessages. Cyclic DataSets can create at most one DataSetMessages per interval. Acyclic DataSets can create multiple event DataSetMessages per interval.

For cyclic DataSets, some encodings differentiate between key frame DataSetMessages and delta frame DataSetMessages. A key frame DataSetMessage includes values for all fields of the DataSet. A delta frame DataSetMessage only contains the subset that changed since the previous DataSetMessage.

A key frame DataSetMessage is sent after a configured number of DataSetMessages.

The DataSetMetaData as data contract defines the fields contained in the DataSetMessage. The header settings for DataSetMessage and NetworkMessage define the communication contract between Publisher and Subscriber.

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

5.3.4 NetworkMessage

The NetworkMessage is a container for messages of different MessageTypes defined in 7.2.

A NetworkMessage can contain an array of DataSetMessages and includes information shared between DataSetMessages. This information consists of:

The payload, consisting of the DataSetMessages will be encrypted in accordance with the configured message security. Individual fields of a DataSetMessage can 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 NetworkMessage format and the used protocol. The NetworkMessage header is not encrypted to enable efficient filtering.

5.3.5 Message security

Message security in PubSub concerns 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 Publisher to Subscriber) and requires common knowledge of the cryptographic keys necessary to sign and encrypt on the Publisher side as well as validate signature and decrypt on the Subscriber side.

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

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

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

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

5.3.6 Transport security

The transport security is specific to the transport protocol mapping. This could be TLS for broker-based middleware and DTLS for broker-less middleware.

When using a broker-based middleware (see 5.4.6.2.2), confidentiality and integrity can be ensured with the transport security between Publishers and the Broker as well as Subscribers and the Broker. The Broker level security in addition requires all Publishers and Subscribers to have credentials that grant them access to a Broker resource.

Transport security may be hop-by-hop security with some risk of man-in-the-middle attacks. It also requires trusting the Broker since the Broker can read the messages.

Transport security and message security may be used together to reduce the risk of man-in-the-middle attacks.

5.3.7 SecurityGroup

A SecurityGroup is an abstraction that represents the message security settings and security keys for a subset of NetworkMessages exchanged between Publishers and Subscribers. The security keys are used to encrypt and decrypt NetworkMessages and to generate and check signatures on a NetworkMessage.

A Security Key Service (SKS) manages SecurityGroups and maintains a mapping between Roles and their access Permissions for a SecurityGroup. This mapping defines if a Publisher or Subscriber has access to the security keys of a SecurityGroup. The SKS is described in more detail in 5.4.5.

A SecurityGroup is identified with a unique identifier called the SecurityGroupId. It is unique within the SKS. A Publisher for its PublishedDataSets needs to know the SecurityGroupId. For Subscribers the SecurityGroupId is distributed as metadata together with the DataSetMetaData. The metadata for a SecurityGroupId includes the EndpointDescription of the responsible SKS. Publishers and Subscribers use the EndpointDescription to access the SKS and the SecurityGroupId to obtain the security keys for a SecurityGroup.

5.3.8 Topics

A Topic is a string associated with a NetworkMessage that can be used to logically organize NetworkMessages published to a Message Oriented Middleware. Topics are most commonly used with Broker-based middleware where the filtering is done by the Broker. However, Topics can be used with Broker-less middleware where the filtering is done by the Subscriber.

Topics have a hierarchical structure with different Topic levels separated by a delimiter like ‘/’. For example:

	opcua/json/status/FlowController1

Mappings to different implementation technologies may add additional constraints.

A Topic for NetworkMessages containing DataSetMessages is typically used as QueueName for the broker-based communication configuration.

5.4 Entities

5.4.1 Publisher

5.4.1.1 General

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. A Publisher may consist of one or more network nodes sending messages and management node(s) responding to discovery probe messages and providing an OPC UA Server for configuration and diagnostics.

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.

5.4.1.2 Message sending

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 need to exist to generate the OPC UA PubSub messages.

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 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. The two concrete PublishedDataSet options with standard OPC UA configuration are PublishedDataItems for Variable base collection and PublishedEvents for Event based collection.

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.4.2) controls which attributes of a value shall be encoded.

The DataSetMessageContentMask (see 6.3.1.3.2) controls which header fields shall be encoded.

The KeyFrameCount (see 6.2.4.3) greater than or equal to 1 controls whether a key frame or a delta frame DataSetMessage is to be created. A KeyFrameCount of 0 is used for non-cyclic PublishedDataSets, like PublishedEvents.

The resulting DataSetMessage is passed on to the next step together with the DataSetWriterId (see 6.2.4.1), the DataSetClassId (see 6.2.3.3), the ConfigurationVersion of the DataSetMetaData (see 6.2.3.2.6), 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.7.1) defined on the PubSubConnection. The structure of this message is protocol specific. If the SecurityMode (see 6.2.5.2) requires message security, the SecurityGroupId (see 6.2.5.3) is used to fetch the SecurityPolicy and the security keys from the SKS (see 5.4.5). 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.

5.4.2 Subscriber

5.4.2.1 General

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

5.4.2.2 Message reception

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.

The Subscriber need 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. 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 is 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. The two concrete SubscribedDataSet options with standard OPC UA configuration are TargetVariables and SubscribedDataSetMirror. The configuration of TargetVariables allows the dispatching of DataSetMessage fields to existing Variables in the Subscribers OPC UA AddressSpace. The configuration of SubscribedDataSetMirror is used if the received DataSet fields should be represented as Variables in the Subscribers OPC UA AddressSpace but the Variables do not exist and must be created as part of the Subscriber configuration.

5.4.3 Actions

Actions allow a request response message exchange pattern to be used via a Message Oriented Middleware. The entities involved in Actions are shown in Figure 9.

Actions are operations executed by a Responder when it receives a request message sent by a Requestor. An Action could be a Method in an OPC UA Address Space or business logic in an OPC UA PubSub application.

The ActionMetaData consists of the DataSetMetaData for the request message, the DataSetMetaData for the response message and a list of Action targets that share the same request and response parameters. An example is a Method defined on an ObjectType that can be called on different Object instances. In this case the Method on the ObjectType is the Action and the Methods on the different Object instances are the Action targets. The ActionMetaData as a contract is provided by the Responder and used by the Requestor to execute Actions on the Responder.

The content of the ActionMetaData and the mapping to Methods is defined in 6.2.3.10. The ActionMetaData message for UADP message mapping is defined in 7.2.4.6.11. The ActionMetaData message for JSON message mapping is definied in 7.2.5.5.7.

The information flow, sequence diagrams and status handling for Actions is defined in 6.2.11.2.

The Action request and response messages for UADP message mapping are definied in 7.2.4.5.9 and 7.2.4.5.10. The Action NetworkMessage, request and response messages for JSON message mapping are defined in 7.2.5.6.

The MQTT Topic levels for Action messages are defined in 7.3.4.7.9, 7.3.4.7.10, 7.3.4.7.11 and 7.3.4.7.12.

5.4.4 Configuration Tool

An OPC UA Application can be pre-configured to send messages as a Publisher but commonly it is required to configure the information to be included into messages and also the frequency the messages are sent.

Subscribers can use discovery mechanisms to find Publishers and to get the DataSetMetaData necessary 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 Subscriber functionality in the device.

The PubSubConfigurationDataType and the other configuration Structures defined in Clause 6 can be used to prepare an offline PubSub configuration that can be stored in a binary file using the UABinaryFileDataType. Such a configuration can be used to configure Publishers and Subscribers if they do not have a online configuration interface or are configured through product-specific configuration tools.

If Publishers and Subscribers are also OPC UA Servers, they can provide the PubSub configuration Information Model defined in Clause 9. This model can be used by generic PubSub 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 Variables and a generic configuration tool establishes the communication by selecting the Variables to be published in the Publisher and then configures the Subscriber to receive the messages from the Publisher and to select the target Variables in the Subscriber.

5.4.5 Security Key Service

5.4.5.1 General

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

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.

5.4.5.2 SecurityGroup Management

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

To secure NetworkMessages, the NetworkMessages shall 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 shall 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 group.

5.4.5.3 Key acquisition handshakes

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 11. The handshake to push the keys from an SKS to Publishers and Subscribers is shown in Figure 12.

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

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.

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.

If the initial pull or push fails, the affected PubSub components like WriterGroup or DataSetReader stay in the PreOperational state. If the updates fail and the PubSub components do not have up to date key material, the state of the affected components change to Error. For both pull and push, the Client executing the key exchange needs to retry the key exchange at a faster rate than the key lifetime.

5.4.5.4 Authorization Services and Security Key Service

Access to the SKS can be managed by an Authorization Service as shown in Figure 13.

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.

5.4.6 Message Oriented Middleware

5.4.6.1 General

Message Oriented Middleware as 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 PubSub are described in 7.3.

This document 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.6.2 and 5.4.6.3.

5.4.6.2 Broker-less Middleware

5.4.6.2.1 General

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

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.

5.4.6.2.2 Broker-less model with OPC UA UDP

Figure 15 depicts the applications, entities and messages involved in peer-to-peer communication using UDP as a protocol that does not require a Broker.

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.

5.4.6.3 Broker-based Middleware

5.4.6.3.1 General

This option assumes a messaging Broker in the middle as shown in Figure 16. 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).

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.

5.4.6.3.2 Broker-based model

Figure 17 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 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 document. 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 one connection Object per Broker. The Broker is 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 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.

5.4.6.4 QoS configuration

OPC UA Applications may demand Quality of Service (QoS) for the transport of NetworkMessages. These QoS requirements have to be fulfilled by the broker-less Message Oriented Middleware and 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 Applications shall 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 Applications from one network technology to another or to interconnect OPC UA Applications over 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 18 and Figure 19 the PriorityLabel from a WriterGroup, DataSetReader or PubSubConnection TransportSettings will be translated into actual values to be used on the wire. Together with the optional QosCategory the PriorityLabel will be present in the mapping table for the network interface used to transmit the data. If the combination of QosCategory and PriorityLabel is 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 QosCategory with the according required structures in the DatagramQos array are defined in Table 118. This list can be extended by specifications built on top of OPC UA PubSub. Each QosCategory will be described in detail by a list of measurable QoS KPIs like assured bandwidth or maximum latency in the parameter DatagramQos.

6 PubSub communication parameters

6.1 Overview

PubSub defines different configuration parameters for the various PubSub components. They define the behaviour of Publisher and Subscriber. The parameters are grouped by component and are partitioned into ‘common’, ’message mapping’, and ‘transport protocol mapping’.

The common parameters are defined in 6.2. The parameters for the different message mappings are defined in 6.3. The parameters for the different transport protocol mappings are defined in 6.4.

The application of communication parameters for concrete message and transport protocol mappings is defined in Clause 7.

Configuration of these parameters can be performed through the OPC UA Information Model for PubSub configuration defined in Clause 9 or through vendor-specific mechanisms. The parameter groupings in this clause define the parameters and also define Structures used to represent the parameters of the groupings. These Structures are used in the PubSub configuration model described in Clause 9 but they can also be used for offline configuration or vendor-specific configuration mechanisms.

Figure 20 depicts the different components and their relation to each other. The WriterGroup, DataSetWriter and PublishedDataSet components define the data acquisition for the DataSets, the message generation and the sending on the Publisher side. These parameters need to be known on the Subscriber side to configure DataSetReaders and to filter and process DataSetMessages.

Figure 20 shows the following components:

PublishedDataSet contains the DataSetMetaData describing the content of the DataSets produced by the PublishedDataSet and the corresponding data acquisition parameters.

DataSetWriter parameters are necessary for creating DataSetMessages. Each DataSetWriter is bound to a single PublishedDataSet. A PublishedDataSet can have multiple DataSetWriters.

WriterGroup parameters are necessary for creating a NetworkMessage. Each writer group can have one or more DataSetWriters. Some of these parameters are used for creating the DataSetMessages. They are grouped here since they are the same for all DataSetMessages in a single NetworkMessage.

PubSubConnection parameters represent settings needed for the transport protocol. One connection can have a number of writer groups and reader groups.

ReaderGroup is used to group a list of DataSetReaders and contains a few shared settings for them. It is not symmetric to a WriterGroup and it is not related to a particular NetworkMessage. The NetworkMessage related filter settings are on the DataSetReaders.

DataSetReader parameters represent settings for filtering of received NetworkMessages and DataSetMessages as well as settings for decoding of the DataSetMessages of interest.

SubscribedDataSet parameters define the processing of the decoded DataSet in the Subscriber for one DataSetReader.

PublishSubscribe is the overall management of the PubSub groupings. It contains a list of PublishedDataSets and a list of PubSubConnections.

The different PubSub mapping specific parameter groupings are shown in Figure 21.

Transport protocol mapping specific parameters may be defined for the PubSubConnection, the WriterGroup or the DataSetWriter.

Message mapping specific parameters are defined for the NetworkMessages on the WriterGroup and for the DataSetMessages on the DataSetWriter.

6.2 Common configuration parameters

6.2.1 PubSubState state machine

The PubSubState is used to expose and control the operation of a PubSub component. It is an enumeration of the possible states. The enumeration values are described in Table 1.

Figure 22 depicts the PubSub components that have a PubSub state and their parent-child relationship. State changes of children are based on changes of the parent state. The root of the hierarchy is the PublishSubscribe component.

Table 2 formally defines the transitions of the state machine.

The PubSubState representation in the AddressSpace is defined in Table 3.

6.2.2 PubSub configuration properties

The PubSub components have configuration property lists as KeyValuePair arrays. These optional configuration properties extend the configuration parameters defined for the different PubSub components.

The configuration properties are mainly used as protocol or product specific parameters influencing the behaviour of the PubSub application. These properties may contain information that should not be visible outside the configuration tools and PubSub applications. Therefore the properties shall not be included in the PubSubConnectionDataType, WriterGroupDataType and DataSetWriterDataType when sent in discovery messages.

The configuration are defined in different sections in the scope where they are used. The properties that can be applied to all PubSub components are defined in Table 4.

The NamespaceIndex of the QualifiedName in the KeyValuePair for properties defined in this document shall be 0. The Name of the QualifiedName is the property key from Table 4. The DataType of the Value in the KeyValuePair shall be the DataType defined in Table 4.

Table 4 formally defines the general PubSub configuration properties.

6.2.3 PublishedDataSet parameters

6.2.3.1 Overview

A PublishedDataSet defines the content of a DataSetMessage and the configuration of the information source for a DataSet. See 5.2 for the introduction to DataSets, 5.3 for the introduction to DataSetMessages and 5.4.1.2 for an introduction to the different source options and the parameters for sending of DataSetMessages.

The content of a DataSetMessage is defined by the DataSetMetaData. This information is required for interoperability between Publisher and Subscriber. See 6.2.3.2.

The information source is only necessary for the configuration of the Publisher. The standard configuration options are published data items for cyclic DataSets as defined in 6.2.3.7 and published events for acyclic DataSets as defined in 6.2.3.8. OPC UA Applications can provide PublishedDataSets where the information source is application specific. The custom PublishedDataSet source DataType defined in 6.2.3.9 indicates if the DataSet is cyclic or acyclic. Cyclic DataSets are sent as key frame or delta frame DataSetMessages. Acyclic DataSets are sent as event DataSetMessages.

6.2.3.2 DataSetMetaData

6.2.3.2.1 General

DataSetMetaData describe the content and semantic of a DataSet. The order of the fields in the DataSetMetaData shall match the order of DataSet fields when they are included in the published DataSetMessages. The DataSetMetaDataType is defined in 6.2.3.2.3.

6.2.3.2.2 DataTypeSchemaHeader

The DataSetMetaData is a subtype of DataTypeSchemaHeader. The DataTypeSchemaHeader provides OPC UA DataType definitions used in the DataSetMetaData. The DataTypeSchemaHeader is defined in OPC 10000-5.

The DataTypeSchemaHeader provides information that is required when the DataSetMetaData is used outside the scope of an OPC UA Server e.g when sent in PubSub messages or when the PubSubConfiguration is exchanged with the UABinaryFileDataType. This information includes a namespace array and DataType descriptions. OPC UA namespace defined DataTypes are not included in the PubSubConfiguration.

The DataTypeSchemaHeader of the DataSetMetaData shall be populated with the necessary information. This includes all namespaces and DataTypes that are potentially contained in the associated DataSetMessages. DataTypes defined in the OPC UA namespace (NamespaceIndex 0) that are not built-in types or the abstract types Number, UInteger, Integer or Enumeration shall be included in the DataSetMetaData.

A Publisher should keep the namespaces array in the DataSetMetaData unchanged even if the order of namespaces is changed in the OPC UA Server of the Publisher. A change of the namespace array in the DataSetMetaData requires a change to the MajorVersion in the DataSetMetaData.

The Subscriber must map namespace indices in received messages if the data is processed in the context of an OPC UA Server information model e.g. if the values are written to target Variables. This affects encoding NodeIds in ExtensionObjects but also all other namespace indices in NodeIds and BrowseNames contained in the messages. If the Subscriber receives Structure DataTypes where the target Variables DataTypes have the same structure but different DataType NodeIds, the Subscriber must verify the consistency of the layout at start-up and must map the complete encoding NodeId when receiving the data.

If the DataSetMetaData is created outside the Publisher, the same mapping may be required in the Publisher.

6.2.3.2.3 DataSetMetaDataType

This Structure DataType is a subtype of DataTypeSchemaHeader and is used to provide the metadata for a DataSet. The DataSetMetaDataType is formally defined in Table 5.

Its representation in the AddressSpace is defined in Table 6.

6.2.3.2.4 FieldMetaData

This Structure DataType is used to provide the metadata for a field in a DataSet. The FieldMetaData is formally defined in Table 7.

Its representation in the AddressSpace is defined in Table 8.

6.2.3.2.5 DataSetFieldFlags

This DataType defines flags for DataSet fields.

The DataSetFieldFlags is formally defined in Table 9.

The DataSetFieldFlags representation in the AddressSpace is defined in Table 10.

6.2.3.2.6 ConfigurationVersionDataType

This Structure DataType is used to indicate configuration changes in the information published for a DataSet. The ConfigurationVersionDataType is formally defined in Table 11.

Its representation in the AddressSpace is defined in Table 12.

6.2.3.3 DataSetClassId

DataSetMetaData may be specific to a single Publisher and a single selection of information or universal, e.g. defined by a standards organization or by a plant operator as a DataSetClass. DataSets that conform to such a DataSetClass are identified with a DataSetClassId.

The DataSetClassId is the globally unique identifier (Guid) of a DataSetClass. It is included in the DataSetMetaData. The NetworkMessageContentMask controls the availability of the DataSetClassId in the NetworkMessage.

6.2.3.4 ExtensionFields

The ExtensionFields parameter allows the configuration of fields with values to be included in the DataSet when the existing AddressSpace of the Publisher does not provide the necessary information. The ExtensionFields are represented as an array of KeyValuePair Structures.

6.2.3.5 PublishedDataSetDataType

This Structure DataType represents the PublishedDataSet parameters. The PublishedDataSetDataType is formally defined in Table 13.

Its representation in the AddressSpace is defined in Table 14.

6.2.3.6 PublishedDataSetSourceDataType

The PublishedDataSetSourceDataType Structure is an abstract base type without fields for the definition of the PublishedDataSet source. Its representation in the AddressSpace is defined in Table 15.

6.2.3.7 Published Data Items

6.2.3.7.1 PublishedData

The parameter PublishedData defines the content of a DataSet created from Variable Values and therefore the content of the DataSetMessage sent by a DataSetWriter. The sources of the DataSet fields are defined through an array of PublishedVariableDataType.

The index into the array has an important role for Subscribers and for configuration tools. It is used as a handle to reference the Value in DataSetMessages received by Subscribers. The index may change after configuration changes. Changes are indicated by the ConfigurationVersion of the DataSet and applications working with the index shall always check the ConfigurationVersion before using the index.

The length of the PublishedData array shall match the length of the fields array in the corresponding DataSetMetaData.

If an entry of the PublishedData references one of the ExtensionFields, the substituteValue shall contain the QualifiedName of the ExtensionFields entry. All other fields of this PublishedVariableDataType array element shall be null or empty.

The DataType PublishedVariableDataType represents the configuration information for one Variable. The PublishedVariableDataType is formally defined in Table 16.

Its representation in the AddressSpace is defined in Table 17.

6.2.3.7.2 PublishedDataItemsDataType

This Structure DataType is used to represent PublishedDataItems specific parameters. It is a subtype of the PublishedDataSetSourceDataType defined in 6.2.3.6.

The PublishedDataItemsDataType is formally defined in Table 18.

Its representation in the AddressSpace is defined in Table 19.

6.2.3.8 Published Events

6.2.3.8.1 EventNotifier

The parameter EventNotifier defines the NodeId of the Object in the event notifier tree of the OPC UA Server from which Events are collected.

6.2.3.8.2 SelectedFields

The parameter SelectedFields defines the selection of Event fields contained in the DataSet generated for an Event and sent through the DataSetWriter. The SimpleAttributeOperand DataType is defined in OPC 10000-4. The DataType of the selected Event field in the EventType defines the DataType of the DataSet field. Event fields can be null or the field value can be a StatusCode. The encoding of Event based DataSetMessages shall be able to handle these cases. ExtensionFields defined for the instance of the PublishedEventsType can be included in the SelectedFields by specifying the PublishedEventsType NodeId as typeId in the SimpleAttributeOperand and the BrowseName of the extension field in the browsePath of the SimpleAttributeOperand.

The index into the list of entries in the SelectedFields has an important role for Subscribers. It is used as handle to reference the Event field in DataSetMessages received by Subscribers. The index may change after configuration changes. Changes are indicated by the ConfigurationVersion and applications working with the index shall always check the ConfigurationVersion before using the index. If a change of the SelectedFields adds additional fields, the MinorVersion of the ConfigurationVersion shall be updated. If a change of the SelectedFields removes fields, the MajorVersion of the ConfigurationVersion shall be updated. The ConfigurationVersionDataType and the rules for setting the version are defined in 6.2.3.2.6.

6.2.3.8.3 Filter

The parameter Filter defines the filter applied to the Events. It allows the reduction of the DataSets generated from Events through a filter. The ContentFilter DataType is defined in OPC 10000-4.

6.2.3.8.4 PublishedEventsDataType

This Structure DataType is used to represent PublishedEvents specific parameters. It is a subtype of the PublishedDataSetSourceDataType defined in 6.2.3.6.

The PublishedEventsDataType is formally defined in Table 20.

Its representation in the AddressSpace is defined in Table 21.

6.2.3.9 Custom PublishedDataSet source

6.2.3.9.1 CyclicDataSet

The CyclicDataSet with DataType Boolean defines the type of DataSetMessages created by the PublishedDataSet.

If CyclicDataSet is false, event DataSetMessages are sent acyclicly and a related DataSetWriter shall use a KeyFrameCount of 0.

If CyclicDataSet is true, key frame or delta frame DataSetMessages are sent and a related DataSetWriter shall use a KeyFrameCount that is greater than or equal to 1.

6.2.3.9.2 PublishedDataSetCustomSourceDataType

This Structure DataType is used to represent custom PublishedDataSet source specific parameters. It is a subtype of the PublishedDataSetSourceDataType defined in 6.2.3.6.

The DataType can be used directly if no further information is exposed for the source. OPC UA Applications shall use DataTypes derived from PublishedDataSetSourceDataType if they want to provide custom information about the source e.g. product specific configuration options.

The PublishedDataSetCustomSourceDataType is formally defined in Table 22.

Its representation in the AddressSpace is defined in Table 23.

6.2.3.10 Published Action

6.2.3.10.1 General

Published Action defines the signature of an Action as a combination of ActionRequest and ActionResponse messages and a list of targets with an optional mapping to OPC UA Methods.

The Action targets, ActionRequest and ActionResponse information is the input to the ActionMetaData.

The parameter RequestDataSetMetaData defines the content of the ActionRequest.

The DataSetMetaData parameter of the PublishedDataSet defines the content of the ActionResponse.

The parameter ActionTargets provides a list of Action targets with the same signatures that can be executed based on the published Action definition.

6.2.3.10.2 RequestDataSetMetaData

The parameter RequestDataSetMetaData defines the payload of ActionRequest messages.

The payload of the ActionResponse messages is defined by the DataSetMetaData parameter of the PublishedDataSetDataType. The fields Name and ConfigurationVersion of the DataSetMetaData and the RequestDataSetMetaData in one PublishedDataSet shall be identical.

6.2.3.10.3 ActionTargets

The parameter ActionTargets defines the list of Action targets that can be invoked with the signature defined by the ActionMetaData.

The DataType ActionTargetDataType represents the configuration information for one Action target. The ActionTargetDataType is formally defined in Table 24.

Its representation in the AddressSpace is defined in Table 25.

6.2.3.10.4 PublishedActionDataType

This Structure DataType is used to represent PublishedAction specific parameters. It is a subtype of the PublishedDataSetSourceDataType defined in 6.2.3.6.

The PublishedActionDataType is formally defined in Table 26.

Its representation in the AddressSpace is defined in Table 27.

6.2.3.10.5 ActionMethods

The parameter ActionMethods defines a list of Object and Method pairs as source for the Action defined in the parameter ActionMethods.

The DataType ActionMethodDataType represents the configuration information for one Object and Method pair. The ActionMethodDataType is formally defined in Table 28.

Its representation in the AddressSpace is defined in Table 29.

6.2.3.10.6 PublishedActionMethodDataType

This Structure DataType is used to represent Action source Method information for PublishedAction. It is a subtype of the PublishedActionDataType defined in 6.2.3.10.4.

The PublishedActionMethodDataType is formally defined in Table 30.

Its representation in the AddressSpace is defined in Table 31.

6.2.4 DataSetWriter parameters

6.2.4.1 DataSetWriterId

The DataSetWriterId with DataType UInt16 defines the unique ID of the DataSetWriter for a PublishedDataSet. It is used to select DataSetMessages for a PublishedDataSet on the Subscriber side.

It shall be unique across all DataSetWriters for a PublisherId.

All values, except for 0, are valid DataSetWriterIds. The value 0 is defined as null value.

The DataSetWriterId shall be within the range 0x0001 - 0x7FFF for external assignment by configuration tools, and 0x8000 - 0xFFFF for internal assignment like through the Method CloseAndUpdate of the PubSubConfigurationType.

6.2.4.2 DataSetFieldContentMask

A DataSet field consists of a value and related metadata. In most cases the value comes with status and timestamp information.

This DataType defines flags to include DataSet field related information like status and timestamp in addition to the value in the DataSetMessage. The parameter is not relevant for heartbeat messages but should be configured according to the header layout requirements.

The DataSetFieldContentMask is formally defined in Table 32.

The handling of bad status for different field representations is defined in Figure 24, Table 34 and Table 35.

The DataSetFieldContentMask representation in the AddressSpace is defined in Table 33.

The DataSetFieldContentMask defines different options that influence the information flow from Publisher to Subscriber in the case of a Bad Value Status or other error situations. Figure 24 depicts the parameters and the information flow from DataSet field to DataSetMessage creation on the Publisher side and the decoded DataSet field on the Subscriber side. The DataSetFieldContentMask controls the representation of the DataSet fields in a DataSetMessage.

The representation of the DataSet fields in a DataSetMessage on the Publisher side and the decoding back to the DataSet fields on the Subscriber side is defined in Table 34 for UADP message mapping and in Table 35 for JSON message mapping. The representation on the Publisher side depends on the field representation defined in the DataSetFieldContentMask.

6.2.4.3 KeyFrameCount

The KeyFrameCount with DataType UInt32 is the multiplier of the PublishingInterval that defines the maximum number of times the PublishingInterval expires before a key frame message with values for all published Variables is sent. The delta frame DataSetMessages contains just the changed values. If no changes exist, the delta frame DataSetMessage shall not be sent. If the KeyFrameCount is set to 1, every message contains a key frame.

For PublishedDataSets that provide cyclic updates of the DataSet, the value shall be greater than or equal to 1. PublishedDataItems or custom sources with CyclicDataSet set to true provide cyclic updates.

For non-cyclic PublishedDataSets that provide acyclic event based DataSets, the value shall be 0. PublishedEvents or custom sources with CyclicDataSet set to false provide acyclic updates.

For a heartbeat DataSetMessage, the value shall be 1.

6.2.4.4 DataSetWriterProperties

The DataSetWriterProperties parameter is an array of DataType KeyValuePair that specifies additional properties for the configured DataSetWriter. The KeyValuePair DataType is defined in OPC 10000-5 and consists of a QualifiedName and a value of BaseDataType.

The mapping of the name and value to concrete functionality may be defined by transport protocol mappings, future versions of this document or vendor-specific extensions.

6.2.4.5 DataSetWriter definition

6.2.4.5.1 DataSetWriterDataType

This Structure DataType is used to represent the DataSetWriter parameters. The DataSetWriterDataType is formally defined in Table 36.

Its representation in the AddressSpace is defined in Table 37.

6.2.4.5.2 DataSetWriterTransportDataType

This Structure DataType is an abstract base type for transport mapping specific DataSetWriter parameters. The abstract DataType does not define fields.

The DataSetWriterTransportDataType Structure representation in the AddressSpace is defined in Table 38.

6.2.4.5.3 DataSetWriterMessageDataType

This Structure DataType is an abstract base type for message mapping specific DataSetWriter parameters. The abstract DataType does not define fields.

The DataSetWriterMessageDataType Structure representation in the AddressSpace is defined in Table 39.

6.2.5 Shared PubSubGroup parameters

6.2.5.1 General

The parameters are shared between WriterGroup and ReaderGroup.

The parameters are related to PubSub NetworkMessage security. See 5.4.5 for an introduction of PubSub security and Clause 8 for the definition of the PubSub Security Key Service.

6.2.5.2 SecurityMode

The SecurityMode indicates the level of security applied to the NetworkMessages published by a WriterGroup or received by a ReaderGroup. The MessageSecurityMode DataType is defined in OPC 10000-4.

6.2.5.3 SecurityGroupId

The SecurityGroupId with DataType String is the identifier for a SecurityGroup in the Security Key Server. It is unique within a SKS.

The parameter is null if the SecurityMode is NONE.

If the SecurityMode is not NONE the SecurityGroupId identifies the SecurityGroup. The SecurityGroup defines the SecurityPolicy and the security keys used for the NetworkMessage security. The PubSubGroup defines the SecurityMode for the NetworkMessages sent by the group.

6.2.5.4 SecurityKeyServices

SecurityKeyServices is an array of the DataType EndpointDescription and defines one or more Security Key Servers (SKS) that manage the security keys for the SecurityGroup assigned to the PubSubGroup. The EndpointDescription DataType is defined in OPC 10000-4.

The parameter is null if the SecurityMode is NONE.

Each element in the array is an Endpoint for an SKS that can supply the security keys for the SecurityGroupId. Multiple Endpoints exist because an SKS may have multiple redundant instances. If the SKS supports non-transparent redundancy, each Server in the redundant set shall have one entry in the array.

The use of the EndpointDescription parameters for the SKS selection are defined in Table 40. The main key for the identification of the SKS is the ApplicationUri.

The ApplicationUri is used in the different Server discovery mechanisms to get the OPC UA endpoint information necessary to connect to the SKS.

The combination of SecurityGroupId and SKS ApplicationUri is the unique key for a SecurityGroup in a PubSub application.

6.2.5.5 MaxNetworkMessageSize

The MaxNetworkMessageSize with DataType UInt32 indicates the maximum size in bytes for NetworkMessages created by the WriterGroup. It refers to the size of the complete NetworkMessage including padding and signature without any additional headers added by the transport protocol mapping. If the size of a NetworkMessage exceeds the MaxNetworkMessageSize, the behaviour depends on the message mapping.

The transport protocol mappings defined in 7.3 may define restrictions for the maximum value of this parameter.

NOTE The value for the MaxNetworkMessageSize should be configured in a way that ensures that NetworkMessages together with additional headers added by the transport protocol are still smaller than or equal than the transport protocol MTU.

6.2.5.6 GroupProperties

The GroupProperties parameter is an array of DataType KeyValuePair that specifies additional properties for the configured group. The KeyValuePair DataType is defined in OPC 10000-5 and consists of a QualifiedName and a value of BaseDataType.

The mapping of the name and value to concrete functionality may be defined by transport protocol mappings, future versions of this document or vendor-specific extensions.

6.2.5.7 PubSubGroup structure

This Structure DataType is an abstract base type for PubSubGroups. The PubSubGroupDataType is formally defined in Table 41.

The PubSubGroupDataType Structure representation in the AddressSpace is defined in Table 42.

6.2.6 WriterGroup parameters

6.2.6.1 WriterGroupId

The WriterGroupId with DataType UInt16 is an identifier for the WriterGroup and shall be unique across all WriterGroups for a PublisherId. All values, except for 0, are valid. The value 0 is defined as null value.

The WriterGroupId shall be within the range 0x0001 - 0x7FFF for external assignment by configuration tools, and 0x8000 - 0xFFFF for internal assignment like through the Method CloseAndUpdate of the PubSubConfigurationType.

6.2.6.2 PublishingInterval

The PublishingInterval with the DataType Duration defines the interval in milliseconds for publishing NetworkMessages and the embedded DataSetMessages created by the related DataSetWriters.

Negative values are invalid. If the PublishingInterval is 0, the KeyFrameCount of all DataSetWriters in the WriterGroup shall be 0.

For cyclic PublishedDataSets one DataSet is produced for one PublishedDataSet in a PublishingInterval. If no new DataSet is available in a PublishingInterval, then either the previous DataSetMessage is resent or no DataSetMessage is sent.

In the case non-cyclic PublishedDataSets like Event based DataSets, this may result in zero to many DataSetMessages produced for one PublishedDataSet in a PublishingInterval. All Events that occur between two PublishingIntervals shall be buffered until the next NetworkMessage is sent. If the number of Events exceeds the buffer capability of the DataSetWriter, an Event of type EventQueueOverflowEventType is inserted as last entry into the buffer and all Events that do not fit into the buffer are discarded.

The Duration DataType is a subtype of Double and allows configuration of intervals smaller than a millisecond.

6.2.6.3 KeepAliveTime

The KeepAliveTime with DataType Duration defines the time in milliseconds until the Publisher sends a keep alive DataSetMessage in the case where no DataSetMessage was sent in this period by a DataSetWriter. The minimum value shall equal the PublishingInterval but shall be larger than 0.

6.2.6.4 Priority

The Priority with DataType Byte defines the relative priority of the WriterGroup to all other WriterGroups across all PubSubConnections of the Publisher.

If more than one WriterGroup needs to be processed, the priority number defines the order of processing. The highest priority is processed first.

The lowest priority is zero and the highest is 255.

6.2.6.5 LocaleIds

The LocaleIds, with DataType LocaleId, defines a list of locale ids in priority order for localized strings for all DataSetWriters in the WriterGroup. The first LocaleId in the list has the highest priority.

If the Publisher sends a localized String, the Publisher shall send the translation with the highest priority that it can. If it does not have a translation for any of the locales identified in this list, then it shall send the String value that it has and include the LocaleId with the String. If no locale id is configured, the Publisher shall use any that it has. See OPC 10000-3 for more detail on LocaleId.

6.2.6.6 HeaderLayoutUri

The HeaderLayoutUri, with DataType String, defines the selection of a well defined configuration for a subset of the PubSub communication parameters. The affected subset is defined by the header layout.

A null or empty String is defined as no layout selected.

If a layout is selected, all affected parameters shall be set to the values defined for the layout.

Available layouts and the corresponding URI Strings are defined in Annex A.

6.2.6.7 WriterGroup structures

6.2.6.7.1 WriterGroupDataType

This Structure DataType is used to represent the configuration parameters for WriterGroups. It is a subtype of PubSubGroupDataType defined in 6.2.5.7.

The WriterGroupDataType is formally defined in Table 43.

The WriterGroupDataType Structure representation in the AddressSpace is defined in Table 44.

6.2.6.7.2 WriterGroupTransportDataType

This Structure DataType is an abstract base type for transport mapping specific WriterGroup parameters. The abstract DataType does not define fields.

The WriterGroupTransportDataType Structure representation in the AddressSpace is defined in Table 45.

6.2.6.7.3 WriterGroupMessageDataType

This Structure DataType is an abstract base type for message mapping specific WriterGroup parameters. The abstract DataType does not define fields.

The WriterGroupMessageDataType Structure representation in the AddressSpace is defined in Table 46.

6.2.7 PubSubConnection parameters

6.2.7.1 PublisherId

The PublisherId is a unique identifier for a Publisher within a Message Oriented Middleware. It can be included in sent NetworkMessage for identification or filtering. The value of the PublisherId is typically shared between PubSubConnections but the assignment of the PublisherId is vendor specific.

The PublisherId parameter is only relevant for the Publisher functionality inside a PubSubConnection. The filter setting on the Subscriber side is contained in the DataSetReader parameters.

Valid DataTypes are UInteger and String. A zero UInteger and a Null or empty String are invalid PublisherIds.

The default PublisherId for datagram transport protocols has a DataType of UInt64. If the default PublisherId is created by the OPC UA Application, it is recommended to set the first 6 bytes with the MAC address of one of the network interfaces and to set the two remaining bytes to the OPC UA Server port of the OPC UA Application.

The default PublisherId for broker based transports equals the PublisherId for datagram transport protocols but the DataType is UInt64 for UADP message mapping and String for JSON message mapping. For the String, the UInt64 value is converted to a String. The PublisherId may be used in message headers, as part of a QueueName or as a client identifier for the broker connection. In these cases the size of the PublisherId and the characters used in the PublisherId may have limitations or impact to the communication performance.

The default PublisherId is used if it is not assigned by a configuration tool.

6.2.7.2 TransportProfileUri

The TransportProfileUri parameter with DataType String indicates the transport protocol mapping and the message mapping used.

The possible TransportProfileUri values are defined as URI of the transport protocols defined as PubSub transport Facet in OPC 10000-7.

6.2.7.3 Address

The Address parameter contains the network address information for the communication middleware. The different Structure DataTypes used to represent the Address are defined in 6.2.7.5.3.

6.2.7.4 ConnectionProperties

The ConnectionProperties parameter is an array of DataType KeyValuePair that specifies additional properties for the configured connection. The KeyValuePair type is defined in OPC 10000-5 and consists of a QualifiedName and a value of BaseDataType.

The mapping of the namespace, name, and value to concrete functionality may be defined by transport protocol mappings or vendor-specific extensions.

The NamespaceIndex of the QualifiedName in the KeyValuePair for properties defined in this document shall be 0. The Name of the QualifiedName is the property name from Table 47. The DataType of the Value in the KeyValuePair shall be the DataType defined in Table 47.

Table 47 formally defines the ConnectionProperties.

6.2.7.5 PubSubConnection structure

6.2.7.5.1 PubSubConnectionDataType

This Structure DataType is used to represent the configuration parameters for PubSubConnections. The PubSubConnectionDataType is formally defined in Table 48.

Its representation in the AddressSpace is defined in Table 49.

6.2.7.5.2 ConnectionTransportDataType

This Structure DataType is an abstract base type for transport mapping specific PubSubConnection parameters. The abstract DataType does not define fields.

The ConnectionTransportDataType Structure representation in the AddressSpace is defined in Table 50.

6.2.7.5.3 NetworkAddressDataType

Subtypes of this abstract Structure DataType are used to represent network address information. The NetworkAddressDataType is formally defined in Table 51.

The NetworkAddressDataType Structure representation in the AddressSpace is defined in Table 52.

6.2.7.5.4 NetworkAddressUrlDataType

This Structure DataType is used to represent network address information in the form of an URL String. The NetworkAddressUrlDataType is formally defined in Table 53.

The NetworkAddressUrlDataType Structure representation in the AddressSpace is defined in Table 54.

6.2.8 ReaderGroup parameters

6.2.8.1 General

The ReaderGroup does not add parameters to the shared PubSubGroup parameters.

The ReaderGroup is used to group a list of DataSetReaders. It is not symmetric to a WriterGroup and it is not related to a particular NetworkMessage. The NetworkMessage related filter settings are on the DataSetReaders.

6.2.8.2 ReaderGroup structures

6.2.8.2.1 ReaderGroupDataType

This Structure DataType is used to represent the configuration parameters for ReaderGroups. The ReaderGroupDataType is formally defined in Table 55.

The ReaderGroupDataType Structure representation in the AddressSpace is defined in Table 56.

6.2.8.2.2 ReaderGroupTransportDataType

This Structure DataType is an abstract base type for transport mapping specific ReaderGroup parameters. The abstract DataType does not define fields.

The ReaderGroupTransportDataType Structure representation in the AddressSpace is defined in Table 57.

6.2.8.2.3 ReaderGroupMessageDataType

This Structure DataType is an abstract base type for message mapping specific ReaderGroup parameters. The abstract DataType does not define fields.

The ReaderGroupMessageDataType Structure representation in the AddressSpace is defined in Table 58.

6.2.9 DataSetReader parameters

6.2.9.1 PublisherId

The parameter PublisherId defines the Publisher to receive NetworkMessages from.

If the value is null, the parameter shall be ignored and all received NetworkMessages pass the PublisherId filter.

Valid DataTypes are UInteger and String.

6.2.9.2 WriterGroupId

The parameter WriterGroupId with DataType UInt16 defines the identifier of the corresponding WriterGroup.

The default value 0 is defined as null value, and means this parameter shall be ignored.

6.2.9.3 DataSetWriterId

The parameter DataSetWriterId with DataType UInt16 defines the DataSet selected in the Publisher for the DataSetReader.

If the value is 0 (null), the parameter shall be ignored and all received DataSetMessages pass the DataSetWriterId filter.

6.2.9.4 DataSetMetaData

The parameter DataSetMetaData provides the information necessary to decode DataSetMessages from the Publisher. If the DataSetMetaData changes in the Publisher and the MajorVersion was changed, the DataSetReader needs an update of the DataSetMetaData for further operation. If the update cannot be retrieved in the duration of the MessageReceiveTimeout, the State of the DataSetReader shall change to Error. The related PublishedDataSet is defined in 6.2.3. The DataSetMetaDataType is defined in 6.2.3.2.3. The options for retrieving the update of the DataSetMetaData are described in 5.2.3.

The Subscriber must map namespace indices in received messages if the data is processed in the context of an OPC UA Server information model e.g. if the values are written to target Variables. This affects encoding NodeIds in ExtensionObjects but also all other namespace indices in NodeIds and BrowseNames contained in the messages. If the Subscriber receives Structure DataTypes where the target Variables DataTypes have the same structure but different DataType NodeIds, the Subscriber must verify the consistency of the layout at start-up and must map the complete encoding NodeId when receiving the data.

The Subscriber should verify that the target Variables can handle array and string sizes if the Subscriber has limits and the DataSetMetaData contains size information. This includes ArrayDimensions and MaxStringLength information in the FieldMetaData and the StructureFields of Structure DataTypes. The verification should be executed at the start-up of the DataSetReader and when the DataSetMetaData is updated. The DataSetReader should go into Error state if the verification fails.

If the DataSetMetaData contains an empty fields array, the DataSetReader is configured to receive heartbeat DataSetMessages. For heartbeat DataSetMessages the majorVersion and minorVersion in the configurationVersion shall always be 0 in the configuration and in the DataSetMessages.

6.2.9.5 DataSetFieldContentMask

The parameter DataSetFieldContentMask with DataType DataSetFieldContentMask indicates the fields of a DataValue included in the DataSetMessages. The parameter shall be ignored for heartbeat messages.

The DataSetFieldContentMask DataType is defined in 6.2.4.2.

6.2.9.6 MessageReceiveTimeout

The parameter MessageReceiveTimeout is the maximum acceptable time between two DataSetMessages. The time starts when the state of the DataSetReader changes to Operational. If there is no new DataSetMessage received within this period, the DataSetReader State shall be changed to Error until the next DataSetMessage is received. The DataSetMessages that reset the period include keep-alive and heartbeat messages. A DataSetMessage is considered new if the sequence number increments or if a new keep-alive message is received. If no sequence number is contained in the DataSetMessage, each received DataSetMessage is considered new.

The MessageReceiveTimeout is related to the Publisher side parameters PublishingInterval, KeepAliveTime and KeyFrameCount.

6.2.9.7 KeyFrameCount

The KeyFrameCount with DataType UInt32 is the multiplier of the PublishingInterval that defines the maximum number of times the PublishingInterval expires before a key frame message, with all field values, is received.

For DataSets that provide cyclic updates, the value shall be greater than or equal to 1. For non-cyclic DataSets, like PublishedEvents, that provide event based DataSets, the value shall be 0.

6.2.9.8 HeaderLayoutUri

The HeaderLayoutUri, with DataType String, defines the selection of a well defined configuration for a subset of the PubSub communication parameters. The affected subset is defined by the header layout.

A null or empty String is defined as no layout selected.

If a layout is selected, all affected parameters shall be set to the values defined for the layout.

Available layouts and the corresponding URI Strings are defined in Annex A.

6.2.9.9 SecurityMode

The parameter is defined in 6.2.5.2.

This parameter overwrites the corresponding setting on the ReaderGroup if the value is not INVALID.

6.2.9.10 SecurityGroupId

The parameter is defined in 6.2.5.3.

The parameter shall be null if the SecurityMode is INVALID.

6.2.9.11 SecurityKeyServices

The parameter is defined in 6.2.5.4.

The parameter shall be null if the SecurityMode is INVALID.

The parameter is only used to overwrite the SecurityKeyServices parameter of the ReaderGroup if the SKS is different for the DataSetReader.

6.2.9.12 DataSetReaderProperties

The DataSetReaderProperties parameter is an array of DataType KeyValuePair that specifies additional properties for the configured DataSetReader. The KeyValuePair DataType is defined in OPC 10000-5 and consists of a QualifiedName and a value of BaseDataType.

The mapping of the name and value to concrete functionality may be defined by transport protocol mappings, future versions of this document or vendor-specific extensions.

6.2.9.13 DataSetReader structure

6.2.9.13.1 DataSetReaderDataType

This Structure DataType is used to represent the DataSetReader parameters. The DataSetReaderDataType is formally defined in Table 59.

Its representation in the AddressSpace is defined in Table 60.

6.2.9.13.2 DataSetReaderTransportDataType

This Structure DataType is an abstract base type for transport-specific DataSetReader parameters. The DataSetReaderTransportDataType is formally defined in Table 61.

The DataSetReaderTransportDataType Structure representation in the AddressSpace is defined in Table 62.

6.2.9.13.3 DataSetReaderMessageDataType

This Structure DataType is an abstract base type for message mapping specific DataSetReader parameters. The DataSetReaderMessageDataType is formally defined in Table 63.

The DataSetReaderMessageDataType Structure representation in the AddressSpace is defined in Table 64.

6.2.10 SubscribedDataSet parameters

6.2.10.1 SubscribedDataSetDataType

This Structure DataType is an abstract base type for SubscribedDataSet parameters. A SubscribedDataSet defines the metadata for the subscribed DataSet and the information for the processing of DataSetMessages. See 5.4.2.2 for an introduction to the processing options for received DataSetMessages.

The SubscribedDataSetDataType is formally defined in Table 65.

The SubscribedDataSetDataType Structure representation in the AddressSpace is defined in Table 66.

6.2.10.2 TargetVariables

6.2.10.2.1 General

The SubscribedDataSet option TargetVariables defines a list of Variable mappings between received DataSet fields and target Variables in the Subscriber AddressSpace. The FieldTargetDataType is defined in 6.2.10.2.3. Target Variables shall only be used once within the same TargetVariables list.

6.2.10.2.2 TargetVariablesDataType

This Structure DataType is used to represent TargetVariables specific parameters. It is a subtype of the SubscribedDataSetDataType defined in 6.2.10.1.

The TargetVariablesDataType is formally defined in Table 67.

Its representation in the AddressSpace is defined in Table 68.

6.2.10.2.3 FieldTargetDataType

This DataType is used to provide the metadata for the relation between a field in a DataSetMessage and a target Variable in a DataSetReader. The FieldTargetDataType is formally defined in Table 69.

Its representation in the AddressSpace is defined in Table 70.

6.2.10.2.4 OverrideValueHandling

The OverrideValueHandling is an enumeration that specifies the possible options for the handling of Override values. The possible enumeration values are described in Table 71.

The OverrideValueHandling representation in the AddressSpace is defined in Table 72.

6.2.10.3 SubscribedDataSetMirror

6.2.10.3.1 General

The SubscribedDataSet option SubscribedDataSetMirror defines an Object in the Subscriber AddressSpace with a mirror Variable for each DataSet field in the received DataSetMessages.

6.2.10.3.2 ParentNodeName

This parameter with DataType String defines the BrowseName and DisplayName of the parent Node for the Variables representing the fields of the subscribed DataSet.

6.2.10.3.3 RolePermissions

This parameter with DataType RolePermissionType defines the value of the RolePermissions Attribute to be set on the parent Node. This value is also used as RolePermissions for all Variables of the DataSet mirror.

6.2.10.3.4 SubscribedDataSetMirrorDataType

This Structure DataType is used to represent SubscribedDataSetMirror specific parameters. It is a subtype of the SubscribedDataSetDataType defined in 6.2.10.1.

The SubscribedDataSetMirrorDataType is formally defined in Table 73.

Its representation in the AddressSpace is defined in Table 74.

6.2.10.4 StandaloneSubscribedDataSetRefDataType

This Structure DataType references a standalone subscribed DataSet. It is a subtype of the SubscribedDataSetDataType defined in 6.2.10.1.

The StandaloneSubscribedDataSetRefDataType is formally defined in Table 75.

Its representation in the AddressSpace is defined in Table 76.

6.2.10.5 StandaloneSubscribedDataSetDataType

This Structure DataType is define a standalone subscribed DataSet. It is a subtype of the SubscribedDataSetDataType defined in 6.2.10.1.

The StandaloneSubscribedDataSetDataType is formally defined in Table 77.

Its representation in the AddressSpace is defined in Table 78.

6.2.11 Information flow and status handling

6.2.11.1 Published data items

The configuration model defines different parameters that influence the information flow from Publisher to Subscriber in the case of a Bad Value Status or other error situations. Figure 25 depicts the parameters and the information flow inside a Publisher and inside a Subscriber.

The parameters and behaviour relevant for the encoding of a DataSetMessage on the Publisher side and the decoding of the DataSetMessage on the Subscriber side are defined in 6.2.4.2 together with the DataSetFieldContentMask.

The mapping of source value and status to the DataSet in the Publisher depends on the substitute value. The dependencies are defined in Table 79.

The mapping of the decoded DataSet on the Subscriber side to the value and status of the target Variable depends on the override value. The dependencies are defined in Table 80.

If one of the target Variables in the SubscribedDataSet does not allow writing of the StatusCode and the OverrideValueHandling is set to Disabled, the DataSetReader shall indicate the configuration error by setting the DataSetReader state to Error. In all other configurations of OverrideValueHandling when the target Variable does not allow writing of the StatusCode, only the Value is transferred to the target Variable.

If a target Variable in the SubscribedDataSet does not allow writing of timestamp, any received timestamp shall not be used and only the received value shall be written to the target Variable.

6.2.11.2 Actions

6.2.11.2.1 ActionState

The ActionState is used to indicate the current state of an Action execution. It is an enumeration of the possible states. The enumeration values are described in Table 81.

The ActionState representation in the AddressSpace is defined in Table 82.

6.2.11.2.2 Action execution sequence

The Action execution sequence and the related ActionMetaData for an Action execution through a reliable transport protocol like MQTT is described in Figure 26.

The RequestId is unique within the context of a RequestorId and CorrelationData. Each Action request in a single NetworkMessage has a different RequestId. Multiple NetworkMessages with the same RequestorId and CorrelationData may be sent.

Multiple Responses may be sent in the same NetworkMessage if the corresponding requests have the same RequestorId and CorrelationData. The grouping of requests in NetworkMessages does not affect the grouping of Responses into NetworkMessages.

The Action execution sequence for an Action execution through a non-reliable transport protocol like UDP is described in Figure 27. The related ActionMetaData is described in Figure 26. It shows the use of the ActionState for a non-reliable transport protocol. The request and response messages are send in the PublishingInterval of the Responder as long as the ActionState requires the exchange of messages for a Action execution.

The state changes for Action execution are defined in Table 83 for the Requestor and in Table 84 for the Responder.

Errors during the execution of an Action are reported in the Status of the Action response message.

For some errors such as decoding errors for the request message, addressing errors or failing security checks, the Responder does not produce a response message. Therefore the Requestor should have an internal timeout setting to stop waiting for a response message.

6.2.11.2.3 Action specific use of parameters

The Action specific use of PubSub configuration parameters is defined in Table 85.

Note that the reliability of the protocol depends on the QoS levels supported by the protocol. Any Broker-based middleware that is using a QoS of AtLeastOnce or greater is reliable (see 6.4.2.5.4). Broker-less middle is not reliable if it does not support any DatagramQoS (see 6.4.1.2.6).

6.2.12 PubSubConfiguration

6.2.12.1 PubSubConfigurationDataType

This Structure DataType is used to represent the PubSub configuration of an OPC UA Application. The PubSubConfigurationDataType is formally defined in Table 86.

Its representation in the AddressSpace is defined in Table 87.

If the PubSub configuration is stored in a file, the UABinaryFileDataType and the related definitions in OPC 10000-5 shall be used to encode the file content. The structure of the UABinaryFileDataType file with typical values for a PubSub configuration is described in Table 88.

6.2.12.2 SecurityGroupDataType

This Structure DataType is used to represent the configuration of a SecurityGroup in a PubSub configuration of an OPC UA Application.

If the SecurityPolicyUri or the KeyLifetime of an existing SecurityGroup are modified, all existing keys of the SecurityGroup are invalidated. The behaviour is described for the InvalidateKeys Method in 8.4.2.

The SecurityGroupDataType is formally defined in Table 89.

Its representation in the AddressSpace is defined in Table 90.

6.2.12.3 PubSubKeyPushTargetDataType

This Structure DataType is used to represent the configuration of a PubSubKeyServicePushTarget in a PubSub configuration of an OPC UA Application. The PubSubKeyPushTargetDataType is formally defined in Table 91.