AutomatedBuildings.com Article - Inside the Killer App for Buildings & Energy Management

While there are several software tools and applications that have proven beneficial for building operations and energy management, the software application with the best verified results and cost effectiveness is fault detection and diagnostics. It’s the killer app of the building automation and building energy management industry.

Fault detection and diagnostics are a subset of the larger category of analytic software related to buildings. Analytics are critical because buildings are becoming more complex, new systems are being introduced into buildings and energy consumption metrics and key performance indicators are now of great interest to corporate or organization executives. In general, analytic software tools primarily support technicians and engineers in the field who are dealing with both the everyday issues of building operations as well broader issues of complicated systems, advanced technology and higher expectations for building performance. The analytic tools provide insights into building systems resulting in reduced energy consumption, improved building performance and lower costs.

Fault detection and diagnostics for HVAC systems are not new. Research, development and testing of fault detection approaches have been around for about 20 years or so. What is new is the increased interest in and actual use of fault detection. As an example of industry approval, in October 2011 the U.S. Green Building Council (USGBC) and SCI Energy announced a technology agreement where building owners would be able to use SCI’s SCIwatch™ technology through the LEED Online platform. This analytic tool utilizes automated fault detection for ongoing commissioning and predictive maintenance in commercial buildings, something of extreme interest to USGBC and energy management in general.

Another example involving actual deployment and use of fault detection, and probably one of the most recent and best examples, was a pilot program at Microsoft’s Redmond campus. Microsoft installed a fault detection application that could “monetize” each fault and identify the annual cost of the fault. Not only did Microsoft discover faults they were never aware of, but their engineers saved significant time in addressing operational issues. This tool allows Microsoft’s typical 5-year retro-commissioning cycle for their campus to be accomplished in just one year. Annual energy cost savings for Microsoft from automated fault detection alone may exceed $1 million. (To read the Microsoft case study, click here.)

Lawrence Berkeley Laboratories in a study on monitoring-based commissioning, an element of which is building diagnostics, showed an average energy savings of 10 percent, with as much as 25 percent in some cases. When you have organizations such as USGBC, Microsoft and Lawrence Berkley Labs broadly supporting the results and benefits of fault detection, there’s something to its application.

System faults are different than traditional system alarms. Faults deal with a system’s performance; that is, the system is operating but performing sub-optimally and the software application identifies the reason for the sub-optimal performance or fault.

The “fault detection and diagnostics” tools in the marketplace may use different methods to detect a fault and have different capabilities for diagnosis. The major differences with the FDD approaches involve capabilities to identify single or multiple faults, the type of building systems to be monitored, whether diagnosis is provided by the tool or done manually, as well as conveying to the building operator the consequences of the fault, such as monetizing the fault. What follows is a discussion of some of the more common methods for finding faults.

The most researched and probably the most used fault detection method is a “rule-based approach” for HVAC systems. This makes sense for several reasons: the HVAC system in larger buildings is the most complex building system, the most energy consumptive system, and rules can be developed for how each piece of HVAC equipment needs to interact with other HVAC equipment. The FDD rules for HVAC are particular to specific types of equipment. The general relationship is a “source” serving a “load” via an air or water interface between the source and load (i.e., a chiller serving air handlers, an air handler serving a VAV box, etc.)

[an error occurred while processing this directive]
Essentially, the software application is monitoring the data points in the HVAC control system in real-time (temperatures, flows, pressures, and actuator control signals) and evaluating whether the relationship between a chiller and an air handler, or an air handler and a VAV box, etcetera is optimal. If not, it detects a fault and diagnoses a problem based on the rule. Usually one would get faults in both the “source” and the “load”, but the assumption is that it’s a fault in the “source” and the faults in the “load” should be suppressed. A simple example is chiller supplying water to an air handler that is too warm. The air handler’s cooling coil valve then becomes 100% open and supply air temperature is above set point, resulting in the VAV not being able to maintain air temperature in its zone. The software would get faults for all three pieces of equipment, but suppress the faults for the loads, the air handler and the VAVs.

The real beauty of the rule-based approach is the simplicity and transparency of the rules and the identification of the causality. Because most of the data points in a building are related to HVAC systems there’s just more data to analyze resulting in more reliable results.

An alternative or supplement to analysis of an HVAC “rules approach" is monitoring electrical loads of HVAC equipment; fans, pumps, chillers, etc. This approach requires metering or voltage and current sensors. This method uses power information for specific pieces of HVAC equipment and typically will correlate power to airflow or motor speed, or examine the changes in power when equipment such as a pump or fan turns on or off. Overall, the technique is useful, but limited.

Some software applications will trend data over time or other variables, attempt to recognize a pattern or relationship in the trend and then compare the pattern to known faults or symptoms or look for abnormalities. Regression analysis, a statistical method, is typically used to define the relationship between variables. It is a common analytical tool, available on applications such as Microsoft Excel, and is used to predict, estimate and possibly identify causation. This approach can provide results but probably not as explicitly or accurately as a rule-based approach. Trending or pattern recognition is likely to identify a single fault or event or something more ambiguous such as a “fault signature”. For example, you may trend actual energy consumption and expected energy consumption and note some abnormalities or “faults”; but identifying the fault or abnormality may involve additional data, analysis and correlations.

Although building operations is a sector which has not typically used software tools to analyze building data or mine data, the growth in the use of analytic tools such as fault detection and diagnostic will be substantial. These tools have proven results for improved operations, reduction of energy consumption and cost savings, and simply cannot be ignored.

Smart Buildings works with building owners to design, specify and procure the energy and building efficiency systems most suitable to their needs. For more information on this article or about how Smart Buildings, LLC helps building owners, write us at info@smart-buildings.com

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources