What Is FDD? How Fault Detection Gets Its Data — and Loses It

Key Takeaways

• FDD is an analytics layer that applies rules or models to equipment data to identify faults, diagnose causes, and quantify cost.
• Berkeley Lab’s Smart Energy Analytics Campaign found that by the second year of installation, participants with FDD achieved a median 9% annual energy savings, with a median simple payback of roughly two years.
• FDD never reads equipment. It reads whatever your OT network delivered — via polling, COV subscriptions, or Trend Log pulls — and each path fails differently.
• A stalled data feed is indistinguishable from a stable, correctly operating point.
• Nearly all of these failures are visible on the wire and invisible in the FDD interface. The protocol usually tells you data was lost. Almost nothing surfaces it.
• FDD platforms are built to reason about equipment behavior, not about the transport that described it.

---

What Is FDD?

Fault detection and diagnostics (FDD) is a software layer above your building automation system that continuously evaluates equipment data against expected behavior. 

It answers three questions in order: Is something wrong? What specifically is wrong? What is it costing?

Two broad approaches dominate.

Rule-based FDD is a set of if-then checks. One common rule watches for heating and cooling fighting each other: if the chilled water valve and the hot water valve are both open at the same time, you’re paying to cool air you’re also paying to heat. Another checks whether an economizer is pulling in free outside air when conditions allow it, instead of running the chiller for no reason.

The appeal is that every alert arrives with reasoning attached. A technician can see exactly which condition tripped and judge whether the rule needs adjusting or the equipment does. Most commercial FDD tools are built this way.

Data-driven FDD learns what “normal” looks like from your own history, then flags behaviour that departs from it. The advantage is catching problems nobody thought to write a rule for. The trade-offs: it needs a stretch of known-good operation to learn from, and when it raises a flag it often can’t tell you why — a harder sell to the technician being asked to act on it.

Both share a structural dependency that matters more than the choice between them: they operate on data that something else has to collect and deliver. FDD never touches an air handler. It touches a database of what your OT network reported the air handler was doing.

What Advantages Does FDD Offer a Building?

The strongest available evidence is the Smart Energy Analytics Campaign, a four-year US Department of Energy initiative facilitated by Lawrence Berkeley National Laboratory.

The findings that matter:

• It works. By the second year of installation, participants with FDD achieved a median 9% annual energy savings, at roughly $0.24 per square foot. Participants with energy information systems achieved a median 3%, at $0.03 per square foot.
• It works fast. Median simple payback was approximately two years.
• It’s pretty cheap. Installation and software costs ranged from two to eight cents per square foot depending on system type.

Berkeley Lab researcher Hannah Kramer put the underlying reason plainly: “It’s impractical for businesses to manually review the amount of data being collected in today’s commercial buildings — analytics are needed to get value from all that data.”

Beyond energy, FDD also changes the shape of a maintenance program. Faults get ranked by cost impact rather than by who complained loudest, turning a reactive dispatch queue into a prioritized one. Commissioning stops being an event and becomes a state you can verify still holds a year later. And when equipment needs replacing, you have a performance record to put in front of whoever signs the capital request.

---

A Real World Example

Kaiser Permanente expanded its FDD program under the Campaign and was recognized in 2019 for EMIS use across 69 buildings, with average energy savings of 12%. It later expanded the program to 113 buildings, and in a Better Buildings webinar described scaling FDD from an initial pilot to a portfolio of more than 150 sites and 16.5 million square feet.

The trajectory is the instructive part. The pilot proved the rules worked. The scale-up is where the data infrastructure had to hold up across a portfolio — which is the part most FDD conversations skip.

---

How Does FDD Actually Get Its Data?

In a BACnet building, an FDD platform acquires time-series data through one of three mechanisms, normally by way of a supervisory device that speaks BACnet/IP or MS/TP to the field and an API, MQTT, or database connection northbound to the analytics tier.

1. Polling. The supervisor issues ReadProperty or ReadPropertyMultiple against Present_Value on a fixed interval. ReadProperty is required of every BACnet device containing an application layer, which makes polling the universal fallback and the default for most platforms. It is also the most bandwidth-hungry option and it scales badly.

This is why we recommend in our own best practices to focus on moving your polling to properly tuned COVs when you can, like we did at one of North America’s largest casinos.

