This stage explains what is the OPC UA communication protocol in the broad lines.
1. Introduction to OPC UA[edit source]
OPC UA[1] is a new standard in the world of communication protocols, created by the OPC Foundation[2] in 2015. The standard was developed with the emergence of IIoT and industry 4.0.
The main features of this protocol are the following:
- Each element of the system is based on a node structure.
- It supports Client/Server communication.
- It supports PubSub communication.
- OPC UA solves security issues that were present with MQTT for example.
2. OPC UA stacks[edit source]
As the OPC Foundation only defines OPC UA specifications, different industries are free to develop their own OPC UA stacks. The OPC Foundation itself gives the OPC UA certification if the stack meets all specifications. Thanks to this, two systems can easily communicate in OPC UA even if they were not developed with the same stack.
From our perspective, the decision was to work with open62541 which is an open source stack available on GitHub. For more information on the installation process of this stack for STM32MP1, refer to How to install OPC UA article.
3. What is OPC UA?[edit source]
3.1. OPC UA architecture model[edit source]
OPC UA communication is based on standard protocols layers like TCP/IP for Client/Server communication. For PubSub communication, it can use both TCP/IP and UDP/IP communication layer. Moreover, this technology has also been adopted to adapt to real-time and TSN technology.
PubSub communication can also be based on already existing protocols such as MQTT or AMQP, although UADP is still the most frequently used.
Regarding the information model, as explained in the introduction, the OPC Foundation expects a node organization of data. This is explained in the later part.
Finally, in the Application zone are the different functions proposed by the APIs of companies' stacks, which allow to use OPC UA functionalities.
3.2. Node organization[edit source]
When using OPC UA, it is important to respect a node organization for our system. Each node can contain other nodes, and are represented in this way:
- an ID
- a name
- a value
- some W/R rights
- ...
This node organization offers a clean data model, and is used by OPC UA to manage information in the system, or between different systems.
3.3. types of communication[edit source]
As explained, OPC UA offers two principal ways to communicate, Client/Server and PubSub. Below are the two ways to communicate.
3.3.1. Client/Server[edit source]
The aim of this type of communication is to target another OPC UA system by its IP address and to read or modify information in its node data model. To take an easy example, look at the picture below.
3.3.2. PubSub[edit source]
The aim of PubSub is to give an entity the possibility to share some information in its nodes to all other entities that want to be updated when they change. This type of entity is called a Publisher. Entities which subscribe to these information are called Subscribers. Note that an entity can be both Publisher and Subscriber at the same time. An important aspect of PubSub pattern is that Publishers and Subscribers do not know each other. It means that replacing a Publisher by another one that does the same thing is not noticed by the Subscribers.
The abstraction zone between Publishers and Subscribers is called PubSub channel and it is a part of your local network. This is considered as the Middleware of your system.
In this Middleware, data are organized into different topics which can contain one or more information.
According to OPC UA specifications, there are two different types of PubSub:
- PubSub broker-less
- PubSub broker-based
Both of these configurations are used depending on the project that is under construction.
3.3.2.1. PubSub broker-less[edit source]
In the case of PubSub broker-less, both Publishers and Subscribers send/receive the information through a UDP multicast port contained in the local network (eg. 224.0.0.22). This communication configuration is quite easy to build, and respect the fact that both entities do not know each other. Moreover, this communication is fast because UDP packets do not pass through another program which manages messages.
However, this solution raises an issue: the man of middleware. If someone listen on the same UDP multicast port, and know how to translate OPC UA messages, he can have access to all communications. The PubSub broker-less is therefore not recommended when manipulating some sensitive data, or when your system represents a human or material threat. Nevertheless, it it possible to partially secure this system by using a group key which is an analog to symmetric encryption. It means that each message will be encrypted with the same key, and decrypted by the same one.
3.3.2.2. PubSub broker-based[edit source]
In the case of PubSub broker-based, both Publishers and Subscribers send/receive the information through another program located at the middleware zone, called broker. Its role is to manage communications, and more particularly different subscriptions, publications of information etc. With its central manager role, our system is now like an OPC UA server (the broker) with some OPC UA clients (Publishers and Subscribers). By comparing this way to manage the communication with the previous one, it is easy to understand that the communication looses speed because of its new intermediate passage.
However, in term of security, it is possible to go further than with broker-less model. Here each Publisher of the system can have its own private key, and communicate its public one with the broker. Regarding the broker, it also has its own private key and can communicate its public one to each Subscribers. Ultimately there is now a double encryption which is much more secure than with broker-less. Moreover, a certificates management can be added in order to recognize if a program is allowed to communicate with the broker or not. If a program is allowed to communicate with the broker, with a valid certificate, it is then part of the security group.
4. Why choosing OPC UA?[edit source]
OPC UA gives some benefits that improve different aspects of your projects:
- It offers some coding comfort because the communication part is well designed in most of OPC UA stacks to facilitate the information management between the different systems of your project.
- It offers a good scalability because the protocol is already made, to add elements in your system very easily. Moreover, it allows to quickly add new shared information in one or more programs.
- It has a good speed performance, which is useful when dealing with different systems which have to be updated at high frequency.
- It begins to be a standard in the world of communication protocols, so as not to depend anymore on suppliers who sell their OPC UA products.
5. References[edit source]