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.