The Secrets of OPC UA Clients

Everyone loves secrets. No one loves secrets more than kids. The other day my granddaughter pestered me for an hour about the contents of an empty box in my desk. (I admit, I loved torturing her.) But just like I broke down and gave up the secret, I’m going to share here some insider scoop on OPC UA client functionality that may be ‘secrets’ to you.

In most industrial networking technologies, there is a controlling device: a device that connects to and controls one or more end devices. In Profinet IO, this device is known as an IO-Controller. In Modbus TCP, it is a Client. In EtherNet/IP, it’s called a Scanner, and a Master in DeviceNet and Modbus RTU. No matter what it is 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. The extended functionality of OPC UA Clients includes:

1.Client devices can read a Server’s Profile and know the service set supported by the Server. The OPC UA Profile definitions include the set of supported services. Nano Profile Servers support the smallest set of services. Standard Profile Servers support the most.

2.The Subscription Service Set and the Attribute Service Set (Read/Write) are the primary services that OPC UA Clients use to interact with the Address Space on an OPC UA Server. The Subscription Service set provides the services that Clients use to request subscriptions to monitored items which the Server publishes on the schedule requested by the Client.

3.Clients can find OPC UA Server devices in multiple ways. Clients can find Servers using traditional configuration, by using a Local Discovery Server, by using a Local Discovery Server with a Multicast Extension, or by using a Global Discovery Server. Discovery servers catalog the application descriptions of servers and clients use those application descriptions to identify servers that match their application requirements.

4.A Client that is given the location of an unidentified Server can obtain the list of available endpoints by issuing a GET ENDPOINTS service request. The response to the GET ENDPOINTS request is an array Endpoint Description structures that consists of:

a.The Application Description for the Server.

b.The Server’s X509 Application Instance Certificate. This is the Certificate received from a CA (Certification Authority) that authenticates the Server’s application.

c.The Server’s Security Mode – one of “all messages must be signed,” “all messages must be signed and encrypted,” or “messages are not signed or encrypted”.

d.The Transport supported on that endpoint; one of HTTPS, HTTP, UATCP, or some other supported transport.

5.Clients begin the process of accessing an OPC UA Server by creating a Channel, a long-term connection between it and an OPC UA Server. Channels are authenticated connections between two devices.

6.Once the Channel is established, Clients create Sessions, long-term, logical connections between OPC UA Applications. A Session is the authorized connection between the Client’s application and the Server’s Address Space.

7.Clients can subscribe to data value changes, alarm conditions, and any results from programs executed by Servers. Servers publish notifications back to the Client when those items are triggered.

8.Clients invoke Methods, which are small program segments. Programs can return results to the Client in the Method call or in a Notification if the Client subscribes to it.

For more information, you should visit the OPC UA Overview Page or get the non-technical short overview of OPC UA technology.

John