What is OPC UA?
OPC Unified Architecture (OPC UA) is a new industrial M2M (machine-to-machine) communication standard developed by the OPC Foundation
. Compared to the original OPC specification that is based on the COM/DCOM technology by Microsoft (and therefore only functional in OS Windows
) the OPC UA technology is based on commonly used communication standards like TCP/IP
. This 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:
- platform independence
- multi-threaded, as well as single-threaded/single-task operation
- security based on new standards
- configurable time-outs for each service
- chunking of big datagrams
Compared 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. This 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 desigers, the difference is only in URL:
- binary protokol URL specification: opc.tcp://Server
- WEB service (SOAP) protocol: http://Server
Compared to the network OPC Classic, the new OPC UA communication does not require DCOM interface setup. OPC UA is a network communication by its basic principle. This means that it must employ mechanisms that provide network communication security. OPC UA communication uses electronic signatures (certificates) in order to provide authorization, encripting and data integrity.
OPC UA security
Each application - participant of OPC UA communication (OPC UA server, client or gateway) must have its own installation 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 server and the client 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 although these are not listed among trusted certificates. This security level does not require any setting on client side or on server side.
Level 2 – server authentication
In this case, the server allows connection of any client. Client verification (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 setup 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 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 side (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 verification procedure 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.
OPC UA communication in PROMOTIC system
Although the PROMOTIC SCADA
software currently does not include bult-in OPC UA
client, the OPC UA
communication can be managed e.g. by using the specialized software of the OPC UA
gateway/proxy type. The PROMOTIC system has been tested with OPC UA GW
software manufactured by the Unified Automation
company. OPC UA GW
works as a two-way converter between OPC
classic and OPC UA
From the PROMOTIC software point of view, the usage of OPC UA GW
is very simple. OPC UA GW
must be installed on the same PC where the PROMOTIC software is running (this way it is not necessary to configure network OPC
communication via DCOM
). In the PROMOTIC software it is then necessary to add new PmOpcClient
object, select the corresponding OPC UA GW
server and map the variables (the same way as with other OPC
See OPC UA Gateway - Installation and setup