Application Note:OPC UA Communication with ALTUS Controllers

Code: NAP165 Revision: B

Application Note NAP165

OPC UA Communication with ALTUS Controllers

List of Contents

1. Introduction ............................................................................................................................. 2
2. Employed Software and Firmware Revisions ....................................................................... 2
3. Configurations of OPC UA Server in Controllers .................................................................. 2
3.1 Configuration of OPC UA Variables ......................................................................................................... 2
3.1.1 Types of Supported Variables ................................................................................................................. 3
3.1.2 Maximum Count of OPC UA Variables ................................................................................................... 4
3.2 Cybersecurity Configurations .................................................................................................................. 5
3.2.1 Configuring Cryptography in Nexto Controllers ....................................................................................... 5
3.2.2 Example of Configuration of Cryptography in a OPC UA Client (UaExpert) ........................................... 5
3.2.3 Removing Cryptography from a Nexto Controller ................................................................................... 6
4. Basic Concepts for OPC UA Protocol ................................................................................... 6
4.1 Implemented Subset in Nexto Controllers .............................................................................................. 6
4.2 Subscriptions (Variables Reported by Exception) ................................................................................. 7
4.3 Groups of Variables Reported by Polling ............................................................................................... 8
5. Main Communication Parameters Configured in OPC UA Clients ...................................... 8
5.1 Endpoint URL ............................................................................................................................................. 9
5.2 Publishing Interval (ms) and Sampling Interval (ms) ............................................................................. 9
5.3 Lifetime Count and Keep-Alive Count ................................................................................................... 11
5.4 Queue Size and Discard Oldest ............................................................................................................. 12
5.5 Filter Type and Deadband Type ............................................................................................................. 13
5.6 PublishingEnabled, MaxNotificationsPerPublish and Priority ........................................................... 13
6. Performance Analysis .......................................................................................................... 14
6.1 Ethernet Bandwidth Consumption ........................................................................................................ 14
6.2 CPU Processing Consumption .............................................................................................................. 15
6.2.1 Results of Test Scenarios ..................................................................................................................... 16
6.2.2 Qualitative Conclusions Using Test Scenarios ..................................................................................... 17
7. Revisions ............................................................................................................................... 19

Altus S.A. Page: 1

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

1. Introduction
This application note addresses several aspects related to OPC UA communication with ALTUS
controllers that support an OPC UA server, that is, Nexto series controllers.
Among the described aspects the following are addressed:
 Configurations of OPC UA server using the Mastertool IEC XE programmer;
 Cybersecurity configurations (cryptography);
 Main configuration parameters negotiated with OPC UA clients and their effects in the behavior
and performance of communication;
 Performance analysis of OPC UA communication, considering CPU processing consumption
and Ethernet communication bandwidth. The goal is to recommend hints for configuration that
optimize performance and allows to forecast the feasibility of applications in conformity with
the expected performance.

2. Employed Software and Firmware Revisions

During elaboration of this application note several tests were executed with controllers, programmer
and OPC UA client. The software and firmware versions employed in tests are indicated in the
following list:
 Controller NX3030: V1.7.0.4
 Controller XP325: V1.7.3.0
 Controller NX3003: V1.7.2.0
 Programmer Mastertool IEC XE (MT8500): V3.11
 Client OPC UA UaExpert: V1.5.0

3. Configurations of OPC UA Server in Controllers

This section describes configurations of OPC UA Server in ALTUS Controllers using the Mastertool
programmer.

3.1 Configuration of OPC UA Variables

The variables available for OPC UA communication are a subset of variables defined inside GVLs or
POUs of a project created using the Mastertool programmer.
After creating GVLs and POUs with these variables, the following steps must be executed:
1. Add the object Symbol Configuration bellow the topic Application in the device tree;
2. In the object Symbol Configuration, in Settings tab, mark the checkbox Support OPC UA
features;
3. Compile the project with no errors;

Altus S.A. Page: 2

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

4. Select the GVLs and POUs that contain OPC UA variables, marking the corresponding
checkboxes in the Symbol Configuration object;
5. Expanding the checkboxes of specific GVLs or POUs, it is possible to:
a. Select a subset of variables declared insides these GVLs or POUs for OPC UA
communication;
b. Configure access rights for each variable (read-write, read-only, write-only). Default is
read-write.
The following figure shows an example where all variables of GVL_INT were made available for
communication, and where part of variables of POU UserPrg were made available (only variable
DelTime is available).

