75 link requests, no answer: a removed DNP3 outstation the master still polls
An outstation is taken out of a site, replaced or moved, and the field crew does its job. The master configuration is someone else's, and the address stays in it. From then on the master keeps trying to reach a device that is not there, forever, and the SCADA carries a communication alarm that everyone learns to ignore.
The setup
Two outstations share one connection to 10.0.15.1:20000: RTU-70 at DNP3 address 70 and RTU-71 at address 71. RTU-71
was removed in the field. The master was not told. The capture runs for 15 minutes.
What the capture shows
| 15 minutes | RTU-70 | RTU-71 (removed) |
|---|---|---|
| Requests from the master | 451 READ, all answered | 75 REQUEST_LINK_STATUS |
| Answers | 451 responses | 0 |
| Pattern | steady polling | 3 requests 2 s apart, then 30 s pause, every 36 s |
- The master never gets past the data link layer for address 71: before any application request it asks for the link status (function 9) and gets nothing back. It tries three times, gives up after 6 seconds, waits 30 seconds and starts again. 25 cycles, 75 frames, no answer.
- RTU-70 on the same connection is perfectly healthy, so the TCP statistics of the channel are clean. Only the per-address view shows the dead one.
- Unlike an outstation that goes quiet now and then, this one has never answered once in the capture. That is the signature of a device that is not there, rather than one that is struggling.
Why it is not harmless
- On a serial or radio multidrop line, every unanswered request holds the line for its timeout. Here that is 6 seconds out of every 36, about a sixth of the line time spent waiting for nobody, and the other outstations' polls queue behind it.
- A permanent communication alarm trains operators to ignore communication alarms, including the next real one.
- If a new device is ever installed with the old address, the master will start talking to it with the old configuration.
What to change
- Disable or remove the address in the master and in the SCADA database when a device is taken out; make it a step of the decommissioning procedure.
- Review the outstations that never answered in a capture: a list of addresses with zero responses is a list of configuration to clean.
Try it on your own capture
ComputingSphere DNP3 lists every outstation in a capture on one page, worst first, with requests, response time, unanswered requests, retries, buffer overflows and rejected requests, so an address that never answered stands out at the top. It only reads what already went over the wire. This capture is among the examples of every free account, to reproduce every number here; or upload your own: the Free plan covers 1,000 messages a month.