One of the use cases for PubSub is the cyclic exchange of real-time data. In such a use case, the layout of the data that needs to be transferred is the same in every PublishingInterval. When the message layout is the same in every PublishingInterval, and the Subscriber knows this in advance, several optimizations are possible:

  • Both Publisher and the Subscriber can be optimized for sending and receiving messages with a fixed layout, therefore offsets of send/receive fields can be pre-calculated based on the configuration.
  • Certain encodings may result in varying size of DataSetMessages, which requires extra fields in the messages to allow the Subscriber to parse these messages. These extra fields can be omitted when the size of the DataSetMessages is constant.

The header layout described in this section is optimized for this use case.

The basic assumption for these header layouts is that the data layout in the published messages is static. This implies the following:

Note: These assumptions have to be fulfilled by appropriate configuration of the Publisher.

Subscribers have to know the static message layout in advance. This means all fields in the headers which would be required for ad-hoc parsing of messages with dynamic layout can be omitted (e.g. PayloadHeader or Sizes).

Finally, a Subscriber needs an easy way to verify that a received message matches the expected message layout. Fields of the NetworkMessage header and the GroupHeader will be used for this purpose.

PublisherId and WriterGroupId identify the WriterGroup. The NetworkMessageNumber is important for WriterGroups which distribute their DataSets over more than one NetworkMessage, and the GroupVersion allows the Subscriber to verify the expected layout of the DataSetMessages and their DataSet fields.

The header layout URI for the fixed layout for periodic data as specified in A.2.1.4, A.2.1.5, A.2.1.6 and A.2.1.7 is

http://opcfoundation.org/UA/PubSub-Layouts/UADP-Periodic-Fixed

A UADP NetworkMessage header shall contain the following fields according to this header layout:

Additional restrictions:

The NetworkMessage header layout is shown in Figure A.1.

image051.png

Figure A.1 – UADP NetworkMessage header layout

Table A.1 shows the configuration for the NetworkMessage header.

Table A.1 – UADP NetworkMessage header layout

Name

Type

Restrictions

UADPVersion

Bit[0-3]

The version shall be 1

UADPFlags

Bit[4-7]

Bit 4: PublisherId enabled = 1

Bit 5: GroupHeader enabled = 1

Bit 6: PayloadHeader enabled = 0

Bit 7: ExtendedFlags1 enabled = 1

ExtendedFlags1

Byte

Bit range 0-2: PublisherId Type with one of the two following options

001 The PublisherId is of DataType UInt16

011 The PublisherId is of DataType UInt64

Bit 3: DataSetClassId enabled = 0

Bit 4: SecurityHeader enabled = 0

Bit 5: Timestamp enabled = 0

Bit 6: PicoSeconds enabled = 0

Bit 7: ExtendedFlags2 enabled = 0

PublisherId

UInt16 or UInt64

Configured value for the PubSubConnection.

The datatype shall be UInt16 or UInt64.

GroupHeader

GroupFlags

Byte

Bit 0: WriterGroupId enabled = 1

Bit 1: GroupVersion enabled = 1

Bit 2: NetworkMessageNumber enabled = 1

Bit 3: SequenceNumber enabled = 1

Bits 4-6: 0

Bit 7: 0

WriterGroupId

UInt16

Configured value for the WriterGroup.

GroupVersion

VersionTime

Configured value for the WriterGroup.

NetworkMessage Number

UInt16

Configured value for the WriterGroup.

SequenceNumber

UInt16

Defined by Table 137.

Table A.2 defines the values for the configuration parameters representing this layout.

Table A.2 – Values for configuration parameters

Parameter

Value

UadpNetworkMessageContentMask

0x0000003F

This value results of the following options:

Bit 0: PublisherId enabled = 1

Bit 1: GroupHeader enabled = 1

Bit 2: WriterGroupId enabled = 1

Bit 3: GroupVersion enabled = 1

Bit 4: NetworkMessageNumber enabled = 1

Bit 5: SequenceNumber enabled = 1

When a PubSubConnection is created by using the Method AddConnection() the element PublisherId contained in the argument PubSubConnectionDataType shall be of the datatype UInt16 or UInt64.

UADP messages may be signed to ensure integrity. In this case the SecurityHeader and the Signature have to be added to the message. See clause 7.2.4.4.3 for a complete description of the signing mechanism.

This header layout is basically the same as the header layout defined in A.2.1.4 but with additional security level ‘signing but no encryption’.

The NetworkMessage header layout with signing is shown in Figure A.2.

image052.png

Figure A.2 – UADP NetworkMessage header layout with integrity (signing)

Table A.3 shows the configuration for the NetworkMessage header with signing. The table contains only the added or modified rows from Table A.1.

Table A.3 – UADP NetworkMessage header layout with integrity (signing)

Name

Type

Restrictions

ExtendedFlags1

Byte

Bit 4: SecurityHeader enabled = 1

SecurityHeader

SecurityFlags

Byte

