Read the DNP3 IIN Bits Before You Blame the Outstation
The two IIN octets in every DNP3 response report restart, lost events, missing time and local control. Reading them, and clearing the ones that stick.
A poll that keeps saying "I just restarted"
An outstation was answering polls normally, values updating, quality good. But the master kept flagging it with a restart alarm every scan, and an engineer had spent an afternoon power-cycling the RTU trying to make it stop. The RTU was fine. The master was reading a bit the outstation had set once, on boot, and nobody was clearing it.
That bit lives in the two octets DNP3 tacks onto the front of every application-layer response: the Internal Indications field, IIN. Almost every real DNP3 problem — lost events, a clock the master never set, an output stuck in local, a corrupt config — announces itself in these sixteen bits before it shows up anywhere else. Most masters expose them as diagnostic tags and most integrators never look. If you learn to read IIN, half of DNP3 troubleshooting turns into "read what the outstation already told you."
What the two octets carry
IIN is two bytes, IIN1 and IIN2, returned in the header of every response and in unsolicited messages. IIN1 is mostly state — what the outstation is holding for you. IIN2 is mostly complaint — what it disliked about your last request.
| Bit | Mask | Name | Meaning |
|---|---|---|---|
| IIN1.0 | 0x01 | Broadcast | Last message was received as a broadcast (all-stations) |
| IIN1.1 | 0x02 | Class 1 events | Class 1 events are waiting to be read |
| IIN1.2 | 0x04 | Class 2 events | Class 2 events are waiting |
| IIN1.3 | 0x08 | Class 3 events | Class 3 events are waiting |
| IIN1.4 | 0x10 | Need Time | Outstation wants a time synchronization |
| IIN1.5 | 0x20 | Local Control | One or more output points are in local, not remote |
| IIN1.6 | 0x40 | Device Trouble | Outstation-specific abnormal condition |
| IIN1.7 | 0x80 | Device Restart | Outstation has restarted since the master last cleared this |
| IIN2.0 | 0x01 | No Func Support | Requested function code not supported |
| IIN2.1 | 0x02 | Object Unknown | Requested object/variation not known here |
| IIN2.2 | 0x04 | Parameter Error | Qualifier/range/parameter out of range or unparseable |
| IIN2.3 | 0x08 | Buffer Overflow | An event buffer overflowed; events were lost |
| IIN2.4 | 0x10 | Already Executing | Requested operation is already running |
| IIN2.5 | 0x20 | Config Corrupt | Outstation configuration is corrupt |
IIN2.6 and IIN2.7 are reserved and should read zero. The bit assignments and clearing rules here are from IEEE 1815 (DNP3); a compliant outstation follows them, but vendors vary on exactly when some of the state bits clear, so verify against your device's profile.
The Class-event bits (IIN1.1–1.3) are not errors — they are the outstation telling you "there is something to read." A healthy event-driven system sees these set and cleared constantly as the master reads events. If they are set but you never poll the matching class, your events pile up until the buffer overflows, which is the next problem.
The two bits that need the master to clear them
Two IIN bits are latched on purpose. The outstation sets them and then waits for the master to do something. If your master is misconfigured, they stay set forever and generate a nuisance alarm every scan — exactly the restart-loop story above.
Device Restart (IIN1.7). Set on every cold or warm restart. It does not clear when the outstation is running happily; it clears only when the master explicitly writes a 0 to the Internal Indications point — Object Group 80, Variation 1, index 7 — using the Write function (FC 2). This is deliberate: it forces the master to acknowledge "I saw that you restarted, and I've re-initialized my view of you" before the flag drops. A master that never issues that write leaves the bit set permanently. The fix is a master-side setting, usually called something like clear restart IIN on startup or enable restart handling — turn it on, and the master writes g80v1 index 7 after it re-integrity-polls. The outstation was never the problem.
Need Time (IIN1.4). Set when the outstation's clock has not been synchronized, or when its configured re-sync interval elapses. It clears when the master performs a time synchronization — a Write of Object Group 50 (Time and Date). If the master's time-sync task is disabled or pointed at the wrong outstation, this bit stays set and every event timestamp the outstation produces is suspect. This overlaps directly with sequence-of-events accuracy: an outstation flagging Need Time is telling you not to trust its event times until you fix the sync.
Both bits share a lesson: a persistent IIN state bit almost always means the master is skipping a step it is supposed to perform, not that the outstation is broken.
Buffer Overflow means you already lost data
IIN2.3 is the one to alarm on and never ignore. It means an event buffer on the outstation filled up and events were discarded before the master read them. Whatever data was in there — a breaker operation, an alarm transition, an analog excursion — is gone. Report-by-exception has a hole, and no amount of re-polling brings the lost events back, because they were overwritten.
When you see it, the cause is one of a few things:
- The master is not polling the event classes often enough, so events accumulate faster than they drain.
- The link was down long enough that the outstation's buffer filled while it couldn't report. On a radio or dial-up path this is common.
- The outstation's event buffer is simply configured too small for the point count and change rate.
The fix is buffer sizing and poll cadence, not clearing the bit. On most outstations the overflow flag clears itself once the buffer is no longer full, but that is cold comfort — the flag clearing does not mean the data came back. Treat every Buffer Overflow as a logged gap in your historian for that outstation, and if it recurs, either raise the event class poll rate or grow the buffer. On links that go offline for long stretches, size the buffer to survive the longest realistic outage.
Local Control, Device Trouble, and the honest-status bits
Local Control (IIN1.5) is set when one or more output points on the outstation are in local mode — a hand switch at the panel, a maintenance lockout — and will not respond to remote commands. This is the bit that explains "I sent the open command and nothing happened, no error." The command was correctly received and correctly refused, because that point is under local control. Surface this on the operator screen. An operator who can see "outstation in local" stops fighting a control that was never going to move, and knows to send someone to the field.
Device Trouble (IIN1.6) is deliberately vague in the standard: an outstation-specific abnormal condition the vendor decided was worth flagging — a failed self-test, a hardware fault, a watchdog trip. On its own it only tells you something is wrong; you have to go to the device's own diagnostics or manual to learn what. Alarm it, but pair it with a note pointing at where the vendor exposes the detail, or it just becomes a mystery light.
Config Corrupt (IIN2.5) means the outstation thinks its own configuration is damaged. Do not clear it and move on — an outstation running on a config it distrusts can produce garbage. This one warrants a site visit and a config reload.
The IIN2 complaint bits are about your request
The bottom of IIN2 — No Function Support, Object Unknown, Parameter Error, Already Executing — are the outstation telling you your request was wrong, not that it is unhealthy. During commissioning these are gold, because they turn "the poll doesn't work" into a specific reason:
- No Function Support (IIN2.0): you asked for a function code this outstation doesn't implement. Common when a master is configured for a richer feature set than a simple RTU supports.
- Object Unknown (IIN2.1): you asked for an object group or variation the outstation doesn't have — often a point index that isn't mapped, or an analog variation the device doesn't produce.
- Parameter Error (IIN2.2): the qualifier or range in your request didn't parse or was out of bounds. Frequently a range asking for more points than exist.
If a poll returns nothing useful during commissioning, read IIN2 first. It usually names the exact object or function the master and outstation disagree about, which is faster than staring at a packet capture guessing.
Wire IIN into your diagnostics, not just the debug log
A good DNP3 master maps the IIN bits to individual diagnostic tags per outstation. If yours does, use them:
- Alarm Buffer Overflow and Config Corrupt — these mean real damage (lost data, distrusted config).
- Display Local Control and Device Restart on operator or maintenance screens — these explain behavior operators will otherwise misread.
- Trend or count Device Trouble and Need Time so a slow-onset problem (a drifting clock, a flaky self-test) is visible before it becomes an incident.
- Leave the Class-event bits for engineering diagnostics; they flicker by design and aren't worth an operator's attention.
The next time an outstation "won't take a command," "keeps alarming restart," or "dropped some events," check the IIN bits before you drive to site. Sixteen bits at the front of every response usually already hold the answer — the outstation told you what was wrong the last time it replied.