Fault Detection and Diagnostics: A Complete Guide

Commercial buildings rarely fail loudly. They drift. A damper sticks half open, a sensor reads two degrees high, an override from a hot afternoon in July is still in place in November. The building keeps its occupants comfortable throughout, because the control system compensates, and the cost of that compensation appears only on the utility bill and eventually in the service record.

Fault detection and diagnostics is the discipline built to find those conditions automatically. It is one of the oldest applied analytics problems in building operations, with a research literature going back decades and a commercial software market that has existed since the 2000s. It also has a well-documented gap between what it detects and what gets fixed.

What is a fault?

A fault is equipment operating in a way that departs from how it was intended to operate, for a reason that can be identified. That definition does more work than it appears to, because it requires a specification of intended behavior. Without one, there is no deviation to measure.

ANSI/ASHRAE Guideline 36-2024 supplies that specification for a wide range of HVAC systems, documenting high-performance sequences of operation. A sequence of operation states what a system should do under given conditions. A fault is a departure from it. Buildings commissioned without a documented sequence are harder to diagnose for exactly this reason: the baseline has to be inferred before anything can be called a deviation.

What is the difference between a fault and an alarm?

An alarm is a threshold crossing. A space temperature exceeds its limit, a pressure sensor reads outside its band, a unit fails to start. The building management system reports it because a number moved past a line somebody set.

A fault is a diagnosis. It says that a specific piece of equipment is behaving incorrectly and offers a probable cause. A high discharge air temperature is an alarm. A cooling coil valve leaking through while the unit calls for no cooling is a fault, and the second one tells a technician where to go.

Alarms are generated by the control system as a byproduct of running the building. Faults are generated by an analytical layer sitting above it, reading the same data with a different purpose. A building can produce thousands of alarms and no faults, which is a common and misleading state.

How does fault detection work?

Three approaches dominate, and mature deployments generally combine them.

Rule-based detection: a rule encodes a known relationship between measured points and reports a fault when the relationship is violated. If an air handler is calling for cooling while its outdoor air damper is fully open and the mixed air temperature sits above the return air temperature, something is wrong with the damper, the sensor, or the sequence.

The reference implementation is public. The Air Handling Unit Performance Assessment Rules, developed at NIST and published in Energy and Buildings in 2006, set out a rule set for air handler faults that a substantial share of commercial rule libraries still descends from. NIST also published an implementation guide for it. Rules are transparent, computationally cheap, and explain themselves, which matters when a technician has to act on the output. Their limitation is that they only find what somebody anticipated.

Model-based detection: a physical or empirical model predicts what a system should be doing given current conditions, and the residual between predicted and measured behavior indicates a fault. This handles equipment whose correct behavior varies continuously with load and weather, where a fixed threshold would either miss faults or produce false ones.

Data-driven detection: statistical and machine learning methods learn normal operation for a specific unit from its own history, then flag departures. The Lawrence Berkeley National Laboratory review of data-driven fault detection for building HVAC systems is the standard survey of this literature. The appeal is catching faults nobody wrote a rule for. The costs are the need for representative training data and reduced interpretability when the system reports something a person then has to explain to a contractor.

None of the three removes the underlying dependency: fault detection needs measured points, and buildings vary enormously in what is instrumented and how consistently those points are named. Data preparation is routinely the largest part of a deployment, and it is the part least visible in a product demonstration.

What kinds of faults occur?

Faults cluster by equipment class, and the same short list recurs across almost every portfolio.

Equipment	Common faults
Air handling units	Damper stuck or leaking, simultaneous heating and cooling, economizer not sequencing, sensor drift, fan running outside schedule
Terminal units	Unable to meet setpoint, reheat valve leaking through, airflow below minimum, damper hunting
Chiller plant	Sequencing inefficiency, condenser approach degradation, pumps running with no load, staging faults
Boilers and heating	Simultaneous operation with cooling, reset schedule not applied, valve leak-through
Controls and schedules	Overrides left in place, holiday schedules missing, setpoints drifted from design

Most of these are invisible to occupants. The control system compensates, comfort holds, and the cost appears only on the utility bill, which is how a fault can run for months without anyone raising a ticket.

A large share also involve no broken hardware. An override left in place after a hot afternoon, a schedule that was never updated when the tenant changed, or a setpoint that no longer matches how the space is used will each produce a genuine fault, and none of them needs a technician with a wrench. Finding them is the hard part. Correcting them is often a single change in the control system.

Published datasets show what these conditions look like in the data. An open-access set of variable air volume terminal unit faults documents them in ordinary trend records, which is the same data a building management system is already collecting.

For an asset-class view of how these show up in practice, our post on hidden HVAC faults in hotels works through five of them in a hospitality context.

