Key Takeaways
Anomaly detection is strong at finding behavior that departs from an expected baseline, including patterns that were never defined as known faults. It does not automatically explain the physical cause.
FDD adds diagnostic logic that maps symptoms to a known fault or likely cause, but its accuracy depends on sensor quality, equipment context, fault models, and the conditions the system was designed to recognize.
The right enterprise architecture is often hybrid: anomaly detection widens coverage, FDD narrows the diagnostic search, and maintenance systems close the operational loop.
Buyers should evaluate diagnostic confidence, false-positive burden, semantic data quality, and maintenance workflow integration rather than comparing detection accuracy alone.
Anomaly Detection and FDD solve different parts of the same problem
The case against treating FDD as automatically superior is straightforward.
A fault library can only reason about conditions it knows how to recognize. An unsupervised anomaly model can potentially identify behavior no engineer explicitly encoded beforehand. In buildings where labeled fault data are scarce, that flexibility can be valuable. Recent HVAC research continues to investigate unsupervised and representation-learning techniques for this reason.
But discovery and diagnosis are different tasks.
Anomaly detection typically establishes that measured behavior differs from a learned baseline, peer group, statistical distribution, physics model, or expected operating pattern.
Fault Detection and Diagnostics, or FDD, aims to go further. Fault detection establishes that operation is unacceptable in some respect; diagnostics attempts to identify or localize its cause. The distinction is well established in building FDD research.
For an operator, the difference is substantial.
“AHU-7 behavior has deviated from its normal operating profile” is evidence.
“AHU-7 appears to have a leaking heating valve while cooling is active” is a diagnostic hypothesis.
“Inspect heating valve VLV-HW-07 during the next maintenance window” is an operational action.
These outputs should not be evaluated as though they provide the same level of certainty.
| Capability | Main question | Typical output |
|---|---|---|
|
Alarm |
Has a defined threshold or condition been crossed? |
High supply-air temperature |
|
Anomaly detection |
Is this pattern unusual? |
Abnormal SAT, valve and airflow relationship |
|
Fault detection |
Does behavior indicate faulty operation? |
Simultaneous heating and cooling detected |
|
Diagnostics |
What may be producing the fault? |
Possible leaking valve or control-sequence issue |
|
Maintenance workflow |
What should happen next? |
Inspect valve, review sequence, verify repair |
This distinction also explains why alarm management and FDD should not be collapsed into one layer. A conventional BMS alarm generally reacts to a predefined condition. FDD can evaluate relationships among several points and operating states. For a deeper view of that distinction, see BMS alarm management and maintenance noise.
Anomaly Detection has an advantage when the Fault is unknown
HVAC anomaly detection becomes attractive when the organization does not have complete failure labels or a comprehensive fault library.
Suppose a chiller plant normally follows repeatable relationships among load, condenser-water temperature, compressor power and chilled-water supply temperature. A model can learn this normal operating envelope.
If compressor power starts increasing under equivalent loads while other variables remain stable, the model may flag the operating window as abnormal.
That matters even if the model has never seen the underlying failure before.
This ability gives anomaly detection broad discovery coverage. It can identify sensor drift, unusual equipment interactions, unexpected control behavior or emerging degradation without first knowing what fault label should apply.
The trade-off is interpretation.
A statistically unusual pattern could reflect equipment degradation. It could also reflect a schedule change, extreme weather, commissioning work, an occupancy shift, sensor replacement or a new control sequence.
A 2026 study of ventilation-system anomaly detection makes this limitation explicit: data-driven models identified additional deviations beyond predefined rules, but those detections remained candidate anomalies requiring validation. (Source:Wachsenegger, A., Buruzs, A., Dautović, A., Šipetić, M., Bernadó, L., & Casas, P. (2026). AI for Sustainable Building Operations: Data-Driven Anomaly Detection in Ventilation Systems. PHM Society European Conference, 9(1), 1–14. https://doi.org/10.36001/phme.2026.v9i1.5012)
That is the correct operating model. An anomaly should begin an investigation, not end one.
FDD becomes more valuable when someone must decide what to fix
FDD creates value by reducing the diagnostic search space.
Consider an AHU with the following evidence:
supply air remains near setpoint;
cooling valve is open;
heating valve is also open;
outdoor conditions do not justify reheating.
An anomaly model may recognize that this combination differs from normal behavior.
An FDD rule can encode the physical expectation that sustained simultaneous heating and cooling indicates inefficient or faulty operation. Diagnostics can then narrow the likely causes to a leaking valve, failed actuator, incorrect valve command, poor sequence logic or another known mechanism.
The distinction matters because maintenance labor is scarce.
Sending a technician a generic anomaly transfers the diagnostic burden from software to the technician. Sending the same technician a probable failure mechanism, affected equipment, relevant trends and supporting evidence shortens the investigation.
This is why the useful question is not simply anomaly detection vs FDD accuracy.
The better metric is:
How much uncertainty remains before a qualified operator can make a maintenance decision?
Building analytics vs FDD vs AI agents provides a related architectural view: FDD sits between basic visibility and higher-level workflow reasoning.
Does Anomaly Detection identify root cause?
Usually, no.
An anomaly model can sometimes provide useful clues about which variables contributed most strongly to a detection. Techniques such as feature attribution can show that supply-air temperature, valve position and airflow contributed heavily to an abnormal event. Recent building anomaly research has used SHAP-based attribution for this purpose.
But variable attribution is not the same as causal diagnosis.
The same symptom may have several explanations.
Low supply-air temperature, for example, might result from a bad temperature sensor, an open cooling valve, excessive airflow, a control-sequence problem, unusual entering-air conditions or incorrect point mapping.
Root-cause analysis therefore requires context beyond the anomalous values themselves:
equipment topology, operating mode, control sequence, related sensor states, maintenance history, known failure modes and sometimes physical inspection.
This is one reason BMS semantics become so important. A model needs to know whether a 0-100% signal represents a valve command or actual valve-position feedback. Confusing the two can produce a technically valid calculation based on the wrong physical meaning.
AIQuinta’s guide to BMS data normalization and point mapping explains why point meaning, equipment relationships, provenance and control roles need to survive the normalization process.
FDD is not guaranteed to find the true root cause either
The term “diagnostics” can create an unrealistic expectation that FDD always identifies the physical root cause.
It does not.
A diagnostic engine normally produces a known fault classification or a probable cause based on available evidence.
For example, an economizer diagnostic may determine that an AHU is not providing expected free cooling. That still may not prove whether the physical cause is a stuck damper, failed actuator, broken linkage, sensor bias or incorrect control logic.
Good FDD therefore narrows the search rather than pretending uncertainty has disappeared.
Operational teams should ask vendors whether diagnostic output represents:
a detected condition, a classified fault, a ranked set of possible causes, or a confirmed root cause.
Those are four different outputs.
HVAC Anomaly Detection vs FDD: An AHU example
Consider an AHU where supply-air temperature starts oscillating.
An anomaly model trained on previous operation detects that the temperature, fan speed and valve signals now follow an unusual temporal pattern.
Its output might be:
Anomalous AHU behavior detected. Confidence: high.
Useful, but incomplete.
FDD then evaluates control relationships.
The cooling valve repeatedly moves between 15% and 80%. Supply temperature overshoots the setpoint in both directions. Fan airflow remains stable.
The FDD layer identifies likely valve hunting or unstable loop control.
The maintenance investigation can then focus on loop tuning, actuator behavior, sensor response and related control parameters rather than examining the entire AHU.
Notice the division of labor.
Anomaly detection widened discovery because the behavior differed from history.
FDD translated that deviation into an engineering concept.
Maintenance confirms the physical cause.
The best architecture is often hybrid
Enterprises do not need to choose one analytical doctrine across an entire building portfolio.
Rule-based FDD works well where physics, sequences and failure mechanisms are understood. Its reasoning is often easier for facility engineers to inspect.
Data-driven anomaly detection is useful when behaviors are complex, fault labels are limited, or unknown patterns need to be surfaced. Research reviews consistently identify missing labeled fault data, transferability and interpretability as ongoing challenges for data-driven FDD.
A hybrid pipeline can therefore use anomaly detection to discover suspicious patterns and deterministic or knowledge-based diagnostics to interpret conditions that fall within known engineering models.
For larger portfolios, this only scales when equivalent equipment is represented consistently. A useful foundation is a common semantic model that preserves local differences while exposing equivalent AHUs, sensors, commands and relationships to shared analytics. See AIQuinta’s framework for standardizing BMS data across a multi-building portfolio.
Evaluate the Output, not the AI label
A vendor can describe almost any analytics engine as AI-driven anomaly detection, predictive maintenance or intelligent FDD.
Those labels reveal little about the actual workflow.
A stronger evaluation starts with six questions:
What evidence triggers a finding?
Can the system distinguish an unusual condition from a confirmed fault?
Does it explain which signals contributed to the result?
How does it map symptoms to probable causes?
What confidence or uncertainty does it expose?
Can the finding enter a maintenance workflow and later be verified against telemetry?
That last step is often neglected.
FDD creates business value only when findings lead to action. The field workflow is better understood as detection, diagnosis, dispatch and verification.
The economic evidence also reflects this operational reality. The U.S. Smart Energy Analytics Campaign reported a median 9% annual energy saving among participating organizations using FDD, but that result came from deployed energy-management programs, not from detection algorithms operating in isolation.
Where Anomaly Detection and FDD both fail
Neither approach compensates for missing operational context.
If the system does not know that an AHU has entered commissioning mode, normal commissioning tests may appear anomalous.
If the equipment hierarchy is wrong, a diagnostic rule can combine unrelated points.
If operating sequences changed last month but the model still uses the old baseline, valid new behavior may appear abnormal.
If the system generates hundreds of low-impact findings without consequence-based prioritization, operators eventually stop responding.
And if a diagnostic conclusion cannot be connected to maintenance history, manuals, work orders and technician feedback, the analytics system repeatedly solves the same problem from scratch.
This is where the next layer of enterprise building intelligence begins.
An AI agent should not replace the deterministic FDD logic responsible for identifying known physical conditions. It can instead collect the wider operational context required after detection: retrieve the sequence of operation, inspect prior repairs, locate the relevant procedure, summarize related alarms and prepare the next maintenance action.
A safe architecture usually keeps the BMS as the deterministic control layer and adds AI above it with bounded authority. AIQuinta’s guide to adding AI to an existing BMS explains this separation in more detail.
Conclusion
FAQs
What is the difference between anomaly detection and FDD?
Anomaly detection identifies behavior that differs from an expected pattern or baseline. FDD goes further by determining whether the behavior represents faulty operation and attempting to classify or diagnose the likely cause. Anomaly detection can therefore be one input into an FDD process, but the two terms are not interchangeable.
Is anomaly detection better than fault detection for HVAC?
Neither is universally better. Anomaly detection is useful for discovering unexpected or previously unlabeled behavior. Fault detection is more useful when the relevant failure condition can be defined through engineering rules, physics or a trained fault classifier. A hybrid model can use anomaly detection for broader discovery and FDD for actionable interpretation.
Can FDD diagnose every HVAC fault?
Turn Enterprise Knowledge Into Autonomous AI Agents
Your Knowledge, Your Agents, Your Control
Your Knowledge, Your Agents, Your Control
Related Articles
Latest Articles
