The discovery process allows applications to find other applications on the network and then discover how to connect to them. Note that this discussion builds on the discovery related concepts defined in OPC 10000-4. Discoverable applications are generally Servers, however, some Clients will support reverse connections as described in OPC 10000-6 and want Servers to be able to discover them.

Clients and Servers can be on the same host, on different hosts in the same subnet, or even on completely different locations in an administrative domain. The following clauses describe the different configurations and how discovery can be accomplished.

The mechanisms for Clients to discover Servers are specified in 4.3.

The mechanisms for Servers to make themselves discoverable are specified in 4.2.

The Discovery Services are specified in OPC 10000-4. They are implemented by individual Servers and by dedicated DiscoveryServers. The following dedicated DiscoveryServers provide a way for applications to discover registered OPC UA applications in different situations:

• A LocalDiscoveryServer (LDS) maintains discovery information for all applications that have registered with it, usually all applications available on the host that it runs on.
• A LocalDiscoveryServer with the MulticastExtension (LDS-ME) maintains discovery information for all applications that have been announced on the local MulticastSubnet.
• A GlobalDiscoveryServer (GDS) maintains discovery information for applications available in an administrative domain.

LDS and LDS-ME are specified in Clause 5. The GDS is specified in Clause 6.

The clause describes how an application registers itself so it can be discovered. Most Applications will want other applications to discover them. Applications that do not wish to be discovered openly should not register with a DiscoveryServer. In this case such Applications should only publish a DiscoveryUrl via some out-of-band mechanism to be discovered by specific Applications.

Applications register themselves with the LDS on the same host if they wish to be discovered. The registration ensures that the applications are visible for local discovery (see 4.3.3) and MulticastSubnet discovery if the LDS is a LDS-ME (see 4.3.4).

The OPC UA Standard (OPC 10000-4) defines a RegisterServer2 Service which provides additional registration information. All Applications and LocalDiscoveryServer shall support the RegisterServer2 Service and, for backwards compatibility, the older RegisterServer Service. If an Application encounters an older LDS that returns a Bad_ServiceUnsupported error when calling RegisterServer2 Service it shall try again with RegisterServer Service.

The RegisterServer2 Service allows the Application to specify zero or more ServerCapability Identifiers. CapabilityIdentifiers are short, string identifiers of well-known OPC UA features. Applications can use these identifiers as a filter during discovery.

The set of known CapabilityIdentifiers is specified in Annex D and is limited to features which are considered to be important enough to report before an application makes a connection. For example, support for the GDS information model or the Alarms information model are Server capabilities that have a ServerCapabilityIdentifier defined.

Before an application registers with the LDS it should call the GetEndpoints Service and choose the most secure endpoint supported by the LDS and then call RegisterServer2 or RegisterServer.

Registration with LDS or LDS-ME is illustrated in Figure 1.

Figure 1 – The Registration Process with an LDS

See OPC 10000-4 for more information on the re-registration timer and the IsOnline flag.

Dedicated systems (usually embedded systems) with exactly one Server installed may not have a separate LDS. Such Servers shall become their own LDS or LDS-ME by implementing FindServers and GetEndpoints Services at the well-known address for an LDS. They should also announce themselves on the MulticastSubnet with a basic MulticastExtension. This requires a small subset of an mDNS Responder (see mDNS and Annex C) that announces the Server and responds to mDNS probes. The Server may not provide the caching and address resolution implemented by a full mDNS Responder.

The discovery process allows Clients to find Servers on the network and then discover how to connect to them. Once a Client has this information it can save it and use it to connect directly to the Server again without going through the discovery process. Clients that cannot connect with the saved connection information should assume the Server configuration has changed and therefore repeat the discovery process.

A Client has several choices for finding Servers:

• Out-of-band discovery (i.e. entry into a GUI) of a DiscoveryUrl for a Server;
• Calling FindServers on the LDS installed on the Client host;
• Calling FindServers on a remote LDS, where the HostName for the remote host is manually entered;
• Calling FindServersOnNetwork (see OPC 10000-4) on the LDS-ME installed on Client host;
• Supporting the LDS-ME functionality locally in the Client.
• Searching for Servers known to a GlobalDiscoveryServer.

The DiscoveryUrl provides all of the information a Client needs to connect to a DiscoveryEndpoint (see 4.3.2).

Clients should be aware of rogue DiscoveryServers that might direct them to rogue Servers. That said, this problem is mitigated when a Client connects to a Server and verifies that it trusts the Server. In addition, the CreateSession Service returns parameters that allow Client to verify that the previously acquired results from a LDS have not been altered. See OPC 10000-2 and OPC 10000-4 for a detailed discussion of these issues.

A similar potential for a rogue GDS exists if the Client has not been configured to trust the GDS Certificate or if the Client does not use security when connecting to the GDS. Note that a Client that uses security but automatically trusts a GDS Certificate is not protected from a rogue GDS even though the connection itself is secure. This problem is also mitigated by verifying trust whenever a Client connects to a Server discovered via the GDS.

