Tag Data Persistence
- Last UpdatedJul 18, 2023
- 3 minute read
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 DataSource Schema, preserving the necessary information about each tag's value, quality, and timestamp. The file is saved in the Plant 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 - |
Standby Device - |
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 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 [Client]StalenessPeriod 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 [Client]StalenessPeriodTolerance 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.