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 Subscriberknows this in advance, several optimizations are possible:

• Both Publisherand the Subscribercan 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 Subscriberto parse these messages. These extra fields can be omitted when the size of the DataSetMessagesis 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:

• Each NetworkMessagecontains the same number of DataSetMessages
• The sequence of the DataSetMessageswithin a NetworkMessageis the same in every PublishingInterval
• The layout of the fields within every DataSetMessageis the same in every PublishingInterval

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

Subscribershave 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. PayloadHeaderor Sizes).

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

PublisherIdand WriterGroupIdidentify the WriterGroup. The NetworkMessageNumberis important for WriterGroupswhich distribute their DataSets over more than one NetworkMessage, and the GroupVersionallows the Subscriberto verify the expected layout of the DataSetMessagesand their DataSet fields.

The header layout URI for the fixed layout for periodic data as specified in A.2.4, A.2.5, A.2.6and A.2.7is

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

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

• Version/Flags
• ExtendedFlags1
• PublisherId
• GroupFlags
• WriterGroupId
• GroupVersion
• NetworkMessageNumber
• SequenceNumber

Additional restrictions:

• The datatype for the PublisherIdshall be UInt16 orUInt64

The NetworkMessageheader layout is shown in Figure A.1.

Figure A.1– UADP NetworkMessage header layout

Table A.1shows the configuration for the NetworkMessageheader.

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: PublisherIdenabled = 1 Bit 5: GroupHeaderenabled = 1 Bit 6: PayloadHeaderenabled = 0 Bit 7: ExtendedFlags1 enabled = 1
ExtendedFlags1	Byte	Bit range 0-2: PublisherIdType with one of the two following options 001 The PublisherIdis of DataType UInt16 011 The PublisherIdis of DataType UInt64 Bit 3: DataSetClassIdenabled = 0 Bit 4: SecurityHeaderenabled = 0 Bit 5: Timestampenabled = 0 Bit 6: PicoSecondsenabled = 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: WriterGroupIdenabled = 1 Bit 1: GroupVersionenabled = 1 Bit 2: NetworkMessageNumberenabled = 1 Bit 3: SequenceNumberenabled = 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 134.

Table A.2defines 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: PublisherIdenabled = 1 Bit 1: GroupHeaderenabled = 1 Bit 2: WriterGroupIdenabled = 1 Bit 3: GroupVersionenabled = 1 Bit 4: NetworkMessageNumberenabled = 1 Bit 5: SequenceNumberenabled = 1

When a PubSubConnectionis created by using the Method AddConnection()the element PublisherIdcontained in the argument PubSubConnectionDataType shall be of the datatype UInt16or UInt64.

UADP messages may be signed to ensure integrity. In this case the SecurityHeaderand the Signaturehave to be added to the message. See clause 7.2.2.4.3for a complete description of the signing mechanism.

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

The NetworkMessageheader layout with signing is shown in Figure A.2.

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

Table A.3shows the configuration for the NetworkMessageheader 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: SecurityHeaderenabled
SecurityHeader
SecurityFlags	Byte	Bit 0: NetworkMessageSigned enabled = 1 Bit 1: NetworkMessageEncryption enabled = 0 Bit 2: SecurityFooterenabled = 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 SecurityHeaderand the Signaturehave to be added to the message. See clause 7.2.2.4.3for a complete description of the security mechanisms.

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

The NetworkMessageheader layout with signing is shown in Figure A.3.

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

Table A.4shows the configuration for the NetworkMessageheader 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: SecurityHeaderenabled
SecurityHeader
SecurityFlags	Byte	Bit 0: NetworkMessageSigned enabled = 1 Bit 1: NetworkMessageEncryption enabled = 1 Bit 2: SecurityFooterenabled = 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 DataSetMessageheader shall consist of the following fields according to this header layout:

• DataSetFlags1
• DataSetMessageSequenceNumber
• Status

Additional restrictions:

• Fields within the payload use RawData Field Encoding
• Only data key frame DataSetMessagesare supported

The DataSetMessageheader layout is shown in Figure A.4.

Figure A.4– UADP DataSetMessage header layout

Table A.5shows the configuration for the DataSetMessageheader.

Table A.5– UADP DataSetMessage header layout

Name	Type	Restrictions
DataSetFlags1	Byte	Bit 0: Indicates whether this DataSetMessageis valid Bit range 1-2: Field Encoding 01 RawData Field Encoding Bit 3: DataSetMessageSequenceNumberenabled = 1 Bit 4: Statusenabled Bit 5: ConfigurationVersionMajorVersionenabled = 0 Bit 6: ConfigurationVersionMinorVersionenabled = 0 Bit 7: DataSetFlags2enabled = 0
DataSetMessageSequenceNumber	UInt16	Defined by Table 142.
StatusCode	UInt16	Defined by Table 142.

Table A.6defines 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: StatusCodeenabled = 1 Bit 5: SequenceNumber enabled = 1
DataSetFieldContentMask	0x00000020 This value results of the following options: Bit 5: RawData
DataSetOrdering	AscendingWriterIdor AscendingWriterIdSingle

Figure A.5shows an example for a UADP NetworkMessagewith fixed layout as defined in A.2.3and A.2.7.

The configuration ensures that every NetworkMessagesent 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(Countand Sizesfor the DataSetMessagesand DataSetWriterIds) is deactivated and the Subscriberhas to retrieve this information through the DataSetMetaData, DataSetWriter and WriterGroupsettings.

The configuration has to ensure that the size of each DataSetMessageis 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 DataSetMessagescan be calculated from the DataSetMetaData. For DataSetMessage[0] in this example the Subscriberdoes 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 NetworkMessageor the position of other DataSetMessagesin this NetworkMessage.

By setting-specific values for KeyFrameCountand DataSetOrdering(see Table A.6) it is guaranteed that the number of DataSetMessagesand their order inside the NetworkMessageis the same in every NetworkMessagethat is sent.

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

Figure A.6shows an example for a UADP NetworkMessagewith fixed layout and security activated (signing, no encryption) as defined in A.2.5and A.2.7.

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

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