Every Server has one or more DiscoveryUrls that allow access to its Endpoints. Once a Client obtains (e.g. via manual entry into a form) the DiscoveryUrl for the Server, it reads the EndpointDescriptions using the GetEndpoints Service defined in OPC 10000-4.

The discovery process for this scenario is illustrated in Figure 2.

Figure 2 – The Simple Discovery Process

In many cases Clients do not know which Servers exist but possibly know which hosts might have Servers on them. In this situation the Client will look for the LocalDiscoveryServer on a host by constructing a DiscoveryUrl using the well-known addresses defined in OPC 10000-6.

If a Client finds a LocalDiscoveryServer then it will call the FindServers Service on the LDS to obtain a list of Servers and their DiscoveryUrls. The Client would then call the GetEndpoints service for one of the Servers returned. The discovery process for this scenario is illustrated in Figure 3.

Figure 3 – The Local Discovery Process

In some situations Clients will not know which hosts have Servers. In these situations the Client will look for a LocalDiscoveryServer with the MulticastExtension on its local host and requests a list of DiscoveryUrls for Servers and DiscoveryServers available on the MulticastSubnet.

The discovery process for this scenario is illustrated in Figure 4.

Figure 4 – The MulticastSubnet Discovery Process

In this scenario the Server uses the RegisterServer2 Service to tell a LocalDiscoveryServer to announce the Server on the MulticastSubnet. The Client will receive the DiscoveryUrl and CapabilityIdentifiers for the Server when it calls FindServersOnNetwork and then connects directly to the Server. When a Client calls FindServers it only receives the Servers running on the same host as the LDS.

Clients running on embedded systems may not have a LDS-ME available on the system, These Clients can support an mDNS Responder which understands how OPC UA concepts are mapped to mDNS messages and maintains the same table of servers as maintained by the LDS-ME. This mapping is described in Annex C.

A GDS is an OPC UA Server which allows Clients to search for Servers within the administrative domain of the GDS. It provides Methods that allow applications to search for other applications (See 6). To access the GDS, the Client uses the Call service to invoke the QueryApplications Method (see 6.6.11) to retrieve a list of Servers that meet the filter criteria provided. The QueryApplications Method is similar to the FindServers service except that it provides more advanced search and filter criteria. The discovery process is illustrated in Figure 5.

Figure 5 – The Global Discovery Process

The GDS may be coupled with any of the previous network architectures. For each MulticastSubnet, one or more LDSs may be registered with a GDS.

The Client can also be configured with the URL of the GDS using an out of band mechanism.

The complete discovery process is shown in Figure 6.

The use cases in the preceding clauses imply a number of choices that should be made by Clients when a Client needs to connect to a Server. These choices are combined together in Figure 6.

Figure 6 – The Discovery Process for Clients

FindServersOnNetwork can be called on the local LDS, however, It can also be called on a remote LDS which is part of a different MulticastSubnet.

An out-of-band mechanism is a way to find a URL or a HostName that is not described by this standard. For example, a user could manually enter a URL or use system specific APIs to browse the network neighbourhood.

A Client that goes through the discovery process can save the URL that was discovered. If the Client restarts later it can use that URL and bypass the discovery process. If reconnection fails the Client will have to go through the process again.

The discovery process for reverse connect does not serve the same purpose as the discovery process for normal connections because reverse connections require the Server to be configured to automatically attempt to connect to the Client and the Client to be configured so it knows what to do with the Server when it receives the connection. The limited mechanisms discussed here may help SecurityAdmins with the configuration of Servers.

A SecurityAdmin tasked with configuring Servers needs to determine the ClientUrls for Clients that support reverse connect.

The following choices are available:

• Out-of-band discovery (i.e. entry into a GUI) of a ClientUrl for a Client;
• Searching for Clients known to a GlobalDiscoveryServer.

The mechanisms based on an LDS are not available since Clients do not register with the LDS.

Every Client that supports reverse connect has one or more ClientUrls that allow Servers to connect. Once the SecurityAdmin acquires the ClientUrl via an out-of-band mechanism, it can configure the Server to use it.

A GDS is a Server which allows other SecurityAdmins to search for Clients that support reverse connnect within the administrative domain of the GDS. The SecurityAdmin uses the Call service to invoke the QueryApplications Method (see 6.6.11) with “RCP” as a serverCapabilityFilter to get a list of Clients that support reverse connect from the GDS.

The discovery process is illustrated in Figure 5.

Figure 7 – The Global Discovery Process for Reverse Connections

The ClientUrls are returned in the DiscoveryUrls parameter of the ApplicationDescription record and have the ‘rcp+’ prefix. DiscoveryUrls without the prefix are used for forward connections. Once the SecurityAdmin has a ClientUrl it can configure the Server to use it.