Errata exists for this version of the document.

A number of examples are provided to help illustrate how AliasNames function. This includes a Client using an AliasName Server, inside of a Server, in an aggregating Server and in a GDS.

Figure A-3 illustrates how this model can be used inside of a Server. This sample includes multiple instances of AliasNameCategoryType. The figure illustrates that Objects might be referenced by more than one instance of AliasNameType.

Figure A-3 – AliasNames in a Server example

The figure describes an information model for a well. This model contains a number of other Objects, which have Variables that are to be available via a standardized naming scheme. The model also includes a configuration for a Pub/Sub dataset that provides the Variables defined in the well.

The AliasName model includes the standard organization items that are required in this document. In addition, the model also defines an extra organizational item for grouping the well information. The example illustrates AliasNames that are both TagVariables and Topics.

An aggregating Server would have much the same structure as the Server in the first example, with the exception that in the aggregating Server the target Nodes referenced by the AliasFor Reference might be in other Servers. Figure A-4 provides an illustration of an example aggregating Server. The Server might have a much more complex AddressSpace than provided in the example.

Figure A-4 - Aggregating AliasNames Server example

The aggregating Server has a choice in that it could just provide the link to the underlying Node (blue lines) or it might provide a link to the replicated Node in the aggregated Server’s AddressSpace (red lines)

The standalone AliasNames Server illustrated in Figure A-5 provides a list of AliasNames that reference Nodes in multiple separate Servers. This type of configuration might be used for Servers that do not have the resources to manage AliasNames on their own. It might also be used in a system where the configuration of AliasNames occurs after the devices that are represented by the Servers have already been deployed or if a Server just does not have support for AliasNames. The standalone AliasNames Server can function as a lookup Server for all of the AliasNames defined in the system. It is the responsibility of the standalone AliasNames Server to ensure that the mapping of AliasNames to actual Nodes is correct. The standalone AliasNames Server might have a subscription to each Server monitoring the status of the Server and monitoring for ModelChangeEvents that occur on the source Servers.

Figure A-5 - AliasNames Server example

An aggregating Server may 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 a Server to browse the AddressSpace and build a list. The aggregating Server would be required to merge all AliasNames listed under the well-known Objects. Some information models might define their own well known AliasCategoryType Objects, which would then also need to be merged. An aggregating Server may easily have the same AliasNames with multiple NodeIds. For example, if a temperature sensor were to be connected to two Servers for redundancy, the same AliasName TI101 might exist in both Servers. The aggregating Server would simple report two ExpandedNodeIds to any Client that requested TI101.

Figure A-6 - Aggregating Server example 2

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 may include additional optional behaviour which this example illustrates. What is required is the availability of all AliasNames in the mandatory TagVariables and Topics folder, but a GDS may also choose to replicate or even merge the additional AliasNameCategoryType instances from the Servers that have registered. Figure 1 provides an illustration of a GDS that merged the AliasNameCategory instance into a tree. It is required that AliasNameCategories be aggregated by the GDS, but the structure of these categories is not defined.

Figure A-7 - GDS with merged AliasNames example

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

AliasNames allow a Client to find TagVariables or Topics easily. Many industrial systems assign tags to specific measurement or sensors. These tags follow established nomenclatures. An example might be TI101, which would be a temperature indicator at a specific location in a plant. The example nomenclature is defined in ANSI/ISA-S5.1-1984 (R 1992), but this specification does not provide or even suggest any nomenclature. A Client could be configured to display or use the information provided by the sensor TI101, but the actual address/location of this sensor might not be known when the Client is configured. AliasNames can be used to resolve this tag to the actual sensor in the system.

The Client, on start-up or when it needs to access the tag, would call FindAlias on a local Server, aggregating Server or GDS depending on how a system is configured. A Client might select which AliasName source to call via a configuration setting. The FindAlias Method call would return a list of all ExpandedNodeIds that the AliasName References. It is important to note that there might be more than one Node referenced by an AliasName and that the Client must be prepared for this. The first Node in the list of referenced Nodes returned by FindAlias Method is the Node that the Server feels is the best match for the requested tag. The returned list might also return more than one instance of AliasNameType and each could have their own list of referenced Nodes. If the Method call was on a GDS or aggregating Server, the Client would need to read the ServerArray to resolve which Server the ExpandedNodeId was referencing. This would be the last piece of information that a Client would need to be able to follow a normal connection pattern to obtain values from the Node.

AliasName might also be configured to provide other information, such as Pub/Sub information, but again it would only be the information that is needed to initially subscribe to an item.