An aggregating Server as shown in Figure B.1 could also collect all of the AliasNames defined in underlying Servers and just build a composite list of these AliasNames. Since all of the AliasNames are required to exist under the mandatory Aliases Object, it is simple for an aggregating Server to browse the AddressSpace and build a list. The aggregating Server shall merge all AliasNames listed under the well-known AliasNameCategoryType instances. Some information models could define their own well-known AliasNameCategoryType Objects, which then also shall be merged. An aggregating Server could expose the same AliasName referencing multiple NodeIds. For example as shown in Figure B.1, if a temperature sensor were to be connected to two Servers for redundancy, the same AliasName TI101 could exist in both Servers. The aggregating Server simply reports two ExpandedNodeIds to any Client that requested TI101.

Figure B.1 – Aggregating AliasNames Server example

In the above example, if the Temperatures AliasNameCategoryType instance were defined locally in the Server and not defined in a standard namespace then two instances of the Temperatures AliasNameCategoryType will exist in the aggregating Server with different namespaces.

The GDS could include additional optional behaviour which this example illustrates. What is required is the availability of all AliasNames in the mandatory TagVariables folder and Topics folder, but a GDS could also choose to replicate or even merge the additional AliasNameCategoryType instances from the Servers that have registered. Figure B.2 provides an illustration of a GDS that merged the AliasNameCategory instance into a tree. A GDS shall aggregate AliasNameCategories, but the structure of these categories is not defined.

Figure B.2 – GDS with merged AliasNames example

For additional information about a GDS and AliasNames see Annex C.