Figure 3-1. Configuration of variables available for OPC UA communication

3.1.1 Types of Supported Variables

The OPC UA communication support simple or structured variables (STRUCTs of Function Blocks).
Moreover, it is also possible to define arrays of simple or structured variables.
The following table shows the basic types supported for simple variables, and the corresponding sizes
of these types (in bytes) allocated for transmission in the OPC UA communication frame. This size
information will be used in section 6.1 for Ethernet bandwidth estimation.
Type Size (bytes)
BIT Note 1
BOOL 1
SINT 1
USINT / BYTE 1
INT 2
UINT / WORD 2
DINT 4

Altus S.A. Page: 3

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

UDINT / DWORD 4
LINT 8
ULINT / LWORD 8
REAL 4
LREAL 8
STRING Note 2
TIME 4
LTIME 8

Table 3-2. Supported types of simple variables

Note 1:
The type BIT cannot really be declared as a simple type, but can be declared inside a STRUCT. In the
controller storage it allocates 1 bit, but in the OPC UA Ethernet frame it allocates 1 byte.
Note 2:
The type STRING allocates N bytes in the controller storage for a string declared with N positions.
However, the size allocated in the OPC UA Ethernet frame varies between 4 and N+4 bytes depending
on the value currently assigned to the string (minimum of 4 when string is empty). The 4 additional
bytes are used to indicate the current size of string.
The size of a structured variable is the sum of sizes of variables that compose the STRUCT. For
instance, consider the following structured type INT_REAL:
TYPE INT_LREAL :
STRUCT
VI : INT;
VL : LREAL;
END_STRUCT
END_TYPE

The size of this type is 10 bytes (2 bytes for INT + 8 bytes for LREAL).
Consider an array of type INT_REAL, for instance:
ARRAY_INT_REAL : ARRAY [1 ... 100] OF INT_REAL;

This array, as a whole, allocates 1000 bytes (100 positions * 10 bytes per position).

3.1.2 Maximum Count of OPC UA Variables

Up to 5000 variables can be made available for OPC UA communication in a Nexto controller. The
Mastertool compiler indicates an error when this limit is exceeded in Symbol Configuration object.
It is important to emphasize how such variables are counted:
 Each simple variable counts as one variable (e.g.: types BOOL, INT, REAL, STRING, etc.);
 Each structured variable counts as N variables, where N is the number of variables that
compose the structure. Considering the previous example of structure INT_REAL (section
3.1.1), each variable of this type counts as two variables;

Altus S.A. Page: 4

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

 Each array position counts as one variable for simple types, or as N variables for structured
types. For instance:
o An array of 100 positions of type INT counts as 100 variables;
o An array of 100 positions of structured type INT_REAL counts as 200 variables.

3.2 Cybersecurity Configurations

Optionally, it is possible to configure cryptography for the OPC UA communication using profile
Basic256SHA256. The following subsections define how to make these configurations in the controller
and in OPC UA client UaExpert.

3.2.1 Configuring Cryptography in Nexto Controllers

For configuring cryptography in a Nexto Controller it is necessary to create a certificate through the
following steps with the Mastertool programmer:
1. Select the active path for communication with controller (login is not necessary);
2. In menu View, select Security Screen;
3. Click on tab Devices in the left side of the screen;
4. Click on icon for refreshing;
5. Click on icon Device. Several certificate folders open bellow it (Own Certificates, Trusted
Certificates, Untrusted Certificates, Quarantined Certificates);

6. Click on icon for generating a certificate and select the following parameters:
a. Key length (bit): 3072
b. Validity period (days): 365 (can be modified if wanted)
7. Wait while certificate is calculated a transferred to controller (this can take some minutes);
8. Restart (power-down and power-up) the controller.

3.2.2 Example of Configuration of Cryptography in a OPC UA

