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.3).

Clients should be aware of rogue DiscoveryServers that might direct them to rogue Servers. Clients can use the SSL/TLS server certificate (if available) to verify that the DiscoveryServer is a server that they trust and/or ensure that they trust any Server provided by the DiscoveryServer. See OPC 10000-2 for a detailed discussion of these issues.

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 ServerCapabilityIdentifiers 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 in the administrative domain. It may also provide Certificate Services (see Clause 7). It provides Methods that allow applications to search for other applications (See Clause 6). To access the GDS, the Client will create a Session with the GDS and use the Call service to invoke the QueryApplications Method (see 6.3.11). The QueryServers 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 have to 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.