Event type data

The PI DNP3 interface considers an event to contain three attributes; information to identify the point, a value, and the time the value changed. DNP events belong to one of four different classes of data, 0, 1, 2, and 3. Events belonging to class 1 generally have a higher priority than events in class 2, 3, or 0 and class 0 usually refers to the static value of the data points. The DNP V3:00 Data Object Library (page 10-1) states "Class 0 data is potentially any information object not assigned to class 1, 2, or 3. That is, class 0 data is non-priority data." An information object refers to an object that contains information to identify the point, the new value, and the time (an event).

Scanning for event type data provides a much more efficient use of the network than scanning for the static values. For example, an analog input type may change every 10 seconds. In order for the interface to retrieve all of these changes, it would be necessary to scan for the static value of the point at a rate higher than 10 seconds. However, this still does not ensure all of the changes will be captured. It is much more efficient and the resolution of the data is ensured if the interface is configured to scan for event data. A scan for event data can be made once a minute or more and all of the changes will be sent to the PI server. The changes may be filtered out through compression or exception reporting, but that is completely configurable on a per-point basis. On the other end, if there is a point that does not change value very often, a request for the static value of the point every ten seconds is unnecessary in order to get 10-second fidelity. Once again a scan for event data every minute will retrieve the data and send to the archive the exact time the value changed without having to send a request every 10 seconds.

The interface does not define event type points, rather it defines event type scan classes with the /event=scanclass parameter in the start-up command file. The scanclass defines a scan class that corresponds to a /f= parameter from the start-up file and Location4 of the PI points. Every point in this scan class will be treated as an event type point. The DNP3 interface will send two types of requests to an RTU regarding event type points.

The first type of request is an integrity scan. An integrity scan is a request for Class 1, 2, 3, and 0 data (in that order). The RTU will respond to this type of scan will all of its events first and then a list of all of its points with their current value. The result of the integrity scan will be to update all of the PI points to their current DNP value. The integrity scan will be performed at start-up, upon recovering from a communications failure, and at a rate that is configured by the <IntegrityScan> node defined in the RTU XML configuration file.

The second type of request the interface will send is an event scan request. The event scan will be sent at the rate specified by the scan class. An event scan is a request for all Class 1, 2, and 3 data from the RTU. The RTU will respond to an event scan with a list of the events that have taken place since the last event or integrity scan. Some RTUs define events in different manners. A change in an analog input point from 1000 to 1010 may constitute a class 1 event in one implementation and not in another. To account for variations in RTU configurations and to prevent data loss, the DNP3 interface requests all Class 1, 2, and 3 data from all the RTUs assigned to an event class. Take care when assigning the /event parameter to a scan class. The scan rate assigned to the /event parameter must not be so long as to let the RTU's buffer fill with data. Refer to the documentation for the specific RTU to determine what constitutes an event, and how long it will take before the RTU buffer becomes full.

Note: Event scans will only be made at one scan rate per RTU. If an RTU is configured with points in two scan classes and both scan classes are configured to be an event class, the interface will send a request for event data at the smallest of the two scan class frequencies. All the RTU events will be returned as a result of an event scan. It does not make sense to ask for events at a rate of 10 seconds and also at a rate of 1 minute.