Client (UaExpert)
After generating a certificate for cryptography in the Nexto controller, it is necessary to execute a
procedure for validating the certificate of a client wanting to connect with the controller.
The following procedure shows what must be done in client UaExpert (for other clients see the
corresponding user manual):
1. Add a connection for the controller and select connection type “Basic256Sha256 - Sign &
Encrypt (uatcp-uasc-uabinary)”;
2. Select menu Server/Connect. An error screen will open. Mark checkbox “Accept the server
certificate temporarily for this session” and then press button “Continue”;
3. Go back to Mastertool programmer (with active path correctly pointing to controller – login not
necessary) and click on icon of Security Screen for refreshing.

Altus S.A. Page: 5

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

4. In Security Screen, select folder “Quarantined Certificates” bellow Device. In the right panel a
certificate requested by client UaExpert must be displayed;
5. Drag this certificate to folder “Trusted Certificates”;
6. Go back to client UaExpert and select menu Server/Connect. An error screen will open. Mark
checkbox “Accept the server certificate temporarily for this session” and then press button
“Continue”. If a message box opens indicating a connection error, press button “Ignore”;
7. After this an “Adress Space” opens, where it is possible to navigate and select variables for the
subscription. After this moment, everything works the same way it works for non-secure
connections.

3.2.3 Removing Cryptography from a Nexto Controller

If cryptography was previously configured in a Nexto Controller, the following procedure can be
executed for removing it:
1. Select an active path for communication with controller (login is not necessary);
2. In menu View, select Security Screen;
3. Click on tab Devices in left side of the screen;
4. Click on icon for refreshing;
5. Click on Device, opening several certificate folders (Own Certificates, Trusted Certificates,
Untrusted Certificates, Quarantined Certificates);
6. Click on folder “Own Certificates”, and select the certificate in the right panel (OPC UA
Server);

7. Click on icon for removing this certificate from the project and from the controller;
8. Restart (power-down and power-up) the controller.

4. Basic Concepts for OPC UA Protocol

Before going on, it is important to have some knowledge of basic concepts about the OPC UA protocol.

4.1 Implemented Subset in Nexto Controllers

The OPC UA specification is very large, and encompasses several functionalities that typically are not
implemented in a single server or client.
The OPC UA server in Nexto controllers implements the following functionalities:
 Data coding: UA binary (section 3.1.1 defines the supported data types);
 Transport: protocol UA TCP, using TCP port 4840;
 Secure cryptography connection can be configured with profile Basic256SHA256;
 Possible to browse variables (on-line import of variables to a client). Some clients also allow
off-line configuration (e.g.: import variables through CSV files), so that the browse step is not
necessary;

Altus S.A. Page: 6

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

 Support multiple clients connected simultaneously. However, communication performance is

reduced as more clients are connected (see section 6);
 Variables can be reported by exception (only after value changes) or by polling (cyclically). The
polling method is not recommended because consumes large Ethernet bandwidth and CPU
processing, and will not be addressed in this application note (some OPC UA clients even do
not support the polling method);
 The variables reported by exception can be split in several subscriptions (see section 4.2) for
better performance.

4.2 Subscriptions (Variables Reported by Exception)

When configuring an OPC UA client, it is possible to group subsets of variables made available by an
OPC UA server in different subscriptions, for variables reported by exception.
The variables contained in each subscription are defined by the client, that is, different clients
connected to the same server can have different configurations of subscriptions.
A subscription is used for sending notifications to a client. Notifications are transported in packets
PublishResponse of OPC UA protocol. These packets contain only those variables of a subscription
that have changed value, and this feature is important for saving Ethernet bandwidth.
Note:
It is possible to see and depict the packets of OPC UA protocol (PublishRequest, PublishResponse and
others) using a protocol analyzer like Wireshark with filter “opcua”.
The following features can be emphasized regarding the subscription notifications transported in
PublishResponse packets:
 The minimum interval between two PublishResponse packets of a subscriptions is defined by a
parameter (Publishing Interval) defined in section 5.2. This is important for limiting bandwidth;
 Each PublishResponse packet carries only those subscription variables which values changed,
and this is also important for limiting bandwidth (reduces size of PublishResponse packet);
 If all variables configured in a subscription have not changed their values, the interval between
