When power comes back after an outage, a PLC has to decide how much of its previous state to trust and how much to throw away, and that decision is governed by its restart mode. Cold, warm, and hot restart describe three points along that spectrum, from wiping memory and starting fresh to picking up almost exactly where the controller left off. This guide explains what each mode does, how it interacts with retentive memory and the first-scan bit, and why the configured behavior decides whether a remote RTU resumes production tracking or starts from zero.
Cold / Warm / Hot Restart in one line: Cold, warm, and hot restart are the ways a PLC can resume after power is restored. A cold restart clears memory to a defined initial state and reinitializes the program as if freshly started. A warm restart resumes the program with retentive data preserved, so values marked to survive power loss carry over. A hot restart continues execution close to where the controller was interrupted, keeping the most state. The chosen mode, together with which memory is configured as retentive, determines what the controller remembers after an outage.
A cold restart is the clean slate. On a cold start the controller clears its working memory to defined initial values, resets non-retentive data, and begins the program from the top as though it had just been loaded. Anything that was not deliberately protected is gone, and the logic starts from its designed initial conditions. This is the safest mode when you cannot trust the state the controller was in when power failed, because it guarantees a known starting point rather than resuming from a state that may have been corrupted mid-interruption.
A warm restart is the middle ground and the most common configuration in the field. On a warm start the controller reinitializes non-retentive memory but preserves the data specifically marked as retentive, so counters, totals, setpoints, and state flags that were designated to survive power loss carry their pre-outage values into the new run. The program restarts, but it restarts already knowing things it is not supposed to forget. This is what lets a controller resume a process meaningfully rather than pretending it just came into existence.
A hot restart keeps the most state of all, resuming execution close to the point where the interruption occurred and treating the outage almost as a brief pause. Because it carries forward the largest amount of the pre-power-loss condition, it is the least conservative option, and it is only appropriate where the process can genuinely tolerate being picked up mid-stride. Not every platform offers all three modes, and the exact semantics vary by vendor, but the ordering - cold discards the most, hot preserves the most, warm sits between - holds across the board.
Restart behavior is inseparable from retentive memory, because the whole question a restart mode answers is which values survive. Retentive memory is the portion of the controller's data configured to persist through a power cycle, backed by battery, capacitor, or non-volatile storage. A warm restart is only useful to the extent that the values you care about - the day's production total, a sequence step number, an accumulated runtime - were actually declared retentive. A value that was not marked retentive is reset regardless of restart mode, so getting retention configuration right is what gives a warm start something to preserve.
The first-scan bit is the other side of the coin. Most controllers provide a status bit that is true only on the very first program scan after a start, and programmers use it to run one-time initialization logic - clearing working registers, priming a sequence, setting a known state - exactly once at startup. How that bit behaves relative to a cold versus warm restart matters, because the initialization logic gated by it may either restore sane starting conditions or, if written carelessly, wipe out the very retentive values a warm restart just preserved.
The interplay is where subtle bugs live. If first-scan initialization unconditionally zeroes a total that was meant to be retentive, then a warm restart hands back the preserved value only for the first scan to erase it, and the controller effectively behaves like a cold start no matter how it was configured. Designing startup logic that respects the restart mode - initializing what should be fresh while leaving retentive data alone - is what makes the configured behavior actually happen.
On a remote RTU, power is not guaranteed, and outages are a normal part of life on solar-and-battery pads, grids at the end of a long line, and sites exposed to weather. What happens when that RTU powers back up is therefore an operational decision, not a footnote. If the controller is configured to cold-start, it comes back with a clean slate: the day's accumulated production, engine runtimes, and sequence state all reset to zero, and everything the site was tracking before the outage is lost. If it warm-starts with the right values retentive, it resumes counting from where it stopped, and the outage becomes a gap rather than a reset.
That difference is visible in the field data. A cloud SCADA such as Merobix trends totals and runtimes over time, and a controller that resets its accumulators on every power blip produces a record full of unexplained drops to zero that look like the site stopped producing when it merely lost power for a moment. Configuring the restart mode and retention so that production tracking survives an outage is what keeps those trends continuous and the totals honest, which matters when the numbers feed allocation, reporting, or billing.
The right choice depends on the point. A running total or a cumulative runtime almost always wants to survive an outage, arguing for warm restart with those values retentive. A momentary command or a transient state that would be unsafe to resume mid-stride may be better cleared, arguing for reinitialization. Deciding this deliberately per site - rather than accepting a default nobody chose - is what determines whether a remote controller comes back as the same controller that went down, or as a stranger that has forgotten everything it was doing.
A cold restart clears memory to defined initial values and starts the program fresh, discarding the most state. A warm restart reinitializes non-retentive memory but preserves data marked as retentive, so protected values survive the outage. A hot restart keeps the most state, resuming execution close to where it was interrupted. The ordering is consistent even though exact behavior varies by vendor.
Retentive memory is the data configured to survive a power cycle, and it is what a warm restart preserves. Values that were not declared retentive reset regardless of the restart mode, so a warm start only carries forward the totals, setpoints, and states you actually marked to be retained. Correct retention configuration is therefore what gives a warm restart something meaningful to preserve.
Because it decides whether the RTU resumes production tracking after an outage or starts from zero. A cold-starting controller resets accumulated totals and runtimes on every power blip, producing trend data full of drops to zero, while a properly configured warm restart lets those values survive so an outage becomes a gap rather than a reset. On unmanned sites where outages are common, this choice keeps totals and reporting continuous.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.