5. CONFIGURATION
5.5.11.6.2. Publishing Interval (ms) e Sampling Interval (ms)
The Publishing Interval parameter (unit: milliseconds) must be set for each subscription.
The Sampling Interval parameter must be set for each variable (unit: milliseconds). However, in many OPC UA clients, the
Sampling Interval parameter can be defined for a subscription, being the same for all the variables grouped in the subscription.
Only the variables of a subscription whose values have been modified are reported to the client through a Publish Re-
sponse communication packet. The Publishing Interval parameter defines the minimum interval between consecutive Publish
Response packets of the same subscription, in order to limit the consumption of processing and Ethernet communication
bandwidth.
To find out which subscription variables have changed and are to be reported to the client in the next Publish Response
packet, the server must perform comparisons, and such (samplings) are performed by the same with the Sampling Interval. It
is recommended that the value of Sampling Interval varies between 50% and 100% of the value of the Publishing Interval,
because there is a relatively high processing consumption associated with the comparison process executed in each Sampling
Interval.
It can be said that the sum between Publishing Interval and Sampling Interval is the maximum delay between changing a
value on the server and the transmission of the Publish Response packet that reports this change. Half of this sum is the average
delay between changing a value on the server and the transmission of the Publish Response packet that reports this change.
5.5.11.6.3. Lifetime Count e Keep-Alive Count
These two parameters must be configured for each subscription.
The purpose of these two parameters is to create a mechanism for deactivating a subscription on the initiative of the
server, in case it does not receive customer’s PublishRequest communication packets for this subscription for a long time.
PublishRequest packets must be received by the server so that it can broadcast Publish Response packets containing the
subscription variables that have changed their values.
If the server does not receive PublishRequest packets for a time greater than Lifetime Count multiplied by Publishing
Interval, the server deactivates the subscription, which must be re-created by the client in the future if desired.
In situations where the variables of a subscription do not change, it could be a long time without the transmission of
PublishResponses and consequently PublishRequests that succeed, causing an undesired deactivation of the subscription. To
prevent this from happening, the Keep-Alive Count parameter was created. If there are no subscription data changes for a
time equal to Keep-Alive Count multiplied by Publishing Interval, the server will send a small empty Publish Response packet
indicating that no variable has changed. This empty Publish Response will authorize the client to immediately send the next
PublishRequest.
The Keep-Alive Count value must be less than the Lifetime Count value to prevent unwanted deactivation of the subscrip-
tion. It is suggested that LifeTime Count be at least 3 times larger than Keep-Alive Count.
5.5.11.6.4. Queue Size e Discard Oldest
These parameters must be maintained with the following fixed values, which are usually the default values on the clients:
Queue Size: 1
Discard Oldest: enable
According to the OPC UA standard, it is possible to define these parameters for each variable. However, many clients
allow you to define common values for all variables configured in a subscription.
Queue Size must be retained with value 1 because there is no event support in this implementation of the OPC UA server,
so it is unnecessary to define a queue. Increasing the value of Queue Size may imply increase communication bandwidth and
CPU processing, and this should be avoided.
Discard Oldest must be maintained with the enable value, so that the Publish Response package always reports the most
recent change of value detected for each variable.
5.5.11.6.5. Filter Type e Deadband Type
These parameters must be maintained with the following fixed values, which are usually the default values in the clients:
Filter Type: DataChangeFilter
Deadband Type: none
169
To Next Page
Loading...
Need help?
General