PublishResponse packets becomes even greater than parameter Publishing Interval, also saving
bandwidth.
When configuring OPC UA communication in a client, the simpler option is to include all variables in
a single subscription. However, split them in multiple subscriptions enables significant advantages
from the performance point of view (bandwidth and CPU consumption).
A suggestion for variable allocation in different subscriptions could be, for instance:
 Subscription 1: digital variables that must be reported quickly after a value change (lower value
of Publishing Interval parameter). If these variables do not change frequently, low bandwidth is
consumed;
 Subscription 2: digital variables that can be reported slowly after a value change (higher value
of Publishing Interval parameter). Lower bandwidth is consumed due to higher value of
Publishing Interval parameter.
 Subscription 3: analog variables which values change frequently, but that can be reported
slowly after a value change (higher value of Publishing Interval parameter). Lower bandwidth is
consumed due to higher value of Publishing Interval parameter. Deadband techniques can be

Altus S.A. Page: 7

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

used in the controller application for preventing that small value changes cause transmission of
variables (see section 5.4 about deadbands);
 Subscription 4: parameters of SCADA system application (e.g.: setpoints, alarm levels) that
rarely change. Bandwidth is low because these variables rarely change.

4.3 Groups of Variables Reported by Polling

When variables are reported by the polling method, they are read cyclically using packets ReadRequest
and ReadResponse. This method is not recommended because consumes lots of Ethernet bandwidth.
Note 1:
This application note does not address configuration and performance of the polling method, because
there is no apparent reason for using this method.
Note 2:
Some clients may use ReadRequest and ReadResponse packets just for testing the connection with
server (not for reading variables). If you see such a packet in a Wireshark log, realize that this is not
polling. These packets are small and transmitted with relatively high intervals, not causing a relevant
impact in Ethernet bandwidth.

5. Main Communication Parameters Configured in OPC UA Clients

The configuration of OPC UA server in the controller using Mastertool is simple, as described in
section 3.
In addition, there are some communication parameters that are configured in the OPC UA client and
that are negotiated with the server when the connection is established. The correct understanding and
configuration of these parameters is important for achieving the following goals related to performance
of OPC UA communication:
1. Limit the delay between a variable change in the controller and its notification to the OPC UA
client;
2. Limit Ethernet communication bandwidth;
3. Limit the CPU consumption of Nexto controller.
The OPC UA protocol may consume lots of Ethernet bandwidth and a high percentage of CPU
processing of a Nexto controller.
The OPC UA task executes in the controller with a priority lower than essential tasks, like MainTask. If
too many variables must be reported frequently, and MainTask consumes a high percentage of its cycle,
then the OPC UA communication may perform poorly. Other tasks with the same priority as OPC UA
task, like MODBUS TCP communication, can also affect negatively the OPC UA performance.
An unsuitable configuration of communication parameters in the OPC UA client can also reduce
performance of communication. Section 6 analyzes performance and show the influence of some of
these parameters.
The following subsections describe some of the communication parameters that have major impact on
performance and that should be configurable in any OPC client.
Note:

Altus S.A. Page: 8

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

Some OPC UA clients may give different names for these parameters. The names in this document are
in conformance with OPC UA specification.

5.1 Endpoint URL

It is necessary to inform the IP address and TCP port of server in the following way:
opc.tcp://192.168.17.2:4840
In this example, the IP address of server is 192.168.17.2.
The TCP port must always be 4840.

5.2 Publishing Interval (ms) and Sampling Interval (ms)

Parameter Publishing Interval must be defined for each subscription, and defines the minimum interval
between PublishResponse packets used for notification of value changes in variables allocated in the
subscription.
Parameter Sampling Interval must be defined for each variable (also known as monitored item in OPC
UA specification) allocated in a subscription. However, many client implementations only allow
configuration of a single Sampling Interval parameter common for all variables allocated in the same
subscription. This parameter defines the period used in the controller (server) for detecting changes in
the corresponding variable.
The maximum delay between a value change of a variable in the controller and its notification using a
PublishResponse packet is equal to the sum between parameters Sampling Interval (maximum delay for
detecting the change) and Publishing Interval (maximum delay for notifying the change). The medium
delay is half of this value.
The parameter Publishing Interval allows limiting the bandwidth of Ethernet communication. The
bigger is this parameters, the lower will be the bandwidth.
About parameter Sampling Interval, it is important not to configure it with too small values, because
the task which detects value changes consumes a big percentage of CPU processing of controller.
Note:
If the server do not support the values of these parameters configured in the client, it may revise these
values to bigger values, and inform the revised values to the client. Some clients show the revised
values for the user. An analysis of Wireshark logs, in packets CreateSubscriptionResponse and
CreateMonitoredItemsResponse show the revised values of these parameters.
The following Wireshark log shows a communication of a subscription which variables are changing
faster than Sampling Interval, and where Publishing Interval is 1000 ms and Sampling Interval is 500
ms.

