This project has moved and is read-only. For the latest updates, please go here.

timestamps validation - how much late / advanced can be a data frame to the historian?

Mar 1, 2010 at 8:31 PM

Hello all! Some days ago a PMU that was connected to the openPDC we have installed at UFSC had a problem in its GPS clock, and the timestamps of the data frames advanced about 30 minutes related to the real time. The openPDC ignored the data frames with advanced timestamps. The outputstreams that used the troubled PMU worked as expected, according to the Ritchie explanation ( No wrong data were stored in the historian. Despite the error in the timestamps, the GPS clock indicated that the clock was synchronized, and the bits at the STAT field of the PMU data frames indicated that the PMU was locked (bits 05 and 04  -> 00). We delayed and advanced artificially the GPS clock (about 30 minutes) to test, with the STAT bits indicating synchronized operation, and the results were the same. We deleted all the outputstreams configured in the openPDC, and the PDC operated storing data to the historian only. The results were always the same.

So, my doubt is: How does the openPDC work if some data arrive with late or advanced timestamps? What is considered the "real time" to compare the timestamps, regarding the historian storage only? Is there a parameter like the "leadtime" of the outputstream to validate the data frames, regarding the historian storage only? (not the real time data flow of the outputstreams)?


Mar 2, 2010 at 3:17 PM

Hi Marcelo,

The historian output adapter does have a LeadTimeTolerance setting in the config file under <xxxArchiveFile> section that can be used to adjust the tolerance on data with timestamp in the future as compared to the local system clock.

- Pinal

Mar 2, 2010 at 4:06 PM

Hi Pinal.

Thanks for your answer. Does the LeadTimeTolerance work if the timestamp is in the past? What happens if a data frame with a timestamp in the past (a lot of minutes, or hours) arrives at the openPDC? The parameter DiscardOutOfSequenceData participates in this process? Can you explain how this parameter works?


Mar 2, 2010 at 6:47 PM

Hi Marcelo,

The logic behind DiscardOutOfSequence has not been implemented yet, but what that will do when implemented, will allow for the insertion of measurements that arrive out-of-order to the historian component.

As far as timestamps in the past goes, say a device is reporting correct time and its measurements are being archived and say the device starts reporting time in the past, this data will not be archived with the current implementation of the historian component since it is considered out-of-order.

- Pinal

Mar 3, 2010 at 1:23 PM

Pinal, I got to reproduce here the behavior you explained. It works great!
Thank you very much!