Reading room · Case study · 21 October 2026

Self-healing on stale data: three DNP3 problems a FLISR scheme should not meet

A self-healing scheme, FLISR (fault location, isolation and service restoration), takes decisions in seconds that an operator used to take in minutes: it reads which devices saw the fault current, decides which section is faulted, opens the switches around it and recloses the rest of the feeder from another source. It is only as good as three things it gets over the communication network:

fault indications that arrive once and on time,
switch and recloser positions that are current,
remote commands that the devices actually execute.

None of these is visible in a SCADA display until FLISR acts on it. All of them are visible in a capture of the DNP3 traffic, before the scheme is commissioned or after it did something surprising. This post goes through three cases.

1. A recloser whose events come back again and again

Recloser R-12 on 10.0.7.12:20000 reports its events unsolicited: trips, recloses and fault flags are pushed to the master as they happen, and the master must confirm each unsolicited response within 3 seconds. For a minute the master stops confirming, and later it confirms 4 seconds late. The recloser does what the standard tells it to: it sends the same unsolicited response again, with the same events and the same timestamps, until it is confirmed.

Report findings for Recloser R-12: a late unsolicited confirmation, 30 unsolicited responses never confirmed, 101 events resent with the same time, one of them 16 times — The report for Recloser R-12: 30 unsolicited responses the master never confirmed, and 101 events sent again with the same timestamp, one of them 16 times.

In the capture: 483 unsolicited responses, 30 never confirmed, 101 events received more than once, one of them 16 times. A SCADA with good duplicate detection shows nothing. A FLISR application fed by a front end that does not drop duplicates sees one fault indication sixteen times, which can look like an evolving fault, count towards lockout logic or restart its timers. The fix is on the master side (confirm in time; drop events already seen, by point, value and timestamp), and the capture is how you prove it is needed.

2. An outstation that is silent when the fault happens

On the multidrop channel 10.0.1.18:20000, outstation 19 stops answering twice for about 90 seconds; the master logs 30 unanswered requests and 20 retries, and events up to 97 seconds late (the whole case is in one silent outstation on a multidrop line).

For fault location, silence is worse than a wrong value. The algorithm works by comparing devices along the feeder: the fault is between the last device that saw fault current and the first one that did not. A device that is silent during the fault reads as "did not see it", and the faulted section moves upstream. FLISR then isolates a healthy section and re-energizes the faulted one. A capture shows whether any device in a FLISR zone has these gaps, and how long they last, before you trust the scheme with it.

3. A switch left in local control

A response from outstation 70 with IIN1.5 Local Control set — Outstation 70 answers with IIN1.5 LOCAL_CONTROL: the device is in local, and remote commands will be refused.

On 10.0.7.70:20000 someone leaves the device in local for three minutes. A command sent then comes back with status LOCAL and nothing moves: for FLISR, an isolation step that did not happen, and a restoration that must not go ahead. The warning was there from the first second: the outstation set IIN1.5 LOCAL_CONTROL on every response of that window, 110 of them, starting a minute before the command. A scheme that reads IIN bits can exclude the device from its plans before it needs it; one that does not finds out from the refused command (the status codes are in why a DNP3 SELECT/OPERATE fails).

A pre-commissioning check for a FLISR zone

Every device in the zone answers every poll: no unanswered requests, no retries, no repeated startup sequences.
Unsolicited responses are confirmed within the device's timeout, and no event arrives twice.
Event timestamps are synced (no NEED_TIME left standing, see NEED_TIME on 904 responses) so the sequence of fault indications can be trusted.
No device reports LOCAL_CONTROL while the scheme is armed, and every control point answers SELECT with SUCCESS.
The event buffers do not overflow during a burst (event buffer overflow): a fault is exactly when every device produces events at once.

Try it on your own capture

ComputingSphere DNP3 decodes a pcap once, splits it per channel and per outstation, and ranks the outstations worst first with the same numbers used here. It only reads what already went over the wire. Each outstation of a FLISR zone gets its own findings: unanswered requests, unconfirmed and repeated unsolicited events, local control and command failures. This capture is among the examples of every free account, to reproduce every number in this post; or upload your own: the Free plan covers 1,000 messages a month.