When a DNP3 outstation reboots - whether a master commanded it or the site simply lost power - the master's stored copy of that device's data is suddenly suspect, and DNP3 has a specific mechanism to flag and repair that. The cold restart is the deepest form of reboot, and the outstation announces it by raising a dedicated internal-indication bit that the master is expected to notice and act on. This guide explains what a cold restart is, how it differs from a warm restart, how the Device Restart bit lets a master detect and re-initialize a restarted RTU, and why ignoring that signal leaves stale or duplicated data in your SCADA history.
DNP3 cold restart in one line: A DNP3 cold restart is a full reboot of an outstation in which the device reinitializes as if it had just been powered up, clearing volatile state and event buffers before it comes back online. The outstation then sets the Device Restart internal-indication (IIN) bit to tell the master it has restarted, so the master knows to re-initialize the connection and re-read the device's current values rather than trusting its now-stale cached copy.
DNP3 defines two restart function codes a master can send to an outstation. A cold restart asks the device to perform a complete reinitialization, the equivalent of a power cycle: it resets its application state, clears volatile buffers, and comes back up in its default startup condition. A warm restart is a lighter reset that reinitializes the DNP3 application and communications without the full device-level reboot, so it typically completes faster and disturbs less. In response to either command, the outstation returns the delay time it expects to need before it will be ready to communicate again, so the master knows how long to wait.
Which one a device actually performs, and how different the two really are, depends heavily on the outstation's implementation. On some RTUs a warm and cold restart do noticeably different things; on others they converge because the device only supports one meaningful reset path. The specification defines the intent - cold is the deeper, more disruptive reset - but the exact scope of what gets cleared is a property of the particular hardware and firmware, which is why integrators check a device's documentation rather than assuming.
Both restarts are separate from the everyday case of an unplanned reboot. A master rarely needs to command a cold restart in normal operation; the more common event by far is a site losing and regaining power, or a watchdog resetting the RTU after a fault. Whether commanded or spontaneous, though, the important part for the master is the same: the outstation must signal that a restart happened so the master does not keep trusting data from before the event.
Every DNP3 response from an outstation carries a pair of internal indication (IIN) bytes, a set of status flags that ride along with the data. One of those flags is the Device Restart bit. After any restart - cold, warm, or an unplanned power-up - the outstation sets this bit and keeps it set in every response until the master explicitly clears it. That bit is the outstation's way of raising its hand and saying it is not the same running process the master was last talking to.
A correctly written master watches for the Device Restart bit and treats it as a trigger for a defined re-initialization sequence. It writes to the outstation to clear the restart flag, acknowledging that it has seen the event. It usually re-enables unsolicited reporting if that was in use, because the restart will have reset that setting. It commonly checks the need-time flag and sends the current time so the outstation can correctly timestamp new events. And it performs an integrity read - a full poll of current values - to rebuild an accurate copy of the device's state from scratch rather than trusting anything cached from before.
This resync is what makes a restart a recoverable event rather than a source of silent error. The Device Restart bit turns an invisible reboot into an explicit, in-band signal, and the master's response turns that signal into a clean re-baseline. Skip any step and the recovery is incomplete: leave the bit uncleared and the master may loop, skip the time sync and new events are misdated, skip the integrity read and the master keeps showing pre-restart values.
The failure mode of an ignored restart is quiet and therefore dangerous. When an RTU cold restarts, its event buffers are cleared, so any changes that occurred but were not yet delivered are simply gone. If the master does not notice the restart and re-read current values, it keeps displaying the last values it saw before the reboot, which may be minutes or hours old. An operator watching a cloud SCADA dashboard sees numbers that look plausible and current but are actually frozen at their pre-restart state, with no visible clue that the device rebooted underneath them.
Timestamps compound the problem. A restarted outstation often loses its sense of time until the master sends it a fresh time synchronization, which is what the need-time flag is asking for. Events generated in that window can be stamped with a default or wrong time, so when they finally reach the historian they land in the wrong place on the trend, out of order or clustered at an impossible moment. Duplicate events are the other classic symptom, arising when partial or repeated delivery around the restart is not reconciled against what the master already stored.
For a cloud SCADA platform such as Merobix polling many remote outstations across oil and gas fields, robust restart handling is essential to keeping history trustworthy, because unattended sites reboot for all sorts of mundane reasons - solar power dips, breaker trips, firmware updates, brownouts. Detecting the Device Restart bit, clearing it, re-syncing time, re-enabling unsolicited reporting, and running an integrity poll on every reconnect is what turns those routine reboots into non-events in the data. Done consistently, a restarted RTU produces a clean seam in the history rather than a stretch of stale readings and misdated alarms.
A cold restart is a full reinitialization equivalent to a power cycle, clearing volatile state and buffers and bringing the device back up in its default condition. A warm restart is a lighter reset of the DNP3 application and communications without the deeper device-level reboot, so it usually completes faster. Exactly how different they are depends on the outstation's implementation, so integrators check the device documentation rather than assuming.
It is a status flag in the internal indication bytes of every outstation response, set whenever the device has restarted. The outstation keeps it set in all responses until the master explicitly clears it by writing to the device. The bit is how an outstation tells the master that it rebooted, prompting the master to re-initialize the connection, re-sync time, and re-read current values.
When an outstation restarts it clears its event buffers, so undelivered changes are lost, and if the master does not notice it keeps showing values from before the reboot. Those values look current on the dashboard but are actually frozen, and new events may be misdated because the device lost its time sync. Handling the Device Restart bit with a clear, time-sync, and integrity read is what re-baselines the master and prevents this.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.