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).