Example: Fault detection

This example demonstrates how to set up fault detection logic in a single source algorithm instead of having to replicate the fault detection logic in the Wire Sheet of every building.

Consider a BooleanPoint set up under each BuildingX folder with an analytic proxy extension to run the alg:HighPower algorithm at some frequency.

Figure 21. Proxy Extension set up to return an alarm

This configuration returns true in the Out slot, which indicates that an unacknowledged alarm condition for a specific Building (Bulidng 1 in this case) on the Campus..

To know how many buildings on your campus currently have a high power fault detection, you can add a NumericPoint to the Campus folder with an analytic proxy extension, run the same alg:HighPower, but this time with the Aggregation property set to Sum.

Figure 22. Proxy Extension configured with Aggregation set to Sum

In this case, the algorithm returns a result of 1 at the campus level because the DataSourceBlocks in the algorithm have the Use Request Aggregation property set to false and the Aggregation property set to null. This configuration causes the algorithm to default to First for the aggregation function. If Building1 is in the first slot position and its MainKw value of 450.0 is greater than its PowerLimit of 400, the algorithm returns true (value of 1). The alarm condition exists.

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, sum 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 result.

The BuildingX folders have a b:Building marker tag. You can configure the Data Filter property on the analytic proxy extension with a NEQL predicate to control where the algorithm is executed. Instead of aggregating all of the data sources (inputs) at the campus level and running the algorithm one time, you can configure the algorithm to run at each BuildingX folder and sum the results of the algorithm (output true=1 or false=0) together.

Figure 23. Use of a NEQL predicate to control algorithm execution

This Data Filter NEQL predicate needs to be an ‘or’ statement, which includes a tag that identifies each data source and a tag that identifies the base components (nodes that are children, grandchildren, etc. under the root node specified by the analytic proxy extension) to run the algorithm against. In this case, the algorithm runs against each of the four BuildingX folders and returns a value of 2 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.

Figure 24. Binding with its Data Filter configured

Alerts also have a Data Filter property, but it may not be used in the same way as the same property does in an analytic proxy extension and analytic binding. Consider an alert that is configured to run the same alg:HighPower against the Campus folder configured with the Roots property.

Figure 25. Analytic alert configured with the Roots property

This results in the following Alerts Node View.

Figure 26. Alerts Node View

This view shows that the algorithm is being run against many nodes under the Campus folder. It is likely that you only want the alert to be run against the BuildingX folders.

The alert has a Node Filter property, which also accepts a NEQL predicate, such as b:Building with which to configure the alert so that it only runs the algorithm against a node with the b:Building marker tag.

Figure 27. Alert configured with a Node Filter

Now the Alert Nodes View shows the algorithm only running against each of the BuildingX folders.

Figure 28. Alert Nodes View after running against a limited number of nodes