Buildings rarely fail loudly. A leaking valve, a stuck damper, a drifting sensor or an economizer running backwards will not raise an alarm — the space stays roughly comfortable while the plant works far harder than it should. The cost shows up on the utility bill and in equipment life, months later, attributed to nothing in particular.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- Equipment templates and tagging — apply diagnostics across a fleet without hand-configuring each unit.
- Streaming rule and model execution — faults detected continuously, not in a quarterly review.
- AHU, VAV, RTU, chiller and boiler fault libraries — the failure modes that actually recur.
- Confidence and persistence scoring — a fault seen once is noise; seen for a week it is real.
- Trend evidence visualization — the data behind the finding, not just the finding.
- Likely-cause and diagnostic guidance — what to check first when you get there.
- Operational and energy impact estimation — what this fault is costing.
- Workflow integration and resolution tracking — findings become work orders and get closed.
Evidence, Not Alerts
FDD tools fail when they produce more alerts than anyone can action — teams learn to ignore them, exactly as they do with over-sensitive alarms. Confidence scoring, persistence and cost impact exist so the output is a short ranked list a technician can trust, with the trend data attached to justify the trip.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- Building Automation Integration Services — Fault detection needs trustworthy point data first – see BAS integration services.
What the Suite Needs From the Building Before It Can Say Anything
Diagnostics are inference over recorded behavior. A rule that decides an economizer is running backwards needs mixed air, return air and outside air temperature at the same timestamps, plus the damper command and, ideally, position feedback, at a logging interval short enough to see the sequence it is trying to observe. If one of those points exists on the graphic but was never set up for history collection, or is trended more slowly than the sequence moves, the rule cannot evaluate the condition honestly. This is the ordinary state of most stations: plenty of live points, far fewer trended ones.
The second dependency is identity. Knowing that a group of points belongs to one AHU, and which point plays which role, is what turns a point list into something a template can bind to. Naming conventions differ per site, per integrator and often per phase of the same building, so this is rarely automatic. Tagging is the work that resolves it, and it is worth doing on its own terms because it is what makes any fleet-wide analysis possible, not only this one.
Partial coverage is the normal case, not the exception, so the design treats it as something to report rather than route around. If an AHU has no damper position feedback, the subset of rules that depend on it cannot run for that unit, and the useful output is a plain statement that those checks are unavailable there. The alternative, quietly skipping them, produces a clean report that overstates what was actually examined.
How the Fault Libraries and Templates Are Designed
The design binds equipment to a type rather than configuring rules unit by unit. Bind an air handler to the AHU type once and the library defined for that type is intended to apply without per-unit rule authoring, with the differences between units carried as parameters: whether there is a return fan, whether there is an economizer, single duct or dual duct, chilled water or DX. The reason for structuring it this way is arithmetic. A campus with a few hundred terminal units cannot be hand-configured, and any approach that requires it will be configured once and then never maintained as equipment is replaced.
Rules are intended to be gated on operating state before they evaluate anything. A cooling coil not meeting setpoint during morning warmup is not a fault, and a unit commanded off is not underperforming. State gating means checking occupancy, mode, command status and override before a rule is allowed to reach a conclusion. Override matters twice over: a point left in manual silently disables every rule that depends on it, so the design reports the override itself rather than suppressing the affected checks without saying so.
Enumerated fault libraries are the deliberate choice over generic anomaly detection. An anomaly detector can say a unit is behaving unlike itself; it cannot say which mechanical thing to go look at, and unlike itself is not the same as wrong, which is why schedule changes and unusual weather tend to light it up. Naming faults and tying each to a mechanism gives an output a technician can act on. The cost of that choice is real and worth stating: the suite would only find conditions someone took the trouble to define, and a fault nobody enumerated stays invisible.
From Finding to Closed Work Order
A finding is designed to carry what a work order needs rather than what a dashboard needs. That means the equipment named the way maintenance names it, the rooftop unit serving the west wing rather than a station point path, when the condition first appeared and how long it has held, and the impact estimate that positions it against everything else open. Timing is part of the record, not a display detail, because a condition that started the week the sequence was modified is a different problem from one that has been running since commissioning.
The design intent is that findings leave the tool and land in whatever queue the maintenance team already works from. A private queue that only the FDD tool knows about is a queue that gets abandoned, and the loss is not only the work that never happens. The resolution never comes back either, and without knowing whether a finding turned out to be real, confidence scoring has nothing to correct itself against and no way to improve.
Closure feedback is therefore designed as a two-way link. A technician marking a finding resolved, or marking it as not a fault, is recorded against that equipment, so a fault that reappears on the same unit after a repair reads as either a repair that did not hold or a rule that is wrong. Both are worth knowing and neither is visible without the return path. Known conditions that cannot be repaired yet, a failed sensor waiting on a part or a unit already scheduled for replacement, need an explicit suppression with an owner and an expiration date; otherwise the suppression happens informally and nobody can see later what was set aside or why.
When Fault Detection Is Not the Right Choice
Since the suite is in development, this is reasoning about where it is meant to fit rather than guidance on a decision anyone can make today. It is still the more useful half of the design conversation, because several common situations are better served by something simpler.
A site with no building automation beyond thermostats has nothing to read, and a handful of packaged rooftop units can be walked and inspected directly by a technician who knows them. Where the problems are already known, the constraint is usually not detection: if the team can already name the units that need attention and the limit is budget or crew hours, the suite would surface more items than can be worked, without changing which ones get fixed first. Buildings mid-renovation are another poor fit, because rules gated on sequences that are themselves being rewritten would report on the commissioning work rather than on the equipment. Better to let the sequences settle first.
There is also a class of problem that detection would find once and then have nothing left to do: a schedule that was never corrected after a tenant moved, a setpoint someone changed during a complaint call, a sequence that was never commissioned properly. Those are real and often expensive, but they are one-time fixes rather than a case for continuous monitoring. The suite is designed to rank faults that have not been found yet and to keep finding the ones that recur; where the list is short, known and static, a review of the schedules and setpoints would answer the question with far less machinery behind it.
Frequently Asked Questions
What is the HVAC Fault Detection and Diagnostics Suite, concretely, and what is it not?
It is analysis software designed to read trended history out of an existing building automation system and identify named mechanical and control faults in HVAC equipment. It is not a control layer: the design has it reading history and writing nothing back, so it cannot change a setpoint, release an override or command equipment. It is also not a replacement for the BAS or for a maintenance system; it sits beside both and depends on both. It is a product concept in active development, not something that can be deployed today.
What does it connect to, and what has to already exist on our side?
The design targets a Niagara station that is already collecting history for the points the diagnostics depend on, with tagging or an equipment model that says which points belong to which unit and what role each one plays. The connection is read access to that history, intended as a read-only account scoped to the histories and equipment in scope. Sites where points exist but were never set up for history collection, or are only retained for a few days, would need that changed before any rule could evaluate a condition over a useful window. Nothing in the design assumes new field devices or added sensors, only that the ones already installed report into the station.
Why is Niagara the first platform?
Because a Niagara station already provides the pieces diagnostics depend on: history collection, a tagging and equipment model, and BQL for querying that history, so the data model does not have to be rebuilt outside the BAS. Writing the first libraries against a real station also keeps the rules honest, since each fault has to be expressed against actual point structures rather than an idealized schematic that no building matches. The fault logic itself is not Niagara-specific; the first implementation is.
How is installation and rollout designed to proceed?
In four steps, in order. First, read access and a history inventory: which points exist, which are actually trended, at what interval and over what span. Second, equipment typing, which is binding units to templates and confirming which point plays which role; this is where most of the effort sits, because naming and tagging differ site by site. Third, a quiet period where rules run against recorded history and the output is reviewed with someone who knows the building, before anything is presented to a technician as a finding. Fourth, connecting the surviving findings to the queue the team works from. This is the designed sequence, not a description of engagements underway.
How would it integrate with the maintenance or ticketing system we already run?
By pushing findings into it as work items carrying equipment identity, the observed condition, the timing and a link back to the evidence, rather than asking technicians to work from a second screen. The design assumes your CMMS or ticketing system remains the system of record for the work itself: assignment, status and closure live there, and the suite reads closure back rather than owning it. Sites without a maintenance system still have to name a destination, whether that is a shared mailbox, a spreadsheet or a scheduled report, and that decision is worth making before rollout rather than after.
Where does our data go, and what stays under our control?
The station remains the source of the trend history; the analysis reads it rather than replacing or relocating the record of record. Access runs on credentials you issue and can revoke, scoped to the histories and equipment you grant, and nothing outside that scope is readable. Where the analysis runs, what is retained and for how long are being designed as customer decisions rather than fixed defaults, because building data and occupancy patterns are sensitive on some sites and unremarkable on others. These are commitments in the architecture being built, not descriptions of a running system.
What do we have to provide or decide?
An equipment list with a point-to-equipment mapping, or the willingness to have one built during typing, since that mapping is what everything else binds to. A decision about which faults matter on your equipment, because a library covers more conditions than any single site cares to chase. And an owner for the output: a named person or role who receives findings and decides what becomes work. Impact estimation also depends on inputs only you hold, such as your utility rate and actual operating schedule; without them, ranking can only be relative rather than expressed in cost.
Can we buy it, pilot it or schedule a deployment now?
No. It is a product concept in active development: there is no release date, and there are no existing installations to reference. The fault libraries, the confidence model and the workflow connections are all still being built, and the design decisions described here can change while that work is underway.