Communication by the OPC UA interface

What is OPC UA?

OPC Unified Architecture (OPC UA) is a industrial M2M (machine-to-machine) communication standard.
This specification is defined and updated by the organization OPC Foundation (see https://www.opcfoundation.org).
Contrary to the original OPC specification that is based on the COM/DCOM technology by the Microsoft company (and therefore only functional in Windows OS) the OPC UA technology is based on commonly used communication standards like TCP/IP, HTTP and SOAP. It means that the OPC UA can work also on other platforms than Windows. OPC UA communication can also be built into PLCs and other devices.

The main requirements for the new standard were:

Contrary to OPC Classic that defines process data access (OPC DA), alarm data access (OPC AE) and historical data access (OPC HDA) separately, the new OPC UA does not define these specific approaches, but only the format of messages that are being transmitted. It means that the OPC UA standard allows transmission of all process data, alarms and historical data.

The OPC UA communication supports two protocols. For application designers, the difference is only in the URL:

Contrary to the network OPC Classic, the OPC UA communication does not require DCOM interface setup. OPC UA is a network communication by its basic principle. It means that it must employ mechanisms that provide network communication security. OPC UA communication uses electronic signatures (certificates) in order to provide authentication, authorization, encryption and data integrity.

OPC UA security

Each application - participant of OPC UA communication (OPC UA server, client or gateway) must have its own instance of application certificate, that unambiguously identifies the application and the device (computer) it is running on. OPC UA defines 4 basic levels of security:

Level 1 – no authentication In this case, both the client and server allow all communication. It means that all valid certificates are considered to be trusted. Application certificates provide only unverifiable information regarding the opposite side. The receiver has no means to verify the legitimity of the provider certificate. On this level, both sides automatically accept valid certificates even if these are not listed among trusted certificates. This security level does not require any setting on the client side or on the server side.

Level 2 – server authentication In this case, the server allows connection of any client. Client authentication (if required) is done by entering login name and password and sending these to the server after the communication channel is secured. All clients must trust the server certificate. This setting is done by Administrator on the client side (the server public key must be explicitly listed in the trusted certificate list, or the server certificate must be issued by trusted certification authority). If the server certificate is not explicitly listed in trusted certificate list, then the client has to compare the DNS name in the server certificate with the DNS name of the computer it is connecting to. This procedure cannot ensure that the client connects to the correct server (OPC UA), but it can ensure it connects to the correct computer. This procedure provides reasonable level of security (similar approach is used usually e.g. for personal access to internet banking Web sites), but the server cannot restrict access of client applications based on their authentication.

Level 3 – client authentication In this case, the client can connect to any server, but the server allows connection only of trusted clients. This approach is used in situations where the access must be granted only to trusted clients while there is no requirement of server legitimity. The server provides data only if the client certificate is trusted. This setup is done by system Administrator on the server (the client certificate must be explicitly listed in the trusted certificate list, or the client certificate must be signed by trusted certification authority).

Level 4 – authentication on both sides (client and server) In this case, both the client and the server allow connection only of trusted partners. This procedure provides highest level of security, but require setup on both sides (client and server). If the server certificate is not explicitly trusted, then the client follows the same way as on level 2. This approach provides highest security and therefore is recommended by the OPC Foundation to be used as default for all clients and servers.

Communication OPC UA in the PROMOTIC system using PROMOTIC driver

For this communication in the PROMOTIC system can be used:

Communication OPC UA in the PROMOTIC system using the converter to OPC DA

The OPC UA communication can be managed by means of the software converters OPC UA to OPC DA.
From the PROMOTIC system point of view, the usage of OPC UA converters is very simple - in the PROMOTIC system the PmaOpcDaClient object must be added, the OPC UA converter is then selected as server and then the desired variables are mapped in the PROMOTIC system.
OPC UA converter must be installed on the same computer where the PROMOTIC application is running (in order to avoid the network OPC communication).

1. General setting of software OPC UA converters:
In order to use these converters in the PROMOTIC system it is necessary to set them up correctly.
Following setting steps must be completed:

2. Recommended OPC UA software converters: