This project has moved. For the latest updates, please go here.

PublishedTimeStamp propery

Apr 11, 2013 at 6:08 PM
Edited Apr 11, 2013 at 6:08 PM

I don't understand how the key TrackPublishedTimeStamp=True affects the output.
  • I added in the database that collects the measurement a column "PublishedTime"
  • in the outputAdapter I wrote something like : PublishedTimeFieldName=PublishedTime
  • in the action adapter (DynamicCalculator) I added TrackPublishedTimeStamp=True
I only get a '0001-01-01 00:00:00.000' in the PublishedTime column, where am I wrong?
Apr 15, 2013 at 5:04 PM
This is currently only gets set by action adapters representing the "publication time" of the measurement - this is used to calculate how much time a measurement was in stasis before publication. This is a little problematic in itself since an individual measurement can travel through various actions adapters with multiple lag-times - so basically the measurement value (depending on when it was queried) would vary when multiple adapters concentrated the same measurement. Technically we could enable tracking of this property for other adapters as well, but it might take some doing. This property was based on a notion that when the system was configured in its simplest form (lots of device inputs and a single output), you could determine how long a measurement remained in the queue before processing was completed. Since then we have added various statistics which are adapter specific which can be used to calculate these kinds of values leaving this particular property as a historical relic, as such I think it has little practical value and should be removed.

What information are you trying to capture from the time? Perhaps there's an easier, more direct way of obtaining the information?

Apr 15, 2013 at 5:42 PM
Edited Apr 16, 2013 at 2:20 PM
The idea is to track the synchrophasors from the instant it enters in the openPDC, to the moment the measure is stored in the database. I can currently get the arrival time in the server (synchronized with a GPS card) using wireshark and I'd like to know when this measure leaves the openPDC to enter in the database (I need to store measurements as fast as possible)
I read in IaonAdapter.jpg that Measurement are sent directly to both Actions and Output Adapter with no delay so, if I don't use any action adapter, can I suppose that the arrival time is exactly the same of the output (I am using AdoAdapter with mysql database. The idea is to retrieve data with Matlab as soon as they are available).

Important question: How can I get the arrival time and output time using openPDC (writing a further column in the database for example). Any suggestion?
Bonus question (off topic): can I retrieve the data (at 50fps ideally) from the historian, without saving them in the database? maybe through the webservice?
Apr 17, 2013 at 3:05 PM
Edited Apr 17, 2013 at 3:05 PM
Yeah - that would be easy enough to add - but if fails at the same point as the other timestamp. In other words, if you only have one "output" it can mark the measurements timestamp, however, what if there are multiple outputs for a measurement? They would compete to set the output time.

It may be easier just to write your own output adapter that could send the current time along with the measurement to your archive instead of adding another field to the measurement - or - in your output adapter create a "derived measurement" that would wrap the original and expose the new "EndOfProcessing" timestamp.

Assuming you mean the "arrival time" of a measurement - this timestamp is there already as "ReceivedTimestamp". Only as accurate as your local clock though...

On your bonus question - you can "subscribe" to any data in real-time using the subscription API, see here:"Gateway%20Style%20Connection"%20between%20openPDCs%20and%2for%20openPGs

Apr 18, 2013 at 9:59 PM
Thanks for the answers, I am now able to subscribe in real-time.
What I am interested in is the possibility of enabling the ReceivedTimestamp property since my local clock is GPS synchronized! what should I do? I guess a simple: ReceivedTimestamp=true in my localhistorian definition doesn't make the trick.
Are you suggesting that once I enable it, I will be able retrieve through the API the received timestamp as well?! that would be great!