01 Overview
OPC UA is an industrial communication protocol that has developed since 2008 and has become very popular in the industry today. This article aims to introduce some concepts of OPC UA and share some related experiences, hoping to be beneficial to friends engaged in OPC UA-related work.
02 OPC UA Information Model and Unified Architecture
Some friends often say that the reason why OPC UA has become so widespread is because it is cross-platform. Personally, I don’t think that’s a sufficient condition. I believe the reason OPC UA has become so widely accepted is because its unified architecture and information model are exceptionally well-designed. The OPC UA information model is derived from the object-oriented programming (OOP) concept, which is most aligned with actual needs.
Suppose there are several air conditioning units that need monitoring on an industrial site. First, we need to monitor its temperature, humidity, and operation status; next, we need to perform start and stop operations; then we need to receive non-stop accident alarm information; finally, we often need to analyze operational parameters for a certain period to determine the condition of the air conditioning. Applying the idea of object-oriented programming, we create a class—air conditioner—in which we define respective attributes, methods, and events. The attributes can be simple data or complex structures. This class can be understood as the OPC UA information model. OPC UA manages these real-time data (DA), historical data (HDA), and accident alarm data (A&E) on the same platform, which is the unified architecture.
>
>
How effective is communication using this model? Let’s do a simple demonstration. In the demo server produced by the unified automation company, several air conditioners have already been defined. We monitor them through the company’s client UA Expert. On the left side of the menu bar, the properties, methods, and events of this air conditioner are listed; on the right side, it only monitors the temperature, humidity, and operating status of the air conditioner. At this time, the air conditioner is in the OFF state. If the air conditioner needs to be started and the target temperature set to a comfortable 25°C, you only need to call the StartWithSetpoint method and enter the target value in the dialog box.
When monitoring events and alarm information, create an event view and subscribe to the air conditioner’s events. If the air conditioner’s start and stop status changes, it will trigger an event; if the air conditioner is in the OFF position, it will trigger an alarm, which can also be confirmed on the client side.
Finally, if a historical storage function for an air conditioner’s attribute is enabled on the server side, historical data can be read on the client side after a period of storage.
This is the charm of the information model and unified architecture, making a communication software feel like an HMI.
Of course, OPC UA’s information model is not unique in the industrial control field. The thing model in PTC’s IoT platform Thingworx and Rockwell’s CIP also use similar object-oriented models. As the saying goes, good designs are all alike, while every bad design is ugly in its own way.
03 OPC UA’s Security
Initially, industrial communication protocols prioritized speed and stability. At that time, to ensure system security, many networks were isolated from external networks. Since they were physically isolated, the protocols had no security design. Back then, with limited processing capacities of chips, conducting encryption and decryption calculations would consume a lot of resources, so security was sacrificed for timeliness. Think about the Modbus protocol. If you could connect to the network using ModScan, couldn’t you easily modify the data of Modbus slaves without any user authentication or access control? You could also use packet capture software like Wireshark to easily analyze these plaintext data packets. One could say that the system was completely running in a nude state.
However, since the system was isolated from the outside world, if someone wanted to attack, they would need to deceive the guard at the gate, dodge the big dog, run into the workshop, pry open the control cabinet, connect to the network, and then use hacking techniques. But if you’re that good, wouldn’t pouring a bucket of water on the controller in a physical attack be more efficient?
Yet now the situation has changed because industry networks wish to embrace the Internet, integrate OT and IT, and develop the Industrial Internet of Things (IIOT). Therefore, under these demands, security has become the top requirement. Just as Dr. Wang Jian said: Security is the lifeline of Internet companies. The communication process faces numerous external security threats, such as information leakage, instruction tampering, unauthorized operations, forged replay, and flood attacks, among others. To counter these threats, OPC UA employs encryption, signature, user authentication, access control, session management, and other methods to achieve in-depth defense.
OPC UA security is recognized in the industry, but there is no absolute security in any protocol in the world. Synopsys found some issues while testing some industrial communication protocols. So, OPC UA security still has some work to do. To wear the crown, it must bear its weight.
04 OPC UA and the Internet of Things (IoT)
The Internet of Things is a hot topic and truly impacts and transforms our lives. From the above example of OPC UA monitoring an air conditioner, we can see that the OPC UA protocol is elegant and efficient in monitoring and controlling things. Together with robust security, it makes it a prime candidate to be a mainstream IoT protocol. OPC UA supports HTTPS well, allowing it to send XML or JSON formatted data when used with HTTPS.
Many IoT platforms now also support OPC UA, such as Azure abroad and Alibaba Cloud domestically. The image below shows a configuration interface of Alibaba Cloud that allows you to select OPC UA as one of the access gateway protocols.
However, OPC UA’s initial one-to-one query and response model between client and server is most suitable for scenarios with fewer communication nodes and a large, stable, continuous amount of communication information. In IoT application scenarios, communication nodes are often more numerous, but inter-node communications tend to be limited, sometimes requiring one-to-multiple or multiple-to-one communication. Continuing to use a one-to-one model to embrace IoT would likely fall short. Thus, OPC UA introduced a pub/sub mechanism, combining someMQTTprotocols to better support IoT scenarios. The related white paper was released in 2018; interested readers can download it from the official website to check the details.
05 Common OPC UA Debugging Tools
Whether developing OPC UA products or debugging on site, some debugging tools are often needed. These tools include clients and some simulation servers. Manufacturers like Matrikon, IntegrationObjects, and unified-automation provide these, which can be downloaded for free from their official sites, and are easy to use. Here, I recommend unified-automation’s debugging tools, UA Expert and UA server.
When debugging communication products, packet capturing and message analysis are very effective methods. For OPC UA protocol, using the packet capture tool Wireshark is strongly recommended. Wireshark’s support for OPC UA is very comprehensive, having included OPC UA in its supported protocol list, with a default port of 4840.
Open Wireshark, then perform some operations in OPC UA, such as browsing nodes. At this time, details of the browse request can be seen in Wireshark, instantly making all the details clear when compared to the fourth part of the white paper. Thus, with Wireshark in one hand and the OPC UA white paper in the other, one can smoothly progress from beginner to expert in two days. (In fact, this method can be applied to learning any network protocol: with a protocol parser in one hand and a white paper in the other.)
06 OPC UA Open Source Libraries
Besides the debugging tools mentioned above, many OPC UA open source libraries have emerged online, developed in various languages. This also shows that OPC UA’s ecosystem is excellent. Skillfully using these libraries can greatly enhance the efficiency of developing and testing products, such as performing certain function tests, regression tests, performance tests, fuzz tests, etc.
Here, I introduce two open-source libraries that I personally favor:
python-opcua: Source code URL: https://github.com/FreeOpcUa/python-opcua
Advantages: Its greatest feature is simplicity; installing it with pip install opcua is all it takes. Over the years of updates, its support for the OPC UA protocol is becoming more comprehensive, supporting both server and client. Below is an example from the official website, where a server containing a dynamic point can be created with less than 30 lines of code.
Disadvantages: The performance of this library is somewhat lacking; some services defined in the OPC UA protocol standard are not yet supported. Finally, some bugs were found during use.
UA-.NETStandard: Source code URL: https://github.com/OPCFoundation/UA-.NETStandard
Advantages: This library is authored by the OPC Foundation, containing both server and client. It can run on Windows, Linux, iOS, and Android. Its performance is excellent, having been officially certified by the OPC UA laboratory, so its support for the OPC UA protocol standard is naturally comprehensive.
Disadvantages: From an industrial control perspective, it requires some C# programming skills. It’s a bit slower to get started compared to the Python library. There are also some sample projects on GitHub, which can be modified based on one’s development and testing needs.
07 Summary
It can be said that OPC UA’s unified architecture is truly all-encompassing, capable of handling real-time data, historical data, going cloud, embedding into controllers, and even being wrapped into PLC function codes, reaching into every corner of the industrial control communication industry. It’s true what they say: reaching for the moon with one hand, catching turtles with the other. This ambition can be seen from its over 14-volume white paper.
Moreover, OPC UA is still a growing protocol, with many functions under expansion, such as integration with TSN technology, planning to do something at the data link layer.
As a bystander, I sometimes feel that it aims not only for a unified architecture but desires to dominate the field. But there’s no perfect thing in the world; what are the weaknesses of such a large and comprehensive architecture, and how will they be addressed? Feel free to share your thoughts!
Author Introduction
An Ordinary Programmer:
Over ten years of experience in industrial control, worked in the chemical industry, power sector, dealt with DCS, and worked with PLCs. Currently transitioning from OT to IT.