2. COV subscriptions. The client sends SubscribeCOV and the controller pushes a notification only when the value moves past a defined increment. Much lighter on bandwidth, and better suited to catching brief events between polls. It is also stateful, aka it remembers previous interactions, tracking session data and context from one request to the next. But for every object type, a change in Status_Flags alone triggers a notification — meaning a fault or out-of-service transition arrives even when the value hasn’t moved. That one is the most FDD-relevant of the three and the one most commonly discarded on the way up.

3. Trend Log objects. The controller records a point locally into a Trend Log and the supervisor pulls records periodically. That log lives in the same device as the point it monitors. This tolerates brief interruptions well, because the controller keeps logging while nobody is listening. That resilience disappears if the Trend Log is hosted in the supervisor or configured for COV against a remote device — a common arrangement that inherits the failure modes of the first two mechanisms.

Each path degrades differently. And in every case, the degradation is quiet.

Why a Degraded OT Network Makes FDD Miss Faults Instead of Flagging Them

Here is the counterintuitive part, and the reason this deserves more attention than it gets.

A struggling network does not make your FDD dashboard noisy. It makes it quieter.

There’s a formal version of this. The standard methodology for evaluating FDD tools scores five outcomes, not four — correct detection, false alarm, misdiagnosis, missed detection, and “no response,” meaning the protocol couldn’t be applied or produced no output. On a dashboard, “no response” and “no fault” look identical. The distinction only exists if something is tracking it.

A stalled COV feed looks exactly like a stable value

Two things can break a COV feed, and they break differently.

If the client’s resubscription request is lost on a congested segment, the client at least sees a failure — SubscribeCOV is confirmed, so it times out. But a timeout is problematic: the subscription may have been created and the acknowledgment dropped. And a successful subscription guarantees nothing about delivery. Where notifications are unconfirmed, the controller has no obligation to queue or retry them and no way to tell you if it didn’t.

The harder case is the controller side. A device that restarts will usually lose the subscriptions it was holding — the standard doesn’t require it to keep them, and most implementations don’t. Vendor behavior varies, which is its own problem: whether a given controller comes back still knowing who was listening is a per-device question you can’t answer from the analytics layer.

BACnet anticipates the loss. But that still carries three ways it can fail: the supporting properties are optional, so not every device implements it; MS/TP devices and nodes can’t participate at all, and where the recipient list is empty, the device is prohibited from sending the notification. That last case is worth checking on your own equipment, because it’s configuration, not firmware.

Where the notification isn’t sent or doesn’t arrive, the client waits for updates that will never come. It doesn’t receive an error. It receives nothing. 

And on a change-of-value feed, “nothing” is indistinguishable from a point whose value is not changing.

Now consider what a large share of FDD rules are looking for: valve hunting, damper oscillation, short cycling, unstable control loops. Those rules detect variation. A stalled feed is close to perfect camouflage for exactly the fault classes FDD is best at catching. The rule does not misfire. It concludes the loop is stable.

A polling gap looks like a rule that had nothing to evaluate

Rules aggregate over a window. If inputs for that window are missing, or the platform’s own input validation judges them unreliable, the rule produces no output — and “no output” is not the same event as “no fault,” even though both render as silence. 

Clockworks Analytics describes running exactly this kind of check before each analysis: validating whether each point is up to date and accurate enough to support the rule at all. Sounds like OT network diagnostics 101 to us.

Data-driven FDD fares are no better here. Research on diagnostic performance under data uncertainty finds accuracy descends sharply as uncertainty rises, with discontinuous sampling named among the causes.

Also important to note: network congestion and equipment faults tend to occur under the same conditions: peak load, simultaneous starts, aggressive resets, everything on at once. The periods most likely to produce a fault are the periods most likely to produce dropped reads.

A Trend Log buffer fails in one of two directions

Trend Logs have a finite buffer size. When it’s filled, the log behaves as a ring buffer and overwrites its oldest records. If the supervisor can’t finish its pull before the buffer wraps — queued behind heavy discovery traffic or a busy router — those records are gone for good. Those gaps cluster in high-activity periods, for the same reason polling gaps do: the conditions that congest a network are the conditions that keep equipment busy. 

The point stops historizing entirely and stays stopped until a human re-enables it. That’s the worse outcome for FDD, and the less obvious one — the failure isn’t a gap in the middle of a series, it’s a series that quietly ends.

Can you tell when either has happened? Sometimes — but not as easily as you’d hope, and not automatically. The loss is announced on the wire. It just rarely makes it into anything a human looks at.

