OPC UA Client vs. Server

Cultures clash all the time creating all sorts of confusion. I’m Italian, and Italians are a very emotional and physical people. We gesture. We touch. We kiss. We hug. As a young person, it was very disrespectful to not hug and kiss everyone when you arrived at someone’s home. Generally, you showed respect to an elder by a kiss on each cheek or at least the pretense of a kiss on each cheek (I’ll admit that I’ve kissed a lot of older men that way). Growing up in that environment led to some embarrassing moments when I met some non-Italian and tried to kiss them hello, “the Italian way.”

Words create confusion, too. How many people really use the words affect and effect properly? There’s also flaunt and flout, pored and poured, adverse and averse, all together and altogether and hundreds more like them. You can check out the Oxford Dictionary list of confusing words if you’re looking for a silly way to waste an hour.

In technology, the confusion is usually from technical words that reference some arcane piece of technology unfamiliar to us. Computer security people have some really impressive words like Public Key Encryption and Asymetric Security. EtherNet/IP has terms that aren’t as impressive but still not always well understood: Requested Packet Interval; Implicit Messaging; scanner; and adapter to name just a few. Even Modbus uses the term ‘coil,’ which was well-understood by manufacturing professionals 30 years ago but much less so today I’d expect. What percentage of manufacturing professionals actually know what a coil refers to today?

OPC UA clients and servers have now joined in this confusion. I’ve heard from a number of people with IT backgrounds asking about OPC UA clients and servers, what they are and how to use them? There seems to be a lot of confusion as to when a device would be a client and when it would be a server. This is especially a problem for our friends in IT. In the IT world, a server is the computer with the files on it. Client devices connect to it and use the data in applications. In that environment, there is one server and lots of clients.

That’s not the case in the automation world. In the automation world, servers are end-point devices. In networks like EtherNet/IP and PROFINET IO, there is one client and lots of servers, the opposite of IT. The PROFINET IO controller or the EtherNet/IP scanner is the client device. A client services one section of a manufacturing system and connects to tens if not hundreds of end devices, the servers. That’s somewhat confusing for IT people.

Before I answer the question of when a device should be an OPC UA client or a server, let’s look at what each of them do. In all manufacturing applications, no matter what the device is called (controller, scanner or client), the device that 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, process logic and, occasionally, send asynchronous command requests to end devices is the client device.

Like controlling devices in other technologies, an OPC UA client device sends message packets to server devices and receives responses from its server devices. Beyond this basic functionality, an OPC UA client device is fundamentally more sophisticated than controllers in other technologies. You can read more about that additional functionality in my book, OPC UA: The Everyman’s Guide.

But the more confusing question still remains: “Should a particular device be an OPC UA client or an OPC UA server?” My answer, which pleases no one, is: “It depends.”

If you make a device an OPC UA server, then any physical world values you have can be accessed by OPC UA client devices through the server’s address space. There are at least two ways clients can accomplish this. They can directly read and write the attributes of the address space or they can use the monitored items and publisher/subscriber services to have those attributes published on some schedule.

If you make a device an OPC UA client, you can take any physical world values you have and write them into some other OPC UA server whenever new data arrives on some schedule. IT people like to call that a push.

You also have the option of making your device both an OPC UA client and a server. Now you can provide data to clients using the two mechanisms mentioned above: read attribute data from other servers or write attribute data into other servers. You have a very flexible implementation.

What’s interesting about this is that all three of these architectures accomplish the same thing. Each of them collects data from the physical world and offers it to other devices. They also get data from other devices and write it out to the physical world. How that is accomplished varies in each scenario but in the end, they all accomplish the same thing.

The best way forward to end all the confusion is to just make every device both a client and a server. That’s the direction I’m hoping the industry will move.