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.
The following sections describe this required behaviour:
- When a Serverregisters with the GDS, the GDS shall merge the AliasNamesof the registering Serverinto a master AliasNameslist on the GDS.
- Pull all AliasNameCategoryinstances, merge any that have identical BrowseNames.
- The GDS will provide the ExpandedNodeIdof all of the referenced NodeIdsand the ServerURIof the Servercontaining the NodeId.
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.
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.
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.
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.
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