A write that was acknowledged still might not be in effect

WriteProperty is confirmed, so a client who times out knows something went wrong — but it only knows the transaction is indeterminate, not that it failed. The write may have executed with the acknowledgment lost on the way back.

The subtler problem is that a successful acknowledgment doesn’t mean the value is in effect. A higher-priority command masks yours silently. The write succeeded; the setpoint never moved. An FDD platform that treats acknowledgment as confirmation will not flag the deviation, because by its own record the equipment is being commanded correctly.

Not every BACnet write is confirmed, either — WriteGroup, used for group commanding of Channel objects, is unconfirmed by design.

Duplicate device IDs corrupt the series itself

Two related faults with different signatures. A duplicate device instance breaks dynamic binding at the application layer: with two devices answering for one instance, a client’s address cache can resolve to either and be re-pointed by whichever I-Am arrived most recently.

A duplicate MAC or IP address breaks things one layer down, with mismatched responses and address conflicts.

Either way, the data reaching the rule engine can be contradictory — discharge temperature from one unit, fan status from another. Rules fed that don’t detect a fault. They detect noise. And noise gets managed by loosening thresholds or ignoring a fault category, which is how a rule stops working without anyone deciding to switch it off.

What This Means for Verification

Read those failures together and a specific asymmetry emerges.

Some FDD platforms do detect data gaps. For example, BuildingLogix solutions can review and identify data gaps. Alex Waibel, President at BuildingLogix explains, “There are several ways to do this depending on what it is you are looking for, the type of equipment and data you are collecting, and the use case of the data. For example,  energy and electric meters will rarely if ever go to 0, however there are some cases it will. But for a main building meter at a school or hospital that will almost never happen, unless power is lost, or the meter goes off line.  Our system is set up to identify anomalies like this and report on them.”

But notice what they find: a hole in the historian, after the fact. They tell you data is missing because they aren’t part of the real-time capture. They don’t tell you a router was saturated at 6 a.m., that a controller restarted and nobody was told, that two devices are answering to the same instance number, or that your writes are landing at a priority something else overrides. The gap is a symptom several layers removed from its cause, which makes it hard to fix and easy to attribute to the wrong thing.

The cause is visible, just not there. Retries, timeouts, unacknowledged confirmed requests, broadcast storms, duplicate device IDs, busy-router messages — all of it is plainly readable in traffic, at the moment it happens. What doesn’t exist is a path from that evidence to the screen the operator sees. FDD platforms are built to reason about equipment behavior, not about the transport that described it.

You Can’t Validate an FDD Deployment by Looking at the FDD Deployment

A dashboard with few alerts is consistent with a healthy building and also with a data pipeline that quietly stopped delivering. Telling those apart means reading the network itself — the job of OT monitoring tools that inspect traffic rather than the values traffic reports.

Two things worth doing:

1. Find gaps. Track expected-versus-received sample counts per point, and enable whatever gap detection your platform offers. A point delivering 60% of expected samples deserves an alert of its own, and the absence of that alert is not evidence the point is fine.
2. Watch the network layer for causes, not just the historian for symptoms. Unacknowledged confirmed requests, duplicate device instances, restart notifications, and discovery traffic volume are the earliest available warning that your analytics layer is being fed an incomplete picture. They’re in the traffic whether or not anyone is looking.

For the broader case on sequencing network remediation ahead of an analytics deployment — including what it cost one 80-building campus to do it in the wrong order — see our companion piece on OT network readiness as a prerequisite for FDD and analytics.

Before You Trust an Absence of Faults, Verify the Absence Is Real

FDD is one of the highest-return applications available to a commercial building, and the Berkeley Lab dataset is about as solid as evidence gets in this industry.

But FDD is a consumer of data, not a producer of it, and its failure mode runs in the direction of reassurance. Clockworks, who sell an FDD platform, put the problem more bluntly than we would: false negatives are “far more elusive, as it is almost impossible to validate the absence of a fault” without extensive manual analysis — and teams tend to discover this only after an equipment failure sends them back through the record wondering why nothing fired.

A quiet dashboard is not evidence of a well-run building until you can show the data behind it arrived intact.

Upload a capture to OptigoVN to see what your OT network is actually delivering — including the unacknowledged requests and duplicate device IDs that shape what your analytics layer is able to see. Request a free trial at optigo.net/signup.

---

FAQ: Fault Detection and Diagnostics and OT Networks