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

How OPC UA Clients Discover Servers (Part 1)

December 022015
How OPC UA Clients Discover Servers (Part 1)

By John Rinaldi, Real Time Automation

The traditional mechanism for matching Client (or Master/Initiator) up with Server (or Slave/Target) is for the user to manually identify the Server to the Client. In a closed system, the Server address on the network is well-known and never varies. The identification is hard coded in the Clients software. In other, more generic systems, there is a front panel, web page or message set that a user or installer can use to identify the Slave to the Client.

These mechanisms 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 work equally well on the factory floor and the Enterprise, so a more robust and flexible mechanism is required.

To play well with Enterprise and Internet type applications, OPC UA had to comply with the rules of the game in the IT world. And though there are a lot of standards, you can categorize how many enterprise applications communicate under the title of SOA – Service Oriented Architecture.

SOA is a communication architecture in which applications provide services to each other. It says nothing about transports, encodings, what protocols are offered or anything else. SOA just means that Server devices provide services that they can perform for Clients. Client devices connect (if allowed), use one or more of the services for some period of time, and then disconnect. Clients connect when they need the service and disconnect when they don’t. SOA provides a much more loosely-coupled architecture than the always-connected Industrial Automation technologies like DeviceNet, EtherNet/IP, Profibus or ProfiNet IO.

OPC UA is designed on the SOA model. One of the interesting features of the OPC UA implementation of SOA is that there is a sophisticated mechanism for Clients to discover Server devices, interrogate them to see what services they offer, and connect to them. The implementation is designed for all sorts of network architectures from the simplest local network with one Client and one Server to the largest device network with thousands of devices connected over the Internet.

OPC UA endpoints

A key term we need to know in connection with the OPC UA Discovery process that many of us in Industrial Automation may not really be familiar with is “endpoint.” Endpoints are commonly used in IT applications, but it’s not a term that we regularly use with our EtherNet/IP, ProfiNet IO and Modbus TCP applications.

An endpoint is nothing more than an access point into a device with a specific set of capabilities. In most Industrial Automation devices, there is just a single entry point, something like 192.168.0.100. All device services are provided at that same address.

OPC UA Server devices USUALLY support a minimum of two endpoints: one endpoint to support the Discovery Services described in this chapter and another endpoint to support server operation with a specific transport, encoding and security profile. Any number of endpoints may be supported to support all the combinations of transports, encodings, and security profile supported by the Server.

Figure 1- OPC UA Server With Three Endpoints

Figure 1 is an example of an OPC UA device with three endpoints. In this example, there are two different TCP/IP addresses used. The device exists on both an IT network and an embedded network The Discovery and IT endpoints use the same NIC (Network Interface card) and have the same address. The embedded interface uses the NIC and TCP/IP address for the manufacturing network. Note that in this example, the embedded endpoint does not use the standard 4840 OPC UA port. OPC UA devices are not required to use Port 4840.

Discovery Security

The Discovery endpoint provides the Discovery services. Like all Discovery endpoints, it is unsecure. The security policies of some installations may prohibit unsecured connections, so OPC UA Servers allow disabling the Discovery endpoint. When disabled, an out-of-band configuration must configure the Client with the connection endpoint of the Server.

Server Types

Unlike other service sets in OPC UA, Discovery services aren’t always provided by the server. In some applications, servers can be used that only exist to provide clients with Discovery information. In smaller applications, each server is going to provide its own Discovery services over a Discovery endpoint. There are “well-known” endpoints (Table 1) for each type of transport, so a Client knows where to get the Discovery information.

TRANSPORT

WELL KNOWN ENDPOINT

HTTP

http://localhost/UADiscovery

OPC UA TCP

opc.tcp://localhost:4840/UADiscovery

HTTPS

https://localhost:4843/UADiscovery

 

Table 1- Well Known Discovery endpoints

It’s possible for several servers to be located on the same platform or within the same local network. In that case, a specialized server, called a Local Discovery Server (LDS), exists only to provide Discovery services. The LDS can be located on the same host with a Client or with a Server or at a separate TCP/IP address.

Once a Server registers itself with an LDS Server, it turns over handling of Discovery messages to the LDS. Client devices can then access the LDS Server and get the list of Servers registered with it.

Servers send identifying information to the LDS Server in the register service message. That information includes the Server name, Server type, a product description string, the list of Discovery endpoints supported by the server, and a short list of Server capabilities.

The same Server registration is used with either standard LDS Servers or LDS Servers that use a multicast network. LDS Servers that operate on a multicast network are called LDS-ME Servers. These servers use Multicast DNS, or mDNS, as the networking technology. That’s the same technology used on many home networks to support network printers.

In very large systems, there are Servers that can track the location of servers across an entire network, plant or corporate facility. These specialized Servers are known as Global Discovery Servers (GDS). A GDS differs from an LDS in that the address space of the GDS is designed to catalog a group of Servers. A Client can search the address space of the GDS to learn about Servers in the network.

Discovery Service Messages

There are three very important services provided in the OPC UA Discovery Service set. The GET ENDPOINTS Service is directed to the Discovery endpoint of a Discovery Server (an LDS or GDS) or a standard Server (transport[1]//hostname:4840/UAdiscovery). The Get Endpoints service provides the requesting device with the endpoints supported by a Server. A Client uses the Get Endpoints service with a standard Server to identify the endpoint that best matches its application requirements. A Server uses the Get Endpoints service to identify the best endpoint of an LDS to use for a Register Service request.

The REGISTER SERVER Service is directed to the registration endpoint of a Local Discovery Server (transport//hostname:4840/someendpointname). An LDS always provides at least one endpoint that supports the Registration Service. The Register Service Request Message is how a standard Server makes itself known to a Local Discovery Server.

The FIND SERVERS Service is directed to the Discovery endpoint of a Local Discovery Server (transport//hostname:4840/UAdiscovery). The Find Servers Request Message is the service a Client uses to obtain the list of application servers that have registered with the Discovery Server (LDS). The Servers can be limited to specific Servers specified in the request or all Servers registered with the LDS.

The Find Servers service returns an Application Description for each Server. The Application Description contains a product URI, the application name, the application type and the discovery endpoints in that Server. A Find Servers request to a non-LDS Server returns the single application description for that server.

The Find Servers request can also be sent to the Discovery endpoint of a non-LDS Server. The application Server returns its application description in the response message.

Discovery Security

Because Discovery endpoints support limited functionality, no security is required. Any Client can request information on the endpoints supported by the Server.

One of the risks in the Discovery process is that Clients may access a Discovery Server provided by some malicious entity and access a rogue Server. This can be mitigated by using Discovery services with a secure transport like HTTPS (TLS/SSL). It can also be mitigated by validating the Server Certificate and ensuring that the Server contains a Server Certificate from a trusted source.

Another risk is a rogue Server registering with an LDS and being found by a Client who initiates a communication session. Clients can mitigate this by validating the Server Certificate and ensuring that the Server contains a Server Certificate from a trusted source.

Another risk is using Multicast DNS (mDNS). Multicast DNS applications are, by their nature, insecure. Critical applications should either not use Multicast DNS Discovery Services or use OPC UA Security and certificate trust lists to control access.

Part two of this article provides descriptions of several common OPC UA network architectures and how Discovery Services work in each of those architectures.

Click here to read Part 2.

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/



[1] Transport refers to one of the supported transports. Three are supported at this time: OPCUA TCP, HTTP and HTTPS.
Back to top
Posted in:
Article
Related Portals:
OPC & OPC UA Interoperability

MORE ARTICLES

VIEW ALL

RELATED