How OPC UA Clients Discover Servers (Part 2) | Automation.com

How OPC UA Clients Discover Servers (Part 2)

December 152015
How OPC UA Clients Discover Servers (Part 2)

By John Rinaldi, Real Time Automation

ABSTRACT: What’s interesting about OPC UA Discovery is that there is a very flexible and sophisticated mechanism for Client devices to find and identify Server devices. The traditional mechanism for matching a Client (also called an Initiator or Master device) to a Server (or a Target or Slave device) is for the user to identify the Server to the Client during some sort of configuration process. These mechanism are effective for the kinds of factory floor applications we’ve used in the past. In fact, for low-level sensor/actuator networks, they would still be recommended. But OPC UA is designed to function equally well on the factory floor and the Enterprise, so what’s really interesting is how OPC UA created a more robust and flexible mechanism that works equally well on the factory floor with embedded devices as it does in the Enterprise with IT devices. This article is the second of two articles that explain that how OPC UA Device Discovery works.

This article is a continuation of the first article, "How OPC UA Clients Discover Servers (Part 1)."

OPC UA Discovery has a very flexible and sophisticated mechanism for Client devices to find and identify Server devices. But OPC UA is designed to function equally well on the factory floor and the Enterprise, so what’s really interesting is how OPC UA created a more robust and flexible mechanism that works equally well on the factory floor with embedded devices as it does in the Enterprise with IT devices. 

The Discovery process depends on the network architecture. It can be very simple one Client and one Server. It may have a standalone Local Discovery Server (LDS) or even a Global Discovery Server (GDS). The Discovery process is different for each of these network configurations.

DISCOVERY PROCESS – NO LDS SERVER

With no LDS Server on the network, the Client must know the local host name (typically the TCP/IP address) of the Server. The host name is obtained through some out-of-band mechanism like a web page, front panel or other mechanism.

The Client appends “UAdiscovery” to the local host name to form the Discovery endpoint. The Client may be configured to use a specific transport like OPC UA TCP or HTTPS. If not, it may progressively try contacting the server using different transports until it finds a Discovery endpoint that the server supports. The possible Discovery endpoints as of this writing include:

More transports may be defined in the future.

Once a Discovery endpoint is identified, the Client issues a Get Endpoints message to discover all the endpoints supported by the Server. Optionally, the Client can specify the endpoints that match some specific transports. For example, the Client my only be interested in HTTPS endpoints. The Server would return endpoint descriptions for each HTTPS endpoint supported by the server.[1] From the one or more endpoints returned by the Server, the Client selects the endpoint that best matches its requirements and begin the connection process by issuing an Open Secure request.

Figure 1- Discovery Process with No LDS Server

A Client may issue a Find Servers request on the Discovery endpoint of a non-LDS Server, but only the Application Description for the Server would be returned to the Client.

DISCOVERY PROCESS – WITH LDS SERVER

An LDS Server presents the same problem to the Client as the standalone Server. The Client has no sure way of finding the LDS Server. There are three ways a Client might find an LDS Server. One, get the specific address through some out-of-band mechanism like a web page, front panel or other mechanism. Two, use the hostname of a Server to see if that host is also supporting an LDS Server or three, and use its own hostname to see if there is an LDS Server active on the platform on which it’s running. 

Before the Client can request the list of Servers from a Local Discovery Server (LDS), Servers must register with it. Two services are available to the Server to accomplish this. First, the Server should use the Get Endpoints request to obtain the list of endpoints from the LDS. Once it chooses an endpoint with a compatible transport protocol and a sufficient security profile, it can send the Register Service request message.

The Server includes its application description in the Register Service request. The application description includes its name, its type, a product string, the list of Discovery endpoints it supports, and a short list of Server Capability Identifiers. Server Capability Identifiers are short strings that map to OPC UA features. The identifiers include strings like “LD“ (live data), “HD“ (historical data), “RED“ (redundancy) and “AC“ (alarms and conditions). These identifiers assist the Client in choosing a Server that meets its application requirements.

The Client requests the Server information and Server Capability Identifiers using the Find Servers service on the unsecured Discovery endpoint of the LDS. The response to the Find Servers request is a set of Application Descriptions. A Client can request application descriptions for a specific set of Servers in the Find Servers service request.

Once the Client has application descriptions for Servers, it next issues Get Endpoint requests to identify endpoints in those servers that meet its criteria. The Client can optionally request endpoints that meet one or more kinds of transports. The Server responds with endpoints for all its available transports, or only the transports that match the list of transports specified in the original request message.

