Every response a DNP3 outstation sends back to its master carries a small bundle of status flags called the Internal Indication field, or IIN. It is two bytes wide, and each bit is a compact signal about the health and state of the outstation: has it restarted, does it need its clock set, does it have events waiting, has a buffer overflowed. This guide decodes what those bits mean, walks through how a well-behaved master reacts to each one, and shows why the IIN field is what turns a DNP3 link from blind polling into a self-correcting conversation.
Internal Indication Field in one line: The DNP3 Internal Indication field is a two-byte set of status flags an outstation includes in the header of every response. Its bits report conditions such as a device restart, a request for time synchronization, whether class 1, 2, or 3 events are available, event-buffer overflow, and various error conditions. The master reads these bits on every reply and reacts to them - clearing a restart, setting the clock, draining events - which is how healthy DNP3 polling stays self-correcting.
The Internal Indication field is not something the master has to ask for. It is attached to the application header of every response the outstation sends, so on each and every reply the master receives a fresh snapshot of the outstation's internal state alongside whatever data it requested. The field is split into two bytes, commonly written as IIN1 and IIN2, and each bit within them carries a distinct meaning. Reading the IIN is therefore a routine part of processing any DNP3 response, not a special diagnostic step.
The first byte tends to carry the operational and event-related flags - things like whether the outstation has restarted, whether it needs time, whether it is in local control, and whether class 1, 2, or 3 events are waiting to be collected. The second byte leans toward error and request-quality conditions - a function code the outstation does not support, an object it did not recognize, a parameter out of range, a request buffer overflow, or an operation that is already executing. Together the two bytes give the master both a running health check and immediate feedback about how its last request was received.
What makes the IIN powerful is that it is proactive from the outstation's side. Rather than the master having to poll a dozen separate status points to learn that events are queued or that the clock has drifted, the outstation simply raises the relevant bit on its next reply and the master sees it for free. The field is small, always present, and cheap to check, which is exactly why it can carry so much of the coordination that keeps a DNP3 link running smoothly.
The device-restart bit is one of the most important. When an outstation powers up or reinitializes, it sets this bit and keeps it set until told otherwise, which is its way of announcing that it may have lost state and that the master should not trust its picture of the outstation. A correct master response is to re-establish a known baseline - typically performing an integrity poll to read all current values - and then explicitly clearing the restart bit by writing to the corresponding internal indication object. Until the master clears it, the bit persists on every response, a standing flag that the outstation restarted and has not yet been resynchronized.
The need-time bit is the outstation asking the master to set its clock. DNP3 outstations timestamp events, and if their clock has never been set or has drifted, those timestamps are unreliable. When the outstation raises need-time, a well-behaved master answers by sending a time-synchronization command to align the outstation's clock, after which the outstation clears the bit on its own. The class-1, class-2, and class-3 event bits are the master's cue that the outstation has buffered event data of that priority waiting to be collected; the master reacts by issuing a poll for the indicated event classes to drain them, which keeps the outstation's buffers from filling.
The buffer-overflow bit is a warning that the outstation's event buffer filled and events were lost before the master could collect them - a signal that polling is not keeping up or that a burst of activity outran the buffer. The master cannot recover the lost events, but it can respond by performing an integrity poll to resynchronize to current values and by reconsidering its polling rate. The error bits in the second byte - unsupported function, unknown object, parameter error, already-executing - tell the master its last request was malformed or could not be honored, which is feedback the master uses to correct its behavior rather than to change the outstation's state.
Put together, the IIN bits let a DNP3 link largely manage itself. A master that faithfully reads and acts on the field will notice a restarted outstation and rebaseline it, will set the clock when asked, will pull events the moment they are announced, and will react to a buffer overflow by resynchronizing. None of this requires an operator to intervene, and none of it requires the master to guess at the outstation's condition, because the outstation keeps telling it. This is what people mean when they say DNP3 is designed for unreliable, intermittently connected links: the protocol carries enough self-reporting to recover cleanly from outages and restarts.
For cloud-based supervision of remote assets, this matters because outstations at distant sites restart, lose time, and buffer events far more than equipment in a clean control room does. A cloud SCADA platform such as Merobix acting as the DNP3 master reads the IIN on every response and reacts automatically: when a remote outstation comes back from a power blip with its restart bit set, the platform performs an integrity poll to recover the current field state and clears the bit, so operators see an accurate picture within moments rather than a stale one. When need-time appears, the clock is set so that event timestamps stay trustworthy for later analysis, and when event classes are flagged, the buffered data is pulled promptly so nothing important sits waiting.
The buffer-overflow bit is especially informative to a monitoring platform because it is a direct signal that something is not keeping up - either the link has been down long enough to overrun the outstation's buffer, or the polling cadence is too slow for how busy the site is. Treating that bit as a first-class alert, rather than ignoring it, lets an operator catch a link that is quietly losing data before an investigation later discovers gaps in the record. In practice, watching and responding to the IIN field is one of the quiet fundamentals that separates a DNP3 integration that stays accurate over flaky field links from one that slowly drifts out of sync.
It means the outstation has restarted or reinitialized and may have lost its previous state, so its data should not be fully trusted until resynchronized. The outstation sets this bit on power-up and keeps it set on every response until the master explicitly clears it. A correct master reaction is to perform an integrity poll to read all current values, then write to the internal indication object to clear the restart bit.
Because it wants the master to set or correct its clock. DNP3 outstations timestamp events, and accurate timestamps require an accurate clock. When the outstation's clock has never been set or has drifted, it raises need-time on its responses. A well-behaved master answers with a time-synchronization command, after which the outstation clears the bit itself and its event timestamps become reliable again.
Treat it as a warning that events were lost because the outstation's event buffer filled before the master could collect them. The lost events cannot be recovered, but the master should perform an integrity poll to resynchronize to the outstation's current values and reconsider whether its polling rate is fast enough for the site's activity. Because it signals data loss, this bit is worth surfacing as an alert rather than silently ignoring.
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.