Providing the JACE controller is equipped with SRAM and is properly licensed, the platDataRecovery module dynamically creates a “DataRecoveryService” in the running station’s PlatformServices container. This service presides over the SRAM option card, which in turn acts as a buffer for flash memory.
The new service partitions the SRAM into multiple buffers, or SRAM data “blocks”. In the initial usage of SRAM, there are 3 blocks. Only one these SRAM blocks is ever “active” at any time.
Operation can be described in the following modes:
Immediately after a station has 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.
-
Unsaved user 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, this new slot config flag (AX-3.6 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.
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 (AX-3.6 and later). By default, this flag is cleared, meaning it is not set.
When this flag is set on newly-created slots, such new slots are not saved by the DataRecoveryService. If running “battery-less” and power is lost before the station is saved, these slots 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.
When saving a station running the DataRecoveryService, the following things occur. Note this applies regardless of how the save was issued—for example, a manually invoked command (Save Station), or an automatically issued save, e.g. a “persistent space full” condition by the DataRecoveryService, or a station save that occurs as part of a station copy operation, reboot command, or from a “controlled shutdown” while running on backup battery power:
-
The normal station save method is used to capture all changes to all the station’s object spaces (components, alarm, history) to flash memory, saved as the file
config.bog. -
Upon a successful save, all “
.drdb” files holding buffered data are erased from flash, as these are no longer necessary. -
The active SRAM data block is also cleared; however, one block operates in a “reserved state”. This is needed to capture any changes that may occur while the station is in the “saving” state. Otherwise, data loss could potentially occur if power was lost during or immediately after a save.
Again, note that buffered data in flash and SRAM is not erased until the save (config.bog) is successfully written to flash. Thus, data recovery records are not lost if a power loss occurs during a save.
-
If power is lost, a battery-less JACE is immediately off, with the last active SRAM block preserved by capacitor charge, plus typically one or more flash-preserved “
.drdb” files. This could also occur if battery-equipped controller was unable to successfully complete an orderly shutdown. The JACE remains in this dormant state until power is restored, when the JACE boot process begins normally. -
If a reboot command is given, the last active SRAM block is present, but typically no flash-preserved “
.drdb” files—because a reboot typically[1] first issues an “orderly shutdown”, starting with at station save. See Station save effects. The JACE boot process begins normally.
During station startup, after loading into DRAM the station’s last saved database (config.bog), the DataRecoveryService starts up and detects that recovered data exists in the preserved SRAM block, and also possibly
in flash-preserved “.drdb” files.
The DataRecoveryService then performs the following actions:
-
It replays (writes to DRAM) all the flash files in sequence, beginning with the oldest.
-
Once flash records have been replayed, the service replays the records found in the SRAM block, as they are the most recent.
Note that in some cases this playback to DRAM can take a few minutes—this depends on how much data there is to replay. Station
startup then completes, and an immediate save of the DRAM-restored station to flash (config.bog) occurs. All previous “.drdb” files are erased in flash, as well as SRAM data blocks, and DataRecoveryService operation begins anew. See Recording (normal operation).
[1] A reboot issued from system shell is one exception—no orderly shutdown occurs before such a reboot. There may be .drdb files saved when this reboot happens. If so, these are “replayed” the same as if power is lost.