Buffering during connection loss

The OPC UA client tries to reuse the OPC UA session and the corresponding subscriptions after a connection loss. Therefore it is possible to use buffered data in the subscriptions and avoid data loss for short connection breaks.

Note

Refer to Buffering during client restart for information on how to use buffered data after restarting the OPC UA client.

There are different timeouts for subscriptions and the session. The buffering works without data loss as long as the connection break is shorter than these timeouts and if the buffer size for the monitored items is not exceeded.

Session timeout

The client may request a session timeout, however, the maximum timeout depends on the limit defined by server configuration. By default the WinCC OA server allows a maximum session timeout of 60 seconds (see maxSessionTimeout) and the WinCC OA client requests 20min (see sessionTimeout). So if our client communicates with our server with default settings, the session timeout is 60 seconds.´

Subscription timeout

The timeout of a subscription depends on the publishing interval and the lifetime count (set via _OPCUASubscription.Config.RequestedLifetimeCount). Per default the lifetime count is 100 and the requested publishing interval is 500ms. This results in a lifetime of 50 seconds (if the publishing interval is not limited by the server).

This means when using default settings, the subscription will die 10 seconds before the session and buffering will work for 50 seconds under the prerequisite that the buffer size of monitored items is big enough.

When buffered data shall be used it is important to select the timestamp either from source or from server in the subscription configuration. If "none" is selected you will get wrong time stamps if connection is reestablished.

Monitored items

The maximum monitored item buffer size of the WinCC OA Server is 100 per default. This can be configured via config entry uaMaxDataQueueSize.

Example

The following example demonstrates how to set the corresponding parameters and which dependencies must be considered or calculated.

Scenario

  • A server provides data for 100 items.
  • The data of each item changes every 100ms (=query interval, see Configuration of a Subscription).
  • The client retrieves the data every 500ms (=publishing interval).
  • The data should be buffered for 10 minutes in case of a connection loss.

Configuration

Server Client
uaMaxDataQueueSize [Value Changes] maxSessionTimeout [ms] sessionTimeout [ms] Queue Size [Value Changes] Lifetime Count [Retries]
6,000 600,000 600,000 6,000 1,200

uaMaxDataQueueSize

The maximum buffer size per monitored item is used to save the number of value changes until the next publish.

The values should be buffered for 10 minutes, therefor the corresponding settings of the config entry must be calculated as follows:

10 (number of value changes per second) * 600 (buffered time in seconds) = 6000.

In this case, for 100 items a total number of 600,000 value changes will be buffered.

maxSessionTimeout

Session timeout (server) for 10 minutes in milliseconds is 600,000.

sessionTimeout

Session timeout (client) for 10 minutes in milliseconds is 600,000.

Queue size

The size of the request queue for the OPC UA server (see maxRequestQueueSize).

LifetimeCount

Number of repeats until the subscription is deleted, if no values can be read. The client tries to read values every 500ms for 600 seconds, therefore, the LifetimeCount is 1,200.

Limits

We recommend not to exceed the limits as stated below. Otherwise it may result in a heavy load on CPU and memory, since all buffered data has to pass the WinCC OA system at connection reestablishment. However, the given numbers are no hard limits. The actual limits also depend on the required processing of buffered data in WinCC OA (archiving, alarming, etc).

  • Total number of buffered data < 1,000,000
  • sessionTimeout < 20,000 seconds
  • Queue size < 10,000

Note

If you want to use buffered data together with invalid bit settings for connection loss, use only setInvalidForConnLoss = 2. Otherwise you might get invalid source timestamps.

As a reference hardware for measuring the limitations stated above a Core i7 of the 8th generation with 16 GB DDR4 RAM has been used.