Editors Note: This Annex has limited implementation to validate the design. Subsequent implementations and interoperability testing may result in breaking changes in future versions of this Annex.

An aggregating Server or GDS, needs to be able to discover the Servers that support AliasNames. Furthermore, the aggregating Server or GDS needs to be able to detect if a Server that contains AliasNames has had updates to the AliasName definitions. An aggregating Server or GDS could Subscribe for the LastChange Variable on AliasNameCategoryType instances to detect when a value is changed, but for systems with a large number of Servers the ClientServer connection might be difficult to manage. This section describes an extension for determining that a Server has had updates to the AliasName definitions. This extension to a Server that supports AliasNames, provides a Publisher capability for the Server (see OPC 10000-14). This extension also provides a simple way to determine if a Server has stopped or started.

With this optional extension, the Server shall be configured to be a Publisher with a fixed DataSet message sent to a multicast address. The DataSet shall consist of a single instance that has a DataType of AliasUpdateDataType (see D.2.2 for details). This Structure contains the ApplicationUri, and an array of a AliasCategoryUpdateDataType that consist of AliasNameCategoryId and the LastChange Variable (see D.2.1 for details). The value shall be published only when there is a change, i.e. either the LastChange Variable is updated (new timestamp) or an AliasNameCategory is add or removed, resulting in a change in the size of the AliasNameCategory array.

This Publisher shall provide a fixed DataSet with a pre-defined DataSetClassId. This Publisher shall generate messages as defined in D.3. These messages are similar to a data key frame/ data delta frame type messages defined in OPC 10000-14. A data key frame message for the Publisher shall include an array with all AliasNameCatagory instances in the Server. A data delta frame message for the Publisher shall include an array with only AliasNameCatagory instances that have a changed LastChange timestamp. For Publisher configuration related information see D.1.3.

The DataSetClassId defined in OPC 10000-14 shall be used by all applications supporting this optional extension. Subscribers will create a subscription to the provided multicast address for the DataSetClassId. Subscribers can filter on the PublisherId to further restrict records to those from a subset of Servers publishing on the same multicast address.

A Subscriber when it is subscribed to the multicast address receives three types of messages, a data key frame message, a data delta frame message and a keep alive message. The following illustrates the process a Subscriber could follow including what each of the message types provides:

For a keep alive message, the following process could be followed: A keep alive message has no payload, it only has the network header, including a PublisherId. This message only indicates that the Publisher is still alive and publishing data. The Subscriber can update the status of the Server that is related to the PublisherId, indicating that it is still alive.

For a data key frame message, the following process could be followed: The Subscriber would have to compare the LastChange value for the first entry in the array to the time stored for the Server with the matching ApplicationUri for the Aliases AliasNameCategory. The first index in the array is always the Aliases AliasNameCategory. If this value is different, then some of the AliasNameCatagories had changes. The Subscriber would then iterate through the entire array of AliasNameCategoryUpdateDataType records and for any that have a LastChange value that does not match the cached value, the AliasNameCaregoryId is added to the list for processing. The following steps describe the processing:

First the Subscriber looks up the ApplicationId and connects to the appropriate Server (if it does not already have a connection).

For the AliasNameCategory NodeId(s) in the list:

The Subscriber would issue a Browse for the provided NodeIds of the AliasNameCategories. Note: The Browse could contain all NodeIds in the list.

The Subscriber compares the browse results, to the list it has from the Server. There could be new AliasNameCategories, new AliasName Nodes, there could also be deleted AliasName Nodes or AliasNameCategories. For new AliasName Nodes, a Browse of the AliasName node would be required. Any updates would be stored.

For a data delta frame message the following process could be followed: The Subscriber would add all of the AliasNameCategories that are returned in the message (only AliasNameCategories that have change would be returned) to a list for processing. Once the list of NodeId is obtained then the same processing as listed above for data key frame message would occur.

The aggregating Server or GDS can remove all AliasName Nodes and AliasNameCategories associated with a Server if no messages of any form are received from a Server for some configurable period of time.

It is important that an aggregating Server or GDS does not rely only on data delta frames, PubSub is not a guaranteed delivery system, so a data delta frame message could be missed, but data key frames would indicate the changes.

The published messages could also be used by an aggregating Server or GDS to detect a new Server that came on-line. If a published message includes an ApplicationUri that the Server did not have, it would indicate the message is from a new Server. The new Server could be added to the aggregating Server or GDS.

Figure D.1 – PubSub illustration

Note: it is important to understand that multicast address might require network setup, depending on the configuration of the network and type of switches/bridges use (see OPC 10000-14).

The setting for a PubSub AliasName Publisher are fixed as defined in D.2. Only the following items can be changed as part of configuring the Publisher.

See OPC 10000-14 for additional details on data key frames, data delta frame,PublishingIntervals and security settings.

• PublishingInterval that is defined for the published messages.
• The KeyFrameCount that is defined for the published messages. It is the multiplier of the PublishingInterval that defines the maximum number of times the PublishingInterval expires before a data key frame message is sent.
• The KeepAliveTime that is defined for the published messages. It is the rate at which an empty message is sent, if no data messages are published.
• The SecurityMode that is associated with the published messages. It is the type of security (None, Sign, SignAndEncrypt) assigned to the messages.
• The SecurityGroupId that is associated with the published messages. It is the unique identifier for a SecurityGroup within an SKS.
• The SecurityKeyServices that is associated with the published messages.
• The Address that is associated with the published messages. It defines a multi-cast address to which all publish messages shall be directed. This can be configured to allow subsets of Servers to direct the notification message to a specific GDS or aggregating Server.
• The Enabled that is associated with the PubSubConnection for the published messages. This flag can be used to enable the Servers AliasName PubSub Notifications feature.

