by John Rinaldi
OPC UA: The Basics is an Everyman’s overview of OPC UA. This is not a hardcore technical specification that digs down to the smallest bits and bytes of OPC UA. This is a high level overview of the protocol for someone without 20 years of experience in embedded programming. Perfect for a sales person, IT Professional or executive trying to figure out what OPC UA brings to the table. Join John Rinaldi (The Dr. Phil of Automation) as he breaks down the features of OPC UA and gives you insight into how this emerging technology is redefining the line between Automation and Enterprise Systems.
Below you will find a brief intro to each of the chapters of the book. To get the full version of the book, click the “Buy Now” button to the right, or at the bottom of each section
[wptabs type=”accordion”] [wptabtitle]Introduction[/wptabtitle] [wptabcontent]
Why a book on OPC UA?
In 2011 I started reading and studying OPC UA, the successor to the widely popular OPC for MS Windows (what I now refer to as “OPC Classic”). There are two really good books on the subject written by some of the authors of the OPC UA specification. I’ve read both these books.
I have no complaints with those books, but I find them exceptionally pedantic. They can be hard to read and require a lot of patience. Connecting the dots from what’s in one section to something in a later section is difficult to do without exceptional diligence.
Even though those books are more than adequate, I felt that there were two good reasons to add my contribution to the subject. First, I felt that it was important to explain UA in a shorter, more direct way. Those books are fine for software developers and people who really want a strong background in UA. But that’s certainly not most people. Most just want to figure out what this is all about and don’t need 350 pages to do that.
Once upon a time, I gathered my engineering team in the RTA conference room. I set up my laptop and project. Put doughnuts on the table. I’ve found that doughnuts are a key ingredient to morning engineering meetings at our shop. And they had better be good doughnuts from a real bakery. Nothing else will do.
So I turned the projector on and OPC UA appears on the screen.
Now, some of them are conversant with OPC. They’ve heard the term. Heard me talk about it. Listened as customers described how they use OPC as a component of their factory automation architecture.
Others don’t know it all. Don’t know the history. Most are pretty young. None have real work experience on a machine startup. Six to eight weeks away from home. Living at the plant. Sweating out (sometimes in summer, really sweating) installation and troubleshooting of three or four thousand points, thousands of lines of ladder logic, plus configuration of all sorts of unique devices. And trying to make all of that electrical stuff work with the mechanical components of the machine.
So I started with the history of OPC. Back to the roots.
It was the 1990s. Very early in the development of the personal computer. Actually very early in the development of Windows. We’re talking Windows 3.0, Windows 95, Windows for Work Groups.
This stuff was, to say the least, challenging to work with. Nothing integrated. Every application was a standalone application. Stuff crashed. Hard drives didn’t last long. But that was okay because every nine months or so there was a new something to buy. New drives, new processor, new OS.
That is a very simple question. The answer when you are discussing a complex technology like OPC UA isn’t as simple.
OPC UA is the next generation of OPC technology. OPC UA is a more secure, open, reliable mechanism for transferring information between servers and clients. It provides more open transports, better security and a more complete information model than the original OPC, which I will refer to as “OPC Classic.” OPC UA provides a very flexible and adaptable mechanism for moving data between enterprise-type systems and the kinds of controls, monitoring devices and sensors that interact with real world data.
Why a totally new communication architecture? OPC Classic is limited and not well suited for today’s requirements to move data between enterprise/Internet systems and the systems that control real processes that generate and monitor live data. These limitations include:
OPC UA is the first communication technology built specifically to live in that “no man’s land” where data must traverse firewalls, specialized platforms and security barriers to arrive at a place where that data can be turned into information. OPC UA is designed to connect databases, analytic tools, Enterprise Resource Planning (ERP) systems and other enterprise systems with real-world data from low-end controllers, sensors, actuators and monitoring devices that interact with real processes that control and generate real-world data.
I’ve studied this technology for a long time now. And yet there is a question that I almost shrink from. In fact, I sometimes hate to answer it.
It’s not because I don’t understand what it is. It’s not that I don’t understand how it works. And it’s not that I don’t believe that it is a very valuable tool to almost every plant floor system.
It’s just hard to put it into context when there isn’t anything to compare it to. For example, when Profinet IO came out, I could tell people that it was the equivalent of EtherNet/IP for Siemens Controllers. Same kind of technology. Basically the same kind of functionality. Easy to explain.
But how do I explain OPC UA when it doesn’t have an equivalent? You could say that it’s Web services for automation systems. Or that it’s SOA for automation systems, an even more arcane term. SOA is “Service Oriented Architecture,” basically the same thing as Web services. That’s fine if you’re an IT guy (or gal) and you understand those terms. You have some context.
But if you’re a plant floor guy, it’s likely that even though you use Web services (it the plumbing for the Internet) you don’t know what that term means.
So the reason I get skittish about answering this question is that they always follow up with another question that makes me cringe: “Why do we need another protocol? Modbus TCP, EtherNet/IP and Profinet IO work just fine.”
So I have to start with the fact that it’s not like EtherNet/IP, Profinet IO or Modbus TCP. It’s a completely new paradigm for plant floor communications. It’s like trying to explain EtherNet/IP to a PLC programmer in 1982. With nothing to compare it to, it’s impossible to understand.
That’s where I am trying to explain OPC UA.
One of the things that I’ve learned about OPC UA is that the terminology is a little different than what I’m used to seeing. With thirty years of industrial networking experience, I thought I had a lock on concepts like node and stack, but found myself unexpectedly confused when starting to study OPC UA.
The terms used in lots of OPC UA documents are similar to what I expected, but the designers twisted the meanings slightly. It’s probably because OPC UA is the first protocol that really crosses the line between the enterprise and the factory Floor. Because it has a foot in both worlds, the terms can be confusing to well-versed individuals in both the IT and factory floor worlds.
Another reason why the terms appear at first glance to be a little confusing is the scope of an OPC UA discussion. In IA (industrial automation), we generally talk about interfaces between software components cohabiting in a processor. Or we talk about devices on the same subnet communicating over a very well-defined and very restrictive interfaces (EtherNet/IP, Modbus TCP or Profinet IO). In the Internet world, people talk about generic services with much more flexibility and capability than the interfaces between factory floor devices.
Here’s part one of my dictionary. It covers general OPC UA terms that I find interesting. (My apologies – It’s not meant to be comprehensive.)
This is the second part of the dictionary I’ve been building as I study OPC UA technology. The terms in this section refer to items that are more pertinent to developers of OPC UA stacks though could be interesting to those who desire a deep understanding of OPC UA technology.
The list is not inclusive of every term that applies to OPC UA stack technology.
WEB SERVICES – Web services is a generic term for loosely coupling Internet services (applications) in a structured way. The majority of Internet applications are today built using Web services. With Web services, you can easily find services, obtain the interfaces and characteristics of the interfaces and then bind to them. HTTP, SOAP, XML are the basic technologies of Web services applications and are some of the technologies that can be used by OPC UA clients and servers.
SERIALIZATION – This is an easy term to comprehend. This is the process of taking a service like the read attribute service and creating the series of bytes that an OPC UA server can process and return the value of an attribute. Serialization dictates how data elements like a floating point value are transformed into a series of bytes that can be sent serially over a wire. Two types of serial encoding are currently supported by OPC UA: OPC UA Binary and OPC UA XML.
This is a section that a lot of readers will find pretty straightforward and comfortable. I’m going to discuss OPC UA from a system point of view. We’ll take a look at the architecture as a whole and then dive into the individual components.
OPC UA uses a Web services kind of architecture. There is another section in this document that discusses Web services in detail. For this section, we should know that Web services is an architecture where systems are de-coupled to provide faster, more flexible interaction between disparate systems. And that’s exactly the goal of OPC UA: to be flexible enough to link major business systems like SAP with small embedded devices such as a motor controller. A key component of the Web services architecture is that you can easily find the available services, obtain the interfaces and characteristics of the interfaces and then bind to them. This is the architecture that has made the Internet so successful.
Web Services and OPC UA both use a client – server type architecture. Client devices seek out, discover, interrogate, connect to and configure one or more server devices. Server devices provide endpoints for specific interactions and make those endpoints available to client devices. A device called a discovery server assists clients in finding servers. Let’s look at each of these components of the OPC UA architecture in more detail, beginning with server devices.
I know a number of people that talk in riddles. As much as I try, I can’t seem to fathom what they are trying to communicate. I hate to say it, but people in their teens and twenties are most guilty of this. They’ve never had to speak in full sentences and they’ve spent their lives texting, emailing, tweeting every little thought generated as they generate it. No context. No patterns. No structure. Just data dumps right from their head.
Data, in and of itself, is not of much use. Placing structure, patterns and context around raw data is the definition of an address space model. In other networks, it’s called the data model, the data representation, the object model – there’s a whole host of names. No matter what the name, an address space model specifies a mechanism for organizing and addressing data.
OPC UA is built around a very highly detailed, superbly organized address space model. The OPC UA model is more sophisticated than object models of the industrial protocols (EtherNet/IP, Profinet IO and Modbus) and the building automation protocols (BACnet and LonWorks).
For the most part, the industrial protocols and the building automation protocols all use a straightforward and well-defined structure that encapsulates the data as objects. Some have other types of organizations: Lon uses network variables, BacNET uses a list of defined data types and Modbus uses registers and coils.
Many automation engineers and even a lot of the people on my staff are confused by the term “Information model.” It’s not a term that they have encountered before because it doesn’t really exist in the networking technologies used in their factories.
An information model is a structure imposed on top of the address space that relates pieces of the address space together in such a way that these elements represent standard systems, processes, devices, manufacturing cells or entire plants.
There are two kinds of information models. There are non-standard models created by integrators, vendors or other professionals to standardize the interfaces of a proprietary or local installation. And there are standardized models that provide common interfaces to entire industries. For example, there are information models that represent the IEC 61131-3 architecture and work underway to provide standard representation for the oil and gas industry.
Let’s look at a very simple example of the first type. In this example, an installation has a number of tanks with simple pumps and level sensors. It’s a very simple system. When the level falls below a set point, the pump runs until the level is restored.
Note: OPC UA Security is only one part of an overall security plan for an installation. As OPC UA is a communications protocol, the security focus is on communications security: the integrity of messages between clients and servers. Developers must use the OPC UA security model as one component of the overall security plan.
Security was easy in the old days. There just was no connectivity between anything on the factory floor and the Internet. That’s the famous “air gap.” A hacker would have to physically penetrate the walls, guards and access systems to create any mischief on the factory floor.
That was fine for those days, but the luxury of maintaining that air gap is gone. Now MIS systems, MES, ERP and other systems must have access to factory floor controllers and sensors to achieve the productivity, quality and interconnectedness required of 21st century automation environments. Today’s manufacturing plants are not only physically larger, but also more geographically diverse and require a level of coordination and integration unfathomable just a few years ago. Integrated systems spanning countries, suppliers and technologies are common. The Internet has become the vital infrastructure for this strategy, and with it, a huge risk to the enterprise.
OPC UA is without a doubt the most scalable networking technology that I have encountered in my twenty-five years in automation. But, of course, the designers of the technology had no choice. How else do you build something that functions on the most advanced, high-end server environments using state of the art tools and in a simple sensor that simply needs to send a humidity reading every hour?
Profiles, facets and conformance units are all concepts that support the scalability inherent in OPC UA. Let’s start by defining each of these terms:
Conformance Units – Conformance units are simply testable units of functionality. The call service is an easy to understand example of a conformance unit. One or more conformance units define a profile. Conformance units are not specific to a particular profile. You will find the same conformance unit in multiple profiles.
Profile – a set of functionality that defines the capabilities of an OCP UA device. A profile indicates to other devices (electronically) and to people (human readable form) what specific features are supported. Engineers can determine from the profile if this device can be used in an application. A client device can determine if a device has the functionality required for the application and if it should initiate the connection process with the device. There are two types of profiles: full-featured and facets. Full-featured profiles define a set of conformance units that a group of applications needs to support. The nano-embedded server profile contains the minimum set of conformance units needed by small embedded devices. All devices must be based on a full-featured profile.
Facets – Facets are profiles that contain specific functionality (conformance units). Facets are added to a full-featured profile to extend the functionality of the profile with that additional functionality.
In this section I’d like to illustrate the power of UA with a simple example: automatic door systems. These are familiar systems found all over the world. You find them at shopping centers, airports, drug stores and many, many other places.
These systems can be rather complex, but for our purposes we are going to limit them to a motor, two sensors and an Ethernet-enabled controller of some sort. An actual system might include a people counter, lighting controls, temperature sensors and more, but we’ll keep it simple in this example.
In our example, the automated door system has only two electro-mechanical requirements:
1. Enable and disable operation of the door based on the facility schedule
2. When in the enabled mode, open the door when indicated by the sensor input
In practice, if the manufacturer chose to connect the system to the back office systems, they could add any number of new features and benefits:
1. Track the number of activations and automatically schedule preventive maintenance
2. Record the number and time for all after hours override door activations
3. Detect motor, sensor and control board failures remotely
4. Detect operational failures
5. Easily update the operating schedule remotely
6. Detect and report unauthorized intrusion
7. Monitor customer entrance and exit activity
There’s a lot of talk today about the integration of the enterprise and the factory floor. I’ve enjoyed a lot of this discussion. Rockwell has a great image of something they call the “Convergence Man.” It’s a guy split in two with a hardhat and factory smock on his right side and the more formal shirt and pants of an IT guy on his left side.
There’s also a bunch of new terms being thrown around like “digital factory” and “integrated intelligence,” a sign of the increasing talk (and action) toward linking the factory floor with systems not directly involved in factory floor control. Enterprise systems can be big and sophisticated like ERP and MES systems, or they can be as simple as a recipe manager on your server that downloads twenty tags once a day.
No matter what you’re doing, there’s a key distinction between the systems on the factory floor and in the enterprise that not many people understand. This difference involves what I call “loosely-coupled” systems and “tightly-coupled” systems. I don’t think these are new concepts, but I don’t think they’ve been examined in the light of the current trend toward the integration of factory floor and enterprise systems.
I would argue that factory floor systems should be labeled “tightly-coupled.” Systems that use Profibus, Profinet IO, DeviceNet, EtherNet/IP or any Modbus version have a very strict architecture. These are really I/O systems, despite that the folks at the ODVA (the Open Device Vendor Association) and PI (Profinet International) would have you believe otherwise.
Why Are We Talking About Web Services?
I’ve included this chapter in this little book because a lot of industrial automation people aren’t really all that literate with the plumbing of the Internet. And in the 21st century, the Internet and all that technology is steadily working its way into the manufacturing/automation environment. The more we know about it, the better off we will be to meet the challenges in the future.
So you’ve heard the term Web services. But what does it really mean?
Let’s start by thinking about when the Internet was new. Moving data between two systems was difficult. Look at the challenges just to move something simple like a bank balance. How do you represent $1,000? Is that two bytes of information? Or is it four bytes of information? Because if you save your money, that $1,000 may exceed $65,535 someday and you can’t represent that in two bytes. If it’s four bytes, is the first byte the most significant, or is it the last? What about the decimal places when I deposit ten more cents? Lots of platforms and processors have radically different mechanisms for storing that simple piece of data. What a mess!
This section is really dedicated to developers. If you develop automation products and need to use OPC UA in your products, this section will help you figure out how to do it.
What You Need to Get Started
There are two requirements to get started with OPC UA. The first is that you have to have an Ethernet-enabled product. Without Ethernet, you can’t have OPC UA. The second is that you have to design the address space for your product.
OPC UA in an embedded automation product uses standard TCP/IP for transport. The base platform that you will need for OPC UA is simply TCP/IP on an Ethernet-enabled processor. There is no requirement for an operating system. There is no specific requirement for processor bandwidth, flash memory or RAM.
Designing an address space will probably be the more complicated part of the project. OPC UA uses an object-oriented address space. If your data is already object-oriented, then mapping it to OPC UA will not be much of a problem.