An Introduction to


What Is It?

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.

OPC UA resources

Want to learn more about OPC UA?

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!


Features & Benefits

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.

  • Scalability – It’s scalable and platform-independent. Both high-end servers and low-end sensors can support it. UA uses discoverable profiles to include tiny embedded platforms as servers in a UA system.
  • A Flexible Address Space – The address space is organized around the concept of an object. Objects are entities that consist of variables and methods and provide a standard way for servers to transfer information to clients.
  • Common Transports and Encodings – It uses standard transports and encodings to ensure that connectivity can be easily achieved in both embedded and enterprise environments.
  • Security – It implements a sophisticated security model that ensures the authentication of clients and servers, the authentication of users and the integrity of their communication.
  • Internet Capability – It’s fully capable of moving data over the internet.
  • A Robust Set of Services – OPC UA provides a full suite of services for eventing, alarming, reading, writing, discovery and more.
  • Certified Interoperability – It certifies profiles such that connectivity between a client and server using a defined profile can be guaranteed.
  • A Sophisticated Information Model – It profiles more than just an object model. True Information is shared between clients and servers because of the way it connects objects.
  • Sophisticated Alarming and Event Management – UA provides a highly configurable mechanism for providing alarms and event notifications to interested Clients. The 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 several industry trade groups that define specific information models for their industries to support those information models within UA.

A Little Bit of History

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?

  • Platform Dependence – It no longer relies on Microsoft DCOM. UA is RTOS-independent and implementable on Linux.
  • Robust Data Models – It offers a highly flexible and robust information model. It also established relationships between data items and systems important in today’s connected world.
  • Security – It offers endpoint authentications and encryption and removes the reliance on DCOM that OPC DA had.

Like what you’re reading?

Subscribe to our Automation Education email series to learn the ins and outs of the top industrial protocols in a byte-size nuggets sent bi-weekly to your inbox!

Why Use OPC UA?

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.

OPC UA Transport Layers

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,

  • SOAP / HTTP TRANSPORTS – HTTP is the connectionless, stateless, request-response protocol that you use every time you access a web page. SOAP is an XML messaging protocol that provides a mechanism for applications to encode messages to other applications.
  • HTTPS TRANSPORT – Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP. It means that all communications between your browser and that website are encrypted. Just like HTTP, SOAP is used as the request/response protocol to move the OPC UA requests between clients and servers.
  • UA TCP TRANSPORT – UA TCP is a simple TCP-based protocol designed for server devices lacking the resources to implement XML encoding and HTTP/SOAP type transports. UA TCP uses binary encoding and a simple message structure that can be implemented on low-end servers.

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.

OPC UA Data Model

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.

OPC UA Services

  • Discovery Services – Services that clients can use to know what objects are available, how they are linked to other objects, what kind of data and what type is available and what metadata is available that can be used to organize, classify and describe those 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 also 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.

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.

OPC UA Device Types

The OPC UA Server

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.

The OPC UA Client

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.

  • Client devices request services from OPC UA server devices. Server devices send response messages and notifications to the OPC UA client device.
  • The subscription service set, which drives notifications, and the read service of the attribute service set are the primary services that OPC UA clients use to interact with the address space on an OPC UA server.
  • Clients find OPC UA server devices in multiple ways. Clients can find servers by using traditional configuration, a local discovery server, a local discovery server with a multicast extension or a global discovery server.
  • Once a client finds a server, it obtains the list of available endpoints and selects an endpoint that supports the security profile and transport that matches its application requirements.
  • Clients begin the process of accessing an OPC UA server by creating a channel, a long-term, connection between it and an OPC UA server. Channels are the authenticated connections between two devices.
  • Once a channel is established, clients create sessions, which are long-term, logical connections between OPC UA applications. A session is the authorized connection between the client’s application and the server’s address space.
  • Clients can subscribe to data value changes, alarm conditions, and any results from programs executed by servers. Servers publish notifications back to the client when those items are triggered.
  • Clients invoke methods, which are small program segments. Programs can return results to the client in the method call or in a notification if the client subscribes to it.

OPC UA Security

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.

OPC UA Certification

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.

  1. Complete your internal testing and validate that your device performs as you expect it to perform. You should have completed both your functional and stress testing before submitting it for a certification test.
  2. Use the online OPC Foundation Registration Wizard to register for your test.
  3. Receive the notice from the foundation regarding your test date and ship your device to the test site. You may wish to accompany your device but that is not required.
  4. Wait for the test to be conducted.
  5. Receive the list of errors, or, if you pass all tests, receive the certification statement that your device is certified.
  6. Receive an x.509 certificate that can be stored in your device and made available to client devices that request it.

OPC UA in Review

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.