Trend Interval defined in a proxy extension

The framework handles the Interval property on the AnalyticProxyExt in a special way because, ultimately, the extension must resolve to a single answer even if it is using a Time Range for an analytic trend request.

Unlike a table or chart, which can display multiple values, the control point only has a single Out slot. Configuring the Interval property may impact the final result because the data (tag or algorithm) might produce different results when the framework rolls up history records into fewer records to be processed by the algorithm. In this case, the framework rolls up the historical records and runs the rolled up values through the algorithm. Then, running the algorithm many times rolls up everything into a single result.

Consider a power history for Yesterday where there are five records (highlighted below) with a value greater than 1,000 kW.

Figure 46.   NumericPoint table reporting kW values from Yesterday
Image

Notice that there are 96 records and the table is sorted on the Value column, not the Timestamp column.

The following basic algorithm evaluates whether the power value is greater than 1,000 kW.

Figure 47.   Algorithm to evaluate kW greater than 1000
Image

In the screen capture that follows, the control point, HighPowerCount, is configured with an AnalyticProxyExt.

Figure 48.   AnalyticProxyExt configured with Interval left at the default
Image

This configuration queries the HighPower algorithm for a Time Range of yesterday and a Rollup of Sum, which sums the results (false = 0, true =1) of running the algorithm 96 times once with each 15-minute record in the Time Range. The result is the expected 5.0 based on the history table above.

If not explicitly configured, Interval defaults to Fifteen Minutes, which just happens to match the collection frequency of the history, so, by default each record in the example above was actually processed.

Figure 49.   AnalyticProxyExt configured with Interval explicitly set
Image

If you explicitly set the Interval to Hour, the framework rolls up the four 15-minute records from each hour into a single value, then processes those 24 rolled-up values once each through the algorithm. Finally, it sums the results of the 24 algorithm executions returning only 2.0.

This result is probably confusing.

The Data Source Block property Use Request Rollup is false and the Rollup is null, so even though the analytic trend request specifies the Interval as Hour and Rollup as Sum, the Data Source Block uses the default Rollup function of First to return the result. Apparently, in this data set there were only two records in yesterday for the top of an hour (1:00 am, 2:00 am, etc.) where the value was greater than 1,000.

You could configure the Data Source Block to explicitly apply the Rollup function of Sum or to use the Rollup function from the analytic request.

Figure 50.   Data Source Block explicitly configured with a Rollup of Sum
Image

The screen capture shows the Rollup function of Sum explicitly configured in the Data Source Block. However, this configuration still does not yield the desired result because the high limit is hard coded in the algorithm and does not get rolled up like the power value does.

Figure 51.   AnalyticProxyExt still with an invalid result
Image

Using the bql query: bql:history:HistoryRollup.rollup(history:RollupInterval ‘hourly’), the request returned 18 because there were 18 hourly intervals yesterday where the sum of the four values is greater than the hard coded high limit of 1,000 as shown below.

Figure 52.   NumericPoint showing 18 instances where kW is greater than 1000
Image

In this case, if you planned to apply an Interval that is different from the history collection Interval you would need to have a history with the high limit value. Even if you do have a history with the high limit value, comparing the rolled up (sum) power values versus the rolled up (sum) high limit values may not produce the same or expected result as processing individual history records.