Three Things Every Beginner Should Know About OPC UA (Told by an OPC UA Newbie)

When I first decided to write a blog about the Open Platform Communications Unified Architecture (OPC UA), I figured it would be a walk in the park. I had already written one on Modbus and EtherNet/IP, how hard could this possibly be? I opened my copy of The Everyman’s Guide to OPC UA and began studying. I didn’t make it very far until I read the five words, “OPC UA is NOT a protocol.” That made me want to bang my head against a wall. This sent me down a rabbit hole of different, often contrary takes on this technology, written by authors with far more experience than I have. There I sat, thinking what the hell is it? Well, I have finally figured it out…sort of. Here are three things every beginner should know about OPC UA, told by someone new to OPC UA.

A Brief History

During the 1990s, automation experts got together and decided that the automation industry needed a better way to operate their factory applications. This eventually led to the creation of the OPC Foundation and OPC 1.0, now referred to as OPC Classic. The mission was simple: create a way for applications to get at data inside an automation device without having to know anything about how that device works. The OPC Classic model was super successful, but there was still room for improvement in terms of security and data consistency. This led to the creation of OPC Unified Architecture.

#1 OPC UA Is Not a Protocol

Well, maybe it is. The jury is still out on this one. You can consider this one of the greatest philosophical debates of all time. Even here at Real Time Automation, we’re a bit torn on this. For the sake of this blog, I will take the stance that it is not a protocol, but rather an architecture that allows you to model everything from factory data to entire factories. A protocol simply specifies how two machines are to talk to each other, their message structure, and how the actual data appears on a wire. Sure, Modbus also specifies inter-computer communications, but the goal of using OPC UA is complete interoperability. It allows you to customize how data is organized and how information about that data is reported.

#2 OPC UA Client/Server Architecture

Just like how Modbus TCP or BACnet support a client/server relationship (once known as master/slave) within their networks, the same is true for OPC UA. There is a surprising difference between OPC UA and the previously mentioned protocols that makes it more similar to EtherNet/IP than other protocols. Typically, when a client device takes ownership of a server device, no other client can access the data or that machine. The opposite is true for OPC UA clients, as they can access the data from any number of server devices. However, servers can only respond to input messages and never initiate communication with clients.

#3 OPC UA Is Platform-Independent and Scalable

Unlike OPC Classic, OPC UA is designed to be platform-independent. What this means is that the technology is not exclusive to any one operating system or device. The range of OPC UA is truly incredible and can be deployed to anything from small chips to entire workstations. Every component of the architecture is designed to be scalable. Encoding mechanisms can be selected by users to provide ease of communication with IT devices. This same scalability exists in the address space. OPC UA address spaces can consist of multiple objects and a single variable, or a sophisticated set of interrelated objects. Pretty cool, huh?

Is your brain tired from reading all that? Because my brain is tired from writing all of this. If you’re trying to improve your factory automation technology using OPC UA, be sure to check out our solutions. And for additional support, don’t be shy—give us a ring at 1-800-249-1612. In the meantime, I’ll be trying to solve the OPC UA protocol conundrum once and for all.