For the discovery of assets, this specification uses the concept of AliasNames, as defined in OPC 10000-17. AliasNames define an additional name for any Node of a Server and can be used to categorize AliasNames and provide filter functionality on the AliasNames. The same AliasName can be represented by several Nodes, for example, if managed in different Servers. Using AliasNames simplifies managing information from various Servers, where some Servers potentially are not aware of AliasNames. AliasNames defines a concept how to integrate AliasNames into a Global Discovery Server (GDS). AliasNames already define the usage of NodeVersion and ModelChangeEvents to get notification on changes, which is used in this specification as well.
Unlike other usages of AliasNames, in this specification the purpose is not to define additional names for a Node / asset, but use the provided information of the assets.
That is, this specification defines two standardized categories for AliasNames, one using the mandatory 2:ProductInstanceUri as AliasName, and another one using the writable 2:AssetId, which can be set by the user.
In Figure 7, an example of the usage of AliasNames is given, to discover assets in a Server. This specification defines the standardized Nodes Assets, AssetsByProductInstanceUri and AssetsByAssetId (see 8.2). In order to discover the assets, a Client would either browse AssetsByProductInstanceUri or AssetsByAssetId to receive the AliasNames representing the assets, and from there with another browse access the Nodes representing the assets. Or it would call the Method 0:FindAlias on one of the Objects, allowing potentially to filter for the 2:ProductInstanceUri or the 2:AssetId. To get notified if assets have been added or removed, the Client subscribes to the 0:NodeVersion Property or subscribes to ModelChangeEvents.
As shown in the example in Figure 7, the Server manages three assets, X:Asset0, X:Asset1 and X:Asset2, somehow arranged in the vendor-specific hierarchy of the Servers AddressSpace. For all three assets, an AliasName Object for the 2:ProductInstanceUri exists. As X:Asset0 does not support the 2:AssetId, AliasName Objects for the 2:AssetId only exist for X:Asset1 and X:Asset2. Each AliasName is based on the identification information of the asset.
Note that a Server might not provide both entry points, depending on the supported ConformanceUnits.
Note that an AliasName could point to several Nodes representing the same asset (not shown in the example). The returned structure of 0:FindAlias allows to return several Nodes for one AliasName (see OPC 10000-17).
Note that the concept also allows for Off-Server References, for the 0:AliasFor References as well as for the 0:FindAlias Method (not shown in the example).
Figure 7 – Example of Discovery of Assets