Building automation fault detection and diagnostics field guide

Fault detection and diagnostics, and the data nobody reads

Fault detection and diagnostics, FDD, is software that reads the trend data a building automation system already collects and finds the faults, the energy waste, and the comfort problems hiding in it, automatically and continuously. A modern building runs thousands of points around the clock. Discharge temperatures, valve commands, damper positions, fan status, meter pulses, all of it logged. The hardware to know what the building is doing is already installed. What is missing is anything that reads the data.

So the building wastes energy with a full set of sensors watching it happen. A damper sticks, a valve leaks by, two zones fight heating against cooling, an override from a service call last spring never comes off, and every one of those leaves a clear fingerprint in the trends. Nobody is looking. FDD is the analytics layer that looks, on every point, every day, and turns the logs into a short list of what is actually broken and what it is costing.

The value is not the dashboard. It is the loop the dashboard feeds: detect the fault, diagnose the likely cause, dispatch a work order, and verify in the data that the fix held. This guide covers that general FDD and analytics layer. For the controllers, sensors, and sequence the data comes from, see the BAS and DDC fundamentals guide. For the economizer-specific version of this same expected-versus-actual logic, see the air-side economizer fault detection guide.

Why a building full of sensors still wastes energy

The trend data sits unused on most buildings, and that is the gap FDD fills. A commercial BAS logs more data in a week than a facility team could read in a year, so it does not get read. The points are there for troubleshooting one piece of equipment when someone complains, not for catching the slow waste that never generates a complaint.

That is the trap. The expensive faults are the quiet ones. A leaking chilled-water valve does not trip an alarm; it just makes the air handler work a little harder every hour for years. A schedule left in override conditions an empty wing all weekend, and the only evidence is a meter reading that no single person ever compares to what it should be. The waste accrues in small amounts across thousands of points and twelve months, where no one number looks wrong enough to chase.

A person can find any one of these by pulling a week of trend and laying the points over each other. The economizer guide leans on exactly that move. What a person cannot do is run that check on every point in every building every night. That is the job FDD was built for: read the data the building already produces, at a scale no one has time to read by hand.

What does fault detection and diagnostics do?

FDD does two jobs the name spells out. Fault detection is finding that something is wrong: a measured behavior that does not match what the equipment should be doing. Fault diagnosis is naming the likely cause, so the finding points at a repair instead of just a red light. The better the diagnosis, the less time a tech spends figuring out what the alarm meant before they can fix anything.

Underneath, the software compares expected behavior against actual behavior, point by point, the same logic a commissioning agent runs by hand. It knows what mode an air handler should be in from the outside-air temperature, the cooling call, and the setpoints, then checks whether the measured temperatures, the valve commands, and the status points agree. When they disagree past a threshold for long enough, it raises a fault.

This is an analytics layer that sits on top of the BAS, not a replacement for it. The BAS runs the building in real time. FDD reads what the BAS recorded and tells you where it is running wrong. The fundamentals guide covers the control side that produces the data; this guide is the layer that reads it.

The faults FDD finds

Most of what FDD catches falls into a short list, and an experienced analyst can usually name the fault from the trend shape before opening the equipment. Stuck dampers and valves, leaking valves that never fully close, simultaneous heating and cooling, sensor drift, schedules and setpoints left in override, economizer faults, and short-cycling equipment cover the bulk of it.

What these share is that they are invisible from the hallway. The space still hits setpoint because something else covers the load, so no one calls. The fault shows only in the data and on the bill. The table below is the field shorthand, the same set of faults the analytics rules are written to find and the same set you confirm by hand at the equipment.

What is simultaneous heating and cooling?

Simultaneous heating and cooling is one system adding heat to air that another system just spent energy removing, or the reverse, and it is the classic waste FDD is built to surface. The textbook case is a VAV box reheating supply air that the central air handler chilled, harder than the zone needs, so the building pays twice: once to cool the air, once to warm it back up. On a chilled-water and hot-water plant it can run for years because the space stays comfortable the whole time.

