Tag Data Persistence

System Model > Variable Tags > Tag Data Persistence | System Model

Each I/O device has a tag data cache on its I/O server. This cache is periodically saved to disk to maintain the last known value (LKV) for each tag. This allows the tags on an I/O device to be initialized to their corresponding LKVs when the device is restarted. On load, the original persisted quality is substituted by the BadLastKnown quality value.

The tag cache file is saved as an XML Data Source Schema, preserving the necessary information about each tag's value, quality, and timestamp. The file is saved in the Citect SCADA Data Folder with the following default name:

<ClusterName>.<IOServerName>.<IODeviceName>.cache

When the time comes to save a tag cache file, a temporary file is used. After it is written, it simply gets renamed to the original file name. This is done to avoid partial master file updates.

If during the file load the schema validation is unsuccessful, the entire file is considered invalid and the tags LKVs are lost. If during the file load a particular tag's value, quality, or timestamp is invalid, the corresponding invalid entry is simply ignored (and logged as such).

Persistence can be configured using the Persist, Persist Period and File Name properties (see Add an I/O Device).

Minimum Update Rate

An I/O device can send tag update notifications to subscription clients after a pre-defined period of time expires. This is configured via the Min Update Rate property.

Devices that are configured for redundant operation needs to have minimum update rate set according to the rules specified in the table below.

Primary Device - Min Update Rate Value	Standby Device - Min Update Rate Value	Compilation Result
Blank (Default)	Blank (Default)	OK
Blank (Default)	Value Defined	Error
Value Defined	Blank (Default)	OK
Value Defined	Same value as primary	OK
Value Defined	Value is different than on primary	Error

Staleness Period

You can specify a "staleness period" for tag values received from an I/O device. If a subscription client does not receive a tag update from the I/O device within this specified period of time, the tag element value is considered to be "stale". The quality item substatus QUAL_EXT_STALE will indicate this condition. Processing of staleness period for tags is performed on the client side of the connection.

A staleness period can be configured in the following ways:

On the server side you can set the staleness period for a particular I/O device by setting the Staleness Period property (see Add an I/O Device). The value you enter should represents the total number of seconds that can elapse after the last update before QUAL_EXT_STALE is set to "stale".

For devices configured for redundant operation, the Staleness Period settings must conform to the same rules outline for Min Update Rate in the table above.

On the server or client, you can use the ClientStalenessPeriod parameter. This specifies the total number of seconds that can elapse following the last update before QUAL_EXT_STALE is set to "stale".
On the client only, you can use the ClientStalenessPeriodTolerance parameter. Staleness period tolerance specifies an amount of time as a percentage of the total staleness period, after which a check of stale client tag elements will be performed. The default value is 10%. This means that if the staleness period is set to 600 seconds, a check for stale client tag elements will be performed every 60 seconds.

Published June 2018