Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Plant SCADA

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 -
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 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.

In This Topic
TitleResults for “How to create a CRG?”Also Available in