Altus S.A. Page: 9

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

Figure 5-1. Notifications with variables changing faster than Sampling Interval

In packet 379 (t = 0 s), there is a PublishRequest where the client request to server to transmit a
PublishResponse notifying the variables of subscription which values have changed. The moment when
the server will transmit PublishResponse depends on some factors:
 Parameter Publishing Interval, that defines the minimum interval between consecutive
PublishResponse packets of same subscription;
 Modification of value of at least one variable of subscription. If no variable has changed value
in the subscription, the interval between consecutive PublishResponse packets of same
subscription can be bigger than Publishing Interval;
 Parameter Keep-Alive Count, described in section 5.3. It defines the maximum interval between
PublishResponse packets when all variables of a subscription do not change value for a long
time.
In packet 453 (t = 1 s) the PublishResponse is transmitted, 1 second after the PublishRequest that
requested it. This happens because a previous PublishResponse packet had been transmitted few
milliseconds before the PublishRequest in packet 379 (not shown in figure), and it is necessary to keep
a minimum interval of 1000 ms (Publishing Interval) between consecutive PublishResponse packets.
Note that 1 ms after the PublishResponse in packet 453, a new PublishRequest was transmitted in
packet 456, requesting a new PublishResponse that can arrive at least one second later.
The following Wireshark log shows another communication with a subscription which variables are
changing slower than Sampling Interval, and where Publishing Interval is 1000 ms and Sampling
Interval is 500 ms. In this example, variables are changing value every 3 seconds.

Altus S.A. Page: 10

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

Figure 5-2. Notifications with variables changing every 3 seconds

This log shows an interval of 3 seconds between PublishResponse packets, in accordance with the
rhythm of modifications in subscription variables.
This demonstrates that when variables of subscription are changing slowly, bandwidth consumption is
reduced.
Moreover, the size of each PublishResponse packet depends on the amount of variables of subscription
that changed value. This way, the bandwidth consumption is also reduced when less subscription
variables have changed value. In the previous example this is not visible (all PublishResponse packets
have the same size) because all variables of the subscription are being change in the test.
Parameters Publishing Interval and Sampling Interval of each subscription must be configured for
achieving the following goals:
 Limit the maximum and medium delays between value change of a subscription variable and its
notification through a PublishResponse packet:
o Maximum Delay = Publishing Interval + Sampling Interval
o Medium Delay = Maximum Delay / 2
 Limit Ethernet bandwidth consumption (see section 6.1);
 Limit CPU processing consumption in controller (see section 6.2).

5.3 Lifetime Count and Keep-Alive Count

These two parameters must be configured for each subscription.
They are used for creating a mechanism for deactivating a subscription by the server, if the client stops
to transmit PublishRequest packets for a long time for this subscription.

Altus S.A. Page: 11

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

If PublishRequest packets are not received by server during a time longer than Lifetime Count
multiplied by Publishing Interval, than the server deactivates the subscription. In this case, the client
must recreate the subscription later if wanted.
In situations where all variables of a subscription do not change value, a long time could pass without
the server sending PublishResponse packets, and therefore the client would not send new
PublishRequest packets, causing unexpected deactivation of the subscription. For avoiding this
situation, parameter Keep-Alive Count was created. If values of variables of subscription do not change
during a time longer than Keep-Alive Count multiplied by Publishing Interval, the server will send an
empty and small PublishResponse packet indicating that no variables have changed. This empty
PublishResponse packet authorizes the client to send immediately a new PublishRequest packed.
The value of Keep-Alive Count must be smaller than the value of LifeTime Count to avoid a spurious
deactivation of subscription. It is suggested that Lifetime Count be at least 3 times bigger than Keep-
Alive Count.
The following Wireshark log shows an example where Lifetime Count is 60, Keep-Alive Count is 5,
and Publishing Interval is 1000 ms, and no variables of subscription are changing value.

