Building HVAC fault detection & diagnostics (FDD)

Heating, ventilation and air-conditioning systems routinely run in degraded states for months: valves that leak, dampers stuck open, economisers that do not economise, sensors that drift, schedules that ignore holidays. Nobody notices because the building is still "comfortable". FDD software continuously analyses the data the building automation system (BMS/BACS) already records, flags such faults, ranks them by wasted energy and gives the technician a likely cause. It is the monitoring counterpart to control optimisation (OPT-007) and is becoming a compliance building block under the revised EU Energy Performance of Buildings Directive.

Problem & value

• Today: facility teams react to comfort complaints and alarms. A BMS alarm only fires when a hard limit is crossed; "simultaneous heating and cooling", overridden points left in manual, or a leaking heating valve in summer produce no alarm. Periodic inspection or retro-commissioning finds some of this, then the faults creep back.
• AI value: continuous commissioning. Detection runs 24/7 on every air-handling unit (AHU), VAV box, chiller, boiler and pump; findings are prioritised by cost impact so a small team works the 20 items that matter instead of thousands of alarms. Energy savings, comfort and equipment lifetime improve; service visits become targeted.
• Evidence: analytics-based commissioning and FDD are among the best-studied building-efficiency measures; the U.S. national-laboratory literature (LBNL, PNNL) documents savings from correcting faults found by analytics, with results varying widely by building type, baseline condition and how consistently findings are acted on [3][4]. No universal saving figure should be promised; measure against your own baseline (IPMVP, see KPIs).
• Regulatory driver: the recast EPBD (Directive (EU) 2024/1275) requires building automation and control systems in larger non-residential buildings (HVAC > 290 kW) and expects monitoring that detects efficiency loss and informs the facility manager; Germany transposes this through the GEG [1]. FDD is the practical way to meet the "detect efficiency loss" requirement at scale.

Variants

• Portfolio FDD (cloud, many sites): one analytics platform across hundreds of retail, office or school buildings; central energy-management team triages.
• Single large campus / hospital / data hall: on-prem or edge analytics, tightly integrated with the CAFM and with strict operational-technology (OT) separation.
• Public buildings and municipalities: FDD for energy-management obligations and subsidy reporting.
• Landlords/service contractors (Contracting, Facility Services): FDD as the basis of performance-based service contracts.
• Small buildings without BMS: retrofit sensors/IoT gateways plus rule-based cloud FDD; low-end "light" offerings.
• Private use: heat-pump and smart-thermostat anomaly hints for homeowners (few simple rules, e.g. short-cycling, high return temperature) → see PRED-031, PRED-048.

How it works

1. BMS / field bus (BACnet, KNX, Modbus, OPC UA, MQTT) + meters + weather
2. gateway / connector (edge, read-only)
3. time-series store
4. semantic model (Brick / Haystack: which point is "supply air temperature of AHU-3")
5. fault detection (rules from ASHRAE-style libraries + ML baselines + residual models)
6. diagnosis (fault tree / classifier; LLM drafts explanation from point trends and manuals)
7. impact quantification (kWh, EUR, CO2 vs. fault-free baseline)
8. prioritised fault list
9. ticket in CAFM/CMMS
10. technician fixes
11. verify (fault cleared?)

• Rules remain the backbone. Established rule sets (AHU Performance Assessment Rules, ASHRAE Guideline 36 sequence deviations, "valve open > X % while the coil sees no temperature rise") are transparent and need no training data.
• ML adds: (a) learned normal-behaviour models per asset (regression/gradient boosting on weather, load and schedule) whose residuals flag drift; (b) multivariate anomaly detection; (c) time-series foundation models (Chronos, TimesFM, Moirai) as zero-shot baselines for sparse data; (d) classification of fault types when labelled history exists.
• Semantic metadata is the real bottleneck. Mapping vendor-specific point names to a common model (Brick, Project Haystack) is what makes rules portable between buildings [5][6]. LLMs now help tag points from names and descriptions; results must be reviewed by an engineer (see DATA-016 for the general approach).
• LLM layer: turns a fault plus its context into a work-order text, summarises weekly findings, retrieves the matching service-manual passage (KNOW-004) and answers "why is AHU-3 using so much heat?". It does not detect faults.
• Human-in-the-loop: the facility manager confirms or rejects findings (feedback tunes thresholds); fixes and any changes to control sequences are done and approved by qualified technicians. Write-back into the BMS is not part of FDD; if wanted it belongs to optimisation (OPT-007) behind approvals.

Data preparation

Data come from the building-management system (BMS/GLT), controllers and meters via BACnet, Modbus or OPC UA, plus point lists, plant schematics and maintenance records. In practice they live in the BMS database, in service technicians' PDFs, in CAFM tools and in paper maintenance logs.

Typical gaps: inconsistent or missing point names (no Brick or Haystack tagging), sensors out of calibration, gaps and different sampling rates, no schematics linking points to equipment, and trend logging switched off to save memory. Access to the BMS often belongs to a service provider, so contractual access rights matter.

