What is Fault Detection and Diagnostics (FDD)? The Complete 2026 Guide

Most building faults don't announce themselves. A damper sticks half-open, a valve leaks by a few percent, a schedule drifts by an hour — and the building keeps running. Tenants stay comfortable, no alarm sounds, and nobody raises a work order. The only evidence is on the energy bill, months later, buried in a number nobody can explain.

Fault detection and diagnostics — FDD — is the discipline of finding those faults automatically, working out what caused them, and putting them in front of the person who can fix them. It's one of the highest-return capabilities available to a commercial building operator, and one of the least understood.

This guide explains what FDD actually is, how it works, what it finds, what it's worth, and how to deploy it without drowning your team in alerts.

What is fault detection and diagnostics?

Fault detection and diagnostics is a software capability that continuously analyses building data — typically from a building management system, meters and sensors — to identify equipment and control problems, diagnose their likely cause, and prioritise them for action.

It has two distinct halves, and the difference matters:

Detection answers “is something wrong?” It compares how equipment is behaving against how it should behave. A chilled water valve commanded shut but showing a temperature drop across the coil is a detected fault.

Diagnostics answers “what is wrong, and why?” It narrows the possibilities to a probable cause — the valve is leaking by, the actuator has failed, or the sensor is reading incorrectly — so the person receiving it knows what to investigate.

A system that only detects gives you a list of symptoms. A system that diagnoses gives you something a technician can act on. When FDD is described as “automated fault detection and diagnostics” (AFDD), the emphasis is on doing both continuously and without human analysis.

How common are faults, really?

More common than most operators expect, and the evidence is now solid.

Researchers at Lawrence Berkeley National Laboratory analysed multi-year monitoring data from more than 60,000 pieces of HVAC equipment, examining around 90 distinct fault types. Their finding: on any given day, 40% of air handling units and 30% of air terminal units had a reported fault of some kind. The study also identified 21 separate AHU fault types affecting a fifth or more of all units monitored, many of them persisting for more than 20% of the monitored period.

That last point is the important one. These aren't dramatic breakdowns. They are conditions that persist — quietly, for months — because nothing in the building's normal operation surfaces them. A fault that trips a plant is found within hours. A fault that wastes 15% of a chiller's energy while keeping the space comfortable can run for years.

Buildings do not lack data. They lack a mechanism for turning data into a short, ranked list of things worth fixing.

How FDD works

Whatever the vendor, the pipeline is broadly the same.

1. Data acquisition

FDD needs building data at reasonable frequency — typically every 5 to 15 minutes. That comes from the BMS over protocols such as BACnet or Modbus, supplemented by utility meters, sub-meters, IoT sensors, weather data and, increasingly, occupancy data. Coverage matters more than exotic instrumentation: a platform reading 2,000 existing BMS points will find far more than one reading a handful of new sensors.

2. Data normalisation and tagging

Raw BMS points are named inconsistently — AHU-3_SAT, L4_AHU3_SupplyTemp and Sup_T_3 may all mean the same thing in the same building. Before any analysis can run, points must be mapped to a consistent structure describing what each one is and what equipment it belongs to. Semantic tagging conventions such as Project Haystack and ASHRAE Standard 223P exist to standardise this. In practice this step is the single biggest determinant of how quickly an FDD deployment delivers value, and the one most often underestimated.

3. Analysis

This is where approaches diverge, and it's worth understanding the trade-offs.

Rule-based FDD encodes engineering knowledge as explicit logic: if the outside air temperature is below the economiser changeover point and the dampers are at minimum position, flag an economiser fault. Rules are transparent, explainable and grounded in how equipment is supposed to work. They require engineering effort to configure per site and can miss faults nobody thought to write a rule for.

Data-driven and machine-learning FDD builds a model of normal behaviour from historical data and flags deviations. It can surface unexpected patterns and adapt to a building's specific characteristics, but it needs good training data, can be opaque about why it flagged something, and risks learning that a long-standing fault is “normal”.

Hybrid approaches — the direction most serious platforms have taken — run engineering rules for known fault modes and layer anomaly detection over the top to catch what the rules don't cover.

4. Diagnosis and prioritisation

A large portfolio generates far more faults than any team can address. Good FDD ranks them — by estimated energy cost, comfort impact, equipment risk, or the effort required to fix. The output should be a work list, not a data dump. Prioritisation is what separates a platform people use from one they mute.

5. Action and verification

