The Method Calls to establish a Connection require information from the ConnectionConfigurationSets and their components. That information may be represented as PortableNodeId, PortableRelativePath or AliasName. These all need to be resolved to NodeIds (illustrated in Figure 67 and described in Clause 13.3.2, 13.3.3, and 13.3.4). This clause contains figures and text that provide examples to help explain these concepts.

Figure 67 – Configuration resolution

A ConnectionManager shall be able to resolve NodeIds using PortableNodeIds, PortableRelativePaths and AliasNames. The following provides an illustration of what needs to be done for each possible Node description in the ConnectionConfigurationSet. It is recommended that the ConnectionManager cache the results of these operations and that they are only performed on the initial start-up of the ConnectionManager or when a new configuration is provided to the ConnectionManager. This operation can also be repeated if changes in the model in a connected Server are detected or if an error occurs.

If the ConnectionConfigurationSets contain PortableNodeIds, then the ConnectionManager should perform the following steps (Figure 68 provides an overview of the configuration and actions):

1. Resolve the location of the Server and connect to it. This process is required for several of the node configuration options and is described in its own clause (see 13.2).
2. Convert the PortableNodeIds into NodeIds. This is accomplished by connecting to the Server, reading the NamespaceArray from the Server, and matching all NamespaceUri from the NamespaceArray to the URI’s store in the PortableNodeId and storing the Index of the URI in the table as the cached NodeId.
3. The cache shall also include the NamespaceArray of the target Server. This array can be checked before establishing a Connection to ensure it has not changed.
4. Repeat for all Servers.

When resolving NamespaceUri, if a Null or empty NamespaceUri is encountered, the Server shall assume that it is a reference to NamespaceArray index 1. NamespaceArray index 1 is the local Server namespace, and the URI corresponding to the Server might not be known at configuration time. For additional details on Namespaces, see OPC 10000-3.

Figure 68 – PortableNodeId client resolution

The process is illustrated in the sequence diagram shown in Figure 69.

Figure 69 – PortableNodeId resolution sequence

If the ConnectionConfigurationSet contains PortableRelativePaths, then the Client should perform the following steps (Figure 70 provides an overview of the configuration and actions):

1. Resolve the location of the Server and connect to it. This process is required for several of the node configuration options and is described in its own clause (see 13.2).
2. Convert PortableRelativePaths to BrowsePaths. This is accomplished by connecting to the Server, reading the NamespaceArray from the Server, and matching all NamespaceUri from the NamespaceArray to the URI’s store in the PortableRelativePaths. PortableRelativePathElements and storing the Index of the URI in the table in the temporary BrowsePath. This will convert the PortableRelativePath to a BrowsePath.
3. Call the TranslateBrowsePathsToNodeIds Service with all of the BrowsePaths that are to be converted to NodeIds. Cache the resulting list of NodeIds.
4. The cache shall also include the NamespaceArray of the target Server. This array can be checked before establishing a Connection to ensure it has not changed. Additionally, the NamespaceMetadata (NamespacePublicationDate) shall be cached. This data can be used to check if the namespace has been updated. If the Namespace has been updated, the process for resolving BrowsePaths shall be repeated.
5. Repeat for all Servers.

When resolving NamespaceUri, if a Null or empty NamespaceUri is encountered, the Server shall assume that it is a reference to NamespaceArray index 1. NamespaceArray index 1 is the local Server namespace, and the URI corresponding to the Server might not be known at configuration time. For additional details on Namespaces, see OPC 10000-3.

Figure 70 – PortableRelativePath Client resolution

The process is illustrated in the sequence diagram shown in Figure 71.

The resolution of BrowsePaths to NodeIds can result in multiple NodesIds for a single BrowsePath. Configurations should try to produce unique BrowsePaths (see 6.4.4, 6.4.5 and 6.4.6 for recommendations). Clients shall be able to handle this condition by reporting an error.

Figure 71 – PortableRelativePath resolution sequence

If the ConnectionConfigurationSet contains AliasNames (Figure 72 provides an overview of the configuration), then the Client should perform the following steps:

1. Connect to the well-known GDS (or aggregating Server). This is typically preconfigured in all Servers since the GDS also provides other functionality, such as certificate management or discovery.
2. Call FindAlias with the provided AliasName(s), which will return the target Server and the NodeId.

A single Call to the GDS or AliasName Server can resolve all AliasNames in all records in the ConnectionConfigurationSet. The returned list of Servers (Connection information) and NodeIds should be cached.

Figure 72 – AliasName Resolution

If an AliasName was used to obtain the Server information, the connection process might be slightly different (illustrated in Figure 73). The AliasName Server provides the information required to connect to the Server. Once connected, the EstablishConnections Call may be issued without any additional resolution step, assuming all nodes were defined using AliasNames and resolved on an initial step.

Figure 73 – Client connection process for AliasNames