Preparation steps: inventory data points and sources (PREP-001, PREP-005), export trend data and normalise timestamps, tag points with a naming scheme (PREP-010), build a glossary of equipment terms (PREP-015), digitise paper logs (PREP-006, PREP-008) and harvest labels from past work orders as known faults (PREP-020). Tools: Python or n8n pipelines, a time-series database, Brick-based tagging.

Rough share of effort: about 40 to 50 percent, mostly point mapping and data access. See also GUIDE-003.

Implementation paths

Which path for whom

• SMB (property owners, small operators): Path A, because FDD is offered as a cloud service or module of building-management systems and the HVAC faults are standard.
• Enterprise (portfolio owners, facility managers): Path B, since many buildings with differing building-management systems need an integrated data layer and own rule and model logic.
• Developer: Path C, as open-source stacks (time-series database, open FDD rule libraries) run on HW1 and fit integrators building their own service.
• Public (municipal and state buildings): Path B on sovereign EU or German cloud, which satisfies procurement and sovereignty requirements for building data.

Path A — Buy (recommended for most organisations)

• BMS manufacturers' analytics: Siemens (Building X / Desigo CC), Schneider Electric (EcoStruxure Building Advisor), Johnson Controls (OpenBlue), Honeywell (Forge); EU/German/Swiss BMS vendors with analytics or energy-monitoring modules: Kieback&Peter, Sauter, Ennovatis (verify current offering per vendor).
• Independent FDD/analytics platforms: SkyFoundry SkySpark, Clockworks Analytics, Mapped, Willow, Gridium and similar; independent platforms are vendor-neutral and cover mixed BMS estates.
• Check: BACnet/OPC UA connectivity without invasive changes, EU data residency or on-prem option, Brick/Haystack export (avoid lock-in), explainability of each fault (show the trend), cost-impact estimate, CAFM integration, contract terms on data ownership.
• Choose A when: you have a BMS with trend logging, no in-house data science, and want results within weeks.

Path B — Build on cloud APIs

• Pipeline: gateway publishes to MQTT → cloud time-series service (Azure Data Explorer/Digital Twins, AWS IoT SiteWise/TwinMaker, Google BigQuery in EU regions, or managed Timescale/Influx in an EU region) → rules and ML jobs → dashboards.
• LLM use: frontier LLMs with tool-calling (Claude, Gemini, GPT, Mistral — EU regions where offered) for explanations, work-order drafting and point-name mapping to Brick; keep raw data processing deterministic.
• Choose B when: you are a service provider or large owner building a differentiated product and already operate a cloud data platform.

Path C — Self-host (open source)

• Data & semantics: Brick schema + BrickServer/ontology tools, Project Haystack tags, TimescaleDB or InfluxDB, Grafana, Node-RED or Apache NiFi, Mosquitto/EMQX for MQTT, BACnet access via bacpypes3 or the VOLTTRON platform (PNNL) [7].
• Detection: rule libraries implemented in Python/SQL; scikit-learn/LightGBM/PyOD for baselines; Chronos or TimesFM for zero-shot forecasting residuals; Modelica Buildings Library, EnergyPlus and the BOPTEST framework for simulation-based testing of rules before go-live [8].
• LLM (optional): a small open-weight model (e.g. Qwen3 or Mistral/Llama family 7–14B) served via Ollama or vLLM for explanations and ticket text.
• Hardware: HW1 (a CPU server or industrial edge PC) is enough for rules and classical ML on thousands of points; HW2 only if a local LLM is added. Ops effort: substantial for the data model and connectors.
• Choose C when: air-gapped OT networks, public-authority sovereignty requirements or in-house engineering.

Path D — Custom training

Seldom needed. Worth it for portfolio operators with many identical buildings: train asset-level models on years of labelled fault/work-order history (fault classifier, remaining-useful-life, cost-impact regression), or fine-tune a small language model for point-name-to-Brick mapping. Needs labelled fault episodes, which most owners lack: start by capturing technician verdicts on each flagged finding and use these as the training set.

State of the art (2026)

• Standardised semantics: Brick and Project Haystack are the established metadata models; ASHRAE 223P (semantic model for building systems) is moving into standards use. Portability of rules across buildings has improved, but onboarding a building is still mostly data-engineering work [5][6].
• Hybrid approach wins: production systems combine transparent rule libraries (reliable, explainable) with ML baselines (catch what rules miss). Pure black-box deep learning is rare in operations because technicians need a reason, not just a score.
• LLMs in the workflow: research and vendor products in 2025–2026 use LLMs to explain faults, generate work orders, map point names and query building data in natural language. Treat reported detection accuracies of LLM-only approaches with caution; most published results are on simulated or lab data.
• Simulation-backed validation: BOPTEST and digital-twin simulation allow fault injection to benchmark detection algorithms before deployment [8].
• Limits and failure modes: poor data quality (missing trends, wrong units, overridden points, mislabelled sensors) dominates error; false positives erode trust and cause alert fatigue; unknown design intent makes "fault" versus "intended behaviour" ambiguous; savings are only realised when faults are actually repaired, so the workflow integration matters more than the algorithm.

Shared resources & combinations

