The DNP3 protocol is useful in multi-layered systems as it allows the user to categorize field data. For example, normal conditions at a pump station, such as pumps starting and stopping, may be configured as Class 2 type events. Thus, when the pump changes state, an event will be created as a Class 2 type and stored in memory. Since this is normal operation, an unsolicited report (or Report by Exception) need not be initiated to a DNP3 master device.
But assume at the same pump station site there is a pump fault indication. This is, in most cases, a critical alarm of whch the DNP3 master needs to be aware, so that appropriate action can be taken. Thus, the pump fault status indication can be configured as a Class 1 event, thereby triggering an unsolicited report to the DNP3 master device.
Another inherent feature of the DNP3 protocol is associatig diagnostic information for each field object, whether it’s a pump status, tank level, current flow rate, etc.
The diagnostic information answers questions such as, is the point online or offline, was it locally forced, chatter-detected, has it been restarted, is the value out of range and much more.
Again, in typical systems, a status indication for a pump will only show it is ON or OFF, in FAULT or OK. But when using the DNP3 protocol, one can detect if the information regarding the status of the pump is coming from the correct location. This is useful because, remotely, one can tell if wiring is correct.
Another example is if the chatter filter bit is SET, then if a field device is going ON/OFF continuously, spurious event logs will not be created. This is very useful when performing maintenance at a location.
Link to the full version of this white paper at bit.ly/awtech007
This white paper was written by CSE Semaphore Inc. Publication Date: 2012