The usual culprits are a leaking heating valve that never seats, a reheat coil with its valve stuck cracked open, a discharge-air setpoint set too low so every zone has to reheat, or two adjacent zones with fighting setpoints. The trend tells the story plainly: a chilled-water valve and a hot-water valve both open at the same time on the same air, or a cooling stage and a heating stage running together.

It is a large number when you find it, because it is energy spent in both directions to land back where you started. Catching it is one of the highest-value finds in the whole fault list, which is why nearly every FDD ruleset ships with a simultaneous heating and cooling rule turned on by default.

Rule-based vs data-driven FDD

Most FDD in the field is rule-based, and that is the approach to start with. A rule encodes physics or sequence logic in plain terms: if the cooling call is on and the outside air is below the changeover and the damper is at minimum, flag a non-economizing fault. The rules come from how the equipment is supposed to work, so the output is transparent. You can read the rule, see why it fired, and argue with it. ASHRAE Guideline 36 publishes vetted sequences and the fault rules that go with them, which is part of why rule-based tools dominate the commercial market.

The other approach is data-driven, where the software learns a building's normal patterns from its own history with machine learning or statistics, then flags anomalies that depart from the learned baseline. It needs little hand-written knowledge and can catch faults nobody wrote a rule for, which is its appeal on large or unusual systems. The cost is opacity: an anomaly flag that cannot tell you why it fired is harder to act on than a named rule.

In practice the market leans heavily rule-based, with data-driven and hybrid methods growing at the edges, often layered on top of rules rather than replacing them. The vendor's approach varies, so confirm what a given platform actually runs and how it explains its faults before you judge it on the brochure.

The trend data is the foundation, and garbage in stays garbage

FDD is only as good as the data under it, so the trend layer decides whether the analytics are worth trusting. Three things about that data matter: the points being trended, the sample resolution, and how much history is kept. A fault rule that needs the mixed-air temperature cannot fire if mixed air is not a trended point. A rule watching for short-cycling needs samples close enough together to see the cycles, not a fifteen-minute average that smooths them away.

Data quality is the part that quietly sinks projects. A sensor that was never calibrated reads wrong, and the analytics will confidently flag faults that are really just bad data, or miss real ones hiding behind a drifted reading. Gaps where a controller dropped off the network leave holes the rules read as zero or as nothing. Run analytics on uncommissioned points and you get confident, wrong faults, which is the fastest way to lose the operator's trust in the whole system.

So the data layer is a commissioning job before it is an analytics job. Verify the points read true, set the trend intervals to match what the rules need, and keep enough history to see a fault develop. The point-to-point checkout in the fundamentals guide is where that verification happens. Skip it and the best FDD platform reports nonsense.

What is point tagging, and why Haystack and Brick matter

Point tagging is attaching standardized metadata to every BAS point so software knows what it is, and it is what lets FDD scale past a single building. A raw point name like AHU3_DAT or a cryptic controller address means nothing to an analytics engine. Tag it as the discharge-air temperature of a specific air handler, related to that unit and that zone, and a generic fault rule can find it automatically in any building tagged the same way.

Two open standards do this. Project Haystack uses a flexible set of tags applied to each point and piece of equipment. Brick Schema uses a formal ontology, a defined class hierarchy of equipment and points and the relationships between them, queried with a standard query language. ASHRAE published Standard 223-2023 for semantic modeling of building data, which draws on both approaches, so they are converging rather than competing.

The payoff is reuse. Without tagging, every building's points have to be mapped to the analytics by hand, one at a time, which is most of the cost and most of the errors. With consistent tags, a rule written once runs across the whole portfolio. Large analytics deployments measured in tens of millions of square feet report they could not manage the portfolio at all without a tagging standard underneath. The metadata is what turns a one-building tool into a fleet tool.

Normalizing the data and mapping the equipment

Normalization is getting every building's data into a common shape so one set of rules can read all of it. Tagging names the points; normalization lines up the units, the engineering scales, and the equipment models so a fault rule does not care whether this air handler came from one manufacturer and that one from another. Without it, the same logical point arrives in Fahrenheit from one site and Celsius from another, or a damper reads 0 to 100 percent here and 0 to 10 volts there, and the rules break on the mismatch.

The equipment model is the other half. FDD organizes points under an equipment template, an air handler with its supply fan, its coils, its dampers, and its sensors, so a rule written for the generic air handler maps onto the real one. Building that mapping is the unglamorous work that decides whether the analytics light up correctly or throw noise.

This is where most of the implementation labor goes, and where the platform's connectors and tagging tools either earn their keep or do not. Budget for the mapping, because it is the difference between rules that fire on real faults and rules that fire on unit mismatches all day.

What is monitoring-based commissioning?

Monitoring-based commissioning, MBCx, is using continuous data and analytics to keep a building commissioned over time instead of commissioning it once and walking away. It combines the BAS trends, the energy meters, and an FDD layer with a standing process to act on what they find. FDD is the technology; MBCx is the practice that wraps people and a workflow around it.

The distinction worth keeping straight: FDD is the software that finds faults, while MBCx is the program that finds them, fixes them, and proves the fix persisted, on a recurring basis. Traditional retro-commissioning is a one-time event, a snapshot that starts drifting the day the agent leaves. MBCx and the broader idea of continuous or ongoing commissioning replace the snapshot with a standing watch, so the drift gets caught as it happens rather than at the next audit years later.

This is the shift FDD makes possible. The data and the analytics turn commissioning from a project into a process. The catch is that the process needs an owner. An MBCx program with the analytics running but nobody assigned to act on the faults is just FDD with better marketing.

Prioritizing faults by cost and comfort

Prioritization is what separates a useful FDD program from a fault firehose. Turn analytics loose on a portfolio and the fault list runs into the hundreds or thousands, because real buildings have many small problems at once. A flat list of every deviation is useless; the team cannot fix a thousand things, so they fix none and stop reading the list. The job is to rank.

The ranking that works is by impact: how much energy the fault is wasting in dollars, how much it hurts comfort, and what it risks if left alone. A simultaneous heating-and-cooling fault on a large air handler outranks a slightly off setpoint on a small zone, every time, because the first one is spending real money every hour and the second one is noise. A stuck-open damper risking a winter coil freeze jumps the line on risk even if its energy cost is modest.

Good platforms estimate the cost of each fault so the list sorts itself by money, which is the language that gets repairs funded. Do not drown the team in low-value alarms. Surface the handful that matter, in dollar order, and the program survives. That triage is most of the value, more than the detection itself.

Diagnosis: the likely cause, not just the alarm

Detection tells you something is wrong. Diagnosis tells you what, and that is the half that makes FDD actionable instead of annoying. An alarm that says a zone is too warm sends a tech to figure out why from scratch. A diagnosis that says the hot-water valve appears to be leaking by, because the discharge air is warmer than the mixed air with the heating valve commanded shut, sends the tech to the valve with a hypothesis already in hand.

The diagnosis is a likely cause, not a certainty, and a good platform says so. It narrows the search; it does not close the fault. A non-economizing flag tells you which unit to visit, not whether the cause is the actuator, the linkage, or a drifted sensor. You still confirm it at the equipment with a functional test, the same one the economizer guide walks through.

Rule-based tools diagnose well because the rule itself carries the cause: the condition that fired the rule is the hint. Anomaly-only methods are weaker here, flagging that something departed from normal without naming what. When you compare platforms, weigh the diagnosis as heavily as the detection, because a fault you cannot diagnose is a truck roll to go find out what the alarm meant.

The workflow: detect, diagnose, dispatch, verify

FDD pays off as a loop, not a screen. The loop has four steps and skipping any one of them breaks it. Detect the fault in the data. Diagnose the likely cause. Dispatch a work order to someone who will fix it. Verify in the data that the fault cleared and the energy came back. Run all four and the building gets better; stop at the dashboard and nothing changes.

The step most programs drop last is verification, and the one most drop first is dispatch. A platform that detects and diagnoses but never turns a fault into an assigned work order produces a wall of findings nobody owns. A program that dispatches but never verifies the fix never learns whether the repair worked or whether the fault came right back, which is common with intermittent faults and bad changeovers.