If the Client finds an endpoint that meets its requirements for compatible transport, security policy and security mode, it can start the connection process by issuing an Open Secure Channel request.

Figure 2- Discovery Process with LDS Server

Discovery endpoints are unsecured endpoints in application Servers and Discovery Servers, and the security policies of some installations may prohibit unsecured connections. OPC UA Servers allow disabling the Discovery Endpoint of a Server in these installations. Some out-of-band configurations must configure the Client with the connection endpoint of the Server.

DISCOVERY PROCESS – WITH LDS-ME SERVER

A Discovery Server that supports the Multicast Extension (LDS-ME) is a Discovery Server that uses a multicast network to identify OPC UA Servers. From networking basics, you’ll remember that multicast networks using addresses in the range of 224.0.0.0 to 224.255.255.255 are networks where packets of information can be easily ignored if they are of no interest. If interested, a device can subscribe to the multicast network and receive those packets.

Discovery Servers with the multicast extension (LDS-ME) use the multicast network to both get information on Server devices and provide that information to interested Clients. The server capability indicators, the same endpoint descriptions and the same application descriptions from the last section, are used by LDS-ME Servers and Clients when communicating over a multicast network. Only the way LDS-ME Servers communicate with Clients and other Servers is different when using multicast Discovery Servers.

For Servers, the registration process to register with either an LDS or an LDS-ME is identical. A Server registers itself when it comes online or goes offline. The Server follows the same process to determine the address of the server as described in the previous section on LDS Servers without the multicast extension. The Server uses the same services to register with an LDS Server as with an LDS-ME Server.

For Clients, an extended version of the Find Servers service described earlier is available to work with the multicast network. Clients can use the same Find Servers service described earlier to get a list of Servers on the local network, or they can use the new “Find Servers On Network” to get the list of Servers that have registered with an LDS-ME on a multicast network.

Multicast DNS, or mDNS, is the multicast networking technology behind the LDS-ME Server implementation. mDNS provides the infrastructure for announcing the Servers on the network and communicating with remote Clients that want access to those Servers. There are many sources on the Internet to learn more about mDNS.

Unfortunately, mDNS is not considered a highly secure technology. Some installations prohibit it, but if you decide to use it with OPC UA, you should use the highest level of security offered by your OPC UA devices.

Like with LDS Servers, before the Client can request the list of Servers from a Local Discovery Server (LDS), Servers must register with it. Again, the Server should use the Get Endpoints request to obtain the list of endpoints from the LDS-ME Server. Once it chooses an endpoint with a compatible transport protocol and a sufficient security profile, it can send the Register Service request message with all the parameters described earlier.

Other than using the Find Servers on Network service, Clients use a process identical to the one used for local LDS Servers. The process for Server Registration and Client access is illustrated in Figure 3.

Figure 3- Discovery Process with LDS-ME Server

DISCOVERY PROCESS – WITH GLOBAL DISCOVERY SERVER

A Global Discovery Server (GDS) is a device that is radically different that the Discovery Servers described previously in this Chapter. A GDS is an OPC UA Server whose address space is a representation of OPC UA Servers. Instead of asking for Server information like a Client might do with a LDS, devices can browse the address space to learn about what Servers are on the network.

As of the time of this writing, few GDS Servers are in service, and those are more beta test units than they are practical, production units.

Reference

[1] There may be different security policies for each HTTPS endpoint. There might be an HTTPS endpoint with no security, since HTTPS provides a secure connection. Or there might be an HTTPS endpoint requiring signed messages and encryption. The Get Endpoints response returns all the endpoints that match the indicated transport.

About the Author

John Rinaldi is Chief Strategist, Business Development Manager and CEO of Real Time Automation (RTA) in Brookfield, WI. John is a recognized expert in industrial networks and the author of five books, three on Industrial Networking. The Industrial Ethernet Book focuses on explaining Industrial Ethernet concepts in a straightforward, clear fashion. The OPC UA: The Basics is an overview of this important technology. John’s latest book is on Modbus: the Most Pervasive Automation Protocol of the last 50 years of automation. You can get more of John’s opinions on automation, health, life, and sometimes, even love by subscribing to the RTA newsletter. Learn more by visiting http://www.rtaautomation.com/company/about-our-founder/ or Connect with him on LinkedIn: https://www.linkedin.com/in/johnsrinaldi or via email; http://www.rtaautomation.com/contact-us/

Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now
Back to top
Posted in:
Article
Related Portals:
OPC & OPC UA Interoperability

MORE ARTICLES

VIEW ALL

RELATED