OPC UA Catch-Up

Overview

This document describes the Catch-Up functionality implemented in the Apis Hive OPC UA client module. The Apis Hive OPC UA client module provides as default a standard OPC UA client with Node subscription and method call functionality.

In the cases of communication loss between an OPC UA server and OPC UA client, most OPC UA servers provides a short term buffering of subscription values. When clients re-connects after a relative short termed communication loss, the server start sending the buffered values. This standard OPC UA functionality will only work on short-term communication losses and are dependent on client/server buffer settings and server capabilities.

To accommodate problems with lost data after a long-term communication failure Prediktor has implemented the Catch-Up functionality in the OPC UA client. Unlike classic OPC, OPC UA provides both Data Access and History Access through the same interface. Apis Hive OPC UA client uses the History Access capability in OPC UA to read the logged values on the subscription nodes provided from the server for the duration of the communication failure. When all available history values on the subscription nodes are read up to the time of the re-connect, the client continues to read the subscribed node value through OPC UA Data Access as normal.

To get Catch-Up in Apis Hive UA client bee to work as intended, the server need to provide history data on all the items that the client subscribes to through Data Access.

The resolution on the logged data is not necessary the same as the negotiated sample-interval on the subscription nodes on source system. Differences between the logging interval and sample interval will result in different resolution on data collected through catch-up periods than through normal data access. Careful configuration on both the source server and client is necessary to accommodate this, if correct data resolution through both the catch-up (History Access) and Data Access data is important for the data consuming system.

Dependencies

The Apis Hive OPC UA bee has no Apis Hive dependencies.

Status Items

The Apis Hive OPC UA bee has a set of status items:

ItemDescription

#Connected#

Item telling if module is connected to the OPC server; true: is connected, false: is disconnected.

#Catchup-State#

Item telling the current state of data Catchup process.

#Catchup-PointInTime#

Item telling the current point in time for the catchup process, when Catchup process is active.

#Catchup-RealTimeBufferCount#

Item telling the current number of buffered real-time data callbacks during the catchup process, when Catchup process is active.

#Catchup-ReadChunksCount#

Item telling the total number of data chunks read from the UA server during the catchup process, when Catchup process is active.

#Catchup-ReadSamplesCount#

Item telling the total number of data samples read from the UA server during the catchup process, when Catchup process is active.

#Catchup-Speed#

Item telling how many times faster than real-time the catchup process is running  (note that a low figure may indicate both bad performance as well as high data density).

#Catchup-ReadSpeedAvg#

Item telling the average read speed of the UA server, in samples per millisecond.

#Catchup-ReadSpeedStdDev#

Item telling the standard deviation of the average read speed of the UA server.

#Catchup-StepNextTimeAvg#

Item telling the average duration of a StepNext iteration, in milliseconds.

#Catchup-StepNextTimeStdDev#

Item telling the standard deviation of the duration of a StepNext iteration.

Command Item

The Apis Hive OPC UA bee has a catch-up relevant command item:

ItemDescription

$Cmd_Catchup-Continue$

Trigger continuation of the catch-up prosess when catch-up type is  SerializedCatchup_PauseAfterInitial

The command item is added through the add item method. The command type id: 10140.

Catch-Up relevant module properties

  • CatchUpMode: The data catchup functionality of the communication. Set this to enable catch-up. Property ID: 1250

    • NoCatchup: No data cathcup, just pure real-time communication.

    • SerializedCatchup: Historical data is streamed through Hive sample-by-sample, until we have caught up real-time. Note that this requires the UA server to implement the OPC UA HA profile!

    • SerializedCatchup_PauseAfterInitial: Same as 'SerializedCatchup', but will stop in playback sequence after first StepNext, use CommandItem $Cmd_Catchup-Continue$ to continue playback sequence.

    • PartialCatchup: Only data missing locally, per item, is read from remote server and streamed through Hive, sample-by-sample, until we have caught up real-time.

    • PartialCatchup_PauseAfterInitial: Same as 'PartialCatchup', but with one stop in playback sequence after first StepNext, use CommandItem #ContinueCatchup# to continue playback sequence.

  • CatchUpPeriod: The maximum period to look back for historical data when initiating a catchup operation. Select a pre-set value, or enter a value in seconds. Property ID: 1262

  • CatchUpChunkSize: How many values to read per node during catchup read operations. Maps to 'numValuesPerNode' parameter of 'ReadRawModifiedDetails'. Default is 5000. Property ID: 1261

  • CatchUpNumberOfChunks: How many chunks to cache during catchup read operations. Must be between 0-255. Default is 5.Property ID: 1260

  • CatchUpPeriod: The maximum period to look back for historical data when initiating a catch-up operation. Select a pre-set value, or enter a value in seconds. Property ID: 1262

CONFIGURATION OF CATCH-UP

Catch-Up operation, step by step