• Same data foundation as OPT-007 (building energy management & HVAC optimisation): BACnet connectors, Brick model, time-series store. FDD first, then optimisation; optimising a faulty plant wastes effort.
• ANOM-005 / PRED-006: same anomaly-detection and time-series stack and the same edge gateway (HW1) can serve industrial assets; FDD feeds predictive-maintenance models with fault history.
• DATA-016: asset/point contextualisation (unified namespace) is shared with industrial data work.
• PRED-048 / PRED-031: building energy performance prediction and smart-meter analytics supply baselines and benchmarking; FDD results prioritise renovation measures.
• KNOW-004: service-manual RAG for technicians; AGENT-002: workflow engine for tickets and escalations.
• SEC-015: the OT/BMS network monitoring and segmentation that must protect the gateway path.
• ANOM-030: KPI/anomaly narration approach can be reused for energy-cost reporting.
• Hardware: one edge PC or small server per site or per portfolio; an optional HW2 GPU shared with other LLM tasks.

Effort, cost & KPIs

• Path A: weeks to connect and tune per site; typically subscription pricing per building, per point or per floor area. Path B: 2–6 months for a platform with a few buildings; cost drivers are cloud ingest and engineering. Path C: 3–9 months, mostly metadata modelling and connectors; low licence cost.
• Main cost driver: data onboarding (point mapping, trend logging configuration) and the fix capacity of the service team, not the algorithm.
• KPIs: number and age of open faults; fault-to-fix time; verified energy and cost saved per fault (IPMVP-style measurement and verification); false-positive rate (share of findings rejected by technicians); comfort complaints; share of equipment covered with usable data; avoided emergency call-outs.

People & change

Involve management for the energy and comfort targets, the facility-management lead as process owner, the technicians (end users) who will work on faults, IT and IT security because BMS networks are critical infrastructure, the BMS vendor or service provider (suppliers) for data access, and the data owner of the building data. DPO involvement is usually small, but occupancy sensors, room bookings or access data can be personal; clarify before using them, and sign an AVV with cloud providers.

Works council: depends. Equipment data alone do not monitor staff. If technicians' response times, work orders or occupancy by person become visible, §87(1) no. 6 BetrVG applies, and §90(1) no. 3 requires early information. Keep reports at equipment level.

Concerns: fear that diagnostics replace technicians and that false alarms waste time. Pilot in one or two buildings, let technicians confirm or reject each finding, and use their verdicts to tune rules. The system proposes; people decide on interventions and safety-relevant actions. Support AI literacy (Art. 4 AI Act) through short trainings. See GUIDE-009, GUIDE-008 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: minimal risk. FDD advises people on maintenance; it is not a safety component in the management of critical infrastructure under Annex III (for example, it does not itself control heating supply networks). Closed-loop control that is a safety function would need separate assessment. AI literacy (Art. 4) applies [2].
• GDPR: mostly machine data. Personal data can arise from occupancy and badge data, room-booking data and per-tenant metering; use aggregated data where possible and a data-processing agreement with SaaS providers. Works-council co-determination (BetrVG §87) may apply when occupancy or individual usage is analysed.
• Building law: EPBD 2024/1275 (BACS, monitoring), German GEG, ISO 52120-1 (BACS impact on energy performance), DIN EN ISO 16484 (BACS), ASHRAE Guideline 36 for sequences [1].
• Security: BMS networks are OT; keep the connection read-only, segment the network, follow NIS2 and IEC 62443-aligned practice; cloud connection via outbound-only gateways.
• Operational risk: wrong diagnoses leading to unneeded repairs; mitigate by showing evidence with each finding and validating after the repair.

Getting started

1. Inventory systems: BMS vendor, protocols, existing trend logging, number of AHUs, chillers, boilers; check whether the 290 kW EPBD/GEG threshold applies.
2. Pick a pilot: one or two buildings with known comfort or energy problems and enough trend history (several months, 5–15 minute resolution).
3. Run a vendor shortlist or open-source rules on that pilot; compare findings with a technician walk-through.
4. Agree the workflow: who reviews findings, who fixes them, how savings are verified (baseline and IPMVP option).
5. Build the metadata model (Brick/Haystack) while onboarding the first site so that rules scale to the portfolio.

Sources

Note: sources compiled in Oct 2026 from stable primary pages; the research session's web-search budget was exhausted, so some vendor details are from prior knowledge and marked "verify". 1. Directive (EU) 2024/1275 on the energy performance of buildings (recast) — https://eur-lex.europa.eu/eli/dir/2024/1275/oj 2. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj 3. Lawrence Berkeley National Laboratory — Building Technology & Urban Systems, fault detection and diagnostics research — https://buildings.lbl.gov/ 4. Pacific Northwest National Laboratory — building energy research — https://www.pnnl.gov/ 5. Brick Schema — https://brickschema.org/ 6. Project Haystack — https://project-haystack.org/doc/index 7. VOLTTRON (PNNL) — https://volttron.org/ 8. BOPTEST (IBPSA Project 1) — https://ibpsa.github.io/project1-boptest/ 9. ASHRAE Guideline 36 — High-Performance Sequences of Operation for HVAC Systems — https://www.ashrae.org/technical-resources/standards-and-guidelines