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

DynamicCalculator adapter and LagTime/LeadTime

May 13, 2013 at 4:37 PM
I have many many instances of DynamicCalculators, some of which work on normal incoming signals, others that operate on calculated data from PowerCalculator and other DynamicCalculators. It is very difficult to get this to work; I've had to set lagtime/leadtime to 37/30 seconds in some cases, and even so some adapters are not returning any results - I imaging they are discarding all data.

Is there a way to tell an adapter to simply accept the latest measurements for the set of inputs, and not to worry about how the timestamps match? Or is there a better way of thinking about this problem?
May 24, 2013 at 3:13 PM
Currently the "LatestMeasurements" property which maintains all the latest values is time bound based on the lead/lag times specified by the adapter. This will usually work fine when all your input measurements have a similar operational time domain.

However SCADA measurements may be in the +/- 10 to 30 seconds range - and there is no need to create such huge lag times for these measurements.

I think what needs to happen is this:

1) Allow a per measurement (or group of measurements) time validation range (i.e., a lead/lag time config option per point)
2) Make sure that the dynamic calculator will access the LatestMeasurements property when the real-time value doesn't exist or is NaN

That should allow the calculator to manage streaming data with widely variable time domains....

May 24, 2013 at 3:24 PM
I have sets of lagtime/leadtime for sets of adapter definitions. The adapters that compare PI data against either PMU data or other PI data are segregated by these definitions, so I could have lagtime/leadtimes based on these characteristics. I'm still not sure what values would work. SCADA data usually isn't too far from real-time, 4-6 seconds, but SE data can be several minutes between values. I guess both SCADA and SE data could be considered 'real-time', but with indefinite gaps.

The value from LatestMeasurement would probably be from the PMU measurement; when a PI data measurement arrives, find the most recent PMU data measurement and perform the calculation. I'm not sure if the other way around would be good; that is, every time a PMU measurement arrived (usually once a second, perhaps 30 times/second), grab the latest PI measurement and calculate... the PI data could be very very old, so the results of this calculation wouldn't be correct. Perhaps the ConnectionString could have a parameter to signify the driving measurement, in this case the PI measurement.