This is the discipline that makes FDD worth its subscription. The technology handles detect and diagnose. People and process handle dispatch and verify. The buildings that get the documented savings are the ones that close the loop every time, not the ones with the most sophisticated detection. A fault found and never fixed costs exactly as much as a fault never found.

Dispatch: turning a fault into a work order

Dispatch is the step where a fault becomes an assigned job with an owner and a due date. The cleanest path is FDD wired to the computerized maintenance management system, the CMMS, so a prioritized fault generates a work order automatically, routed to the right tech with the diagnosis and the trend attached. The tech shows up knowing what to check instead of starting cold.

Without that handoff, the analytics and the maintenance team live in separate worlds. The faults pile up in one system while the work orders flow from complaints in another, and the quiet, high-value faults FDD is best at finding never make it into anyone's queue, because nobody complained. Integration is what carries the finding across that gap.

This is where a field tool earns its place. FieldOS captures the fault, the diagnosis, the photo of the leaking valve or the disconnected linkage, and the test result on site, and keeps that record attached to the equipment instead of scattered across the analytics platform, the CMMS, and a paper ticket. The point is that the fault the software found and the fix the tech made end up in the same history, so the next person can see both.

Verifying the fix in the data

Verification is reading the trends after the repair to confirm the fault actually cleared, and it is the step that proves the program works. The same data that detected the fault is the proof of the fix. The simultaneous heating and cooling that showed two valves open on one airstream should show one valve closed after the repair, and the energy the fault was wasting should come back on the meter. If it does not, the fault is not fixed, whatever the work order says.

This closes the loop and it does something else: it builds the savings record the program is judged on. A fault detected, dispatched, and verified, with the before-and-after trend, is a documented dollar number you can put in front of the people who fund the contract. A pile of closed work orders with no data behind them is a claim nobody can check.

Verification also catches the repairs that did not hold. Intermittent faults, bad changeovers, and overrides that come right back show up only when you look at the data again a week later. Verify the fix, then keep watching, because the fault you proved fixed in June can drift back by September. That recurring check is the continuous-commissioning part of the job.

Integrating the BAS, the CMMS, and the meters

FDD lives or dies on its integrations, because it produces nothing of its own. It reads the BAS for the trends, writes to the CMMS for the work orders, and pulls the meters for the energy picture, and a weakness in any of those connections weakens the whole program. The BAS connection is the input: FDD needs read access to the points and the trend history, usually over BACnet/IP or a data export from the front-end.

The meter integration is what puts a dollar on each fault. Pairing the equipment-level fault with whole-building and submeter data lets the platform estimate what a fault is costing and confirm the savings after the fix. The CMMS connection is the output that turns findings into action, covered in the dispatch section.

The trap is assuming integration is plug and play because both ends speak a standard protocol. Speaking BACnet is not the same as exposing the points and the history the analytics need, and a packaged unit may publish only a thin slice of its points over a gateway. Confirm what data actually comes across each connection before promising the owner what the analytics will see.

The FDD platform: cloud, on-prem, and connectors

The platform is the software that hosts the rules, stores the data, and presents the faults, and the choices here vary by vendor. Most run in the cloud now, pulling trend data up from each building over a connector and running the analytics centrally, which is what makes a portfolio view possible across sites. Some run on-premises for owners with data-residency or security requirements that keep the building data inside their own network. The trade-off is the usual one: cloud scales and updates easily, on-prem keeps the data in house and takes more to maintain.

The connectors are the part that decides how much building you can actually onboard. A platform with mature BACnet and common front-end connectors and a tagging toolset gets a building live in a reasonable time; one without them turns every site into a custom integration. Scalability is about the connectors and the tagging more than the analytics engine.

This is a place to hedge. The platform, the rule library, the diagnosis quality, and the connector coverage differ enough between vendors that the right choice depends on the portfolio and the existing BAS. Pilot it on real buildings before committing the fleet, and judge it on how cleanly it onboarded your equipment, not on the demo.

What FDD actually saves

The energy case for FDD is real and it is measured, though the number depends on the building and how hard the program runs. Field studies put typical whole-building savings from FDD-driven programs in the range of about 5 to 20 percent, with portfolio studies reporting median savings around 8 to 9 percent. The wider claim that correcting building faults can save up to 30 percent shows up in the research, but treat the high end as a ceiling for a badly run building, not a promise.

