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 is visible for local discovery (see 4.3.4) and MulticastSubnet discovery if the LDS is a LDS-ME (see 4.3.5).

The OPC UA Standard (OPC 10000-4) defines a RegisterServer2 Service which provides additional registration information. All Applications and LocalDiscoveryServer the 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. ServerCapabilityIdentifiers are short, string identifiers of well-known OPC UA features. Applications can use these identifiers as a filter during discovery.

The set of known ServerCapabilityIdentifiers 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.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.