Fault Detection & Diagnostics

FDD bundles two related but different tasks. Detection is noticing that something is wrong - a value out of range, a pattern that does not fit, energy where there should be none. Diagnosis is the harder, more valuable step: identifying which fault and where, so it becomes an actionable work order rather than a vague alarm. An alert that says AHU-3 is behaving oddly is detection; AHU-3 heating and cooling valves are both open, wasting energy is diagnosis. The whole discipline is sometimes called fault detection and isolation in control engineering - the isolation being the pinpointing of the specific faulty component.

The reason diagnosis matters so much is triage. A building can throw off hundreds of alerts a day, and an operator who cannot tell a real, costly fault from noise quickly starts ignoring all of them - alarm fatigue is the graveyard of FDD projects. Good FDD does not just flag; it diagnoses, ranks by cost or severity, and hands over an actionable item: this unit, this fault, this much wasted energy per day, fix in this order. When it is automated across the plant it is often called AFDD (automated FDD), and increasingly it runs continuously - a practice known as continuous commissioning, keeping a building tuned rather than letting it drift.

It helps to see where FDD sits relative to the rest of this module. It is a specialised, high-value application of the analytics ladder: detection is largely diagnostic analytics (why is this happening), and the best systems edge toward prescriptive by recommending the fix and its priority. It leans on the same raw material - clean, well-tagged time-series data - and on the same rules-versus-models choice. What makes FDD distinctive is its narrow, unglamorous, enormously profitable focus: not predicting the future or optimising comfort, but simply catching the many small ways a building is already running wrong today. That modest ambition is exactly why it works so reliably, and why it is usually the first advanced analytic worth deploying.

A handful of faults account for a huge share of wasted energy, and knowing them by name trains your eye. Simultaneous heating and cooling is the canonical villain: a zone or air handler heats and cools the same air at once, paying twice to stand still - usually from a leaking valve, a bad control sequence or fighting setpoints. Stuck or broken dampers leave outside-air dampers jammed open (over-ventilating in extreme weather) or shut (starving the space of fresh air). Leaking valves let hot or chilled water pass when they should be closed, bleeding energy invisibly. Sensor drift or failure quietly corrupts control - a temperature sensor reading three degrees low makes every downstream decision wrong. Schedule and setpoint faults - overrides left on, plant running nights and weekends in an empty building - are the cheapest to fix and among the most common.

These are common precisely because they are invisible in comfort terms. The building still feels fine; only the meter suffers, and only if someone is looking. That is why they can persist for years. FDD works because each of these faults leaves a distinct signature in the data - a relationship between valve position, air temperature, flow and energy that a rule or a model can recognise even when the room feels perfectly comfortable.

There are two families of FDD, mirroring the rules-versus-models split from the last lesson. Rule-based FDD encodes expert knowledge as explicit logic: if the outside-air damper is commanded shut but mixed-air temperature tracks outside air, the damper is stuck open. Most commercial FDD products are predominantly rule libraries - often built on published fault rules such as those developed for air handlers by national labs. Their great strength is that they are explainable and work from day one: each rule names a specific fault, needs no training history, and an engineer can audit exactly why it fired. Their weakness is coverage - they only catch what someone thought to encode, and the rules need upkeep as plant is modified.

Data-driven FDD instead learns the building's normal behaviour from historical data and flags departures from it. It can catch faults nobody wrote a rule for and adapt to a specific building, but it needs clean history to learn from, tends to say something is odd without naming the fault, and is harder to trust and audit. Neither wins outright. The strongest systems combine them: a solid library of rules for the known, high-value faults, with data-driven anomaly detection layered on top to catch the unknowns - and both feeding one triaged, ranked queue of work.

The prize is real. Faults that hide in plain sight commonly waste a meaningful slice of a building's HVAC energy - studies and field programmes put avoidable waste from undetected faults broadly in the region of 5 to 30 percent, depending on the building and how long faults have festered. Because many fixes are cheap - reset a schedule, reseat a damper, replace a stuck valve - FDD often shows among the fastest paybacks in the whole smart-building toolkit. It is one of the clearest cases where analytics pays for itself.

But be honest about the pitfalls. FDD is only as good as its data: a drifting or mislabelled sensor produces false faults or masks real ones, and messy equipment naming makes rules impossible to apply at scale - which is exactly why metadata schemas like Brick and Project Haystack matter, giving every point a consistent, machine-readable tag so rules can be written once and applied everywhere. And detection is worthless without a workflow: a fault nobody triages, assigns and closes is just another ignored alert. The buildings that capture the savings are the ones where FDD feeds a maintenance process and someone owns the queue - not the ones with the cleverest algorithm and nobody watching it.

Make it concrete. Imagine a mid-size office where one perimeter zone has felt fine all year - no complaints, comfortable, unremarkable. What nobody sees is that its reheat valve has been leaking by: even when the control system commands it fully closed, hot water keeps trickling through the coil. The zone's cooling then has to work a little harder to hold setpoint, so the space is quietly being heated and cooled at once. In comfort terms, nothing is wrong. In energy terms, this one zone has been bleeding money every hour of every day for twelve months, and it is completely invisible on a walk-through.

Now add FDD. A rule watches the relationship between the reheat valve command and the discharge-air temperature: if the reheat valve is commanded closed but discharge temperature keeps rising above mixed-air temperature, suspect a leaking or stuck valve. On this zone the rule fires. Crucially, the system does not stop at something is odd - it diagnoses the specific fault (leaking reheat valve on this zone), estimates the daily energy cost, and ranks it against every other open fault in the building so the operator knows it is worth attention today rather than next quarter. That triage is what lifts it above the noise.

The rest is workflow, not analytics: a work order is raised, a technician reseats or replaces the valve, and - the step too many projects skip - the fix is verified by watching the signature disappear and the zone's energy drop. One rule, one fault, one fixed valve. Multiply that across dozens of units and hundreds of buildings and you see why FDD is among the fastest-paying analytics there is - and why its payoff lives as much in the maintenance process behind it as in the cleverness of the rule in front.