- By John Rinaldi
By John Rinaldi
Introduced in the late 1990s, OPC quickly became a global standard for communications to Microsoft Windows computers. Tens of thousands of OPC servers were deployed in every corner of the automation industry. The acronym OPC was born from object linking and embedding (OLE) for process control. As the technology changed, the acronym changed to stand for open platform communications.
The problem with OPC
OPC was built on now obsolete Windows Object Linking Embedding (OLE) using Microsoft Windows Common Object Model (COM), and it served industry well. It let OPC servers conceal the gritty details of communication from applications (figure 1), so data from all sorts of automation equipment could communicate using a standard and open mechanism. Users could work with standard Microsoft applications, including Excel, Word, or Visual Basic, or implement their own applications using data from automation equipment without ever knowing the details of how those devices communicated. Over time, OPC (commonly referred to as OPC Classic) had security issues, both real and perceived, and a real problem was its dependency on Microsoft Windows COM. In addition, new versions of Windows were continually being released, making previous versions obsolete and complicating support.
Figure 1. OPC Classic using Microsoft COM
OPC was strictly a Microsoft Windows technology that could not be used on other platforms, including Linux and VxWorks. It was impossible to maintain an OPC Classic server on a Microsoft Windows platform for the life of an industrial application. Older Windows versions became unsupported and eventually unavailable, and the costs to upgrade (deployment, testing, downtime, new PCs) became unacceptable. In manufacturing, automation processes are built to last, and it is common to build production processes for diapers, soap, tea, and hundreds of other products that run for five, 10, or 20 years. There was a strong desire to run OPC Classic servers with longer lives, stable hardware, and smaller, embedded platforms. Companies asked, “Why do I have to be tied to Microsoft?” With devices like flowmeters, drives, programmable controllers, and other field devices becoming smarter, users asked, “Why can’t they be an OPC server?”
There was also dissatisfaction that OPC required multiple layers of networks and computers to communicate field device data to all those data-hungry factory automation, historian, and enterprise servers. Further, since there is no metadata that provides the semantics and definition of units, scaling and strict configuration control had to be maintained, making systems brittle. Every time a new piece of data was added, you had to reconfigure multiple systems without breaking any of them. “Yuck” is the technical term for it. More recently, OPC does not have a direct way to communicate with the Internet and cloud applications.
OPC UA to the rescue
The answer to the problems is OPC Unified Architecture (UA), referred to as UA throughout this article. UA is the next generation of OPC technology. It is a more secure, open, and reliable mechanism for transferring information between servers and clients. It provides more open transports, better security, and a more comprehensive information model than OPC Classic. UA has a very flexible and adaptable mechanism for moving data between enterprise systems and automation, controls, monitoring devices, and sensors that interact with real-world data. OPC UA overcomes the limitations of OPC Classic with:
- Scalability and platform independence: It can be supported on high-end servers and on low-end sensors. UA uses discoverable profiles suitable for tiny embedded platforms as servers.
- Flexible address space: Address space is organized around the concept of an object, which is an entity consisting of variables and methods. It is a standard way for servers to transfer information to clients.
- Common transports and encodings: Standard transports and encodings make sure connectivity is easily achieved in embedded and enterprise environments.
- Security: A sophisticated security model for authentication of clients, servers, users, and communication integrity.
- Internet capability: Fully capable of moving data over the Internet.
- Robust set of services: Full suite of services, including managing events, alarming, reading, writing, and discovery.
- Certified interoperability: UA certifies defined profiles to guarantee connectivity between a client and server.
- Sophisticated information model: UA profiles more than just an object model, enabling true information sharing between clients and servers.
- Sophisticated alarming and event management: UA has a highly configurable mechanism for providing alarms and event notifications to interested clients. Alarming and event mechanisms go well beyond the standard change-in-value type alarming found in most protocols.
- Integration with standard industry-specific data models: The OPC foundation is working with many industry trade groups that define specific information models for their industries to support those information models within UA.
UA is a 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 it can be turned into information. UA connects databases, analytic tools, enterprise resource planning, and other enterprise systems with real-world data from low-end controllers, sensors, actuators, and monitoring devices.
UA uses scalable platforms, multiple security models, multiple transport layers, and a sophisticated information model to allow the smallest dedicated controller to freely interact with complex, high-end server applications. UA can communicate anything from simple downtime status to massive amounts of highly complex plantwide information.
Different from plant floor systems
OPC UA is about reliably, securely, and most of all, easily modeling “objects” and making those objects available around the plant floor, to enterprise applications, and throughout the corporation. The scope of UA is much broader than anything most of us have ever thought about before.
It starts with an object that could be as simple as a single piece of data or as sophisticated as a process, a system, or an entire plant. It might be a combination of data values, metadata, and relationships. For example, a dual-loop controller object relates variables for the set points and actual values for each loop. Those variables reference other variables that contain metadata like the temperature units, high and low set points, and text descriptions. The object might also make available subscriptions to get notifications on changes to the data values or the metadata for that data value. A client accessing that one object can get as little data as it wants (single data value) or an extremely rich set of information that describes that controller and its operation in detail.
OPC UA is, like its factory floor cousins, composed of a client and a server. The client device requests information; the server device provides it. But, as we see from the loop controller example, what the UA server does is much more sophisticated than an EtherNet/IP, Modbus TCP, or Profinet IO server.
An OPC UA server models data, information, processes, and systems as objects and presents those objects to clients in ways that are useful to vastly different types of client applications. It provides sophisticated services that the client can use, including:
- Discovery services: Services that clients can use to know what objects are available and link to other objects, data types, and metadata used to organize, classify, and describe objects and values.
- Subscription services: Services that the clients can use to identify what kind of data is available for notifications. Services that clients can use to decide how little, how much, and when they wish to be notified about changes, not only to data values but to the metadata and structure of objects.
- Query services: Services that deliver bulk data to a client, like historical data for a data value.
- Node services: Services that clients can use to create, delete, and modify the structure of the data maintained by the server.
- Method services: Services that the clients can use to make function calls associated with objects.
An OPC UA server is a data engine that gathers information and presents it in ways that are useful to various types of OPC UA client devices. Devices could be located on the factory floor like a human-machine interface, or could be a proprietary control program like a recipe manager. They could also be a database, dashboard, or sophisticated analytics program located on an enterprise server.
Even more interestingly, this data is not necessarily limited to a single physical node. Objects can reference other objects, data variables, data types, and more that exist in nodes someplace else in the subnet, architecture, or the Internet.
OPC UA organizes processes, systems, data, and information in a way that is absolutely unique to the experience of the industrial automation industry. It is a unique tool that goes beyond existing industrial protocols with information modeling and delivery tools that provide access to that information to clients throughout the enterprise.
Figure 2. OPC UA information model
OPC UA is in your future
Hands down, OPC UA is the most open, reliable, secure technology for moving data between factory, enterprise applications, and the cloud. For that reason alone, it will be part of your future industrial network. There are two other reasons, however.
One, major trade organizations are using OPC UA as an infrastructure component that provides the latest transports, encoding, and security to their applications from building automation to undersea drilling. They use OPC UA as the infrastructure for moving their data models between end devices, controllers, and the cloud. It allows them to focus on organizing information models that best serve their industries instead of the mechanisms to transport, encode, and secure data. They now use the OPC UA Foundation, the organizing association for OPC UA, to provide those and support that part of the infrastructure.
Secondly, there is broad industry support from industrial automation suppliers, industrial networking standards, and enterprise software suppliers.
If you are one of those engineers who have been ignoring OPC UA and the whole Internet of Things, cloud, Microsoft Azure business, it is time to get serious about it. Yes, it has not been our bread and butter in the past, but the times “they are a changing.” Seeing pieces drop out of a mold, packages flying down a conveyor line, or bottles and cans being precisely filled is now only part of our job. Getting the data we need to operate more productively and efficiently is the new job—and OPC UA is going to be your tool to move forward!
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.