The fact that communication between the OPC UA server and the OPC UA client can now be encrypted is a feature that also has disadvantages.
This affects establishing connections as well as power requirements during operation.
It was tested with a weaker device – the Raspberry Pi 3 – in which the results can be seen more clearly.
UaExpert was used as the OPC UA client.
The measurements were performed manually and the variables changed their value in cycles (worst case scenario).
Establishing communication
When creating a server certificate for a CODESYS controller, you can determine the length of the encryption:
A temporal difference can already be noticed when the certificate is created.
Depending on the length of the key, the following times may result when establishing communication:
| Variable count / Key length | unencrypted | 2048 | 3072 | 4096 |
|---|---|---|---|---|
| 1000 variables | ~ 1 Sek. | ~ 6 Sek. | ~ 16 Sek. | ~ 25 Sek. |
| 2000 variables | ~ 2 Sek. | ~ 8 Sek | ~ 18 Sek. | ~ 26 Sek. |
Depending on the client, it may not be possible to establish a connection to the controller.
The "ConnectionTimeout" in UaExpert has to be edited (default setting: 10 seconds):
The device is running at full capacity when the connection is established. => CPU load: ~ 100%
To illustrate how strongly the influence depends on the device, here is a connection from an OPC UA client to a CODESYS Control Win V3.
With 1000 variables and a key length of 3072 bits, this takes approximately 1 second:
Normal operation
Even during normal operation, the encryption requires a little more computing power, as the following table shows:
| Variable count / Key length | unencrypted | 2048 | 3072 | 4096 |
|---|---|---|---|---|
| 1000 variables | ~ 23 % | ~25 % | ~ 25 % | ~ 25 % |
| 2000 variables | ~ 35 % | ~ 39 % | ~ 40 % | ~ 40 % |