The fault goes to whoever can resolve it — in-house engineer, contractor, or a work order in a maintenance management system — and the platform then confirms the fault has actually cleared. Without that closing step, you can't tell a fixed fault from an ignored one, and savings claims rest on assumption.

FDD vs BMS alarms: the distinction that matters most

The most common objection to FDD is understandable: “our BMS already alarms.”

It does — but BMS alarms and FDD answer different questions. A BMS alarm is generally threshold-based and instantaneous: a value crossed a limit, a device stopped responding, a plant tripped. It tells you something has broken.

FDD looks at relationships between points over time. It tells you something is wrong even though nothing has broken: heating and cooling running simultaneously, a sensor drifting slowly out of calibration, equipment running outside occupied hours, a control loop hunting, a valve leaking through when commanded closed. None of these cross a threshold. All of them cost money.

There's also a volume problem. Threshold alarms in a large portfolio produce thousands of notifications, most of them nuisance repeats, which is exactly how teams end up with BMS alarm fatigue — a state where alarms are routinely acknowledged and dismissed without investigation. FDD done well moves in the opposite direction: fewer items, each diagnosed and ranked, each worth someone's time.

How FDD relates to other building technologies

The category is crowded with acronyms. FDD is best understood as the analytics layer between the system that runs the building and the system that manages the work.

BMS / BAS. The control layer. It runs the building and holds the data. Its job is control, not self-analysis — which is why FDD generally sits alongside a BMS rather than inside it.

CMMS. The work management layer. It tracks work orders, assets and maintenance history. FDD generates the reason for a work order; the CMMS manages its execution. They are complementary, and the integration between them is where a lot of practical value sits.

Monitoring-based commissioning (MBCx). A programme, not a product: using continuous monitoring to keep a building performing as designed, rather than commissioning once at handover and letting performance drift. FDD is the engine that makes MBCx continuous rather than periodic. Our complete guide to monitoring-based commissioning covers this in depth.

Predictive maintenance. Forecasts when an asset will fail so it can be serviced beforehand. FDD identifies things that are wrong now. The two overlap, and both sit on the spectrum away from purely preventive maintenance schedules.

Digital twin. A virtual representation of the building, often used for simulation and scenario modelling. A digital twin may consume FDD outputs; it doesn't replace the diagnostic layer.

The faults FDD typically finds

The specifics vary by plant, but a well-configured system consistently surfaces the same families of problem.

• Simultaneous heating and cooling — reheat fighting cooling, one of the most expensive faults in commercial HVAC and rarely visible to occupants
• Economiser faults — dampers stuck, changeover setpoints wrong, free cooling not being used when conditions allow it
• Scheduling faults — plant running outside occupied hours, early starts that were never reverted, holiday schedules never applied
• Sensor drift and failure — a temperature sensor reading 2°C low will quietly bias every control decision downstream of it
• Valve and damper leak-through — commanded closed, still passing
• Control loop instability — hunting, oscillation, and PID loops tuned once at commissioning and never revisited
• Setpoint drift — manual overrides applied during a complaint and never removed
• Short cycling — equipment starting and stopping excessively, driving both energy use and wear
• Static pressure and flow issues — fans working harder than the system requires

Two examples from CIM's own portfolio make the pattern concrete: a hidden fan fault in a 6-star rated building — a high-performing asset, still carrying an undetected fault — and rectifying overnight operation that drove a 33% energy reduction. Neither was visible through normal operations.

What FDD is worth

The best available benchmark comes from a Lawrence Berkeley National Laboratory study published in Building and Environment (Lin, Kramer and Granderson, 2020), which surveyed 26 organisations running FDD across 550 buildings totalling 97 million square feet. Those users achieved median energy savings of 8%.

The same study documented median costs: around US$8 per monitoring point for software implementation, US$2.70 per point in annual recurring software cost, and US$8 per point in annual labour, on a typical deployment of roughly 1,300 points. Those figures are from 2020 and should be treated as indicative rather than current, but the shape holds: FDD is a modest operating cost set against a percentage of total building energy spend.

Energy is the easiest benefit to quantify, but rarely the only one that matters.

Maintenance efficiency. Technicians arrive knowing what's wrong instead of diagnosing on site. Faults are addressed while they are cheap.

Asset life. Short cycling, hunting and running outside design conditions all shorten equipment life. Removing them defers capital replacement.

Comfort and tenant satisfaction. A meaningful share of comfort complaints trace back to faults that FDD detects before anyone picks up the phone.