Figure 5-3. Packets PublishRequest and PublishRequest with variables not changing value

Note there is an interval of 5 seconds (Keep-Alive Count * Publishing Interval) between a

PublishRequest and the next PublishResponse. This PublishResponse is a small packet that does not
carry any variable. Few milliseconds after a PublishResponse, a new PublishRequest is transmitted by
the client.

5.4 Queue Size and Discard Oldest

These parameters must have fixed values that normally are the default values in clients:
 Queue Size: 1
 Discard Oldest: enable

Altus S.A. Page: 12

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

According OPC UA specification, it is possible to define these parameters for each variable. However,
many clients only allow to define common values for these parameters for all variables configured in a
subscription.
Queue Size must be kept with value 1 because there is no support to events in this server
implementation, so event queues are not necessary. If value of Queue Size is increased, communication
bandwidth and CPU processing consumption can increase, so this must be avoided.
Discard Oldest must be kept with value “enable” so that the PublishResponse packets always report the
more recent value change for each variable.

5.5 Filter Type and Deadband Type

These parameters must be kept with the following fixed values that normally are the default values in
clients:
 Filter Type: DataChangeFilter
 Deadband Type: none
According OPC UA specification, it is possible to define these parameters for each variable. However,
many clients only allow to define common values for these parameters for all variables configured in a
subscription.
Parameter Filter Type must be DataChangeFilter, indicating that change of value in variables must
cause their transmission in next PublishResponse packet.
Deadband Type must be “none” because the OPC UA server does not implement deadbands for analog
or numeric variables. This way, even small changes in analog variables cause its transmission in a
PublishResponse packet.
For optimizing bandwidth and CPU processing the user can implement deadbands in his controller
application, using the following strategy:
 Do not include the analog variable in the subscription.
 Instead, include in the subscription an auxiliary variable associated with the analog variable;
 Copy the analog variable to the auxiliary variable only when bigger value changes occurred,
using a deadband algorithm managed by the user application.

5.6 PublishingEnabled, MaxNotificationsPerPublish and Priority

These parameters should be kept with the following fixed values that normally are the default values in
clients:
 PublishingEnabled: true
 MaxNotificationsPerPublish: 0
 Priority: 0
They must be configured for each subscription.
Publishing Interval must be “true” so that variables of subscription are reported in case of value change.
MaxNotificationsPerPublish indicates how many of the variables which changed value can be
transmitted in a same PublishResponse packet. The special value “0” indicates that there is no limit,

Altus S.A. Page: 13

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

and this value is recommended for allowing all values changes to be reported in a same
PublishResponse packet.
Priority indicates the relative priority of this subscription compared to other subscriptions. If the server
must transmit several PublishResponse packets in a given moment the sequence of transmissions will
be determined by these parameters. If all subscriptions have the same priority, the PublishResponse
packets will be transmitted in a fixed sequence.

6. Performance Analysis
This section analyzes OPC UA communication performance from the following points of view:
 Ethernet bandwidth consumption, considering several influence factors;
 CPU processing consumption in the controller, necessary for complying with requirements of
delay specified through parameters Publishing Interval and Sampling Interval, and considering
several influence factors.

6.1 Ethernet Bandwidth Consumption

For estimating Ethernet communication bandwidth used by a subscription, several factors must be
considered:
 Number and type of variables included in the subscription, from which it is possible to calculate
the maximum number of bytes associated with these variables;
 Parameter Publishing Interval;
 An estimation of medium percentage of variables transmitted in each Publishing Interval.
This section describes how to calculate the steady state bandwidth, after the initialization phase and
without communication failures.
The following parameters are used for the calculation:
 N: number of variables in the subscription (section 3.1.2 describes how to count these
variables);
 MS: medium size of variables in bytes. For instance, if a subscription has 3000 INT variables
(3000 * 2 bytes) and 2000 LREAL variables (2000 * 8 bytes), MS = (3000 * 2 + 2000 * 8) /
(2000 + 3000) = 4.4 bytes;
 PI: parameter Publishing Interval (milliseconds) configured for the subscription;
 MPV: medium percentage of subscription variables which values change in each Publishing
Interval. In worst case, assume that 100% of variables are changing faster that Sampling
Interval, and that Sampling Interval is equal or smaller than Publishing Interval.

