Retentive memory is the PLC data that survives having the power pulled. When a controller loses power and comes back, some values reset to zero and some come back exactly as they were, and the difference is whether they were held in retentive memory. Which values fall on which side is not an accident - it is an engineering choice made tag by tag, and getting it wrong shows up as a lost production total or a valve that snaps to the wrong position after an outage. On lean, remote oilfield operations where nobody is standing by to fix the aftermath, choosing what to retain is one of the quiet decisions that determines whether a power blip is a non-event or a callout.
Retentive Memory in one line: Retentive memory is PLC or RTU data that keeps its value through a power cycle rather than resetting to a default, as opposed to non-retentive data that reinitializes on power-up. Retention is implemented with battery-backed RAM, NVRAM, or ferroelectric memory, and engineers mark specific tags retentive so that chosen values - like production totals - survive an outage while others start clean.
Every controller draws a line between two kinds of data. Non-retentive, or volatile, data lives in ordinary RAM that loses its contents when power is removed, so those values come back at their default - usually zero - on the next start. Retentive, or retained, data is held in a way that survives loss of power, so those values reappear unchanged when the controller powers back up. The same PLC holds both, and which category a given value falls into is a deliberate configuration, not something the hardware decides for you.
The right choice depends entirely on what the value means. Some data should reset on power-up: transient states, working intermediates, and anything whose stale value would be wrong or unsafe to resume from. Other data must persist: accumulated production totals, run-hour counters, recipe or setpoint configuration entered by an operator, and sequence positions where restarting from the beginning would be disruptive. The mistake in either direction has a cost - retaining something that should have cleared can resume a stale or unsafe state, while failing to retain something that should have persisted throws away information the operation depends on.
It is worth separating retentive memory from program storage, which people sometimes conflate. The program itself - the logic - is stored in non-volatile memory and is not what retention is about; a PLC does not forget its program on power loss. Retention concerns the runtime data values the program operates on: the tags, counters, totals, and registers whose current values may or may not survive the outage. Those are what an engineer decides to make retentive, and those are what cause trouble when the decision is wrong.
There are several physical mechanisms behind retention, and they differ in reliability and maintenance. The oldest is battery-backed RAM, where a small battery keeps ordinary volatile memory powered while the controller is off; it works well but introduces a maintenance item, because a dead or missing battery silently turns retained data back into data that vanishes at the next outage. Newer designs favor non-volatile technologies that need no battery: NVRAM, flash-backed schemes that copy data to non-volatile storage on power-down, and ferroelectric RAM (FRAM), which retains without a battery and tolerates many write cycles. The trend is away from batteries precisely because a battery is a failure point that can quietly defeat retention.
Configuration happens at the tag or data level, and the exact mechanism depends on the platform. Some controllers have a designated retentive data range, so any value placed in that area is retained; others expose a retentive or retain attribute on individual tags that the engineer sets when the tag is created. Certain instructions carry retention implicitly - a retentive timer or counter holds its accumulated value by design - while others do not. Knowing which tags in a given program are retentive is part of understanding that program, because it defines the controller's behavior after any power event.
The practical discipline is to decide retention intentionally rather than accept whatever the default is. Marking exactly the values that must persist as retentive, leaving the rest to reset cleanly, and - where batteries are involved - tracking and replacing them, is what keeps power-up behavior predictable. On battery-backed systems especially, a plan for battery health matters as much as the initial configuration, because retention that depends on an unmonitored battery is retention you cannot count on when an outage finally comes.
Remote oil and gas sites are where retention decisions get tested, because power at a wellsite is rarely rock-solid and no one is on site when it drops. An RTU that loses power and comes back must return in a state that is both safe and honest, and retention is central to both. Production totals are the honesty half: a flow total or accumulated volume held in retentive memory picks up exactly where it left off, while the same total in non-retentive memory resets to zero and the volume that accrued before the outage simply disappears - a direct loss to measurement and allocation that is difficult to reconstruct after the fact.
Valve and equipment states are the safety half, and here retention can cut the wrong way if applied carelessly. A remote valve position or mode that is retained will resume as it was before the outage, which may or may not be appropriate after an unattended power loss - sometimes the safe move is to force a known default on startup rather than resume a possibly stale commanded state. This is where retention and first-scan initialization have to be designed together: the engineer decides which states are safe to retain and which should be re-defaulted on power-up, so the site comes back neither losing data it should have kept nor blindly resuming a state it should have reset.
A cloud SCADA platform such as Merobix does not change what the RTU retains, but it does surface the consequences and provide a safety net. Because the platform historizes each site's totals and readings continuously in the cloud, a total that was lost to a local reset can often be reconciled against the last stored value, and a value that comes back suspiciously reset - a total that jumps to zero, a state that changed across an outage - can be flagged for a human. Alarming on stale data, on unexpected resets, and on communication loss lets a remote monitoring layer catch a retention problem that would otherwise stay hidden until a monthly reconciliation, which is exactly the kind of early warning a lean field operation needs.
Retentive memory keeps its value through a power cycle, so those values return unchanged when the PLC powers back up, while non-retentive memory resets to a default, usually zero, on power-up. The same controller holds both, and which category a value falls into is a deliberate configuration. You make values retentive when they must survive an outage, such as production totals, and leave others non-retentive when they should start clean.
Through mechanisms that preserve data without continuous power: battery-backed RAM, where a battery keeps volatile memory alive while the controller is off; non-volatile technologies like NVRAM and flash-backed schemes; and ferroelectric RAM (FRAM), which retains without a battery. Newer designs favor battery-free options because a dead or missing battery can silently defeat retention. The choice affects reliability and whether there is a battery maintenance item to manage.
Because an unmanned RTU has to come back both safe and accurate on its own. Production totals held in retentive memory survive the outage, while the same total left non-retentive resets to zero and the accrued volume is lost. Valve and mode states must be considered carefully too, since resuming a stale retained state can be unsafe - which is why retention is designed alongside first-scan initialization so the site returns correctly.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.