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