September 4, 2020 Articles OPC UA

What is OPC UA and How OPC UA Works

Now, any attempt to describe OPC UA would be incomplete without a brief history of the standard, for context.

So, it all started in the mid-’90s when there was a rapid rise in the use of software-based automation which relied on Windows PCs for visualisation 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 the PC, resulting in a large number of different 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. As a result, a group of automation companies came together to solve the 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 standardised 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 standardised interface without having to know specific driver details. That interface would be an OPC Server and the HMIs would be Clients consuming automation data from the server. And then, the device vendors would follow specifications to produce drivers that are understood by an OPC Server.

Now, as you can imagine, it would have been a lot of work coming up with a mechanism for communication. Lucky enough, It so happened that Microsoft already had a communication framework, called Component Object Model (COM), which enabled different applications to communicate with each other within the same PC. And there was also DCOM Distributed COM (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 .NET 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 include OPC Data Access or (DA) which allows OPC UA clients real-time reading, writing, and monitoring of process variables. OPC Historical Access for providing access to data already stored. And OPC Alarms & Events interface enabling the reception of event and alarm notifications.

And to this day, OPC is used as the main channel that enables the flow of automation data from PLCs and DCSes into SCADA and Historian. The diagram below shows a depiction of the relationships that OPC components have with each other.

So, the obvious implication here is that both the server and 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 smart phones e.t.c

This dependency on Windows became a disadvantage when the need for an OS independent standard became necessary. Also the fact that OPC 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.

But yet, there was an attempt to make OPC cross-platform by introducing OPC XML-DA to replace COM/DCOM with HTTP web services and allow for internet communication, but the project was not as successful due to some performance and resource consumption issues.

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 a total transformation.

Enter 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 (OPC UA).

Now, to give you a clearer picture of the differences, I’ve listed four characteristics that are at the core of OPC UA as a standard, and consequently, put it in a firm position to become the Industry4.0 standard of choice

Cross-Platform and Removal of classic OPC limitations

First of all, OPC UA does away with COM/DCOM dependence and requires that all OPC UA applications be deploy-able across different computing platforms which include Sensors, PLCs, embedded controllers, gateways, web applications, you name it.

Second, 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 an ability to securely and seamlessly exchange information over the internet.

Ability to expose complex data and complex system

Now, with Classic OPC you are only able to expose automation data in it’s purest form, for example, the value of pressure on an industrial machine.

On the other hand, using OPC UA Information Modelling capabilities, which we are going to discuss in a later email, 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 are able to expose the units of measurement, the current setpoints, the type of instrument used for measuring the pressure, it’s configuration parameters, its position in a hierarchy of a machine or plant components, and also define all other components of that machine or plant and how they are related to the pressure sensor in order to give the OPC UA client a holistic view of the plant information.

So, it’s not just pure information that you get as an OPC Client, but a total digital description of an underlying physical asset.

It’s important to note here that, even with its complex Information modelling capabilities OPC UA is still able to support simple data models as in classic OPC.

In fact, most individuals and organisations today still use OPC UA for simple data access. Not many are exploiting its information modeling capabilities

Based on Service Oriented Architecture(SoA)

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 master/server or slave, you have to send a specific bit or byte sequence.

Now, In as much as we have adapted to understanding bits and bytes as programmers and engineers, this is not a user-friendly way for exchanging information. Not only for humans but for other machines and digital systems needing to communicate with each other.

In contrast, an OPC UA Sever exposes services, in the form of methods, that a client can use to request information from the server. Consequently, These methods can be used for performing administrative tasks, e.g. the FindServer() method. And they can also be used for accessing actual automation data, for example, the ReadTag() and WriteTag() methods.

Now, I’m sure you can see how using a Service Oriented Architecture would simplify the engineering effort in terms of development and maintenance of communication systems, as methods can be easily read by humans and machines consuming automation data via OPC UA.

Simplified IT 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. Now, 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/sensor using Fieldbus 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 level applications.

Even better, OPC UA also makes it possible to run non-critical process logic from the cloud.

Below is a diagram that shows potential OPC UA uses cases across different levels of a manufacturing organisation.

You’ll notice here that, its commonplace to have a system that has both an OPC UA Client, for accessing other servers, and a Server, for exposing its own system

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 predecessor. It was created to solve problems that are entirely different from what industrial communication protocols are being used for.

How OPC UA Works

On defining the OPC UA standard, the foundation focused on two things:

How implementers of the standard would be able to describe the data to be exposed by the server.
How data would be transported between the client and the server.

In other words, Data Modelling and Transport Mechanisms are the two basic pillars of OPC UA.

As you will find out, 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.

OPC UA Transportation Mechanisms

Now, you’ll remember that classic OPC really didn’t define ‘end-to-end’ transportation, it simply acted as an interface to device drivers to allow HMI and SCADA systems to access data from different types of automation hardware.

In contrast, OPC UA was defined to act as a complete interface between systems, for example, directly interfacing between a PLC running OPC UA server with an HMI running OPC UA client.

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.

More of that is discussed in part 7 of this series.

But, as I highlighted before, the specification of transport mechanism is kept abstract in order to allow adding new protocols in the future.

OPC UA Data 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 a DA server.

On the other hand, OPC UA has a complete data modelling specification which defines the rules that OPC UA application developers must follow to expose a complex information model in an OPC UA server. The specification also defines how you can build a hierachy for the type of components that are found within your systems in order to expose them in the correct structure.

So in a nutshell, with OPC UA, we have a standard of information interchange based on 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 server and clients can be deployed across different computing platforms ranging from big servers to embedded devices with constrained computing resources.