The savings come from the faults the program closes: the simultaneous heating and cooling shut off, the schedules pulled out of override, the economizers put back to work, the resets restored. Beyond energy, FDD avoids truck rolls by sending a tech with a diagnosis instead of to investigate a vague complaint, and it catches developing equipment problems before they become failures and overtime.

The part that makes the case hold is persistence. A one-time retro-commissioning saves until the building drifts back, often within a few years. Continuous FDD catches the drift as it happens, so the savings persist instead of decaying. The dollar figure varies with the building, the climate, and the program, so model it on the actual portfolio rather than borrowing a headline percentage.

Avoiding alarm fatigue

Alarm fatigue is the failure mode that kills more FDD programs than any technical problem. Set the analytics to flag every deviation with no prioritization and the operator drowns in low-value alarms, the real fault gets buried in the noise, and the team learns to ignore the whole system. An alarm nobody reads is worse than no alarm, because it trained someone to look away.

The fix is tuning and prioritization, not more rules. Set the thresholds and the timers so a fault means something needs attention, suppress the known-and-accepted conditions, and route only the ranked, high-value faults to the people who will act. A fault that fires every afternoon and gets dismissed every afternoon should be retuned or turned off, not left to erode trust in everything else on the list.

Trust is the real currency of an FDD program. The first month sets whether the operators believe the faults or write them off, so start narrow with the high-confidence, high-value rules and widen the net as the team learns to act on them. A program that floods the team on day one rarely recovers, because adoption is a people problem and the people stop reading.

The energy driver behind the analytics

Two pressures are pushing FDD from a nice-to-have toward standard practice. The first is decarbonization and energy cost: buildings are a large share of energy use, and squeezing 5 to 20 percent out of existing stock with analytics is cheaper than most capital upgrades. The second is the load growth from data centers and large electrified buildings, which makes every percent of avoided waste matter more to the grid as well as to the bill.

For the analyst this is mostly context, not a change in the work. The faults are the same faults and the workflow is the same loop. What changes is the funding and the attention, as efficiency moves from a soft goal to a number owners and utilities track. FDD is the cheapest tool for finding the waste in buildings that already exist, which is why it keeps showing up in energy programs and utility incentives.

Getting started: pilot the high-value equipment first

Start small and start where the money is. The instinct to onboard the whole portfolio at once is how programs stall, buried in mapping and noise before anyone sees a result. Pick a pilot: a few buildings, or the high-value equipment, the large air handlers, the central plant, the chillers, where a single fault is worth real money and a single fix proves the program.

The first work is data, not analytics. Confirm the points you need are trended at the right resolution, verify the sensors read true, and get the equipment tagged and mapped. Then turn on the high-confidence rules, the simultaneous heating and cooling, the stuck and leaking valves, the overrides, the economizer faults, and run the full loop on a handful of faults: detect, diagnose, dispatch, verify, and put a dollar on the savings.

That first verified, documented save is what funds the rollout. Take it to the people who control the budget, show the before-and-after trend and the recovered energy, and expand from there. A pilot that closes the loop on real faults beats a portfolio-wide deployment that produces a dashboard nobody acts on.

FDD needs people to act

The hardest part of FDD is not the software; it is the people and the process around it. The analytics find the faults. People fix them, and a fault found and never fixed saves nothing. Every study of what makes these programs work points at the same thing: a standing process to review the faults, an owner assigned to act, and a routine for following up, often with an analyst or an MBCx provider doing the triage.

That role is real work. Someone has to review the ranked faults, confirm the diagnoses, generate the work orders, check that the repairs happened, and verify the fix in the data. Where that role exists, the savings show up. Where the platform was bought and nobody was assigned to run it, the faults pile up unread and the contract gets cancelled as a cost with no return.

Be blunt about this before the purchase. FDD is a tool, and a tool needs a hand on it. The decision to buy the analytics is also a decision to staff the process that acts on them. Skip the second half and the first half is money spent on a dashboard.

What to record

