Fault detection and diagnostics (FDD)

Most commercial buildings have HVAC faults that nobody knows about. A stuck outdoor air damper, a leaking chilled water valve or a heating coil fighting a cooling coil will rarely trigger a complaint, but each one wastes energy and shortens equipment life. Fault detection and diagnostics (FDD) is the practice of using data the building already collects to find these problems automatically.

FDD is not a single product. It ranges from a few logic blocks inside the building automation system (BAS) to cloud analytics platforms that pull thousands of points every few minutes. What they share is a simple idea: compare what the system is doing with what it should be doing, and flag the difference before it becomes a failure or a utility bill surprise.

What FDD actually does

FDD has two parts that are often confused.

• Fault detection identifies that something is wrong: for example, the supply air temperature of an air handling unit (AHU) is 3 K above setpoint while the cooling valve is 100% open.
• Fault diagnostics identifies the likely cause: a failed chilled water supply, a fouled coil, a mis-calibrated sensor or a valve actuator that is not stroking.

Detection is relatively easy. Diagnosis is harder because many faults produce similar symptoms. Good FDD tools narrow the list of probable causes and tell an operator where to look first, rather than claiming to know the answer with certainty.

Common approaches

Rule-based FDD

Rule-based FDD uses expert rules written as logical tests on trend data. The best-known public example is the set of AHU performance assessment rules (APAR) developed at the US National Institute of Standards and Technology, and ASHRAE Guideline 36 now includes fault detection rules for AHUs and terminal units alongside its standard sequences. A typical rule checks a condition, waits for the system to be stable, and only raises a fault if the condition persists.

Rule-based methods are transparent. An engineer can read the rule, understand why it triggered and adjust thresholds. Their weakness is that every rule must be written and tuned, and rules written for one system type do not transfer automatically to another.

Model-based and data-driven FDD

Model-based FDD compares measured performance with a physical or empirical model of the equipment, such as a chiller efficiency curve or a coil model. Data-driven methods use statistical or machine learning techniques to learn normal behaviour and flag deviations. These approaches can catch subtle degradation, but they need good baseline data and can be harder for operators to trust because the reasoning is less visible.

In practice, most commercial FDD platforms combine a large library of rules with some model-based checks for central plant equipment.

Faults FDD commonly finds

Sensor faults deserve special mention. Every control decision depends on sensor accuracy, and FDD tools often find that a significant share of reported problems trace back to a bad sensor. Regular calibration and good sensor selection and location make FDD results far more reliable.

Data requirements

FDD is only as good as the data it receives. Before buying a platform, check the following.

1. Point coverage. Rules need specific inputs. An economizer rule needs outdoor, return and mixed air temperatures plus damper command. If the mixed air sensor is missing, that rule cannot run.
2. Sample interval. Most HVAC rules work with 1 to 15 minute intervals. Faster sampling helps with oscillation and short cycling detection.
3. Consistent naming and tagging. FDD software must know which point is which. Haystack tags, the Brick schema or ASHRAE Standard 223P semantic models make mapping much faster than relying on inconsistent legacy point names.
4. Reliable storage. Gaps in trend data generate false faults or hide real ones. See trend logging and using BAS data for setting up trends properly.
5. Network access. Cloud platforms need a secure path out of the BAS network, which raises cybersecurity questions that should be resolved with IT before installation.

Setting up an FDD program that gets used

The most common failure of FDD is not technical. It is a dashboard full of faults that nobody acts on. A useful program has these elements.

Prioritize faults

Rank faults by energy cost, comfort impact and equipment risk. Many platforms estimate the cost of each fault. A short list of high-value items, reviewed weekly, is far more effective than hundreds of open faults.

Assign ownership

Each fault needs a person responsible for investigating and closing it, whether in-house staff or a service contractor. Integrating FDD output with the work order system closes the loop.

Tune before trusting

During the first few months, expect false positives. Thresholds, delays and occupancy schedules need adjusting to match the building. Treat this period as part of implementation, not a sign the tool does not work.

Verify fixes

When a fault is closed, the data should show that it stays closed. Recurring faults often point to a design or sequence problem rather than a maintenance one.

FDD and commissioning

FDD is closely linked to ongoing and monitoring-based commissioning. In new construction, FDD can verify that sequences perform as intended after turnover. In existing buildings, it can find retro-commissioning opportunities and then keep the improvements from drifting away. Many owners use an initial retro-commissioning project to fix the backlog, then rely on FDD to maintain performance.

Frequently asked questions

Does FDD replace the BAS alarm system?

No. Alarms handle urgent conditions that need an immediate response, such as a freezestat trip or a high space temperature in a server room. FDD finds slower, persistent problems that waste energy or degrade performance. The two should be designed together so that operators are not flooded with duplicate notifications.

Can FDD run on an older BAS?

Often yes, as long as the system can trend the needed points and export data. Older proprietary systems may need a gateway or a data integration layer. Very old systems with limited trend memory may be better addressed through a controls upgrade first.

How much data history is needed to start?

Rule-based FDD can begin producing results within days of collecting good data. Model-based checks and seasonal faults, such as economizer or heating-season problems, need data across the relevant operating conditions.

Key takeaways

• FDD compares actual system behaviour with expected behaviour to find faults that do not trigger alarms or complaints.
• Rule-based methods, including those in ASHRAE Guideline 36, are transparent and are the backbone of most commercial platforms.
• Point coverage, sensor accuracy, consistent tagging and reliable trend storage determine how useful FDD results will be.
• Prioritizing faults, assigning ownership and verifying fixes matter more than the number of rules a platform offers.
• FDD works best as the maintenance phase of a commissioning effort, keeping hard-won improvements in place. An independent control system verification is a good starting point before connecting FDD.