What do faults cost?

Portfolio-level figures are estimates and should be treated as such.

The most commonly cited comes from the US Department of Energy, which states that faults in US commercial buildings have been estimated to waste 0.7 quads of energy annually, worth nearly $14 billion. The same source notes that around 90 percent of buildings, and nearly half of commercial floor space, is served by rooftop units, which concentrates a great deal of the opportunity in equipment that is rarely monitored closely.

Building-level economics are more tractable. A fault has three costs: the energy it wastes while it persists, the accelerated wear it causes to equipment forced to compensate, and the labor eventually spent diagnosing it reactively rather than deliberately. The third is routinely the largest and the least tracked, because it arrives disguised as ordinary maintenance.

How should a team evaluate fault detection software?

Criteria that hold regardless of vendor:

Detection coverage against your equipment: rule libraries are usually strongest on air handlers and weakest on plant. Ask which equipment classes are covered and at what depth.

Point requirements: ask what measured points each rule needs, then check them against what your buildings actually trend. Point availability is where most deployments slip.

Diagnosis quality: whether output names a probable cause or only reports an anomaly. The difference determines whether a technician can act without re-investigating.

Prioritization: whether the system ranks output by financial consequence, and on what basis. Given the volumes below, this is arguably the most important question on the list.

False positive handling: how the system learns that a reported fault was not real, and whether that learning persists.

What happens after detection: whether the product's responsibility ends at the report.

Where fault detection stops

Lawrence Berkeley National Laboratory ran a three-year study, funded by the Department of Energy, examining fault prevalence across a large sample of real buildings. The results presented at the 2023 Building Technologies Office Peer Review covered 317 buildings, 3,660 air handling units, 53,865 air terminal units and 7,974 rooftop units, drawing 18 million rows of fault data across 182 defined faults from eight commercial FDD tools.

The headline number is that the average building generated 245 faults per month. That works out to roughly three faults per air handling unit and one per air terminal unit each month, which sounds modest until it is multiplied by the equipment count of a real asset. The study gives two examples. An office building with 8 air handlers and 175 terminal units produced 98,234 daily fault records over a year. A hospital with 47 air handlers and 818 terminal units produced 443,308.

No engineering team has the hours to triage that. The output gets sampled rather than worked, the same faults recur in every report, confidence in the tool declines, and eventually the reports stop being opened. The detection was correct throughout. The capacity to act on it was the binding constraint, and it always was.

This problem has been recognized in the literature for a long time. An ACEEE Summer Study paper from 2012 on coordinating fault detection, alarm management and energy efficiency was addressing the same tension more than a decade ago.

For anyone evaluating this software, detection capability is rarely the differentiator. Two competent products will both find the faults. They differ in what they do with several hundred findings a month, and in whether the team receiving them ends up with a shortlist or a backlog.

Where the discipline is heading

The direction of travel in the research is toward systems that do more with what they detect. The systematic review of AI methods in HVAC fault detection and diagnostics tracks a shift from classification accuracy as the objective toward diagnosis, prioritization, and integration with the operational workflow.

Agentic approaches extend that further. Rather than presenting detected faults for a person to sort, an agentic system treats them as raw material: correlating findings across systems to identify a common root cause, testing which items carry enough financial consequence to justify the work, executing changes where it is authorized to, and verifying the outcome. Detection itself changes very little. The work that follows detection changes substantially.

Whether that is worth anything depends entirely on the constraint identified above. In an organization with abundant engineering hours, better triage is a convenience. In one where a lean team covers a growing portfolio, it is the whole problem. Our guide to agentic AI for building operations covers the category in full, and our post on moving from reactive operations to automated low-carbon buildings works through what the transition looks like operationally.

Where Noda fits

Noda is an agentic AI platform for commercial building operations that works as an always-on virtual building engineer, scaling engineering team capacity across every asset in a portfolio.

In the terms of this guide, Noda sits above the detection layer rather than replacing it. Fault detection output is one of its inputs. The platform correlates findings across building systems to identify root causes, validates which items are economically worth acting on, executes optimizations through two-way controls where it has been authorized to do so, and measures the result. Connection to building systems is established through the Noda LaunchPad, an on-premise gateway.

The design assumption is the one the LBNL numbers describe: that the scarce resource in building operations is engineering attention, and that the useful thing to do with several hundred monthly findings is to reduce them to a short list of validated work. More detail on the architecture is on the platform page.

Related reading

• Agentic AI for Building Operations: A Complete Guide
• 5 Hidden HVAC Faults That Are Quietly Driving Up Energy Costs in Hotels
• From Reactive Ops to Automated, Low-Carbon Buildings