What is OPC UA and How It Works?
Any attempt to describe what is and how OPC UA works would be incomplete without a brief history of the standard for context. Before we begin, below is a link to the video version of this article.
Introduction to Classic OPC
So, it all started in the early 90s, when there was a rapid rise in the use of software based automation, which relied on Windows PCs for visualization and control purposes. This meant that each automation device had to have specific windows drivers in order to exchange automation data with HMI, and SCADA software running on a PC.
As a result, there came about very different communication protocols and interfaces. And this was a problem not only because automation data could not be easily accessed, but it was also not easy to pass it on to higher level systems. So a group of automation companies came together to solve this problem. And the result was OPC, or what is now called classic OPC.
So the idea behind classic OPC is that, instead of having the HMI communicate directly with multiple device drivers, why not put a standardized interface between the drivers and the HMI, such that the HMI would be able to access data from any kind of automation device via this standardized interface without having to know the specific driver details. That interface would be an OPC server, and the HMI would be an OPC client consuming automation data from the server. The device vendors would then follow the specification to produce drivers that are understood by an OPC server.
As you can imagine, it would have been a lot of work coming up with a mechanism for communication. However, it so happened that Microsoft already had a communication framework called Component Object Model, or COM, which enabled different applications to communicate with each other within the same PC.
And there was also a Distributed COM, or DCOM, which enabled communication between applications running on two separate PCs that are on the same network. In some way you can liken COM and DCOM to present day dotnet framework.
So, in order to reduce the specification work, the OPC foundation decided to adopt this technology for communication between OPC clients and servers. Once the communication framework was established, it was time to move on to specify the kind of data that was to be made available via OPC. So different interfaces were introduced, which included OPC data access, or da which allows clients real time reading, writing and monitoring of process variables OPC historical access for providing access to data already stored, and OPC alarms and events interface enabling the reception of event and alarm notifications.
To this day, OPC is used as the main channel that enables the flow of automation data from PLCs and DCSes into SCADAs and historians.
Disadvantages of Classic OPC
So, the obvious implication here is that both the server and the client have to be on a Windows environment for this to work. But that was hardly a problem back then, because there were no plans to make the OPC server deployable on Linux devices, tiny embedded devices, sensors or smartphones etc. This dependency on Windows became a disadvantage when the need for an operating system independent standard became necessary. Also, the fact that obviously cannot be used for internet communication made it clear that this won’t be the technology that takes us to the future of industrial communication.
It was time to go back to the drawing board. And this time around, it wasn’t just the platform independence and internet connectivity issues that were to be addressed. The standard had to undergo total transformation.
Introduction to OPC UA
The OPC foundation documented a set of requirements to be satisfied by an OPC UA application, and in 2008, released the first specification for the new generation of OPC called OPC Unified Architecture, otherwise known as OPC UA. Now to give you a clearer picture of the major differences between classic OPC and OPC UA, I’ll go through four characteristics that are at the core of OPC UA as a standard, and those that put it in a firm position to become the industry 4.0 standard of choice.
Characteristics of OPC UA
1. Cross-Platform and Internet Ready
First of all OPC UA does away with cold DCOM dependence and requires that all OPC UA applications be deployable across different computing platforms, which includes Sensors, PLCs, Embedded controllers, Gateways, Web Applications, Smartphones, you name it.
Secondly, OPC UA is internet ready and firewall friendly because it uses protocols such as HTTPS, which are already being used for internet communication without the need to open ports on the firewall. This ensures that production equipment can be embedded with the ability to securely and seamlessly exchange information over the internet.
2. Complex Information Model
Now, with classic OPC, you’re only able to expose automation data in its purest form, for example, the value of pressure. On the other hand, using OPC UA Information Modeling, which is discussed in part two of this series, OPC UA allows you to expose machine or sensor information in a manner that is much more complex than just a single value.
For example, instead of just the pressure value, you’re able to expose the unit of measurement. The current set points the type of instrument used for measuring its configuration parameters, its position in the hierarchy of machine or plant components, and also define all other components of that machine and how they are related to the pressure sensor in order to give the OPC UA client a holistic view of the machine or plant information. So it’s not just pure information that you get as an OPC UA client, but a total digital description of an underlying physical asset.
It’s important to note here that even with its complex information modeling capabilities OPC UA is still able to support simple data models, such as those in classic OPC.
3. Service Oriented Architecture
Take for example, in legacy protocols such as Modbus, data exchange is based on the bits and bytes that are transmitted back and forth. That is, in order to request information from a device or machine, you have to send a specific bit or byte sequence. As much as we have adapted to understanding Bits and Bytes as programmers and engineers, this is not a user friendly way of building communication systems. In contrast, an OPC UA server exposes services in the form of methods that a client can use to request information from a server.
These methods can be used for performing administrative tasks, Eg define server method. And they can also be used for accessing actual automation data, for example, the ReadTag tag and the WriteTag methods. I’m sure you can see how using a service oriented architecture could simplify the engineering effort in terms of development and maintenance of communication systems, as methods can easily be read by humans and programmed into machines for consuming automation data via OPC UA.
4. Simplified IT/OT Integration
If you are familiar with automation systems, then you’d be aware of the automation pyramid, which describes how data flows from field devices up to high level applications such as ERPs. That pyramid is the way it is simply because seamless information integration between systems at different levels of operation has not been easy to achieve in the past. Take for example, a low level device or sensor using field bus communication protocols could not communicate directly with a high level application, the information has to be collected by PLCs, made available to SCADA, and then finally pushed up the stack to IT networks. Now, because OPC UA is an information carrier that is common throughout all these stages. It kind of makes that pyramid obsolete. Devices can deliver data directly to higher levels.
Even better, OPC UA makes it possible to run non-critical process logic from the cloud. This diagram above shows potential OPC UA use cases across different levels of a manufacturing organization.
You will notice here that it is usual to have a system that has both an OPC UA client for accessing other servers, and a server for exposing on-system information.
By now it should have become evident to you why OPC UA shouldn’t be compared to other industrial communication protocols. Not even with its own predecessor. It was created to solve problems that are entirely different to what industrial communication protocols are being used for.
Two Pillars of OPC UA
So in defining the OPC UA standard, the foundation focused on two things. One, how implementers of the standard would be able to describe the data to be exposed by the server. Two, how data would be transported between the client and the server. In other words, Data Modeling and Transport Mechanisms are two basic pillars of OPC UA.
As you will find out in other parts of this series, the OPC foundation made an effort to keep these specifications as abstract as possible. This was intentionally done so as to leave room for any technology to be used for the actual implementation in order to future proof the standard and eliminate concrete reliance on one particular technology.
1. OPC UA Data Transportation
There are two transportation versions that OPC UA defines. The first one is the use of a Binary TCP protocol, which works well in scenarios that require high performance. And the second one is mapping the transportation to existing internet standards like HTTP, XML and web services, which works well for internet communication.
2. OPC UA Information Modelling
As stated earlier, classic OPC does have a way of presenting information, but in a very basic format, which could simply be a tag value for an OPC DA server. On the other hand, OPC UA is a complete data modeling specification, which defines the rules that OPC UA application developers must follow in order to expose a complex information model in an OPC UA server. The specification also defines how you can build a hierarchy for the type of components that are found within your system in order to expose them in the correct structure.
So in a nutshell, with OPC UA, you have a standard of Information Interchange based on a client server model, whereby the server is able to describe in detail the information of the underlying physical asset and also expose services that the client can use to consume that information. This exchange of data between client and server is conducted over TCP and HTTPS protocols. And both servers and clients can be deployed across different computing platforms, ranging from big servers to embedded devices with constrained computing resources. In addition to the client server model, the OPC UA specification was extended to cater for a publish subscribe pattern, whereby the OPC UA server broadcasts information to many clients that are subscribed to that piece of information.
