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

Mixing archived and real-time signals - do these have the same ID?

Apr 26, 2011 at 3:06 PM

One problem we need to solve for our implementation of openPDC is the replay of past events where data is flowing not from the real time inputs, but from the historians.
As far as I can tell these signals all appear to have the same identifiers (something like PPA:<n>) - how to we differentiate between archive and real-time data in this case?

A scenario would be:

Client A is subscribed to frequency averages using PPA:1, PPA:2 and PPA:3 (realtime).
Whereas Client B is reviewing frequencies PPA:1, PPA:2 and PPA:3 from 7 days ago.

How do we ensure that the streams with the same identifier do not get "mixed together" - especially if Client B decides to create a frequency average, still from 7 days ago.

Do we need completely distinct action adapters?
One checking that the time stamp is current, and the other is for data 7 days ago.

So far the only controls I've used are the lead and lag time, this does not seem viable for historical data.


Apr 29, 2011 at 8:38 PM

One thought is that old and new measurements flowing through the system with the same IDs would be perfectly valid.

  1. If you have a real-time concentrator, this would ignore (i.e., discard) all the old measurements.
  2. Then you could have another adapter that was looking for non-realtime data - see flags for dealing with historical data (e.g., performTimestampReasonabilityCheck = false) - another flag might be needed to set the base real-time for this adapter to be in a historical context.

Alternately you might define two sets of points in the system - one set representing real-time (perhaps RT:<n>) and one set representing historical (perhaps HD:<n>) - just because these may represent the same points would not affect system operation, just your adapter implementation and personal interpretations.

In this scenario:

  1. Normal real-time device inputs would map to an actual historian (i.e., archived) with an acronym of RT, and,
  2. An input adapter would map historical data to a virtual historian (i.e., not-archived) with an acronym of HP

Two thoughts anyway...