Thirteen RTUs behind one gateway: four clock and function findings on one DNP3 outstation
A substation gateway or serial server puts many DNP3 outstations behind one IP address and port. The master opens one TCP connection and talks to each outstation by its DNP3 address. When something is wrong with one of them, nothing at the TCP level shows it: the connection is up and most addresses answer. The only way in is to split the traffic per address and look at each outstation on its own.
The verdict
Twelve outstations on the gateway were fine or close to it. Outstation 3637 got a FAILED verdict with four findings, and all four can be proven from the messages alone, without access to the device.
1. The time sync was never applied
The master writes the time (group 50, variation 1, or the LAN procedure with RECORD_CURRENT_TIME) and the outstation answers SUCCESS. That only says the request was accepted. The proof is the next response that carries a timestamp: if the clock read back right after the write is still off by about the same amount, the write did not take. Typical causes are a time source in the outstation that has priority over DNP3 (an IRIG-B or GPS input, see the GPS case), or a firmware that ignores DNP3 time sync unless it is enabled in its configuration.
2. The clock is stopped
Two reads of the outstation's time, several seconds apart on the wire, came back with the same timestamp. A clock that does not advance stamps every event with the same instant, and the sequence of events loses its order. This is usually a failed RTC or a clock that only moves when it is written.
3. The clock drifts between syncs
Compare the outstation's time with the capture time right after a sync and again just before the next one. The difference grows between the two, so events late in each sync interval are stamped further from the truth than events early in it. The fix is a shorter sync interval or a better time source, and the capture tells you how short it needs to be.
4. Function Not Supported, 5 times
Five responses carried IIN2.0 NO_FUNC_CODE_SUPPORT: the master asked for something this outstation does not implement. On a gateway this often means the master profile was copied from the other outstations. The decoded request next to each rejection says which function it was; the full pattern is in the configuration mismatch case.
What to do with it
- Fix the time source first: findings 1 to 3 are three faces of the same clock, and an unsynced outstation makes every SOE row it sends doubtful.
- Align the master's profile for this address with the outstation's device profile document to remove the rejected requests.
- Keep the report with the commissioning record: it states what the traffic proved on that day, per outstation.
Try it on your own capture
ComputingSphere DNP3 splits a capture per channel and per outstation address, checks the clock against the capture time after every sync, and writes a report per outstation with a verdict and the findings it can prove. It only reads what already went over the wire. Upload your own capture: the Free plan covers 1,000 messages a month.