A Server that supports this feature would typically have this feature pre-configured, allowing notification to begin on startup of the Server.

This structure is used to indicate that an AliasName category has an updated AliasName(s). Its elements are defined in Table D.1.

Table D.1 – AliasCategoryUpdateDataType DataType structure

Name	Type	Description
AliasCategoryUpdateDataType	Structure
Category	PortableNodeId	The NodeId of an AliasNameCategory.
LastChange	VersionTime	The value of the LastChange variable in the AliasNameCategory referenced by the Category NodeId.

Its representation in the AddressSpace is defined in Table D.2 .

Table D.2 – AliasCategoryUpdateDataType Definition

Attribute	Value
BrowseName	AliasCategoryUpdateDataType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the Structure defined in OPC 10000-5
Conformance Units
AliasName PubSub Notification

This structure is used to define a DataSet. This DataSet is used to indicate a Server has had changes to one or more AliasNameCategories, where an AliasName was added or deleted. Its fields are defined in Table D.3.

Table D.3 – AliasUpdateDataType DataType structure

Name	Type	Description
AliasUpdateDataType	Structure
ApplicationUri	String	The ApplicationInstance associated with the Server that has the AliasNames defined. (this is the Server that needs to be browsed for any updates).
Categories	AliasCategoryUpdateDataType[]	The array the AliasCategoryUpdates, it will contain entries for unique AliasNameCategories. The first element in the array always contains information for the well-known Aliases category Node.

Its representation in the AddressSpace is defined in Table D.4.

Table D.4 – AliasUpdateDataType Definition

Attribute	Value
BrowseName	AliasUpdateDataType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the Structure defined in OPC 10000-5
HasProperty	Variable	DataSetClassId	Guid	PropertyType
HasProperty	Variable	DataSetMetaData	DataSetMetaDataType	PropertyType
Conformance Units
AliasName PubSub Notification

This layout is specially configured for AliasName update messages. For additional detail on PubSub and header layouts see OPC 10000-14.

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

• Version / Flags
• ExtendedFlags1
• PublisherId
• DataSetClassId

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 D.2.

Figure D.2 – UADP NetworkMessage header layout

Table D.5 shows the configuration for the NetworkMessage header.

Table D.5 – 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 = 0 Bit 6: PayloadHeader enabled = 0 Bit 7: ExtendedFlags1 enabled = 1
ExtendedFlags1	Byte	Bit range 0-2: PublisherId Type 011 The PublisherId is of DataType UInt64 Bit 3: DataSetClassId enabled = 1 Bit 4: SecurityHeader enabled configurable (default=1) Bit 5: Timestamp enabled = 0 Bit 6: PicoSeconds enabled = 0 Bit 7: ExtendedFlags2 enabled = 0
PublisherId	UInt64	Configured value for the PubSubConnection. The datatype shall be UInt64.
DataSetClassId	Guid	The DataSetClassId associated with the DataSets in the NetworkMessage. All DataSetMessages in the NetworkMessage shall have the same DataSetClassId. – It shall be 65880051-7e5b-4a96-ae47-e0ef4704b924

UADP messages may be signed to ensure integrity. In this case a security header and a signature have to be added to the message.

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

Figure D.3 – UADP NetworkMessage header layout with integrity (signing)

Table D.6 shows the configuration for the NetworkMessage header with signing. The table contains only the added or modified rows from Table D.5.

Table D.6 – 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	The length of the Nonce used to initialize the encryption algorithm.
MessageNonce	Byte[NonceLength]	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:

• DataSetFlags1
• DataSetFlags2

Additional remarks:

• Field is encoded as a Variant
• The following types of DataSetMessages (Data Key Frame, Data Delta Frame, Keep Alive, etc.) are supported

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

Figure D.4 – UADP DataSetMessage header layout

Table D.7 shows the configuration for the DataSetMessage header.

Table D.7 – UADP DataSetMessage header layout

Name	Type	Description
DataSetFlags1	Byte	Bit 0: Indicates whether this DataSetMessage is valid Bit range 1-2: Field Encoding 00 - VariantBit 3: DataSetMessageSequenceNumber enabled = 1 Bit 4: Status enabled = 0 Bit 5: ConfigurationVersionMajorVersion enabled = 0 Bit 6: ConfigurationVersionMinorVersion enabled = 0 Bit 7: DataSetFlags2 enabled = 1
DataSetFlags2	Byte	Bit range 0-3: UADP DataSetMessage type Shall be 0000 for a Data Key Frame Shall be 0001 for a Data Delta Frame Shall be 0011 for a Keep Alive Bit 4: Timestamp enabled = 0 Bit 5: PicoSeconds enabled = 0 (not included in the DataSetMessage header)

For a description of Data KeyFrame, Data Delta Frames and Keep Alive see OPC 10000-14.

Bibliography

ANSI/ISA-S5.1-1984 (R 1992), Instrumentation Symbols and Identification

https://webstore.ansi.org/standards/isa/isa1984r1992

__________