Everyone loves secrets. No one loves secrets more than my granddaughter. I had an empty box in my desk at home and she pestered me for an hour about what might be in that box. And I loved torturing her.

There aren’t a lot of secrets in Industrial Automation, but OPC UA Clients have so much functionality that some of it seems like ‘secrets.’ Today, I’m going to let you in on those secrets.

Let’s start by talking about what a Client is. In most industrial networking technologies, there is a controlling device, one that connects to and controls one or more end devices. In Profinet IO, for example, this device is known as an IO Controller and in EtherNet/IP it’s called a Scanner. No matter what it’s called, that device is configured by the user to open connections with one or more end devices, send outputs to that end device, receive inputs from that end device and, occasionally, send asynchronous command requests.

In OPC UA, a device of this type is known as an OPC UA Client. Like controlling devices in these other technologies, an OPC UA Client device sends message packets to Server devices and receives responses from its Server devices. But beyond this basic functionality, an OPC UA Client device is fundamentally more sophisticated than controllers in other technologies.

Extended Functionality Included in an OPC UA Client:

• Use of a Discovery process to find eligible Servers on the network.
• The capability to find available Servers in a standard way and identify the Server’s application type, application name, and set of hostnames it supports.
• The capability to message a Server on a special non-operational endpoint that exists to provide information like the security mode (signed or encrypted messages), the Server’s security policy, the transports it supports, and the Server’s Application Instance Certificate.
• Creation of authenticated connections with the Server using the security mode supported by the Server (or an unsecure connection if the Server doesn’t support security).
• Creation of secure and authorized logical communication sessions with Servers using the security mode supported by the server.
• Evaluation of the capability of the Server to perform required services for the Client application by inspecting the Server’s software certificate.
• Sending message requests to Servers requesting the execution of one or more of the service requests supported by the Server.
• Configuring the Server to notify the Client of alarm conditions, program outputs and data changes.

How OPC UA Clients Find OPC UA Servers
In most industrial and building technologies, you can’t search for Servers on the network. Normally, some “out-of-band” configuration occurs using a dedicated vendor -specific tool or a configuration web page. Unlike these technologies, OPC UA contains a built-in Discovery process where Clients can find and connect to Servers without user intervention. The Discovery process is field configurable by the user, as some installations may not want to expose their Servers, and other installations may want to restrict a Server to communications with specific Client devices.

Every Client has its own process for discovering servers, but there is a set of options that an OPC UA Client can use:

• Get the Server’s information directly from the Server. Get the hostname of the Server from the user at the installation using some out-of-band mechanism.
• Get Server information from a Local Discovery Server (LDS) on the same host as the Client
• Get Server information from LDS Servers on external hosts. The hostnames for these servers would be obtained from the user at the installation using some out-of-band mechanism.
• Get Server information from external LDS-ME (Multicast Extension) Servers. The hostnames for these servers would be obtained from the user at the installation using some out-of-band mechanism.
• Search the address space of a Global Discovery Server (GDS) for information on available Servers.

The primary OPC UA service for discovering Servers is the FIND SERVERS service. A FIND SERVERS request directed to a non-Discovery Server returns the application description of that Server.

How Clients Access Server Devices
Once a host has identified a Server of interest and has the Discovery Endpoint and product information, its next step is to identify what Transports and Security that device supports. To get that information, the Client issues the GET ENDPOINTS request. The response to that request is an array of structures called the Endpoint Description.

The Endpoint Description consists of the Application Description for the Server, the Server’s Application Instance Certificate, the Server’s Security Mode, and the Transport supported on each endpoint supported on the Server. The Client device examines all the endpoints available in the Server and selects the one best suited for its application.

How a Client Connects to a Server
Once an endpoint is chosen, the OPC UA Client must make three connections before it can begin to issue Service requests to a Server. First, the Client must make a connection to the Server using the Transport assigned to that endpoint. (Transport options are HTTPS, HTTP and UA TCP, but that list is going to expand as time goes on.)

Second, the Client must establish a secure communication path between itself and the Server device. This connection, a “channel” in OPC UA terms, is a long-running, secure, authenticated connection between the Client and the Server. The channel connection is a device-to-device communication path. The channel authenticates each side in that communication path, and exchanges the keys needed for secure communications between the Client and Server. The keys to encode and decode the secure messages are specific to the security profile implemented on the selected endpoint.

Once the channel is authorized, the final step is for the Client to establish a logical connection with the Server called a session. The session is a long-term, authorized connection between two applications. Sessions are not active until enabled by a Client request. Once enabled, a session can remain open even if the underlying secure channel is closed. In that case, another channel can be created to host that open session. In fact, the Client can access the session from any channel. Sessions typically have a lifetime, and the Client must renew a session before the “homeless” session’s lifetime expires and it is deleted.

Where the channel processing serves to authenticate the devices operating over the connection, sessions serve to authorize the Client application to access the Server application. Servers can reject channel requests or session requests for a whole host of reasons. Servers may have numerous reasons for rejecting these requests, but that approval or rejection is application-dependent and outside the scope of OPC UA.

Once both the channel and session are created, a Client device can begin to access the Address Space of the Server. The various ways a Client can access the Server’s Address Space is a subject for a future article… Stay tuned for further spilling of OPC UA Client secrets!

Learn more about OPC UA by reading the easiest book on OPC UA. Find out more at :

https://www.rtautomation.com/opc-ua-basics/.