The future of engineering lies in universal communication standards, one of which is well worth paying attention to – the OPC UA protocol (also known as OPC Unified Architecture). What do you need to know about it? Is it necessary to read the voluminous documentation before using it?
One such universal standard is the subject of this article – the OPC UA (Open Platform Communications Unified Architecture) protocol, which was developed and continuously improved by the OPC Foundation[1]. The protocol specification is quite lengthy – written in twenty-three parts in large PDF files, which may initially seem overwhelming.
However, where there’s a will, there’s a way – I have walked down this path, so I will share the most relevant elements to grasp the concept of the solution and, in doing so, point out a few aspects you might want to bear in mind when adding support for the OPC UA standard to newly-designed or existing systems.
OPC Unified Architecture is a universal communication standard aiming to unify how data is exchanged between machines, controllers, IoT devices, or monitoring applications. The protocol defines a client-server architecture and is the successor to pre-existing protocols known collectively as OPC Classic. OPC UA integrates the functionalities of the protocols included in OPC Classic while also making them independent of any specific operating system or hardware platform. The OPC UA server can be successfully implemented on industrial computers, mini SBCs (Single Board Computers), or microcontrollers. One of the applications of the standard is the integration of multiple systems, often provided by various manufacturers, in a single operator panel, as shown in Image 1.
Another exciting application of the standard is to make available, universally and standardized, the state of an IoT system that communicates internally in a different way, e.g., via low-power protocols such as LoRaWAN or Wi-SUN.
In this text, I have focused on select aspects of the OPC UA protocol: the information model, the communication stack, and the security of the transmitted data, which are described in the fifth[4], sixth[5], and second parts of the standard[3] respectively.
The full protocol specification can be downloaded from the OPC Foundation website (registration required).
An information model, in the sense of the OPC UA standard makes it possible to describe the objects and processes that make up a particular system. It also describes the relationships between them. Several properties characterize each object. The easiest way to illustrate this is with an example.
Image 2. Information model of an example factory.
The diagram in Image 2 shows an information model of a hypothetical factory. The factory contains two machines of the same type, which include two sensors and two actuators. Each sensor has unique properties, such as a serial number or the value of the last measurement. The actuators additionally have methods to start or stop specific processes. A particular type of data is assigned to each object’s property. In this example, the sensor’s serial number is stored as a string, and the measurement value is a 32-bit number with a sign (int32). Specifying the information model in such a way is one of the steps that must be performed in order to implement OPC UA standard-compliant communication to the selected system or controller. The OPC Unified ArchitectureUA standard’s comprehensive nature also specifies the notation in which the information model should be created. It is described in detail in the third part of the standard.
OPC UA is a service-oriented standard, and its communication stack can be seen as a set of services performing specific functions, such as data encoding, encryption, or transport. These services form the subsequent layers of the communication stack and can be implemented by different protocols. Image 3 illustrates the layers of the stack, with their tasks outlined below:
This approach makes the standard flexible and allows it to adapt to changing market needs. For instance, if new and better security protocols emerge as technology evolves, only one layer of the stack needs to be replaced without affecting the others. The current standard version defines several different communication profiles that accurately specify the protocols used at each layer. All of them are described on the OPC Foundation page. Examples of three profiles with their names are shown in Image 4.
When incorporating support for the OPC UA standard into your system, you need to decide which profile you want to support. It would be best if you aimed to keep them all, but due to the time-consuming nature of implementation or limited hardware resources, this may be complicated. In practice, Profile 1 seems to be the most popular, especially in the world of embedded systems – it provides better performance and uses fewer resources than the others.
The security of the OPC UA connection is closely related to the specific communication profile. For instance, Profiles 2 and 3 use the TLS protocol to ensure a secure connection, which specifies its own cryptographic algorithms and is not part of the OPC Unified ArchitecturUA standard. In this text, I have focused on the security policies set by the standard and implemented by the UA SC (UA Secure Conversation) protocol.
The standard specifies the three levels necessary to set up a client-server connection. These are illustrated in Image 5 and listed below:
For both the session set-up and the secure channel, credentials are required.
The purpose of the secure channel is to ensure the integrity and confidentiality of the information exchanged, as well as to verify the authenticity of the communicating applications. At the session level, on the other hand, it is essential to authenticate a specific user attempting to connect to the server and verify their credentials. In order to set up a secure channel, a security mode and policy must be defined. The available modes are ‘None,’ ‘Sign,’ and ‘SignAndEncrypted.’ As the names of these modes indicate, they determine whether the messages exchanged should be signed and encrypted. Security determines the cryptographic algorithms used to sign and encrypt messages, among other things. Example policies are shown in the table.
| Security policy | Security level | |
| 1 | Basic256Sha256 | High |
| 2 | Aes256Sha256RsaPss | High |
| 3 | Aes128Sha256RsaOaep | Medium |
| 4 | Basic128Rsa15 | low |
To enable the policies mentioned above to work, each party of the communication should have its own x509 certificate, signed by the CA and trusted by the other party. In addition, each party should have a private key complementary to the public one contained in the certificate. Thus, determining the supported cryptographic algorithms, the public key infrastructure, or the way the private key is stored are other essential elements to consider when implementing the OPC UA standard in your own IoT system.
The protocol elements that I have indicated above allow you to understand the concept of the solution and are an excellent introduction to further deepen your knowledge of the OPC UA standard. We have not completely covered the topic, but let this text be a good start for those who are interested in the ins and outs of the OPC UA protocol.
Keep in mind that when planning to implement this type of communication into your own system, you should first prepare its information model. You should then decide on the communication profile and security policies, making sure they are aligned with the market’s needs and requirements. The next step would be to decide how to implement the OPC UA protocol in your own system, but that is a topic for another article.
