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 specification formally defines the term DataSetMessage to mean the application data (the payload) supplied by the Publisherand the term NetworkMessage to mean the message handed off and received from a specific Message Oriented Middleware.DataSetMessages are embedded in NetworkMessages. Figure 4shows 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.

Following is an abstract definition of DataSetMessageandNetworkMessage. The concrete structure depends on the message mapping and is described in 7.2.

A DataSetMessagefield is the representation of a DataSetfield in a DataSetMessage.

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

A DataSetfield can be represented as a DataValue, as a Variantor as a RawDatain the DataSetMessagefield. The representation depends on the DataSetFieldContentMaskdefined in

The representation as a DataValueis used if value, status and timestamp should be included in the DataSetMessage.

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

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

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

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

Additional header information includes:

DataSetWriterIdIdentifies theDataSetWriterand indirectly the PublishedDataSet.

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

TimestampA timestamp describing when the data in this DataSetMessagewas obtained.

VersionVersion information about the configuration of the DataSetMetaData.

StatusStatus information about the data in this DataSetMessage.

Keep aliveWhen no DataSetMessagesare sent for a configured time period, a keep alive DataSetMessageis sent to signal the Subscribersthat the Publisheris still alive.

Some encodings differentiate between key frame DataSetMessages and delta frame DataSetMessages. A key frame DataSetMessageincludesvalues forall fields of the DataSet.A delta frame DataSetMessageonly contains the subset that changed since the previous DataSetMessage.

A key frame DataSetMessageis sent after a configured number of DataSetMessages.

The NetworkMessageis a container for DataSetMessagesand includes information shared between DataSetMessages. This information consists of:

PublisherIdIdentifies the Publisher.

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

Promoted fieldsSelected fields out of the DataSetalso sent in the header.

PayloadOne or more DataSetMessages.

The payload, consisting of the DataSetMessageswill be encrypted in accordance with the configured message security. Individual fields of a DataSetMessagecan 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 NetworkMessageformat and the used protocol. The NetworkMessageheader is not encrypted to enable efficient filtering.

Message security in PubSubconcerns integrity and confidentiality of the published message payload. The level of security can be:

  • No security
  • Signing but no encryption
  • Signing and encryption

Message security is end-to-end security (from Publisherto Subscriber) and requires common knowledge of the cryptographic keys necessary to sign and encrypt on the Publisherside as well as validate signature and decrypt on the Subscriberside.

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

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

All parameters that are relevant for message security are described in 6.2.4. These parameters are independent of any Brokerlevel transport security.

The message security for PubSubis 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, confidentiality and integrity can be ensured with the transport security between Publishersand the Brokeras well as Subscribersand the Broker. The Brokerlevel security in addition requires all Publishersand Subscribersto have credentials that grant them access to a Brokerresource.

Transport security may be hop-by-hop security with some risk of man-in-the-middle attacks. It also requires trusting the Brokersince the Brokercan read the messages. Combining transport security with message security reduces this risk.

A SecurityGroupis an abstraction that represents the message security settings and security keys for a subset of NetworkMessagesexchanged between Publishersand Subscribers. The security keys are used to encrypt and decrypt NetworkMessagesand to generate and check signatures on a NetworkMessage.

A Security Key Service(SKS) manages SecurityGroupsand maintains a mapping between Rolesand their access Permissionsfor a SecurityGroup. This mapping defines if a Publisheror Subscriberhas access to the security keys of a SecurityGroup. The SKS is described in more detail in 5.4.3.

A SecurityGroupis identified with a unique identifier called the SecurityGroupId. It is unique within the SKS. A Publisherfor its PublishedDataSetsmust know the SecurityGroupId. For Subscribersthe SecurityGroupIdis distributed as metadata together with the DataSetMetaData. The metadata for a SecurityGroupIdincludes the EndpointDescriptionof the responsible SKS. Publishers and Subscribers use the EndpointDescriptionto access the SKS and the SecurityGroupIdto obtain the security keys for a SecurityGroup.