For professionals without lots of programming experience, OPC UA: The Basics breaks down the complex barriers of OPC UA.

SKU: BK-OPCUABASICS

OPC UA: The Basics

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 salesperson, IT Professional or executive trying to figure out what OPC UA brings to the table. Join John S. 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.

Amazon-Buy-Now-Button

Below you will find a brief intro to each of the first six chapters of the book.

Introduction

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.

A Little History of OPC

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.

What is OPC UA?

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:

  • Platform dependence on Microsoft – OPC Classic is built around DCOM (Distribution COM), an older communication technology that is being de-emphasized by Microsoft
  • Insufficient data models – OPC Classic lacks the ability to adequately represent the kinds of data, information and relationships between data items and systems that are important in today’s connected world
  • Inadequate security – Microsoft and DCOM are perceived by many users to lack the kind of security needed in a connected world with sophisticated threats from viruses and malware.

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.

How OPC UA Differs from Plant Floor Systems

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.

OPC UA Dictionary (Part 1)

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.)

OPC UA Dictionary (Part 2)

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.

Weight1 lbs