Effects of RTU Clock Changes on Kingfisher Driver

[Anonymous user]

📖 Home  Back  
A change in the clock in a Kingfisher RTU can have significant effects on the data processing in ClearSCADA. In particular, outstation clock changes can affect:

• Event Uploads

• The Order of Events.

Event Uploads

Kingfisher RTUs keep a circular buffer of historic data. When event data is read from a Kingfisher RTU, the data is not deleted from the RTU event buffer. Instead, it remains in the circular buffer until the buffer becomes full (at which point, the data is overwritten).

When ClearSCADA first establishes communications with a Kingfisher RTU (that it has never communicated with before), it requests all historic data from the 1/1/1970. This ensures that all data that is available in the RTU is transferred to  ClearSCADA. As part of this process, the RTU returns a Log Index. ClearSCADA uses the Log Index to identify the starting point for the next set of updates (where the polls should continue from next time).

For subsequent polls, ClearSCADA will simply request the next set of data based on the current Log Index it has stored. 

If the clock in the Kingfisher RTU is set to an earlier time, ClearSCADA will retrieve the historic event data without any problems as the RTU will return the new events based on the Log Index (even though they are out of order).

If there has been a loss of communications, ClearSCADA will only have historic data up to the time of the communications loss. This means that when ClearSCADA is able to re-establish communications, the Log Index may be invalid. To ensure that ClearSCADA continues to receive the historic data, ClearSCADA requests all data from the time of the communications loss. For this reason, it is important that the RTU clock is not set to an earlier time during a communications loss as ClearSCADA will only request data from the time of the last time-stamp. If events are generated in the RTU with timestamps that are earlier than the last known time in ClearSCADA, ClearSCADA will not request them from the RTU.

Note that this is only an issue if the time is changed in the RTU while communications are disrupted.

 

The Order of Events

When events appear to be in the wrong sequence, there are two possible causes:

• Future Data---Data that is time-stamped ahead of ClearSCADA time.
  * Past Data---Data that has older time-stamps than the most recent event data received by ClearSCADA.

Future Data

Future data is data that is a certain period ahead of the ClearSCADA server's current time.  The time window settings in the Server Configuration Tool affect the data that is received by ClearSCADA - only data with a time-stamp within the defined time window is processed; all data time-stamped outside of the time window is discarded.

The default time window settings apply to all data with a time-stamp that is from 365 days in the past to 72 hours in the future. Any data that has a time-stamp outside of this time window is discarded. Data that is time-stamped with a time more than 60 seconds into the future is marked as future data (the 60 seconds limit is the default setting but can be changed). Future data is still handled by ClearSCADA, but it will be allocated a quality setting of Future Data and will be represented by a different color in the system (the color is also configurable in ViewX).

Past Data

Each I/O point assumes that data will be received in time order i.e. new incoming data will be more recent than data that has already been received. In normal circumstances, this does not pose a problem as reported data does have a later timestamp than the data already received. However, if the clock in the RTU has its time moved backwards, the data that is sent to ClearSCADA could have a timestamp that is older than data that has already been received.

This only applies to time-stamped event data received from the outstation. It does not apply to current data.

In versions prior to ClearSCADA 2007, past data such as this was discarded due to the duplicate data checks that the Kingfisher driver performed. This meant that if an outstation clock was put back and an alarm was generated in the RTU with a timestamp older than the most recent time in ClearSCADA, the alarm was discarded. Also, historic data was not logged and Mimics did not update. Although rare, this scenario could cause problems, particularly if alarms were not received.

In ClearSCADA 2007, a new setting was made available  to resolve this problem. The Chronological Event Data field is a new field on the Outstation Form. It allows you to define whether the chronological order of event data that is returned from the Kingfisher RTU is checked.

If the Chronological Event Data field is enabled (it is enabled by default to maintain compatibility with older versions), data which has an older timestamp than the most recently received data in ClearSCADA is discarded.

If the Chronological Event Data field is disabled, ClearSCADA will process all data irrespective of the data's timestamp. This means that historic data will be added to the historic lists, Mimic data will be updated, and alarms will be generated based on the time-stamp received (even if it is older). The generation of alarms relies on the Logged Data - Alarms From field on the points being set to allow alarms from Logged Data.

When the outstation clock is set back, you need to be aware of:

• Unreliable Data - During the period between the clock being set back and the clock catching up with the real time in ClearSCADA, the historic data shown in ClearSCADA will be unreliable. This includes historic, alarms, and events. Sequence of event information will also be incorrect. However, alarms and the current values of points will continue to update.

• Duplicate Historic Events---After the RTU clock has been changed, it is possible to get duplicate historic events in the historic lists and event journal. If the clock is set back, ClearSCADA will begin (on the first poll after the change where historic data is provided) to request data from an older timestamp. This means that all historic data already processed in this time window will be processed again as it is returned by the RTU. This may result in many duplicate data events and historic entries in the system.

Go: Home Back