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.