Recording (normal operation)

Immediately after a station is started, any subsequent change in any of its three object spaces (component, alarm, history) is immediately recorded by the DataRecoveryService, writing to the currently active SRAM block. In bytes, each block has a total capacity, a calculated amount of needed overhead, and the current available free area. Exceptions to this recording are noted below.

NOTE:

Unsaved edits to files, e.g. Nav or Px files (working in the Px Editor) are not recorded, and thus are lost upon any power event if running battery-less. See SRAM does not preserve data or files external to station.
Slots of objects that have the Non-Critical config flag set are also not recorded. Note by default, for most slots, this new slot config flag ( Niagara 4.10 and later) is cleared. See Non-Critical config flag.

When the active SRAM block becomes full, i.e. its free area is not large enough for a record write, its data is written out (flushed) to a file in the JACE’s flash memory, then that SRAM block is cleared. Concurrently, while this transfer/flush occurs, another SRAM block is activated and used. This multi-threaded buffer method enables recording station changes that would otherwise be lost or blocked.

Over time, many SRAM blocks may fill, where each results in another file in flash on the JACE. These files are automatically named in a numeric sequence with a “.drdb” extension (data recovery database), stored in the station’s file space under the \dataRecovery directory. For example, this folder may contain files “1.drdb”, “2.drdb”, “3.drdb”, and so on, with “1.drdb” being the oldest. This sequence becomes important later, when the DataRecoveryService restores (plays back) data.

At some point, the collective size of the station’s “.drdb” files may exceed the “persistent capacity” limit used by the DataRecoveryService. This is a “persistent space full” condition. If this occurs, an automatic station save occurs. Effects on the DataRecoveryService are the same as if a station save is manually issued, or if an automatic save from the platform “auto-save” frequency occurs. See “Station save effects”.

Non-Critical config flag

There may be cases where new slots or the data values of those slots is not considered critical, and does not need to be saved by the DataRecoveryService. To accommodate for this, a new “Non-Critical” config flag can be set on any slot ( Niagara 4.10 and later). By default, for most slots, this flag is cleared meaning that it is not set.

From Niagara 4.10 and later, “Non-Critical” config flag can be added to component and history IDs to flag items not necessary to be monitored by data recovery. To flag the history IDs as non critical, navigate to history inside the history space, right-clickViews > AX Slot Sheet and set the History ID as Non Critical. The setting exists on the history, in history space, this flag cannot be set until the station has been started in a host and the history is created. The configuration is not included in backup. However, the Backup Service configuration can be modified to include histories.

Figure 5. SlotSheet with Config Flag Properties

NOTE: When this flag is set on newly-created slots, the value of such new slots is not saved by the DataRecoveryService. If running “battery-less” and power is lost before the station is saved, these values will be permanently lost.

However, if power is not lost, then the slots are still saved as part of a routine station save. But when the values of the slots change, those changes are not recorded by the DataRecoveryService; they are only saved when a “station save” occurs. Not saving this non-critical data through the DataRecoveryService may offer some performance advantages.