A Global Discovery Server (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. An example of a GDS that supports AliasNames is illustrated in Figure B.1.
Figure B.1 – Example GDS aggregating AliasNames
The following sections describe this required behaviour:
- When a Server registers with the GDS, the GDS shall merge the AliasNames of the registering Server into a master AliasNames list on the GDS.
- Pull all AliasNameCategory instances, merge any that have identical Name part of the BrowseNames.
- The GDS will provide the ExpandedNodeId of all of the referenced NodeIds and the ServerUri of the Server containing the NodeId.
The details of the expected behaviour of a GDS that supports AliasNames is described inB.2, B.3 and B.4.
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.2 illustrates the process a GDS that supports AliasNames would follow.
Figure B.2 – Server Registration Process
[Note: a GDS could 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. However, the AliasName instance or AliasNameCategory instance could 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.3 illustrate the unregister process in a GDS.
Figure B.3 – 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 could recover and again be listed in the GDS, but the Client is not required to switch back. Figure B.4 provides an overview of this process.
Figure B.4 – 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
__________