OPC UA Specification - Amendment

OPC 10001-6

 

OPC Unified Architecture

Amendment 6: UADP Header Layouts

 

 

Release 1.04

2019-06-04

 

 

 

 

 

 

 


 

Specification Type:

Industry Standard Specification

Comments:

Report or view errata: http://www.opcfoundation.org/errata

 

 

 

 

Document
Number

OPC 10001-6

 

 

Title:

OPC Unified Architecture

Amendment 6 UADP Header Layouts

Date:

2019-06-04

 

 

 

 

Version:

Release Candidate 1.04

Software:

MS-Word

 

 

Source:

OPC 10001-6 - UA Specification 1.04 Amendment 6 - UADP Header Layouts.docx

 

 

 

 

Author:

OPC Foundation

Status:

Release

 

 

 

 


 

 

OPC Foundation

____________

 

UNIFIED ARCHITECTURE

FOREWORD

This specification is the specification for developers of OPC UA applications. The specification is a result of an analysis and design process to develop a standard interface to facilitate the development of applications by multiple vendors that shall inter-operate seamlessly together.

Copyright © 2006-2019, OPC Foundation, Inc.

AGREEMENT OF USE

COPYRIGHT RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

OPC Foundation members and non-members are prohibited from copying and redistributing this specification. All copies must be obtained on an individual basis, directly from the OPC Foundation Web site
HTUhttp://www.opcfoundation.orgUTH.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830

COMPLIANCE

The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

ISSUE REPORTING

The OPC Foundation strives to maintain the highest quality standards for its published specifications, hence they undergo constant review and refinement. Readers are encouraged to report any issues and view any existing errata here: HTUhttp://www.opcfoundation.org/errataUTH

 


 

Revision 1.04 Amendment 6 Highlights

The following table includes the Mantis issues resolved by this Amendment.

Mantis ID

Summary

Resolution

4530

UADP Header Layouts

UADP Header Layouts specified in this Amendment

 

 


OPC Unified Architecture Specification

 

AMENDMENT 6: UADP Header Layouts

 

OPC 10000-14, OPC Unified Architecture - Part 14: PubSub

Add the following as Annex C:

                                                                                Annex C
(normative)

UADP Header Layouts

C.1      General

The UADP header formats for both NetworkMessages and DataSetMessages were designed to be flexible and to support different use cases by enabling or disabling individual fields within the headers.

While this flexibility makes it possible to support many different use cases with PubSub, the number of possible header field combinations also increases the effort needed for the implementation and verification. On the other hand, within a given application domain or for different use cases some configurations might be more appropriate than others. The UADP Header Layouts described in this section intend to find a reasonable set of header options to provide a compromise between flexibility, interoperability and optimized support for different use cases.

C.2      Message headers for periodic data with fixed layout

C.2.1      Motivation

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.

C.2.2      Overview

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

·      Each NetworkMessage contains the same number of DataSetMessages

·      The sequence of the DataSetMessages within a NetworkMessage is the same in every PublishingInterval

·      The layout of the fields within every DataSetMessage is the same in every PublishingInterval

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.

C.2.3      Header layout URI

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

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

C.2.4      Header layout for NetworkMessages

A UADP NetworkMessage header 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 PublisherId shall be UInt16

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

Figure C.1: UADP NetworkMessage header layout

 

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

Table C.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

Bit 5: GroupHeader enabled

Bit 6: PayloadHeader disabled

Bit 7: ExtendedFlags1 enabled

ExtendedFlags1

Byte

Bit range 0-2: PublisherId Type

      001    The PublisherId is of DataType UInt16

Bit 3: DataSetClassId disabled

Bit 4: Security disabled

Bit 5: Timestamp disabled

Bit 6: PicoSeconds disabled

Bit 7: ExtendedFlags2 disabled

PublisherId

UInt16

Configured value for the PubSubConnection.

The datatype shall be UInt16

GroupHeader

 

 

      GroupFlags

Byte

Bit 0: WriterGroupId enabled

Bit 1: GroupVersion enabled

Bit 2: NetworkMessageNumber enabled

Bit 3: SequenceNumber enabled

Bits 4-6: 0

Bit 7: disabled

      WriterGroupId

UInt16

Configured value for the WriterGroup

      GroupVersion

VersionTime

Configured value for the WriterGroup

      NetworkMessageNumber

UInt16

Configured value for the WriterGroup

      SequenceNumber

UInt16

Defined by Table 74

 

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

Table C.2: Values for configuration parameters

Parameter

Value

UadpNetworkMessageContentMask

0x0000003F

 

This value results of the following options:

Bit 0: PublisherId enabled

Bit 1: GroupHeader enabled