A fault that nobody recorded is a fault the building pays for twice. The record is what turns a stream of findings into a managed program: what was found, what it was diagnosed as, what was done, and whether the data confirmed the fix. It is also the savings ledger the program is judged on when the contract comes up for renewal.

Capture the equipment and the fault, the diagnosis and the confirming check, the priority and the estimated cost, the work order and who it went to, the repair and the date, and the verification trend after the fix. When that history lives in one place across the fleet and across seasons, the recurring faults surface: the valve that keeps leaking, the unit that drifts out every spring, the override that comes back after every service call. A field tool like FieldOS that captures the fault, the photo, and the test result on site keeps the analytics finding and the field fix attached to the same equipment, so the chronic problem you can name is the one you can finally fix for good.

Common mistakes

• Treating FDD as a dashboard nobody acts on, so the faults pile up unread.
• Alarm fatigue from no prioritization, so the real fault gets buried and the team ignores all of them.
• Running analytics on bad or missing trend data, so the faults are confidently wrong.
• Detecting faults with no diagnosis, so every alarm is a truck roll to find out what it meant.
• Never dispatching a work order, so the quiet high-value faults never reach the maintenance queue.
• Never verifying the fix in the data, so nobody knows whether the repair held or the fault came back.
• Onboarding the whole portfolio at once and stalling in mapping and noise before any result.
• Buying the platform without staffing the process that acts on it.

Field checklist

Standards and references

The references for FDD sit in a few places, and citing the right one for the point keeps a spec honest. ASHRAE Guideline 36, high-performance sequences of operation, publishes vetted control sequences and the fault-detection rules written to run on a DDC system, and it is increasingly what specifications point to for both the sequence and its FDD logic. Pair it with the actual project sequence of operations, which controls what this building is supposed to do.

For the data layer, Project Haystack and Brick Schema are the open tagging and semantic-modeling standards, and ASHRAE Standard 223-2023 is a single semantic-modeling standard for building data that builds on both. These govern how the points are tagged and normalized so the analytics scale. On the commissioning side, monitoring-based commissioning and ongoing-commissioning practice, documented by national labs and energy programs, frame the process the analytics serve.

Below the standards sit the platform and the people. The FDD vendor's rule library, diagnosis method, and connector coverage vary, and the controls contractor and the facility decide what gets trended, tagged, and acted on. Hedge the fault rules, the savings, and the approach to the platform you actually run, the controls contractor who built the BAS, and the facility's own process. FDD reads the data the building already has to find the waste, it prioritizes and diagnoses rather than just alarming, and it earns its keep only when someone closes the loop and verifies the fix.

Units and terms

FDD work crosses analytics, controls, and commissioning vocabulary, so the same idea reads differently across a platform screen, a controls drawing, and an energy report.

A point is a single BAS input or output; a trend is its logged history over time. A rule is a logic statement that flags a fault; an anomaly is a data-driven departure from a learned baseline. Tagging and semantic modeling are the metadata that tell software what a point is. Savings are usually expressed as a percentage of whole-building or system energy, and a fault's cost as dollars per year. The energy figures here are typical ranges from field studies, not guarantees, and the actual numbers depend on the building, the climate, and the program.

FDD

Fault detection and diagnostics, software that reads BAS trend data to find faults and name the likely cause

Rule-based vs data-driven

Rules encode physics or sequence logic and are transparent; data-driven methods learn normal patterns and flag anomalies

Point tagging (Haystack / Brick)

Standardized metadata on each point and equipment so analytics rules find and reuse across buildings

MBCx

Monitoring-based commissioning, using continuous data and analytics to keep a building commissioned over time

Simultaneous heating and cooling

One system heating air another system just cooled, a classic and costly waste FDD targets

Sensor drift

A sensor slowly reading off true, so the controller holds the wrong condition and the analytics decide on bad data

Fault prioritization

Ranking faults by energy cost, comfort, and risk so the team fixes what matters instead of every alarm

Continuous commissioning

Replacing one-time commissioning with an ongoing process so drift is caught as it happens

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is a building automation system?
• What is economizer fault detection?
• What is retro-commissioning?
• What is building pressurization?
• What is a good temperature split for AC?