Do you work in industrial automation, do you often hear about OPC UA and want to understand what it is and how to use this protocol?
You’ve landed in the right place!
In this series of articles we’re going to take a closer look at what OPC UA is and how you can develop client and server applications using the .NET API provided by the OPC Foundation.
I’d say let’s start with a brief introduction to the platform!
Up until the 1990s, when you needed to integrate an industrial device into a GUI, you first had to figure out which protocol to use.
Although widely used protocols already existed, the devices to be integrated often used different ones, making the developer’s job very expensive.
Since the graphical interfaces were in all cases developed in Windows environment, it was decided to simplify life by introducing a new communication platform, used today, called OPC (Open Platform Communication).
OPC is based on Microsoft’s proprietary COM (Component Object Model) and DCOM (Distributed Component Object Model) interfaces which allow communication between running processes.
Thanks to these, the HMI developer can communicate with an OPC Server that acts as an interface with external devices.
The manufacturer of an industrial component simply has to develop an OPC Client communication driver to make its integration much more immediate.
The transmission of data between client and server in OPC Classic is done through different interfaces defined according to the purpose, the main ones are:
- DA (Data Access): allows clients to read, write and monitor variables in real time;
- HA (Historical Access): used to access already stored data;
- A&E (Alarms and Events): manages alarms and event notifications.
Over the years, the use of Unix devices in the industry quickly led to the need to extend the functionality of this platform that was otherwise only applicable to Windows systems.
In addition to this, OPC Classic was a poor tool for data exchange, allowing only primitive data types to be transferred.
Around 2008 was born, therefore, the second version called OPC Unified Architecture which, among many other things, offers:
- Full compatibility with the most popular operating systems (Windows, Linux and Mac);
- Support for Internet protocols for distributed communication;
- description of complex data models with an approach very similar to the OOP paradigm;
- possibility to expose remote methods;
We can say that OPC UA is based on 3 fundamental pillars: the transport mechanism, the management of calls to remote methods and the data description model.
Regarding the first point, OPC UA supports both a TCP-based binary protocol that guarantees high performance in transmission, and two widely used web communication protocols such as HTTPS and SOAP.
This allows to extend the previous version, adding in fact the possibility to communicate also via Internet between different devices.
The possibility, then, to call remote methods, makes the protocol an incredible tool to expand the potential of devices such as PLCs. For those who don’t know, the PLC is a programmable controller widely used in industrial automation for its reliability and stability. On the flip side, PLC systems are very crude and don’t offer the same possibilities that a PC can provide.
To give an example, if we wanted a PLC to write to a database, we would have to use a PC as a mediator and then implement complex (and difficult to manage) methods to allow communication between the PLC and the PC.
OPC UA in this sense, extends the features of PLCs, making it simple and immediate to call remote methods.
A PC with an OPC Server, therefore, can expose more or less sophisticated methods, such as database read/write functions, that can be evoked by the PLC when needed.
Talking finally about Data Modeling, OPC UA offers a complete modeling system that allows to describe data of variable complexity.
This is undoubtedly the most important strength of the whole platform as it is possible to create systems in which data exchange takes place with a completely decentralized infrastructure.
To better understand the implications of what has just been said, it is necessary to introduce the concept of the automation pyramid.
The automation pyramid is a structure that describes the different levels of automation in a production plant and is an excellent example of how technology is interpreted in industry.
At the base of the pyramid we have the field level. This represents devices, actuators and sensors that are installed in a production line.
The next one is called the control level. In this case we refer to PLCs and PIDs, those devices that are responsible for managing the field level. A PLC, for example, will collect data from sensors installed on the line, send commands to actuators, and make decisions about what logic to execute.
The third level of the pyramid is called the supervision level. If in the previous one we made use of PLCs, in this case we make use of SCADA (Supervision Control and Data Acquisition).
A SCADA is nothing more than a tool that combines the previous levels allowing you to view data and control elements in the field from a single point. Normally, this is also possible with the help of an interface, known as an HMI.
There is a tendency to often confuse SCADA with HMI, this is because most of the time these two entities are merged together.
To understand the real difference, it is worth remembering that a SCADA can monitor and control several systems installed in a plant and is not limited to a single machine as is the case with HMIs.
The fourth level of the pyramid is called the planning level. Here we make use of systems known as MES (Manufacturing Execution System) which have the task of monitoring the entire production process in a plant: from the raw material to the finished product.
The last level is called management level. In this case, systems called ERP (Enterprise Resource Planning) are used.
OPC UA and Smart Manufacturing
A structure like the one just presented is necessary when dealing with devices that are only capable of transmitting raw data.
These, before being presented at a higher level, must be collected and interpreted.
With the advent of the Industry 4.0 concept, this vision is gradually being supplanted by another totally decentralized structure also known as smart manufacturing.
The idea is to have devices that are sophisticated enough to send data independently to the various control tools, SCADA, MES or ERP.
In this way, for example, instead of leaving the PLC the burden of collecting data from dummy sensors, and then organizing the information and presenting it to the SCADA plan, you can let the sensors themselves send complex data directly to SCADA, leaving the PLC with the sole task of managing the progress of production.
In order to do this, it is essential to have a communication protocol that can handle complex data.
This is where OPC UA comes in and changes the game, allowing information to be represented in units called nodes.
To draw a parallel in OOP terms, a node is nothing more than a class which can be composed of attributes and methods.
Like a class, each node, once described, can be instantiated into different objects giving rise to models of increasing complexity.
In this article we have made a brief excursus purely theoretical on what is OPC UA and what are its strengths.
In the next articles we’re going to analyze more in depth the features of data modeling, creating a model describing a simple production line and publishing this model on an OPC Server designed with the .NET libraries provided by OPC Foundation.
We will continue our journey then with a further article where we will see how to develop a simple OPC Client, always based on the same libraries.