Annex A Examples (Informative)
A.1 Overview
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.
A.2 AliasNames used within a single Server
Figure A.1 illustrates how this model can be used inside of a Server. This sample includes multiple instances of AliasNameCategoryType. The figure illustrates that Objects could be referenced by more than one instance of AliasNameType.
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 PubSub DataSet (see OPC 10000-14) 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.
A.3 AliasNames in an aggregating Server
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 could be in other Servers. Figure A.2 provides an illustration of an example aggregating Server. The Server could have a much more complex AddressSpace than provided in the example.
The aggregating Server has a choice in that it could just provide the link to the underlying Node (blue lines) or it could provide a link to the replicated Node in the aggregated Server’s AddressSpace (red lines).
A.4 Standalone AliasNames Server
The standalone AliasNames Server illustrated in Figure A.3 provides a list of AliasNames that reference Nodes in multiple separate Servers. This type of configuration could be used for Servers that do not have the resources to manage AliasNames on their own. It could 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.
A.5 Client use of an AliasName Server
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 tag is TI101, which is 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 is often not 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 wants to access the tag, would call FindAlias on a local Server, aggregating Server or GDS depending on how a system is configured. A Client could select which AliasName source to call via a configuration setting. The FindAlias Method call returns a list of all ExpandedNodeIds that the AliasName has a Reference to. It is important to note that there could 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 the FindAlias Method is the Node that the Server feels is the best match for the requested tag. The returned list could 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 reads the ServerArray to resolve which Server the ExpandedNodeId was referencing. This is the last piece of information that a Client requires to be able to follow a normal connection pattern to obtain values from the Node.
AliasName could also be configured to provide other information, such as PubSub information, but again it is only the information that is required to initially subscribe to or configure an item.