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.
A DataSet field contains the actual value as well as additional information about the value like status and timestamp.
The representation as RawData is the most efficient format and is used if a common status and timestamp per DataSet is sufficient.
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.
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 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.
- 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.
This standard defines a general distribution framework for cryptographic keys. This framework is introduced in 5.4.4.
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 184.108.40.206.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.