The title is a frequently asked question that can be answered quite easily: "There is no fixed limit."
Nevertheless, there are various possibilities to minimize the performance demand of the OPCUA server and thus to lighten the load on the controller. The influence of hardware is ignored in this article.
All values refer to the online mode. Load peaks during login or browsing of the data points via the client are not examined. |
A Raspberry Pi 3 serves as controller and the Unified Automation UaExpert was used as client.
A POU with 1000 variables of type UDINT as created as a test project.
A value change can be switched on or off at the variables:
This POU can then be copied as often as required, working with 10,000 "prepared" variables.
The copied POUs are called using the code of PLC_PRG.
Simply providing the data points has no negative influence on the CPU load because the data is not used.
However, the compiler process takes longer.
In the test project, the CPU has a load of ~8%, whereby the monitoring of the CODESYS IDE is continuously active.
As soon as the client is connected, the load increases to ~9%, which is the base load.
When the first 1000 data points are activated by the client, the load increases to ~17%.
When we start the counter, we have a constant value change of the variable.
This increases the load to ~23%.
The measurement results with an increasing number of data points are summarized in the following table:
Number of data points | Subscribed data points without value change | Subscribed data points with value change |
|---|---|---|
| 0 | ~10% (base load) of the project | ~10% (base load) of the project |
| 1000 | ~17% | ~23% |
| 2000 | ~25% | ~35% |
| 3000 | ~30% | ~45% |
| 4000 | ~36% | ~55% |
| 5000 | ~41% | ~67% |
The first conclusion can be drawn as follows:
The next point, the sampling rate, can also be derived from this. |
The above measurement results are recorded with the default settings of the OPCUA client with an refresh rate of 500 milliseconds.
There are many values and parameters for which a slower refresh rate at the client has practically no influence.
As an example, a room temperature or preset/setpoints, such as the parameters of a PID controller, should be mentioned here.
Starting from the worst case in the above table, more and more data is now set to a lower sampling rate, while the others remain unchanged:
| Sampling rate / Number of data points | 0 | 1000 | 2000 | 3000 | 4000 | 5000 |
|---|---|---|---|---|---|---|
| 1000 | ~67% | ~65% | ~64% | ~62% | ~60% | ~59% |
| 2000 | ~67% | ~64% | ~62% | ~59% | ~58% | ~56% |
| 5000 | ~67% | ~64% | ~61% | ~59% | ~56% | ~54% |
A mixed operation of 1000 variables each with a sampling rate of 500, 1000, 2000, 3000, and 4000 milliseconds resulted in a CPU load of ~59%. The second conclusion can be drawn as follows:
|
The variables of a project can be combined not only in time-based groups via the OPCUA client, but also by data type on the controller.
For demonstration purposes, the program is extended a little bit:
This time as well, the values are recorded with and without the value being changed.
Again, the sampling rate is at 500 milliseconds.
| Number of data points | Without value change | With value change |
|---|---|---|
| 1000 | ~10% | ~11% |
| 2000 | ~10% | ~12% |
| 3000 | ~11% | ~13% |
| 4000 | ~11% | ~14% |
| 5000 | ~12% | ~14% |
Even if combining data points in different groups/arrays means more work in the actual project, this investment should be made for larger plants. |
Please note that all tests were performed with only one client connected. |
