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.
- The dangerous failure is not a false alarm. It’s a false negative. 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.
What Is FDD?
Fault detection and diagnostics (FDD) is a software layer above your building automation system that continuously evaluates equipment data against expected behaviour. It answers three questions in order: Is something wrong? What specifically is wrong? What is it costing?
Two broad approaches dominate.
Rule-based FDD encodes engineering logic as conditional tests. A simultaneous heating-and-cooling rule checks whether a chilled water valve and a hot water valve are both open past a threshold in the same evaluation window. An economizer rule checks damper position against outside air and return conditions. These rules are transparent, tunable, and explain themselves, which is why most commercial FDD tools are built on them.
Data-driven FDD learns a baseline from historical operation and flags statistical deviation from it. It catches drift nobody wrote a rule for, at the cost of needing a clean training period and being harder to justify to the technician who has to act on the alert.
Both share a structural dependency that matters more than the choice between them: they operate exclusively on time-series data that something else had 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. It produced the largest known dataset on energy management and information systems (EMIS), the category containing FDD: 104 organizations, more than 6,500 buildings, 567 million square feet.
The findings that matter:
- 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.
- Median simple payback was approximately two years.
- 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 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 verifiable example: Kaiser Permanente
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 Better Buildings materials has 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, which makes polling the universal fallback and the default for most platforms. It is also the most bandwidth-hungry option and it scales badly. (ReadPropertyMultiple, which reduces that overhead considerably, is optional for smaller device profiles.)
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, which is where the interesting failures live.
3. Trend Log objects. The controller historizes a point locally into a Trend Log and the supervisor pulls records periodically using ReadRange. Where the 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 when 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.
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 dropped on a congested segment, the client finds out. SubscribeCOV is a confirmed service, so a lost request surfaces as a timeout. The information is there.
The harder case is the controller side. A device that restarts loses the subscriptions it was holding. BACnet anticipates this: the Device Restart Procedure has a restarting device broadcast an UnconfirmedCOVNotification carrying its System_Status to a configured list of recipients. But that procedure is optional, MS/TP slave devices cannot support it at all, and the notification is an unconfirmed local broadcast — droppable, and not necessarily routed across networks to whoever needed it. Where it isn’t implemented or doesn’t arrive, the client waits for notifications that will never come.
It does not 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.
Worth knowing on the configuration side: the Lifetime parameter in SubscribeCOV is optional, and when it’s absent a lifetime of zero — indefinite, never automatically cancelled — is assumed. Indefinite subscriptions remove the lapse risk entirely, but they also remove the renewal cycle that would otherwise heal a subscription lost to a restart.
A polling gap looks like a rule that had nothing to evaluate
Most fault rules require a minimum count of valid samples in an evaluation window before returning a verdict. That’s sound design — it stops one bad reading from generating a work order.
It also means that when reads time out against a saturated router, the rule does not report “insufficient data.” It simply doesn’t evaluate. Nothing on the dashboard distinguishes evaluated, no fault from never evaluated.
There’s a compounding effect worth sitting with. 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.
An overflowing Trend Log buffer loses the busiest hours first
Trend Logs have a finite Buffer_Size. When Stop_When_Full is false, the log behaves as a ring buffer and overwrites its oldest records. If the supervisor can’t finish its ReadRange pull before the buffer wraps — queued behind heavy discovery traffic or a busy router — those records are gone for good, and the gaps cluster in high-activity periods for the same reason as above.
But notice what the protocol does here. A ReadRange-ACK with its FIRSTITEM flag set is telling the subscriber, explicitly, that records have probably been missed. Sequence number gaps say the same thing. So does Total_Record_Count against Record_Count. The loss is announced on the wire. It just rarely makes it into anything a human looks at.
A write that was never acknowledged still gets treated as done
BACnet writes are confirmed services — WriteProperty returns an acknowledgment — so a client whose write times out does know it failed. The failure mode is what happens next. Where a platform assumes success, it believes a setpoint is in effect that isn’t, and won’t flag the resulting deviation, because by its own record the equipment is being commanded correctly. Confirmed requests with no observed acknowledgment are among the most common diagnostic findings on real networks, and they sit precisely in this blind spot.
Duplicate device IDs corrupt the series itself
If two devices share a device instance or address, an FDD platform can end up trending an interleaved mix of two pieces of equipment. The series reaching the rule engine is internally contradictory: discharge temperature from one unit, fan status from another. Rules fed that don’t detect a fault. They detect noise, and noise gets tuned out — often by someone disabling the rule.
The Pattern Underneath All Five
Read those failures together and something specific emerges.
In nearly every case, the network told someone what happened. The FIRSTITEM flag was set. The sequence numbers skipped. The confirmed request went unacknowledged. The restart notification either fired or the device was one that couldn’t send it. The evidence exists, at the packet layer, at the moment of loss.
What doesn’t exist is a path from that evidence to the dashboard the operator is actually looking at. FDD platforms are built to reason about equipment behaviour, not about the transport that described it. So the protocol’s own error signalling terminates one layer below the only screen anyone checks.
Which produces the practical conclusion: you cannot validate an FDD deployment by looking at the FDD deployment. A dashboard with few alerts is equally consistent with a healthy building and with a data pipeline that quietly stopped delivering. Telling those apart requires reading the network itself — the job of OT monitoring tools that inspect traffic rather than the values traffic reports.
Two things follow that are specific to FDD, and that neither a BMS front end nor an analytics platform will do for you:
- Instrument data completeness as a first-class metric. Track expected-versus-received sample counts per point. A point delivering 60% of expected samples deserves an alert of its own. That is a network finding, and FDD will never raise it — the missing samples are precisely what it cannot see.
- Treat protocol-level loss signals as monitorable events. FIRSTITEM flags, sequence gaps, and unacknowledged confirmed requests are the earliest available warning that your analytics layer is being fed an incomplete picture. They are on the wire whether or not anyone is watching.
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. That inverts the instinct most operators have. 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 dropped 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
What is fault detection and diagnostics (FDD)? FDD is an analytics layer above the building automation system that continuously evaluates equipment data against expected behaviour to identify faults, diagnose likely causes, and estimate cost impact. Rule-based FDD applies encoded engineering logic; data-driven FDD flags statistical deviation from a learned baseline.
How much energy does FDD actually save? In the DOE Smart Energy Analytics Campaign, facilitated by Berkeley Lab across 104 organizations and more than 6,500 buildings, participants with FDD achieved a median 9% annual energy savings by the second year of installation, at roughly $0.24 per square foot, with a median simple payback of about two years.
How does an FDD platform get data out of a BACnet building? Three ways: polling Present_Value with ReadProperty or ReadPropertyMultiple, subscribing to change-of-value notifications with SubscribeCOV, or pulling historized Trend Log records with ReadRange. Most deployments use a supervisory device that aggregates these and passes data northbound over an API, MQTT, or a database connection.
What happens to FDD when the OT network degrades? It generally produces fewer alerts, not more. A stalled COV feed presents as an unchanging value. A polling gap prevents a rule from evaluating rather than triggering a warning. An overwritten Trend Log buffer loses records permanently. In each case the dashboard looks cleaner than reality does.
Why is a stalled COV feed particularly dangerous? Because many FDD rules detect faults by looking for variation — hunting, oscillation, short cycling. A feed that has stopped updating looks like a perfectly stable control loop, so those rules conclude the equipment is operating correctly.
If a controller reboots, does the FDD platform find out that its subscriptions are gone? Not reliably. BACnet’s Device Restart Procedure has a restarting device broadcast a notification to configured recipients, but the procedure is optional, MS/TP slave devices cannot support it, and the notification is an unconfirmed broadcast that can be dropped or fail to reach a subscriber on another network.
How do I tell a genuinely healthy building from a broken data pipeline? Not from the FDD dashboard, since both look the same there. Track expected-versus-received sample counts per point, and monitor protocol-level loss signals — ReadRange FIRSTITEM flags, Trend Log sequence gaps, and confirmed requests with no observed acknowledgment.
Can I detect these problems without changing my FDD platform? Yes. All of them appear in network traffic, independent of the analytics layer. That’s the argument for monitoring the OT network as its own system rather than inferring its health from application output.
