DNP3 Driver Guide - How Data Retrievals Affect the Persistence Expiry Time (Points Used on DNP3 Outstations)

How Data Retrievals Affect the Persistence Expiry Time

With points on advanced drivers, Geo SCADA Expert maintains three views of each point's data. These are based on:

Current data
Logged data
Last retrieved data.

(With the DNP3 driver, current data comprises DNP3 static data, and logged data comprises DNP3 event data.)

Current data comprises the last current data to be sent to the database and logged data comprises the last logged data updates to be sent to the database. Current data is timestamped by the driver, whereas logged data is timestamped by the outstation.

Retrieved data comprises the very latest data that Geo SCADA Expert has received for the point (either current or logged). Retrieved data is local to the driver and is updated before filters such as Significant Change are applied. In many cases, the retrieved data will match either the current data or logged data that is in the database, but in the case of insignificant changes, this is not guaranteed. Logged data and external refreshes that have been requested by users or Logic are always sent to the database, but current data is filtered to avoid needless repeats of the same data being stored. For example, filtering such as Significant Change will prevent current data changes that are very close to the last value that has already been reported to the database from being sent to the database. However, the retrieved data will still include this later change.

Persistence can be triggered by any current data or logged data update that shows a point's value to be in a point state other than that which was last reported to the database. If the outstation has not provided the driver with both the Value and State of the point, then the driver derives the State from the relevant data to which it has access. This includes checking that the engineering range has not been exceeded and applying any Hysteresis before determining the new state of the point. If the new state differs to that which was last reported to the database, then the persistence timer is started. (In the case of 'Away From Normal' persistence, multiple persistence timers can be started by a single point update, depending how many states away from the Normal state the point is deemed to have traveled.)

If the Persistence is initially triggered by logged data, that data will have a timestamp that is in the past (as the timestamp was applied by the outstation). The Persistence expiry time is then calculated from that logged data timestamp.

If the Persistence is initially triggered by current data, that data update is timestamped by the driver. As such, the timestamp might be later than the actual time that the point entered the new state at the outstation. However, in order to compensate for this, the driver is able to adjust the persistence timer as it is running. It does this by taking into account any further data updates that it receives and processes while the persistence timer is running. If it receives logged data from the outstation that contains an event for the state change with an earlier timestamp, it adjusts the persistence timer to take account of that new, more accurate, timestamp for the state change. In such situations, it might initially appear that the persistence timer has expired after a shorter time than expected. However, a review of the Events List or driver log files should clarify that the driver has adjusted the persistence timer's start time in response to more accurate data being received from the outstation while that timer was running. The persistence timer will still only have expired at the end of its configured Persistence Duration, but its start time (and therefore also its end time) might well have been updated in relation to those further data updates.

This example demonstrates how the driver might adjust the start time (and therefore also the end time) of a persistence timer while that timer is running. The driver is designed to do this in response to further point data updates that it receives from the outstation, in order to reflect more accurately the time that the point entered its new state.

With the above example, HH = High High, H = High, N = Normal state, T = Time, S = Seconds, CDR = Current Data Retrieval (received via an Integrity Poll, or a Refresh), Log = Logged Data Retrieval. The outstation is configured to enable Unsolicited Messages, with the interval set to 10 seconds. The Persistence Duration on the analog point is set to 30 seconds.

At T, an analog point changes state from its Normal state to the High state. This state change is timestamped by the outstation, which then stores the information as logged data. The state change occurs in between polls of the outstation.

8 seconds later, at T+8S, the driver processes a Current Data poll (CDR1) from the outstation, which indicates that the above point state change has occurred. As current data does not have a timestamp, the driver timestamps the data with the receipt time of that data (which it received at T+8S). As the change in point state is configured to trigger persistence, the driver starts the persistence timer. The Persistence Duration is configured as 30 seconds, so the driver sets the timer to expire at T+38S (which is 30 seconds after the time that it received the current data).

At T+10S, the driver receives Log1. This includes the data that the outstation logged about the same change in point state. It includes a timestamp from the outstation which indicates that the point actually changed state (from Normal to the High state) at T. The driver therefore adjusts the persistence expiry time from T+38S to T+30S (which is 30 seconds from the state change time provided by the outstation's timestamp). This adjustment takes into account the time that the point actually changed state on site (rather than the system time that the driver applied when it was first notified of the point state change in CDR1).

Therefore, at T+30S, the persistence timer expires and the state change is recorded as a message in the Events List (and also raised as a alarm if the High state is configured as an alarm state).