Each variable with size S byte (e.g.: 8 bytes for a LREAL) is transmitted using “22 + S” bytes (e.g.: 30
bytes for a LREAL), because other information are transmitted along with the value (timestamp, client
handle, type, etc.).
This way, the communication bandwidth in kbits/seconds will be at least:
Calculated Bandwidth (kbps) = (8 * N * (MS + 22) * MPV / (PI * 100))

Altus S.A. Page: 14

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

For instance, for 5000 LREAL variables changing continuously (MPV = 100%) and with Publishing
Interval equal 1000 ms:
Calculated Bandwidth (kbps) = (8 * 5000 * (8 + 22) * 100 / (1000 * 100)) = 1,200 kbps (1.2
Mbps)
In addition, there are some overheads. The following traffics were measured with Wireshark during one
minute:
 Upstream (client to server): filter “tcp.port = 4840 and ip.dst == <server IP address>”
 Downstream (server to client): filter “tcp.port = 4840 and ip.src == < server IP address >”
The following tables shows the result for tests with 1000, 2000, 3000, 4000 and 5000 LREAL
variables, with 100% of these variables changing values faster than Sampling Interval.
N (LREAL) MS (bytes) MPV (%) PI (ms) Calculated bandwidth (kbps) Real bandwidth upstream (kbps) Real bandwidth downstream (kbps)
1000 8 100,00% 1000 240 6 253
2000 8 100,00% 1000 480 10 500
3000 8 100,00% 1000 720 14 753
4000 8 100,00% 1000 960 19 1007
5000 8 100,00% 1000 1200 24 1258

Table 6-1. Bandwidths measured with Wireshark

The following equations can be used for estimating the real bandwidths:
 Real Upstream Bandwidth = 0.03 * Calculated Bandwidth
 Real Downstream Bandwidth = 1.06 * Calculated Bandwidth
Note:
With cryptography there is no relevant differences in bandwidth, so the previous equations can still be
used.

6.2 CPU Processing Consumption

The OPC UA communication needs a minimum processing capability of CPU of controller for
complying with performance requirements, like maximum delay for updating variables in a client.
This section shows the results of several tests executed in different scenarios, and determine the
minimum percentage of CPU processing needed for each scenario. Each scenario is characterized by
several factors (CPU model, number of clients, quantity and type of variables, and other factors that
will be described in this section).
Note that the OPC UA communication task executes in the controller with priority smaller that
MainTask, and compete with other tasks with the same priority, like MODBUS TCP servers or clients.
A special tool was used for measuring the CPU processing consumption in each test scenario.
Furthermore, the Wireshark sniffer was used for confirming that packets PublishResponse were being
transmitted with period defined by parameter Publishing Interval.
The following influence factors were used for defining the test scenarios:
1. CPU model, because different models have different processing capabilities. The used models
were NX3030, NX3003 and XP325. Models NX3010, NX3020, NX3004 e NX3005 were not
used because they have the same processing capability of NX3030;
2. Usage of cryptography;
3. Types and quantities of variables included in the subscription;

Altus S.A. Page: 15

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

4. Percentage of subscription variables that are changing faster than parameter Sampling Interval;
5. Publishing Interval;
6. Sampling Interval;
7. Number of OPC UA clients connected;
8. Cycle time of MainTask;
9. Number of subscriptions.
Besides showing the results for the several test scenarios, this section also presents some qualitative
conclusions about performance, related to the influence factors previously listed.

6.2.1 Results of Test Scenarios

The following table shows the results for the test scenarios. Some testes (T47 to T52) occupy two rows
of the table, because they involved two subscriptions.

Altus S.A. Page: 16

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

Table 6-2. Results of Test Scenarios for CPU Consumption

6.2.2 Qualitative Conclusions Using Test Scenarios

In this section, the test scenarios results shown in previous table are used for obtaining qualitative
conclusions related to processing consumption of OPC UA server task in the Nexto controller. The
tests are referenced by their identifiers in first column (T01, T02, etc.).

Altus S.A. Page: 17

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

Influence of CPU Model