Bit 0: NetworkMessage Signed enabled = 1

Bit 1: NetworkMessage Encryption enabled = 0

Bit 2: SecurityFooter enabled = 0

Bit 3: Force key reset enabled = 0

Bit range 4-7: Reserved

SecurityTokenId

IntegerId

The ID of the security token that identifies the security key in a SecurityGroup.

NonceLength

Byte

8

MessageNonce

Byte[8]

A number used exactly once for a given security key.

UADP messages may be signed and encrypted. In this case the SecurityHeader and the Signature have to be added to the message. See clause 7.2.4.4.3 for a complete description of the security mechanisms.

This header layout is basically the same as the header layout defined in A.2.1.4 but with additional security level ‘signing and encryption’.

The NetworkMessage header layout with signing is shown in Figure A.3.

image053.png

Figure A.3 – UADP NetworkMessage header layout with integrity and confidentiality

Table A.4 shows the configuration for the NetworkMessage header with signing and encryption. The table contains only the added or modified rows from Table A.1.

Table A.4 – UADP NetworkMessage header layout with integrity and confidentiality

Name

Type

Restrictions

ExtendedFlags1

Byte

Bit 4: SecurityHeader enabled = 1

SecurityHeader

SecurityFlags

Byte

Bit 0: NetworkMessage Signed enabled = 1

Bit 1: NetworkMessage Encryption enabled = 1

Bit 2: SecurityFooter enabled = 0

Bit 3: Force key reset enabled = 0

Bit range 4-7: Reserved

SecurityTokenId

IntegerId

The ID of the security token that identifies the security key in a SecurityGroup.

NonceLength

Byte

8

MessageNonce

Byte[8]

A number used exactly once for a given security key.

A UADP DataSetMessage header shall consist of the following fields according to this header layout:

Additional restrictions:

The DataSetMessage header layout is shown in Figure A.4.

image054.png

Figure A.4 – UADP DataSetMessage header layout

Table A.5 shows the configuration for the DataSetMessage header.

Table A.5 – UADP DataSetMessage header layout

Name

Type

Restrictions

DataSetFlags1

Byte

Bit 0: Indicates whether this DataSetMessage is valid

Bit range 1-2: Field Encoding

01 RawData Field Encoding

Bit 3: DataSetMessageSequenceNumber enabled = 1

Bit 4: Status enabled

Bit 5: ConfigurationVersionMajorVersion enabled = 0

Bit 6: ConfigurationVersionMinorVersion enabled = 0

Bit 7: DataSetFlags2 enabled = 0

DataSetMessageSequenceNumber

UInt16

Defined by Table 145.

StatusCode

UInt16

Defined by Table 145.

Table A.6 defines the values for the configuration parameters representing this layout.

Table A.6 – Values for configuration parameters

Parameter

Value

KeyFrameCount

1

UadpDataSetMessageContentMask

0x00000024

This value results of the following options:

Bit 2: StatusCode enabled = 1

Bit 5: SequenceNumber enabled = 1

DataSetFieldContentMask

0x00000020

This value results of the following options:

Bit 5: RawData

DataSetOrdering

AscendingWriterId or AscendingWriterIdSingle

Figure A.5 shows an example for a UADP NetworkMessage with fixed layout as defined in A.2.1.3 and A.2.1.7.

The configuration ensures that every NetworkMessage sent has the same layout of header fields and also the same layout of DataSet fields. This allows a highly efficient encoding and decoding of the message because the offset of all fields is constant and can be pre-calculated. The Payload Header (Count and Sizes for the DataSetMessages and DataSetWriterIds) is deactivated and the Subscriber has to retrieve this information through the DataSetMetaData, DataSetWriter and WriterGroup settings.

The configuration has to ensure that the size of each DataSetMessage is constant. This can be achieved by avoiding DataSet fields of types with variable size, or by using the parameter ConfiguredSize. In this example it is assumed that DataSetMessage[1] and DataSetMessage[W-1] are using RawData field encoding and all DataSet fields are from constant size, so the total length of theses DataSetMessages can be calculated from the DataSetMetaData. For DataSetMessage[0] in this example the Subscriber does not have to calculate the total length but it should take it from the parameter ConfiguredSize. This allows to provide spare bytes for future extension of DataSetMessage[0] without effect on the size of the complete NetworkMessage or the position of other DataSetMessages in this NetworkMessage.

By setting-specific values for KeyFrameCount and DataSetOrdering (see Table A.6) it is guaranteed that the number of DataSetMessages and their order inside the NetworkMessage is the same in every NetworkMessage that is sent.

image055.png

Figure A.5 – Example for fixed message layout without security

Figure A.6 shows an example for a UADP NetworkMessage with fixed layout and security activated (signing, no encryption) as defined in A.2.1.5 and A.2.1.7.

The layout of all header fields and DataSet fields is constant like described in A.2.1.8. Additional to this the SecurityHeader is activated for signing (but no encryption).

image056.png

Figure A.6 – Example for fixed message layout without signature