When the OPC UA Client module re-connects after a period of communication loss, and if configured to do automatic catch-up, the OPC UA Client module will start to read the history data on the subscription items, starting from the time when the connection was lost, possibly limited by the set CatchUpPeriod module property. During this period of history data read, the module will buffer all Data Access subscription values in the module until all history data are read from the source system. After all the available item data is read up to the time of the re-connect, the module continuous with normal OPC UA Data Access subscription operation. During the Catch-Up the OPC UA Client Bee updates the configured data items in steps, assuring that all History data values for the items are written to the tags. Only single values are updated in each step.

Implications on memory usage

The OPC UA Client module reads the data in chunks. The number and size of the chunks for each item is configurable through the module properties: CatchUpChunkSize and CatchUpNumberOfChunks. The values set on these properties together with the number of items and item types will have implications on memory usage. The buffering of the OPC UA Data Access subscription items will also add to the memory consumption, so careful choice of Catch-up period must be selected to avoid out-of-memory situations. It is recommended to use the 64bit version of Apis Hive to ensure enough memory in high item volume solutions.

Timestamps

Item values read through OPC UA History Access (and OPC UA Data Access) will keep the server data timestamp through all the External Item transfers in Apis Hive, if not the TimeReferenceItems module property is set explicit. We recommend not using the TimeReferenceItems property in a catch-up solution.

EventBroker

Each Apis module normally have set of events and a set of commands. An event in one module can cause a command to be fired in another module. The mapping of the events to commands are done in the Event Broker. The OPC UA client module has a specific event CatchUp-StepNextDone and a specific command CatchUp-StepNext, that fires when a catch-up step is done and triggers each step in the catch-up process respectively. The module also fires a ServerDataChanged event after a new set of item values are received, both during catch-up and normal operation. Only a single value for each item are updated for each trigging of the ServerDataChanged event.

Trig the CatchUp-StepNext command by the CatchUp-StepNextDone event on the OPC UA Client Module, to ensure proper operation of events during normal operation.

This will be coverd in more detail below.

Figure 1, Event broker, CatchUp-StepNext on CatchUp-StepNextDone.

Apis Hive Inter-module data exchange

When using the Catch-Up functionality in the Apis Hive OPC UA Client Bee, it is important to configure the Apis Hive Data Exchange accordingly.

It is important to use the synchronized event/command functionality in the Apis Hive Event Broker instead of asynchronous timer-based Data Exchange

ExternalItem transfer in Apis

Apis Hive is a module based system environment that gives you the opportunity to collect, process and store real-time data. Different modules in Apis Hive provides different functionality, but common to all is the inter-module data exchange provided by the ExternalItem functionality.

Example of data exchange between modules

In this example system, we use a simple setup consisting of tree modules in an Apis Hive default instance:

  • A connection module, the OpcUa Client bee, named OpcUaBee.

  • A process module, the Calculate Bee, named Calculate.

  • A store module, the Logger Bee, named ClientLogger.

A simple view of the modules:

Figure 2, Apis Hive with Calculate, Logger and OpcUa client module.

The OpcUaBee module has one subscription item that reads a sine signal from the a source systemed named CustomerServer. The Item is named CustomerServer.Worker.Sine. Further the Calculate module has one item, named SineTimes2, which has CustomerServer.Worker.Sine as input through the external item connection.

Figure 3, Item connection.

Normally, data exchange (ExternalItem) is configured at destination side by adding one or more external items to an item by the item attributes. Second the destination module need to be set to use a specific Exchange rate, a definition of the period between each read of the connected items, normally in the millisecond area. In this way, the items will be inter-connected, and read at a specific time period.

Data exchange, by event broker:

In the figure below, we see that the OpcUa trigger the ClientLogger module to log, the Calculate module to handle its external items and the ClientLogger module to log again when ServerDataChanged event fires. The reason for logging twice is to ensure that history values that could be needed by calculate operations are properly logged before calculations are trigged, and results from the calculations are logged. Values on items that has not changed will not be logged.

We also see that CatchUp-StepNext is triggered as before by CatchUp-StepNextDone.

Figure 4, Event broker.

Catch-Up steps summary

The steps of the Catch-Up summed up:

  • The module re-connects after a period of lost communication

  • The buffering of the OPC UA Data Access subscription data on the items starts immediately

  • The module decides from what timestamp to start to read item history data from, based on time of communication loss or reconnect-time and CatchUpPeriod setting.

  • The module starts to read history data in chunks and trigger the event in event broker for each change in item value.

  • If configured, the external item values are synchronously updated through the Event Broker for each value update. ServerDataChanged

  • After all history data is read, the OPC UA Client Module continuous with normal OPC UA Data Access subscription operation.

  • If configured, the external item values are synchronously updated through the Event Broker for each value update.

Recommendations

  • Use 64bit Apis Hive installation when using catch-up in high item volume installations and expected catch-up for long periods.

  • Use event-broker to handle Apis Hive Data Exhange, trigging of CatchUp-StepNext command by the CatchUp-StepNextDone event is a must.

  • Ensure proper configuration of both client and source system server to achieve same data sampling rate of both History Access item data and item subscription (OPC UA Data Access) data.