Some CPU models are faster than others, and therefore consume last percentage of CPU processing.
CPU models were classified in three groups with similar performance:
 NX3030: NX3030, NX3010, NX3020, NX3004, NX3005
 XP325: XP325, XP315, XP300
 NX3003
Considering tests with 2500 type INT variables with other influence factors identical, the following
comparison can be done, from the fastest group (NX3030) to the slowest group (NX3003):
 NX3030 – Test T42: 33.8 %
 XP325 – Test T56: 37.0%
 NX3003 – Test T64: 45.8%
Influence of Cryptography (Cybersecurity)
Comparing some tests, like T42 x T76, and T44 x T78, a small increase of processing consumption is
observed due to the usage of cryptography:
 2500 INT, 1 client: T42 – without cryptography: 32.5% x T76 – with cryptography: 34.0%
 2500 INT, 2 clients: T44 – without cryptography: 54.1% x T786 – with cryptography: 57.0%
Influence of Variable Types
The influence of this factor can be disregarded, as well the fact of being structures, arrays or arrays of
structures. What really matters is the variable count, as described in section 3.1.2.
For instance, the following tests with 1000 variables reported similar results:
 T10: 1000 INT: 16.3%
 T12: 500 STRUCTS(INT, LREAL): 16.0%
Influence of Sampling Interval
This parameter has a very high impact in processing consumption. A low value of Sampling Interval
consumes lots of processing.
Comparing tests T07, T08, T09 and T10, only Sampling Interval changed, and processing consumption
changed from 63% with Sampling Interval of 100 ms to 16.3% with Sampling Time of 1000 ms.
Influence of Publishing Interval
This parameter has a medium impact in processing consumption. The lower it is, the more CPU is
consumed.
This is demonstrated by tests T30, T33 and T34, where only Publishing Interval changed, and the
minimum consumption ranged from 27.5% with Publishing Interval of 1000 ms to 25.5% with
Publishing Interval of 4000 ms.
Influence of Percentage of Variables Changing Value
Variables that change value faster than Sampling Interval consume processing relative to insertion in a
transmission queue (on each Sampling Interval) and due to its transmission in PublishResponse packets
(on each Publishing Interval).

Altus S.A. Page: 18

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

For instance, tests T37, T38 and T39 (5000 INTs) demonstrate an increase from 43% to 55% in
processing consumption, when percentage of variables changing value varies from 0% to 100%.
Influence of Number of Connected OPC UA Clients
In these tests all clients have the same configuration for subscriptions.
Discounting a basic processing consumption common for all clients, the remaining processing
consumption is proportional to the number of connected clients.
For instance, test T45 (a single INT variable) consumes 4.7%, and this can be considered as the basic
processing consumption common for all clients.
From tests T30 (1 client: 27.5 %) and T32 (2 clients: 46.4%) it is possible to note that:
(27.5% – 4.7%) is about the half of (46.4% – 4.7%).
Influence of MainTask Cycle
The MainTask cycle time has a minor influence in results.
This is demonstrated comparing tests T10 (cycle of 100 ms: 16.3%) and T11 (cycle of 10 ms: 15.5%),
that produced similar results.
Influence of Number of Subscriptions
Splitting variables in multiple subscriptions has a minor influence in results. This is demonstrated
comparing tests T30 (2000 variables in same subscription: 27.5%) and T48 (two subscriptions, each
one with 1000 variables: 28%), that produced similar results.
However, there are advantages in dividing variables in multiple subscriptions because it is possible to
select different parameters (Publishing Interval and Sampling Interval) for each subscription.
Comparing tests T50 and T52, note that it was possible to reduce processing consumption from 42% to
34.5% increasing Publighing Interval and Sampling Interval of only one of the two subscriptions. This
measure also reduces Ethernet bandwidth.

7. Revisions
Revision of this document is shown in the header of this document.
Revision: A
Date: 30/11/2018
Author: Osmar Brune
Reviser: Roberto Martiny
Approver: Rafael Lima
Changes history:
 First emission of document.

Revision: B
Date: 10/12/2018
Author: Osmar Brune
Reviser: Roberto Martiny

Altus S.A. Page: 19

Application Note:OPC UA Communication with ALTUS Controllers
Code: NAP165 Revision: B

Approver: Rafael Lima

Changes history:
 Corrections and inclusion of new parameters in section 5.

Altus S.A. Page: 20