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.

Figure 4 – OPC UA PubSub message layers

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.

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.

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.

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:

DataSetWriterId Identifies the DataSetWriter and indirectly the PublishedDataSet.

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

Timestamp A timestamp describing when the data in this DataSetMessage was obtained.

Version Version information about the configuration of the DataSetMetaData.

Status Status information about the data in this DataSetMessage.

Keep alive When no DataSetMessages are sent for a configured time period, a keep alive DataSetMessage is sent to signal the Subscribers that the Publisher is still alive.

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.

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:

PublisherId Identifies the Publisher.

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

Promoted fields Selected fields out of the DataSet also sent in the header.

Payload One or more DataSetMessages.

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.

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

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.

The transport security is specific to the transport protocol mapping.

When using a broker-based middleware (see 5.4.5.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. Combining transport security with message security reduces this risk.

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

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.

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.