GDS that supports AliasNames,provides AliasNames functionality, but the target Nodesreferenced are in other Servers.The AliasNames are aggregated from the Serversthat have registered with the GDS that expose the “Alias" capability (for information on capabilities see OPC 10000-12). Additional examples on aggregating AliasNamescan be found in the aggregating Serverexample - A.3. A GDS implementation also requires additional behaviour. This section describes automatic behaviour that is required by all implementations of a GDS that supports AliasNames.


Figure B-8– Example GDS aggregating AliasNames

The following sections describe this required behaviour:

The details of the expected behaviour of a GDS that supports AliasNamesis described in the following sections.

A GDS that includes support for AliasNamesshall automatically aggregate all instances of AliasNameTypethat are available in any Serverthat has registered with the GDS. If the same AliasNameis registered from different Servers, the GDS shall combine the AliasNamewithin its Aliasstructure. The GDS shall add the ServerURIof the registered Serverinto its ServerArrayProperty. It shall provide a single merged tree list for any of the well-known AliasNameCategoryType Objectsdefined in 9.3(i.e. TagVariablesor Topics). The organization of the actual structure of the AliasNameCategoryTypehierarchy is specific to the GDS vendor and/or the configuration of the GDS, but all AliasNameCategoryTypeinstances shall be aggregated into the GDS. This hierarchy allows for a single instance of the AliasNameTypeto appear in more than one location in the tree. Figure B-9illustrates the process a GDS that supports AliasNameswould follow.


Figure B-9– Server Registration Process

The GDS shall subscribe for ModelChangeEventsform the Server, to ensure that any changes to the AliasNameswould be reflected in the GDS. [note: not all Serverswill support ModelChangeEvents, but AliasName Aggregating Servershall support ModelChangeEvents]. When the GDS receives a ModelChangeEventit shall update as needed and generate a ModelChangeEvent for its Clients- in essence the original event is forwarded to listening Clients.

[Note: a GDS may encounter a large list of AliasNamesand it is important that an efficient storage of AliasNameis provided to allow for fast AliasNameresolution (FindAlias)]

The GDS should automatically remove any instances of AliasNameTypeand AliasNameCategoryTypethat are associated with an unregistered Server. [Note: the AliasNameinstance or AliasNameCategoryinstance might be from multiple Serversand should only be removed if all of the Serversthat referenced it have been removed.] The GDS shall remove any AliasFor Referencesthat point to the unregistered Server. The GDS shall delete the ServerURIof the unregistered Serverfrom the ServerArrayProperty. Figure B-10illustrate the unregister process in a GDS.


Figure B-10– Unregister Server Process

When a Clientthat uses aliased Nodesdetects a communication problem with the Server, the Clientcan return to the GDS and request a new AliasNodeListfor the AliasName. The original Servermay recover and again be listed in the GDS, but the Clientis not required to switch back. Figure B-11provides an overview of this process.


Figure B-11– Example Client Process for Server subscription with errors

It is important to remember that the FindAlias Methodwill return a list of NodeIds(and Servers) that meet the requested AliasNamesearch string. It is up to the Clientto determine if the NodeIdthat is returned is the same Serveror on a different Serveror if the next NodeIdshould be used instead of the first.


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