Ratings and compliance. Operational ratings such as NABERS are calculated from measured consumption, so anything that removes waste feeds directly into the rating. The same applies to energy performance obligations under schemes like EPC/MEES in the UK and building performance standards in the US.

Contractor accountability. Continuous monitoring makes it visible whether work was completed and whether it worked — a recurring theme in portfolios that use FDD data in contractor reviews.

Where FDD is required, not just recommended

FDD is increasingly written into codes and standards rather than left to good practice.

California's Title 24 energy code requires fault detection and diagnostics on economisers for certain packaged air conditioning units, with specified fault conditions the system must detect and report. ASHRAE Guideline 36, which defines high-performance sequences of operation for HVAC systems, incorporates alarming and fault reporting directly into its standard sequences — so buildings implementing Guideline 36 are implementing a form of FDD by default. Green building rating systems including LEED offer credits for ongoing commissioning and monitoring approaches that FDD supports.

The direction of travel is consistent: continuous performance verification is moving from differentiator to expectation.

Deploying FDD: a practical sequence

1. Establish data access. Confirm what your BMS exposes, over what protocol, and at what frequency. This is usually the gating item, particularly across mixed-vendor portfolios.

2. Map and tag the points. Invest here. A rushed point-mapping exercise produces false positives for years, and false positives are how FDD programmes lose credibility.

3. Start with a defined scope. One or two representative buildings, with the fault library tuned to the plant actually installed. Portfolio-wide rollouts before rules are tuned generate noise at scale.

4. Decide who owns the output — before go-live. The most common cause of failure is not technical. Faults arrive, nobody owns triage, the list grows, people stop looking. Name the owner, agree the review cadence, and agree what gets escalated to a contractor.

5. Close the loop and verify. Track resolution and confirm the fault cleared. This produces the evidence base for continued investment.

6. Report on outcomes, not activity. “1,400 faults detected” means nothing. “Resolved faults worth an estimated $180,000 annually, 62% of them without a site visit” means everything.

Common pitfalls

Treating it as a dashboard. FDD that nobody is accountable for acting on is a reporting tool, and an expensive one.

Tuning for sensitivity over relevance. A system that flags everything is functionally identical to a system that flags nothing.

Ignoring the fix workflow. If resolving a fault requires a contractor who isn't contracted to respond to them, the fault will persist however well it was diagnosed.

Skipping verification. Without confirming faults clear, you cannot distinguish a working programme from an ignored one.

Assuming high-performing buildings are exempt. The 6-star building example above is the point: a strong rating reflects performance against a benchmark, not the absence of faults.

How to evaluate an FDD platform

Useful questions when comparing options:

• Does it integrate with our existing BMS vendors and protocols, across the whole portfolio?
• Is the fault library configurable to our plant, or fixed?
• Does it diagnose probable cause, or only detect symptoms?
• How does it prioritise — by energy cost, comfort, asset risk?
• Can it verify that a fault has cleared after work is done?
• Does it integrate with our CMMS and existing workflows?
• What does the vendor's engineering support model look like — software only, or software plus engineers who tune it?
• How is value reported, and can it be tied back to energy and maintenance outcomes?

That last pair separates a data feed from a programme. Software alone finds faults; the combination of software and engineering discipline is what closes them.

Where FDD fits in a building analytics strategy

FDD is usually the first capability a building analytics platform delivers, because the payback is fastest and the evidence is concrete. It rarely stays the only one. Once fault data flows reliably, the same infrastructure supports energy analytics, ratings tracking, maintenance optimisation and portfolio benchmarking — which is why FDD tends to arrive as part of a broader building analytics deployment rather than as a standalone tool.

CIM's PEAK Platform takes this approach: it supplements an existing BMS with continuous fault detection and diagnostics, drawing on BMS, meter, IoT, weather and occupancy data to identify faults, rank them by impact, and track them through to resolution — so building teams spend their time fixing problems rather than hunting for them.

The bottom line

Faults are not the exception in commercial buildings; they are the steady state. With 40% of air handling units carrying a fault on any given day, the question for most operators isn't whether their buildings have faults — it's whether anyone knows about them.

FDD makes that knowable, and the economics are unusually clear: a median 8% energy saving against a modest per-point operating cost, plus maintenance, asset life and comfort benefits that are harder to price but easy to feel.

The technology is mature. What separates the portfolios that get results from those that don't is rarely the algorithm — it's whether someone owns the list, works it, and checks the fault actually cleared.