In most cases, you design an algorithm that runs against a specific piece of equipment (AHU, VAV, FCU, boiler, chiller, electric meter, etc.), in which case, you are likely to have a single matching component for each data source in the algorithm. You may run that same algorithm against ancestor nodes in the station to show analytic results at a less granular level, such as for all equipment on a floor, all equipment in a building or all VAV zones associated with a specific AHU. When you run the algorithm against those ancestor nodes you must understand how the analytics engine aggregates the data. Typically, the default is to aggregate the data sources (inputs) to the algorithm and process the algorithm one time; however, this might not return the desired results.

Consider a tree of components in a folder named BuildingX (Building1 in this example):

Figure 14.   Building example with tags identified

Building1 has the b:Building marker tag, and two numeric points:

The current values of the points are shown in the table to the right in the screen capture above.

The Wire Sheet for Building 1’s algorithm is called HighPower:

Figure 15.   Building 1’s HighPower algorithm

This algorithm has DataSourceBlocks for two inputs based on two tags associated with the points: hs:power and b:PowerLimit. The algorithm result returns true (value = 1) if MainKw > PowerLimit, otherwise it returns false (value = 0).

Extending this example, the customer might want to know in how many of their campus buildings they can currently detect a high-power fault? To answer this question, you would use a Numeric Point on an Analytic Proxy Ext to run the alg:HighPower algorithm with the Aggregation property configured as Sum. You would configure the property sheet for the extension’s Numeric Point as follows:

Figure 16.   Algorithm with Aggregation = Sum

In this case, the result (Out) is 1.0 at the campus level because the DataSourceBlocks in the algorithm have their Use Request Aggregation properties set to false and their Aggregation properties set to null. With these settings, the algorithm defaults to the First aggregation function. Building1’s MainKw point reports 450, which is greater than the building’s PowerLimit of 400, so the result is true (a value of 1). This is not the desired result since two buildings currently have power values greater than the power limit.

The DataSourceBlocks in the algorithm could be configured with Aggregation = Sum, but that would sum all of the MainKw point values for a single power value and all of the PowerLimit values for a single setpoint and then process the algorithm one time. It is very unlikely that summing all of the point values and running the algorithm once will return the expected answer.

The BuildingX folders have a b:Building marker tag. To control where the algorithm is executed, the Data Filter property on the Analytic Proxy Ext can be configured with a NEQL predicate. Then, instead of aggregating all of the data sources (inputs) at the campus level and running the algorithm one time, each BuildingX folder can run the algorithm and the results of the algorithm (output true=1 or false=0) for each BuildingX folder can be summed together.

Figure 17.   Algorithm with Data Filter configured

In this situation, the Data Filter NEQL predicate needs to be an ‘or’ statement that includes a tag to identify each data source required in the algorithm and a tag to identify the base components (nodes that are children, grandchildren, etc.). This gives the root node specified by the Analytc Proxy Ext’s Node property something to run the algorithm against. In this example, the algorithm runs against each of the four BuildingX folders and returns a value of 2.0 because Building1 and Building4 currently have high power levels. Widgets with analytic bindings also have a Data Filter property, which you can configure in the same fashion.