Bit 2: WriterGroupId enabled

Bit 3: GroupVersion enabled

Bit 4: NetworkMessageNumber enabled

Bit 5: SequenceNumber enabled

 

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

C.2.5      Header layout for NetworkMessages with integrity (signing)

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.2.2.3 (UADP Message Security) for a complete description of the signing mechanism.

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

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

Figure [RSA1] C.2: UADP NetworkMessage header layout with integrity (signing)

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

Table C.3: UADP NetworkMessage header layout with integrity (signing)

Name

Type

Restrictions

ExtendedFlags1

Byte

Bit 4: Security enabled

SecurityHeader

 

 

      SecurityFlags

Byte

Bit 0: NetworkMessage Signed enabled

Bit 1: NetworkMessage Encryption disabled

Bit 2: SecurityFooter disabled

Bit 3: Force key reset disabled

Bit range 4-7: Reserved

      SecurityTokenId

IntegerId

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

      NonceLength

Byte

0

 

C.2.6      Header layout for NetworkMessages with integrity and confidentiality (signing and encryption)

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.2.2.3 (UADP Message Security) for a complete description of the security mechanisms.

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

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

Figure [RSA2] C.3: UADP NetworkMessage header layout with integrity and confidentiality

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

Table C.4: UADP NetworkMessage header layout with integrity and confidentiality

Name

Type

Restrictions

ExtendedFlags1

Byte

Bit 4: Security enabled

SecurityHeader

 

 

      SecurityFlags

Byte

Bit 0: NetworkMessage Signed enabled

Bit 1: NetworkMessage Encryption enabled

Bit 2: SecurityFooter disabled

Bit 3: Force key reset disabled

Bit range 4-7: Reserved

      SecurityTokenId

IntegerId

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

      NonceLength

Byte

4

      MessageNonce

Byte[4]

A number used exactly once for a given security key.

 

C.2.7      Header layout for DataSetMessages

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

·      DataSetMessageSequenceNumber

·      Status

Additional restrictions:

·      Fields within the payload use RawData Field Encoding

·      Only Data Key Frame DataSetMessages are supported

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

Figure C.4: UADP DataSetMessage header layout

 

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

Table C.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

Bit 4: Status enabled

Bit 5: ConfigurationVersionMajorVersion disabled

Bit 6: ConfigurationVersionMinorVersion disabled

Bit 7: DataSetFlags2 disabled

DataSetMessageSequenceNumber

UInt16

Defined by Table 82

StatusCode

UInt16

Defined by Table 82

 

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

Table C.6: Values for configuration parameters

Parameter

Value

KeyFrameCount

1

UadpDataSetMessageContentMask

0x00000024

 

This value results of the following options:

Bit 2: StatusCode enabled

Bit 5: SequenceNumber enabled

DataSetFieldContentMask

0x00000020

 

This value results of the following options:

Bit 5: RawData

DataSetOrdering

AscendingWriterId_1 or AscendingWriterIdSingle_2

 

C.2.8      Examples

C.2.8.1        Fixed message layout without security

Figure C.5 shows an example for a UADP NetworkMessage with fixed layout as defined in C.2.3 and 0.

The configuration ensures that every NetworkMessage sent has the same layout of header fields and also the same layout of DataSetFields. This allows a highly efficient encoding and decoding of the message because the offset of all fields is constant and can be precalculated. 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 DataSetFields 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 C.6) it is guaranteed that the number of DataSetMessages and their order inside the NetworkMessage is the same in every NetworkMessage that is sent.

Figure C.5: Example for fixed message layout without security

C.2.8.2        Fixed message layout with integrity

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

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

Figure C.6: Example for fixed message layout without signature

C.3      Message headers for Events and Data with dynamic layout

C.3.1      Motivation

In PubSub use cases with dynamically changing message layouts or Event based DataSetMessages the number and ordering of DataSetMessages within different NetworkMessages can change arbitrarily. The header layouts described in this section are intended for use cases with dynamic DataSets and ad-hoc identification of DataSetMessages.

C.3.2      Overview

With the header layout described in this section, the NetworkMessage header only identifies the Publisher and the contained DataSetMessages. In contrast to the fixed layout, more header fields are enabled in the DataSetMessage header with this header layout but the GroupHeader is deactivated.

C.3.3      Header layout URI

The header layout URI for the dynamic layout as specified in C.3.4, C.3.5, C.3.6 and C.3.7 is

http://opcfoundation.org/UA/PubSub-Layouts/UADP-Dynamic

C.3.4      Header layout for NetworkMessages

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

·      Version/Flags

·      ExtendedFlags1

·      PublisherId

·      PayloadHeader

Additional restrictions:

·      The datatype for the PublisherId shall be UInt64

