DELAY_MEASURE 30 times higher than at the FAT: the DNP3 outstation, not the network
Before a master writes the time to an outstation over a slow link, it sends DELAY_MEASURE (function 23). The outstation answers with a Time Delay Fine object (group 52 variation 2): the milliseconds it spent between receiving the request and sending the response. The master subtracts that from the round trip it measured, halves the rest to get the one-way network delay and adds it to the time it writes. The value the RTU reports is its own processing time. The network is not in it. That makes it a useful health number, especially next to the factory acceptance test (FAT).
The setup
A distribution substation RTU passed its FAT with a capture recorded on the test bench. Six months after commissioning, operators complain that its events arrive late and its clock is often a few hundred milliseconds off. The team captures the field link and puts both captures side by side.
FAT versus field
| Same RTU, same firmware | FAT | Field |
|---|---|---|
| Delay reported in g52v2, median | 6 ms | 180 ms |
| Delay reported in g52v2, max | 9 ms | 420 ms |
| Round trip of DELAY_MEASURE | 48 ms | 260 ms |
| Response time to event polls, median | 30 ms | 240 ms |
| Configured points | 1,100 | 1,500 |
Reading it
- The RTU's own number grew thirtyfold. The round trip minus the reported delay is 42 ms at the FAT and 80 ms in the field: the network got slower, but by tens of milliseconds, not hundreds. Almost all of the extra time is spent inside the outstation.
- Event polls slowed down by the same amount. A busy RTU is slow for every request, which confirms the reading. If only DELAY_MEASURE had grown, the suspect would be how the device computes it.
- The spread matters as much as the median. The master trusts the reported delay to correct the time it writes. When the RTU's processing time swings between 100 and 420 ms, the time it receives can be off by that swing, which is what the operators saw as a clock a few hundred milliseconds off.
What it turned out to be
- 400 points added after the FAT, raising the work per poll.
- A chattering binary input generating events continuously (see tuning a chatter filter from a capture).
- Debug logging left on from commissioning, writing to slow flash on every message.
With logging off and the input filtered, the reported delay went back to 12 ms. Other common causes are firmware updates, a protocol gateway sharing the CPU, or a failing storage card.
Keep the baseline
A DELAY_MEASURE value means little on its own; different devices have different normal values. Next to the FAT capture of the same RTU, it is a direct measurement of how much slower the outstation has become. Keep the FAT capture with the commissioning record and compare after every configuration or firmware change.
Try it on your own capture
ComputingSphere DNP3 decodes a pcap per outstation and shows, on each outstation's Analysis page, the delays it reported to DELAY_MEASURE (average and maximum) against a limit you set on the RTU: 250 ms unless you choose another, for example the FAT value plus a margin. When the highest answer is over it, the report raises an Attention finding for that outstation, so a FAT capture and a field capture can be compared number by number. It only reads what already went over the wire. The Free plan covers 1,000 messages a month.