Skip to main content
Skip table of contents

Data Recovery Service

The Data Recovery Service is the station platform service that provides an NV-RAM support for the iSMA-B-MAC36NL. Providing the platDataRecovery module is installed, this service automatically appears under Platform Services.

Warning!

Please note that the from the Niagara 4.10 version and up the Data Recovery Service is carried out automatically–there is no need to manually install the PlatDataRecoveryService module, it is installed by default.

Niagara 4.6 and up includes support for the iSMA-B-MAC36NL operation, where a controller uses the NV-RAM (non-volatile random access memory), to preserve RAM-resident data if a power outage occurs. This includes station data that is not committed to non-volatile flash memory yet.

Note: A station running in the iSMA-B-MAC36NL has no seamless immunity to power surges. Although all station data, including components, histories, and alarms, are automatically restored to pre-event values, as part of a station start-up (following power restoration), the briefest power outage results in a controller reboot.

The iSMA-B-MAC36NL solves that problem, as all station-generated data (changed from that stored in its non-volatile flash memory at the time of a power loss) is always preserved in the NV-RAM. Upon power restoration, this data is reinstated in the station during start-up, then saved in its non-volatile flash memory.

Note: The NV-RAM does not preserve data or files external to the station.

Please note that, if the power surge occurs when station users have unsaved file changes, for example, a Px file or Nav file being edited, these unsaved changes are lost.

Station users may be aware of such event and react by saving changes (click the Save button in the active view).

Providing that communication is still established, the edited file may be saved. Or, if the power is lost only momentarily and then remains stable, the user can save the file normally.

Note: The iSMA-B-MAC36NL does not provide a similar saving opportunity after a power surge—it is already rebooting. Therefore, as a best practice, the iSMA-B-MAC36NLs system users are advised to often save their files manually if editing items like Px graphics or Nav files.

The Data Recovery Service writes current values as they occur to a block of the NV-RAM. If such block is full, the service copies it from the NV-RAM to the controller’s flash memory. A station that creates rapid COV (change of value) histories may fill the NV-RAM data blocks too frequently, triggering a database saving possibly every couple of minutes. Ideally, such database saving to flash memory should occur no more than once an hour.

Saving the database too frequently results in an inefficient use of the controller’s CPU time and in potential flash problems.

Flash memory is designed to be written to a certain number of times. Several variables contribute to how often the database needs to be saved, including:

  • Rate of changes that need to be persisted;
  • Size of the changes (histories, alarms, and setpoint changes differ in size);
  • Amount of free flash memory space.

Data Recovery Service Editor in PlatformServices of MAC36NL

The figure above shows the default view for the service: the Data Recovery Service Editor.

Note: The example above reflects a scenario, where a station saving has occurred at least once since the service was created. Some NV-RAM data recovery blocks have already been flushed to flash (“Persistent Storage Size” is not 0.00 kB).

Data Recovery Service Editor

This Data Recovery Service Editor is the default view of the Data Recovery Service.

The Data Recovery Service Editor view has the following three main areas:

  • Data Recovery Settings;
  • Blocks Configuration;
  • Data Recovery Blocks.

 Data Recovery Settings include the following:

  • Service Enabled: Defaults to true, to enable the NV-RAM support via this service.
  • Service Status: the current status of the DataRecoveryService, which, typically, is Ready. Other states include Starting, Configuring, Replaying, Saving, Stopping, Stopped, Fault, and Unknown.
  • Last Station Save Time: reflects the last time a station saving occurred (config.bog written to flash memory). This save may (or may not) have occurred as a result of the DataRecoveryService.
  • Last Station Save Successful: the Boolean value that reflects if the last station save attempt was successful, as either true or false. This save may (or may not) have occurred as a result of the DataRecoveryService.

Note: In the case of a newly created DataRecoveryService, this  value is false until the next save occurs.

  • Station Save Limit:configurable in N4.6 and later. The number of station saving operations that are allowed to occur during the Station Save Limit Period, before it is determined that the station is spending too much time saving. Exceeding the limit throws the Data Recovery Service into the fault status, since too much data is being generated.
  • Station Save Limit Period: configurable in N4.6 and later. The period of time defined for Station Save Limit. If enough number of saving operations occur during the Station Save Limit Period to exceed the Station Save Limit, then the service goes into the fault status. For example, more than 5 station saving operations in 3 minutes period triggers a fault status.
  • Persistent Storage Size: reflects the total size of all the data block files flushed to the flashmemory (“.drdb” files) that exist in the station’s /dataRecovery folder, in kB. Initially, this will be 0, until the first NV-RAM block flushes to flash. It will then increment by that kB amount for each subsequent NV-RAM block flushed.

Note: This value is continually compared to the Persistent Capacity property in the Blocks Configuration property section.

  • Generate Alert On Replay: configurable in N4.6 and later. The Boolean (true/false) value that generates an alert (low priority alarm type), which indicates whether a Data Recovery Replay occurred (power was lost). This is a persistent artifact that will show up in the alarm console, since it is useful to know when the power loss occurred. By default the value is false. If set to true, upon any controller boot sequence in which the NV-RAM recorded data is discovered and played back, a corresponding alert is routed to the Alarm Class named in the Data Recovery Alarm Support container. The figure 34. shows details for such an example alert.
  • Data Recovery Alarm Support: configurable in N4.6 and later. This is the standard container slot for routing platform service-generated alarms or alerts; in this case, an alert from the DataRecoveryService upon any controller boot sequence in which NV-RAM recorded data is discovered and played back. These properties work in the same fashion as those in an alarm extension for any control point.

Blocks Configuration

These status properties include the following:

  • Total Size: reflects, in bytes, the total amount of the NV-RAM buffer memory available to the service. For example, this is 32768 for the 128 kB NV-RAM memory.
  • Number of Data Recovery Blocks: reflects the number of data block partitions of the used NV-RAM, for example, 3.
  • Active Directory: reflects the directory used in the NV-RAM for the active data block.
  • Persistent Directory: reflects the full flash file directory path used to store flushed .drdb files, which equates to: /dataRecovery.
  • Full Policy: reflects the current policy in case an NV-RAM data block becomes full (by default: Flush).

Persistent Capacity: reflects the size limit, in kB, for the total of all data block files (.drdb files) that has been flushed to the flash memory. If this limit is exceeded (see property “Persistent Storage Size”), the service automatically triggers a station saving operation.

Data Recovery Blocks

This area provides expandable bar graphs for each of the NV-RAM buffer data blocks, to visually represent the current amount of the used space, overhead space, and available free space, along with numerical values. By default, the currently active NV-RAM block is expanded, showing a bar graph of current buffer usage.

Above the bar graph of each block, its Status is described, typically as either: Active, Idle, or Flushing, with other states Purging, Awaiting Idle, Flush Queued, Defragmenting, Reserved, Fail, and Unknown.

Below the bar graph of each block, numerical amounts display, in bytes, for its total capacity, currently used space, calculated overhead space, and available free space.

Data Recovery Service Properties

In addition to the (default) Data Recovery Service Editor view, the Data Recovery Service also has properties on its Platform Service Properties view, many of which are shown here.

MAC36NL Platform Service Properties view of DataRecoveryService

Most of these properties are also on the Data Recovery Service Editor default view.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.