Note: For the PublisherId the DataType UInt64 was selected because it allows a simple way for a Publisher to generate unique PublisherIds by using the local MAC address (48 Bit) as part of the PublisherId.

 

The NetworkMessage header layout is shown in Figure C.7.

Figure C.7: UADP NetworkMessage header layout

Table C.7 shows the configuration for the NetworkMessage header.

Table C.7: UADP NetworkMessage header layout

Name

Type

Restrictions

UADPVersion

Bit[0-3]

The version shall be 1

UADPFlags

Bit[4-7]

Bit 4: PublisherId enabled

Bit 5: GroupHeader disabled

Bit 6: PayloadHeader enabled

Bit 7: ExtendedFlags1 enabled

ExtendedFlags1

Byte

Bit range 0-2: PublisherId Type

      011    The PublisherId is of DataType UInt64

Bit 3: DataSetClassId disabled

Bit 4: Security disabled

Bit 5: Timestamp disabled

Bit 6: PicoSeconds disabled

Bit 7: ExtendedFlags2 disabled

PublisherId

UInt64

Configured value for the PubSubConnection.

The datatype shall be UInt64.

PayloadHeader

Byte[*]

Defined by Table 80

 

Table C.8 defines the values for the configuration parameters representing this layout.

Table C.8: Values for configuration parameters

Parameter

Value

UadpNetworkMessageContentMask

0x00000041

 

This value results of the following options:

Bit 0: PublisherId enabled

Bit 6: PayloadHeader enabled

 

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

C.3.5      Header layout for NetworkMessages with integrity (signing)

UADP messages may be signed to ensure integrity. In this case a security header and a signature have to be added to the message. See clause 7.2.2.2.3 (UADP Message Security) for a complete description of the signing mechanism.

This header layout is basically the same as the header layout defined in C.3.4 but with additional security level ‘Signing but no encryption’. The NetworkMessage header layout with signing is shown in Figure C.8.

[RSA3] Figure C.8: UADP NetworkMessage header layout with integrity (signing)

Table C.9 shows the configuration for the NetworkMessage header with signing. The table contains only the added or modified rows from Table C.7.

Table C.9: UADP NetworkMessage header layout with integrity (signing)

Name

Type

Restrictions

ExtendedFlags1

Byte

Bit 4: Security enabled

SecurityHeader

 

 

      SecurityFlags

Byte

Bit 0: NetworkMessage Signed enabled

Bit 1: NetworkMessage Encryption disabled

Bit 2: SecurityFooter disabled

Bit 3: Force key reset disabled

Bit range 4-7: Reserved

      SecurityTokenId

IntegerId

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

      NonceLength

Byte

The length of the Nonce used to initialize the encryption algorithm.

 

C.3.6      Header layout for NetworkMessages with integrity and confidentiality (signing and encryption)

UADP messages may be signed and encrypted. In this case a security header and a signature have to be added to the message. See clause 7.2.2.2.3 (UADP Message Security) for a complete description of the security mechanisms.

This header layout is basically the same as the header layout defined in C.3.4 but with additional security level ‘Signing and encryption’. The NetworkMessage header layout with signing and encryption is shown in Figure C.9.

Figure[RSA4]  C.9: UADP NetworkMessage header layout with integrity and confidentiality

Table C.10 shows the configuration for the NetworkMessage header with signing and encryption. The table contains only the added or modified rows from Table C.7.

Table C.10: UADP NetworkMessage header layout with integrity and confidentiality

Name

Type

Restrictions

ExtendedFlags1

Byte

Bit 4: Security enabled

SecurityHeader

 

 

      SecurityFlags

Byte

Bit 0: NetworkMessage Signed enabled

Bit 1: NetworkMessage Encryption enabled

Bit 2: SecurityFooter disabled

Bit 3: Force key reset disabled

Bit range 4-7: Reserved

      SecurityTokenId

IntegerId

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

      NonceLength

Byte

4

      MessageNonce

Byte[4]

A number used exactly once for a given security key.

 

C.3.7      Header layout for DataSetMessages

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

·      MessageSequenceNumber

·      Timestamp

·      Status

·      MinorVersion

Additional remarks:

·      Fields can use any encoding

·      All types of DataSetMessages (Data Key Frame, Data Delta Frame, Event, etc.) are supported

The DataSetMessage header layout is shown in Figure C.10

Figure C.10: UADP DataSetMessage header layout

Table C.11 shows the configuration for the DataSetMessage header.

Table C.11: UADP DataSetMessage header layout

Name

Type

Description

DataSetFlags1

Byte

Bit 0: Indicates whether this DataSetMessage is valid

Bit range 1-2: Field Encoding

      <anything>
