Retentive Memory

What is retained

The controller has the program and it has the data table, and at power-up it needs both. The program is held in nonvolatile memory or restored from a card on every platform. The data is another matter. Some platforms retain the entire data table, so every tag comes back with the value it had. Some retain only areas or files marked retentive, and everything else returns to zero. Some retain timers and counters only if a retentive instruction was used. The platform manual states the rule, and it is different enough between vendors that assuming it from a previous project is how a plant comes up with every setpoint at zero.

What protects it

Lithium battery

Holds up the memory when power is off. Lasts two to five years depending on the controller and how much of that time it spends without power. The controller warns when it is low, on a status light and in a status bit, and the warning is the most ignored indicator in the industry. Replace on a schedule, and replace with the controller powered so the memory is held during the swap.

Energy storage module

A capacitor bank that charges while the controller runs and powers the memory long enough to write it to nonvolatile storage when power fails. No maintenance and no replacement, at the cost of holding data only for days to weeks if the controller is left unpowered, and a module that has aged holds less.

Nonvolatile memory card

A removable card holding a copy of the program and, optionally, the data table. The controller can be set to load from it on power-up, on a corrupt memory, or never. It is the only protection that survives indefinitely without power, and it is also the one that can restore a copy months out of date.

What should be retentive

First scan

Every controller exposes a first-scan bit, true for the first scan after power-up or after a transition to run. The logic that runs on it decides what the plant does: clear the commands in progress, reset the sequence to its safe step, validate the retained setpoints against their ranges, and decide whether equipment that was in auto restarts. Left unwritten, the plant does whatever the retained bits happen to say, which was correct at the moment the power failed and may not be correct ten minutes later with the wet well full and the operator on the road.

How retained data gets lost

• The battery died, quietly, and the next power cycle found nothing to retain. The low battery indicator had been lit for months.
• The controller sat unpowered on a shelf or in a de-energized panel long enough for the energy storage module to discharge.
• A download loaded the project, and the project carried the tag values from the day it was saved, replacing the current ones.
• A memory card set to load on power-up restored an old copy.
• A firmware update or a processor replacement cleared the memory, and nobody had uploaded a current copy first.
• The tags were never retentive on a platform that requires them to be marked, and this was the first power cycle since commissioning.

Keeping a copy

The defence against every one of those is a current copy: an upload from the running controller, including the data table, taken on a schedule and after every change, stored somewhere that is not in the panel. Setpoints can additionally be held in SCADA and written back to the controller on first scan, so that a controller that comes up with zeros gets its configuration back from the host. Both are cheap. Re-commissioning a plant from memory is not.