Errata exists for this version of the document.

GDS that supports AliasNames, provides AliasNames functionality, but the target Nodes referenced are in other Servers. The AliasNames are aggregated from the Servers that have registered with the GDS that expose the “Alias" capability (for information on capabilities see OPC 10000-12). Additional examples on aggregating AliasNames can be found in the aggregating Server example - 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.

image011.png

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 AliasNames is described in the following sections.

A GDS that includes support for AliasNames shall automatically aggregate all instances of AliasNameType that are available in any Server that has registered with the GDS. If the same AliasName is registered from different Servers, the GDS shall combine the AliasName within its Alias structure. The GDS shall add the ServerURI of the registered Server into its ServerArray Property. It shall provide a single merged tree list for any of the well-known AliasNameCategoryType Objects defined in 9.3 (i.e. TagVariables or Topics). The organization of the actual structure of the AliasNameCategoryType hierarchy is specific to the GDS vendor and/or the configuration of the GDS, but all AliasNameCategoryType instances shall be aggregated into the GDS. This hierarchy allows for a single instance of the AliasNameType to appear in more than one location in the tree. Figure B-9 illustrates the process a GDS that supports AliasNames would follow.

image012.png

Figure B-9 - Server Registration Process

The GDS shall subscribe for ModelChangeEvents form the Server, to ensure that any changes to the AliasNames would be reflected in the GDS. [note: not all Servers will support ModelChangeEvents, but AliasName Aggregating Server shall support ModelChangeEvents]. When the GDS receives a ModelChangeEvent it 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 AliasNames and it is important that an efficient storage of AliasName is provided to allow for fast AliasName resolution (FindAlias)]

The GDS should automatically remove any instances of AliasNameType and AliasNameCategoryType that are associated with an unregistered Server. [Note: the AliasName instance or AliasNameCategory instance might be from multiple Servers and should only be removed if all of the Servers that referenced it have been removed.] The GDS shall remove any AliasFor References that point to the unregistered Server. The GDS shall delete the ServerURI of the unregistered Server from the ServerArray Property. Figure B-10 illustrate the unregister process in a GDS.

image013.png

Figure B-10 - Unregister Server Process

When a Client that uses aliased Nodes detects a communication problem with the Server, the Client can return to the GDS and request a new AliasNodeList for the AliasName. The original Server may recover and again be listed in the GDS, but the Client is not required to switch back. Figure B-11 provides an overview of this process.

image014.png

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

It is important to remember that the FindAlias Method will return a list of NodeIds (and Servers) that meet the requested AliasName search string. It is up to the Client to determine if the NodeId that is returned is the same Server or on a different Server or if the next NodeId should be used instead of the first.

Bibliography

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

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

__________