Optimizations

There are various ways to optimize the communication connection between OPC UA client and server or PLC. The runtime behavior, in particular the CPU and memory load of the TwinCAT OPC UA Server, can also be optimized using various parameters. This chapter presents various optimization options, in particular on the following topics:

• SamplingInterval vs. PublishingInterval
• StructuredTypes
• StructuredTypes and their member variables

The screenshots and performance values shown here represent examples under laboratory conditions, which were run on different hardware devices. Therefore, they cannot be transferred 1:1 to customer projects and only serve to illustrate certain facts.

SamplingInterval vs. PublishingInterval

When creating a subscription, an OPC UA client uses various parameters for the subscription and the so-called MonitoredItems contained in it to receive notifications about variable changes. The following table explains two of these parameters, which will then be described in more detail.

The following figure illustrates the relationship between these two parameters once again. It is assumed here that the TwinCAT OPC UA Server has been installed on the PLC controller and that the OPC UA client accesses the server from an external system.

As can be seen in the figure, the situation can arise that the OPC UA client does not notice certain value changes in the PLC, e.g. if they happen "too fast" in the PLC or the sampling rate is not high enough or a variable value returns to the original value (as can be seen above). Via another parameter, the so-called QueueSize, several value changes between the PublishingIntervals can be recorded and transferred to the OPC UA client. In the above example, a QueueSize of 1 was selected, i.e. the "Last Known Value" is always transferred to the client. In the following figure, on the other hand, a QueueSize of 2 was selected, i.e. the last two known value changes are transmitted to the client.

With the first PublishResponse it can be seen that only one value change is transmitted to the client, because also only one value change has taken place in the PLC. With the second PublishResponse it can be seen that two value changes have occurred in the PLC and both are also transmitted to the client.

The parameters described above are settings that the client usually controls and requests from the server. And it is exactly here that many optimizations can be made, because both parameters have a strong influence on how much CPU time the OPC UA client and server need, since a corresponding amount of information has to be processed or requested.

Depending on the application scenario used, the two parameters should be set appropriately. For example, if the OPC UA client is a visualization, then fast PublishingIntervals and SamplingRates make only limited sense, since the human eye cannot process information faster than ~200 ms anyway. The use of the QueueSize should also be chosen sensibly depending on the situation. If the OPC UA client does not process any values from the queue anyway, a QueueSize of 1 is sufficient and makes sense, since correspondingly less information has to be transferred and this further optimizes the system.

In the following example an OPC UA client has created a subscription with 10,000 variables on the TwinCAT OPC UA Server. 500 ms was selected as the PublishingInterval and 250 ms as the SamplingInterval. The CPU load of the TwinCAT OPC UA Server was at an average value of about 6.9%, see the following screenshot of the Windows Performance Monitor.

Then the PublishingInterval was set to 200 ms and the SamplingInterval to 100 ms. This increased the CPU load of the TwinCAT OPC UA Server to an average value of approx. 19%.

StructuredTypes

By default, the TwinCAT OPC UA Server provides structures as FolderType in its address space. The member variables are then displayed as separate nodes below the folder and can be accessed. The server also allows the use of StructuredTypes for the structure, whereby the type information of the structure is processed by the client and the structure can be read/written in a data-consistent manner. When communicating with the PLC (via the TwinCAT ADS protocol), the two variants behave fundamentally differently.

When an OPC UA client accesses individual member variables, the ADS communication may well be split into multiple ADS read/write commands, depending on the number of variables. This in turn can result in the ADS commands being processed by the PLC in different PLC cycles. Data consistency cannot therefore be guaranteed.

When an OPC UA client accesses a StructuredType, on the other hand, it is ensured that the StructuredType is processed by the PLC in a single ADS Read/Write command, thus ensuring data consistency.

When using StructuredTypes for large PLC data structures, the following should be considered:

• Depending on the structure size, the ADS read/write command or the corresponding response can become very large and require a correspondingly large amount of memory in the TwinCAT ADS router. Therefore, please pay attention to the router memory.
• StructuredTypes must be encoded or decoded by the TwinCAT OPC UA Server when communicating with the TwinCAT real-time environment, which requires additional CPU time.
• Depending on the size of the structure, read/write commands can take a long time, which is also heavily dependent on the time the server needs to encode/decode.

For these reasons, the maximum size of a StructuredType is limited in the delivery state of the server, but can be adjusted as required using the parameter <MaxStructureSize> in the configuration file TcUaDaConfig.xml. This parameter specifies the maximum size of a structure in bytes. If a structure exceeds <MaxStructureSize>, it is imported as FolderType, where each structure element is available as a single node. For more information, see the chapter Structures.

Especially in connection with the parameters for the SamplingInterval and PublishingInterval that can be set for a subscription, some optimizations can be made with StructuredTypes, which can have a major influence on the runtime behavior of the server.

In the following sample, an OPC UA client has created a subscription to a StructuredType. The lower-level PLC data structure is structured as follows:

TYPE ST_TEST :
STRUCT
  stComplex : ST_Complex_1;
  strString5 : STRING[5]; 
  eEnum : E_Enum_1;
  strString3 : STRING[3]; 
  arrComplex : ARRAY[0..9999] OF ST_Complex_1;
  arrDint : ARRAY[0..9999] OF DINT;
END_STRUCT
END_TYPE

The structure ST_Complex_1 used as member variable is about 91 bytes. In total, this is a data structure with a size of about 1 MB. 500 ms was selected as the PublishingInterval and 250 ms as the SamplingInterval. The CPU load of the TwinCAT OPC UA Server after creating the subscription was at an average value of about 54.6%, see the following screenshot of the Windows Performance Monitor.

According to the selected SamplingInterval, an ADS Read is sent every 250 ms for the lower-level ADS communication. In the corresponding response you can clearly see the size of the data structure of approx. 1 MB, i.e. every 250 ms a 1 MB data packet is transported through the TwinCAT ADS router (and must be processed accordingly by the server). The encoding/decoding process from the server requires a lot of CPU power, which explains the high CPU load.

StructuredTypes and their member variables

By default, the member variables of a StructuredType are represented and made available as separate nodes in the server's address space. This requires additional main memory, because the TwinCAT OPC UA Server allocates main memory for each node. An OPC UA client that works exclusively with the StructuredType, i.e. the "root element" of a structure, does not require these additional nodes. These can be explicitly hidden using a special pragma, which reduces the server's memory load. The pragma is described in more detail in the chapter Structures.