Data Acquisition within DNP3

DNP3 offers an array of methods for data acquisition from DNP3 devices, but not all devices will support all methods of data acquisition. The simplest form of data acquisition, and the one that all DNP3 devices support, is the acquisition of a group of points that have been pre-defined in the device. This is known as a class request.

DNP3 devices have four definable groups (classes) of I/O points:

• Class 0 lists the I/O points that are to have their current value sent back to Plant SCADA, when Plant SCADA sends a Class 0 request.

• Class 1 lists the I/O points that are to have their events sent back to Plant SCADA, when Plant SCADA sends a class 1 request.

• Class 2 and class 3 are conceptually the same as class 1 but are separate groups to allow prioritizing of event data.

To summarize, class 0 requests will result in a reply containing the current value of all of the predefined I/O points, whereas class 1, class 2, and class 3 requests will result in a reply containing all of the buffered events that have occurred for all of the predefined I/O points in class 1, class 2, or class 3.

The DNP3 protocol ensures that if a request is made to a device for Class 0, class 1, class 2, and class 3 data, then the device will reply with all of the buffered events (with the most recent event received last), and then reply with the current data. The order in which the data arrives guarantees the most recent value is held in the driver cache, and the inclusion of Class 0 static data assures that data acquisition is not overly dependent on the report-by-exception mechanism. This form of all-classes poll is termed an integrity poll.

The device may automatically send event data to Plant SCADA (this is termed an Unsolicited Response), or it may wait until Plant SCADA requests class 1, class 2, or class 3 data. In either case the driver will update its cache with the value received in the event data, and also check if the event is related to an alarm tag or a trend tag that needs processing.

Citect.ini parameters exist that allow event polls to be isolated into classes. The default behavior is that all event classes are polled on each event poll. The following Citect.ini parameters control the ratio for each class to the event poll (see Polling Regime Parameters):

• [DNPR]EventPollRatioClass1Default

• [DNPR]EventPollRatioClass2Default

• [DNPR]EventPollRatioClass3Default

• [<unit>]EventPollRatioClass1

• [<unit>]EventPollRatioClass2

• [<unit>]EventPollRatioClass3

A value of zero will turn event polls off for that class. A value of 2 would mean that this event class happens every n second poll period. Be reminded that the integrity poll always asks for the static data for all event classes.

The default DNP3 master address for Plant SCADA is defined by the parameter [DNPR]SCADAAddress Define this master address in the slave device, if the slave is to send unsolicited responses to Plant SCADA. A different master address can be specified in each unit, using the device-level parameter [<unit>]SCADAAddress.

If the device does support unsolicited responses, then having all I/O points report through exception (send events on change of data) will allow Plant SCADA to poll (with an integrity poll) the device infrequently. This data acquisition algorithm requires very low traffic throughput on the network.

If the device does not support unsolicited responses, then more frequent Plant SCADA polling (with event polls for all classes) will keep its cache up-to-date. After every n event polls, Plant SCADA sends an integrity poll to ensure the data integrity of the driver cache. The period between polls for a device is defined by [DNPR]EventPollPeriodDefault and [<unit>]EventPollPeriod, and the ratio of Event Polls for every integrity poll for a device, is defined by [DNPR]EventPollRatioDefault and [<unit>]EventPollRatio.

If the device does not support report-by-exception (i.e. it does not buffer event data but will only reply with current data) then the EventPollRatio should be set to zero so that only integrity polls are issued, and the EventPollPeriod should be set to a low value in order to keep the driver cache up-to-date.

The DNP3 protocol also offers other data acquisition algorithms in which the device master (Plant SCADA) can request points that are defined by the master, not by the slave. There are numerous methods, each offering varying levels of control the master has in determining which points it can request. As the level of support for these data acquisition algorithms differs from device to device, and some devices do not support these data acquisition algorithms, Plant SCADA will only implement the Class read data acquisition algorithm described above.

In summary, all of the I/O points in a device that are required by Plant SCADA should be allocated to Class 0 in the device. If the device supports report-by-exception (which is strongly recommended), then also allocate each point to one of the event classes.

Example

The following diagram gives an overview of the DNPR functional blocks. Debug options are also along these functional block lines.