OPC UA FX requires more than just a Server with an OPC UA FX Information Model. All devices that implement the ConnectionManager are required to support Client functionality. This clause will describe the requirements for this Client functionality. Some additional key points related to establishing a connection are:

1. The Connection and security information may have changed since the engineering tool generated configuration information (ConnectionConfigurationSets).
2. The ConnectionManager may be local on one of the devices, i.e., on the same device that has one end of a logical connection.
3. The configuration might contain Nodes in any of the following formats: PortableNodeId, PortableRelativePath or AliasName, each of which has components that might have changed since they were generated by the engineering tool.
4. System in which OPC UA FX is deployed may contain Global Services (GDS) that a ConnectionManager may be required to interact with.
5. During the establishment of a logical connection (Connection), the ConnectionManager needs to locate the FunctionalEntities and the Servers on which they reside. The ConnectionConfigurationSets contain the information from which this location can be derived.

The ConnectionManager shall behave as a standard Client, including the ability to recover an interrupted Session if a Session is being used. A ConnectionManager may also use Session- less Service invocations in certain cases. The ConnectionManager is required to be able to issue Method Calls and also resolve Node information. Resolving Node information may require using View Services (Browse, TranslateBrowsePathsToNodeIds) and Attribute Services (Read). The details related to an application’s configuration are provided in a Descriptor, but the engineering tool associated with a ConnectionManager may not be able to resolve Node information beyond what is in the Descriptor, which results in a ConnectionManager requiring support for all of the Node resolution options.

The Server is located following the standard procedure as defined in OPC 10000-12, i.e., FindServers, GetEndpoints, OpenSecureChannel, CreateSession and ActivateSession on the Server Address with the specified SecurityMode (see 9.2.2 for the description of the provided Server information).

Figure 63 – Client connection process

If Address contains a GDS Address, the GDS is queried to find the Server.

If the Server is the same Server that the ConnectionManager resides on, the EstablishConnections Method may be invoked by vendor-specific means, and all portable node identifiers can be resolved locally.

The Session established by the ConnectionManager shall support the use of authentication and/or encryption. This includes:

1. Application Authentication based on security mode and policy
2. The use of Roles (this may require user authentication or specific application certificates)

If SecurityPolicyUri contains “BestAvailable”, the EndpointDescription with the highest SecurityLevel of the ones supported by the Client and matching the requested SecurityMode (see 9.2.2) shall be chosen. Otherwise, the EndpointDescription matching the requested SecurityMode and SecurityPolicyUri (see 9.2.2) shall be chosen. The complete process, including NodeId resolution, is illustrated in Figure 63.

The Server can also be accessed via a Session- less Service invocation (illustrated in Figure 64). Session- less Service invocations still access the Server with security but create a one-time connection. This type of connection can only be used by ConnectionManager exchanges that do not require a saved state across multiple invocations. For example, it cannot be used for a ReserveCommunicationIdsCmd since the communication IDs are released when the Session ends.

Figure 64 – Session-less Service invocation

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 65 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 65 – Configuration resolution

A ConnectionManager will be required to be able to handle all of the possible manners to identify a Node. 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 caches the results of these operations and that they are only performed on 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 66 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.

Figure 66 – PortableNodeId client resolution

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

Figure 67 – PortableNodeId resolution sequence

If the ConnectionConfigurationSet contains PortableRelativePaths, then the Client 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 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 NodeId. 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.

Figure 68 – PortableRelativePath Client resolution

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

Figure 69 – PortableRelativePath resolution sequence

If the ConnectionConfigurationSet contains AliasNames (Figure 70 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 70 – AliasName Resolution

If an AliasName was used to obtain the Server information, the connection process might be slightly different (illustrated in Figure 71). 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 71 – Client connection process for AliasNames

If a logical connection is configured to use secure PubSub communication, then a Security Key Server is required. An SKS is described in detail in OPC 10000-14. The SKS may be located on any Server in the network, including the Server where the ConnectionManager is located. A ConnectionManager shall be able to communicate with the designated SKS in all cases which require Client connections to a remotely located SKS Server. The SKS process is illustrated in Figure 72.

Figure 72 – SKS Process

The ConnectionManager shall be able to configure the SKS for push distribution of security keys.