OPC UA is the next generation of OPC technology. It’s 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 DA (a.k.a. OPC Classic). It 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.
OPC 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. It can communicate anything from simple downtime status to massive amounts of highly complex plant-wide information.
Subscribe to our Automation Education email series to learn the ins and outs of OPC UA and the top industrial protocols in a byte-size weekly format!
RTA is a proud member of the OPC Foundation. For more information, visit their site: opcfoundation.org
OPC UA is a sophisticated, scalable and flexible mechanism for establishing secure connections between clients and servers. Some of the most important features of this unique technology are below.
Around 1994-1995, a bunch of factory automation experts got together and decided there had to be a better way to operate their factory floor applications. Their work eventually led to the OPC 1.0 and the creation of the OPC Foundation. Their 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.
Their solution centered on Component Object Model (COM). COM was a newer Microsoft technology at the time. It provided a way for Microsoft Windows applications to share data. One application could request data and another would supply it. The OPC founding fathers took this technology, mated it to an API that supported device protocols for automation devices and OPC 1.0 was born. Any Microsoft application that supported COM could read or write the data from any device, no matter what physical layer or protocol it supported.
This was revolutionary and probably accelerated the adoption of PCs on the factory floor. For the first time ever, systems integrators and other factory floor application developers could implement applications without spending vast sums on driver development.
However, not long after its invention, the application demands, and a changing automation landscape began to erode the acceptability of PCs and OPC servers in these applications. Why? COM and DCOM (the distributed version of COM) are difficult to maintain and understand without significant training. How you use it, configure it and set up authorizations varies slightly from one version of Microsoft Windows to the next.
The lack of COM/DCOM knowledge and the seemingly inconsequential act of plugging in a data stick are not OPC Classic problems. The problem is that management didn’t dictate that a checklist be in place when an OPC server stops communicating. Management didn’t have a certification program in place to ensure that the people maintaining OPC servers were well trained in COM and DCOM and troubleshooting OPC server problems.
The other problem is the deficiencies that come with dependency on Microsoft and Windows. COM, the base technology for OPC, is a Microsoft product. It runs only on Microsoft platforms. Not Linux, not VxWorks, not anything else.
Microsoft’s negative reputation is especially well-deserved in industrial automation. In this industry, we generally build automation processes to last. Processes for diapers, soap, tea and hundreds of other products need to run for the next five, 20 or 50 years. Microsoft products and PCs aren’t suited for that kind of environment: they’re obsolete in just a few years.
The real problem with OPC Classic was that this was an expensive and inefficient way to get data from a device (RFID reader) into a database. A PC needed to be involved: someone needed to set it up, maintain it, validate that it was secure, etc. There was also the hardware setup and labor and the ongoing labor to maintain it to consider.
But more than all of that, it was very inefficient and provided incomplete data. The data had to be carefully managed all the way from the RFID reader to the server to make sure that the different systems used the correct data types, that resolution was maintained and that the endian order (which byte is first) is proper for that system.
Lastly, OPC Classic was vulnerable. Microsoft platforms that support COM and DCOM are vulnerable to sophisticated attacks from all sorts of viruses and malware.
Even though OPC Classic was wildly successful and worked well when managed right, there was enough dissatisfaction with the security issues, platform issues and data inconsistencies that a successor was planned for it. That successor is OPC UA (Universal Access).
What does OPC UA add as a new communication architecture?
It’s the first communication technology built specifically for 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. Most other technologies are designed for a specific application. It’s more flexible in that it provides connectivity advantages for all levels of the automation architecture.
OPC UA connects the factory floor to the enterprise. Servers can support the transports used in many traditional IT type applications. Servers can connect with these IT applications using Simple Object Access Protocol (SOAP) or Hypertext Transfer Protocol (HTTP). In fact, the World Wide Web uses HTTP as the foundation of its data communication.
A key differentiator for this protocol is that the mapping to the transport layer is totally independent of the services, messaging, information and object models. That way, if additional transports are defined in the future, the same information model, object model and messaging services can be applied to that new transport. It truly is a future-focused protocol.
Many of the common industrial automation protocol technologies limit the available transports. Devices that want to communicate with Programmable Logic Controllers (PLCs) must use the transport that is defined for the communication technology supported by that brand of PLC. However, the transports of OPC UA are not limited like other protocols. The technology space where this protocol operates is much more extensive. It requires support for many different transports and the capability to add new transports in the future. Transports are about how an OPC UA message is moved from your node to some other node on the network.
Once an OPC UA application forms a UA message or a response, it must send it somewhere. Transports are the low-level mechanisms for moving those serialized messages from one place to another.
OPC UA operates in very broad technology space and the devices can support multiple transports as well as custom or proprietary transports. OPC UA devices can be anything from a factory floor sensor or actuator to a PLC, a Human Interface Device, a Windows server operating a massive Oracle database or an undersea pipeline controller. A rich set of support transports are required to support the OPC UA mission of being a completely scalable solution.
The OPC UA specification defines several transports that clients must support,
What makes OPC UA transports so powerful is that requests to read or write an attribute can use standard web services technologies. UA requests and responses can be encoded as XML, placed inside a SOAP request and transferred to an IT application that already knows how to handle the HTTP, the SOAP message and the XML. OPC UA has an essentially free mechanism for sending messages between the factory floor and IT devices.
It all starts with an object. 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. A dual loop controller object, for example, would relate variables for the setpoints and actual values for each loop. Those variables would reference other variables that contain metadata like the temperature units, high and low setpoints, 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.
Like its factory floor cousins, OPC UA is composed of a client and a server. The client device requests information. The server device provides it. But as we can see from the loop controller example, what the server does is much more sophisticated than what an EtherNet/IP, Modbus TCP or PROFINET IO server does.
An OPC UA server models data, information, processes, and systems as objects and then presents those objects to clients in ways that are useful to vastly different types of client applications. Better yet, the server provides sophisticated services that the client can use, such as those listed below.
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 somewhere else in the subnet, in the architecture or even on the Internet.
All industrial servers provide the physical interface to the real world. Servers measure physical properties, indicate status, initiate physical actions and do all sorts of physical measurements and activations in the real world under the direction of a remote client device. Servers are where the physical world meets the digital world.
The specific capabilities of an OPC UA server are described by the profile it supports. A profile indicates to other devices (electronically) and to people (human-readable form) what specific features of the OPC UA specification are supported. Engineers can determine from the profile if this device is suitable for an application. A client device can interrogate the server and determine if it is compatible with the client and its application and if it should initiate the connection process with the device.
A server announces its availability to interested client devices, it provides a list of its capabilities and functionality to interested clients, it provides notifications of different kinds of events, it executes small pieces of logic called methods, it provides address space information in bulk to clients (query service), it provides browsing services so that a client can walk through its address space, and it can allow clients to modify the node structure of its address space.
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. Better yet, the UA server provides sophisticated services that the client can use, those already outlined above.
The 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 that could be located on the factory floor like a human machine interface, a proprietary control program like a recipe manager or a database, dashboard or sophisticated analytics program that might be located on an enterprise server.
In most industrial networking technologies, there is a controlling device: a device that connects to and controls one or more end devices. In OPC UA, a device of this type is known as an OPC UA client. Like controlling devices in these other technologies, an OPC UA client device sends message packets to server devices and receives responses from its server devices. But beyond this basic functionality, a client device is fundamentally more sophisticated than controllers in other technologies.
There are a few important concepts you need to remember when thinking about OPC UA clients.
When a request is received to connect to a server, the server validates the request, decrypts it and validates the certificate. Once a valid request for authentication or authorization is received and decoded, the next step is to determine if the server should accept the connection from that device or allow access to that user. It’s very important to realize that the OPC UA software stack does not do that. It passes that to the application to make the final determination of the request.
The OPC UA specification says nothing about how an application validates an authentication or authorization request. It is entirely up to the application as to how it should determine what devices can connect to it and what users can access what resources.
This protocol disconnects its request/response messaging protocol from the serialization, security, and transports. An OPC message, like the read service, reads the value of an attribute and can be serialized in multiple encodings (binary or XML). It can also be secured with one or more security protocols (OPC UA secure conversation or WS secure conversation) and be transported with one or more transports (UA TCP, HTTPS or SOAP/HTTP). In most systems, there is no such division between these functions.
OPC UA makes a distinction between client applications and users. A server may authorize a connection with a client application and create a communication channel, while not authorizing a connection with a user of that client application. Applications and users are authenticated and authorized separately.
OPC UA is designed to counter threats most likely to occur in your manufacturing plant, specific to various types of operating equipment with varying amounts of resources and processing power. Threats like message flooding, unauthorized disclosure of message data, message spoofing, message alteration, message replay and other attacks are countered by the security procedures built into the protocol.
When you submit a device, like an OPC UA server device, for testing at an OPC UA Foundation test facility, you are not only getting the most rigorous evaluation of your device, but also an evaluation of how well it works with other devices in a sophisticated network. That’s more than you can do on your own unless you are a global megacorporation.
In the case of the OPC UA Foundation tests, there is a specific process that you must follow.
OPC UA is an architecture that systematizes how to model data, model systems, model machines and model entire plants. You can model anything in OPC UA. It is a systems architecture that promotes interoperability between all types and manner of systems in various kinds of applications.
It’s a technology that allows users to customize how data is organized and how information about that data is reported. Notifications on user-selected events can be made on criteria chosen by the user, including by-exception. It is a scalable technology that can be deployed on small, embedded devices and large servers. OPC UA functions as well in an IT database application as on a recipe management system, a factory floor or a maintenance application in a Building Automation System.
It is a technology that provides layers of security that include authorization, authentication and auditing. The security level can be chosen at runtime and tailored to the needs of the application or plant environment.
This isn’t to say that OPC UA is better than EtherNet/IP, ProfiNet IO or Modbus TCP. For moving IO data around a machine, these protocols provide the right combination of transports, functionality and simplicity that enable machine control with a networked I/O. They are very good technologies for the machine control level of the automation hierarchy.
In the end, OPC UA increases productivity, enhances quality, and lowers costs by providing not only more data, but also information, and the right kind of information to the production, maintenance, and IT systems that often need that information in real-time. That’s the stuff that EtherNet/IP ProfiNet IO, Modbus TCP and all the rest just can’t do.