This continues from the earlier DNP3 posts -

Part One: Date/Time Stamping – or Less Guessing
Part Two: Communications Options – Polling and Unsolicited Reporting
Part Three: Security

The DNP3 protocol also supports guaranteed delivery. What does this mean?

Suppose you want to send a command to start a pump. How do you know the RTU at site received the command? With some older and simpler protocols the only way to check is to read the status of the pump at a slightly later time – and hope you catch it in the act.

Or suppose you want to ensure that the message High level alarm or All pumps unavailable sent from the RTU was not missed by the master station or SCADA? With some protocols, like Modbus, there isn’t any mechanism for ensuring this.

DNP3 provides message acknowledgements. With unsolicited reporting, the RTU might send all changed data every half hour, or if the event buffer was full. The “message” that the DNP3 protocol sends includes all the tags that have changed with the date/time of each, and also includes a sequence number. The master station would send an acknowledgement to the RTU – or “outstation” – that that sequence number had been received.

In the event that the RTU / outstation didn’t get that confirmation, it would retry. And after a certain time period the site would go into a Comms Fail mode with probably a longer retry delay. I say “probably” because that depends on how the user sets it up, but that would be the sensible approach.

As you can see if you’ve been following this series on DNP3, the creators of DNP3 designed it for the challenging world of telemetry where communications is always suspect and often problematic.

There’s more to configure in the protocol of course, but each element is there to ensure data integrity:

• you know what happened
• exactly when it happened
• you can guarantee that the SCADA system knows about it
• and you can ensure that data is genuine and not from a hacker

admin General News DNP3, reliability, RTU, SCADA, telemetry