Bit 3: DataSetMessageSequenceNumber enabled

Bit 4: Status enabled

Bit 5: ConfigurationVersionMajorVersion disabled

Bit 6: ConfigurationVersionMinorVersion enabled

Bit 7: DataSetFlags2 enabled

DataSetFlags2

Byte

Bit range 0-3: UADP DataSetMessage type

      <anything>

Bit 4: Timestamp enabled

Bit 5: PicoSeconds disabled (not included in the DataSetMessage header)

DataSetMessageSequenceNumber

UInt16

Defined by Table 82

Timestamp

UtcTime

Defined by Table 82

StatusCode

UInt16

Defined by Table 82

MinorVersion

VersionTime

Defined by Table 82

 

Table C.12 defines the values for the configuration parameters representing this layout.

Table C.12: Values for configuration parameters

Parameter

Value

UadpDataSetMessageContentMask

0x00000035

 

This value results of the following options:

Bit 0: Timestamp enabled

Bit 2: Status enabled

Bit 4: MinorVersion enabled

Bit 5: SequenceNumber enabled

 

DataSetFieldContentMask

<anything>

 

C.3.8      Examples

C.3.8.1        Dynamic message layout with different DataSetMessage types

Figure C.11 shows an example for a UADP NetworkMessage with dynamic layout. As defined in C.3.3 and C.3.7 only the layout of the NetworkMessage header and the DataSetMessage header is fixed. The number, the type, the length, and the order of DataSetMessages can vary from one NetworkMessage to the next.

Figure C.11: Example for dynamic message layout without security

OPC 10000-14, OPC Unified Architecture - Part 7: Profiles

The following PubSub conformance units are used for the Header Layouts in this Amendment.

 

 “PubSub Publisher UADP Periodic Fixed Settings” is used as Conformance Unit in the “Publisher UADP Periodic Fixed Layout Facet” (http://opcfoundation.org/UA-Profile/Publisher/UADP-Periodic-Fixed).

Category

Title

Description

Publisher

PubSub Publisher UADP Periodic Fixed Settings

Publisher supports encoding NetworkMessages and DataSetMessages with UADP Message headers for periodic data with fixed layout (http://opcfoundation.org/UA/PubSub-Layouts/UADP-Periodic-Fixed). If signing is supported, the layout variant for integrity shall be supported also. If encryption is supported, the layout variant for confidentiality and integrity shall be supported also.

 

 “PubSub Publisher UADP Dynamic Data or Events Settings” is used as Conformance Unit in the “Publisher UADP Dynamic Data or Events Facet” (http://opcfoundation.org/UA-Profile/Publisher/UADP-Dynamic).

Category

Title

Description

Publisher

PubSub Publisher UADP Dynamic Data or Events Settings

Publisher supports encoding NetworkMessages and DataSetMessages with UADP Message headers for Events and Data with dynamic layout (http://opcfoundation.org/UA/PubSub-Layouts/UADP-Dynamic). If signing is supported, the layout variant for integrity shall be supported also. If encryption is supported, the layout variant for confidentiality and integrity shall be supported also.

 

 “PubSub Subscriber UADP Periodic Fixed Settings” is used as Conformance Unit in the “Subscriber UADP Periodic Fixed Layout Facet” (http://opcfoundation.org/UA-Profile/Subscriber/UADP-Periodic-Fixed).

Category

Title

Description

Subscriber

PubSub Subscriber UADP Periodic Fixed Settings

Subscriber supports decoding NetworkMessages and DataSetMessages with UADP Message headers for periodic data with fixed layout (http://opcfoundation.org/UA/PubSub-Layouts/UADP-Periodic-Fixed). If signing is supported, the layout variant for integrity shall be supported also. If encryption is supported, the layout variant for confidentiality and integrity shall be supported also.

 

“PubSub Subscriber UADP Dynamic Data or Events Settings” is used as Conformance Unit in the “Subscriber UADP Dynamic Data or Events Facet” (http://opcfoundation.org/UA-Profile/Subscriber/UADP-Dynamic).

Category

Title

Description

Subscriber

PubSub Subscriber UADP Dynamic Data or Events Settings

Subscriber supports decoding NetworkMessages and DataSetMessages with UADP Message headers for Events and Data with dynamic layout (http://opcfoundation.org/UA/PubSub-Layouts/UADP-Dynamic). If signing is supported, the layout variant for integrity shall be supported also. If encryption is supported, the layout variant for confidentiality and integrity shall be supported also.

 

_________


 [RSA1]Spurious field at start of line.

 [RSA2]Spurious field at start of line.

 [RSA3]Extra field field at start of line.

 [RSA4]Extra figure field at start of line.