Building Analytics and Fault Detection Software: Why Your BMS Alarms and Still Misses the Waste

Why building management systems miss the faults that cost the most

A chief engineer gets a call in July about a warm floor in a downtown office building. He finds an air handler running with the cooling valve at 40 percent and the reheat valves on eleven terminal boxes open, because a static pressure reset was disabled during a tenant fit-out in March and never re-enabled. The building has been heating and cooling the same air for four months. Nothing alarmed, because every sensor was inside its limits the entire time. Space temperature was fine. Discharge air temperature was fine. The system was doing exactly what it was told, expensively.

That is the shape of the problem. A building management system, whether it is Johnson Controls, Siemens, Honeywell, Schneider, Trane or a Niagara-based integration over a mix of them, alarms on thresholds and on equipment status. It tells you a fan failed or a temperature exceeded a limit. It does not tell you that the behaviour of a working system is wrong. Simultaneous heating and cooling, an economiser damper stuck at minimum position through a mild spring, a valve leaking by when commanded closed, a schedule override left in place after a weekend event, a control loop hunting and wearing out an actuator, a sensor drifting three degrees over two years: none of these trip a threshold, and all of them run for months.

The commercial products in this space exist because this gap is real. SkySpark is the established analytics platform and its rule engine is genuinely capable. Clockworks Analytics and KGS Buildings both bring strong fault libraries developed over years of practice. Switch Automation and Facilio wrap analytics into broader operations platforms. If you have fifteen buildings and no analytics capability, buying one of these through a good integrator is the right decision and this guide will not talk you out of it.

The reason operators at scale end up building is more specific, and it is rarely the rule engine. It is that the value of fault detection is realised in the operating model, not in the detection, and the operating model is yours. Which faults matter depends on your leases and your energy contracts. What happens when a fault is found depends on whether you self-perform, use a national service contractor, or bill tenants for above-standard service. Whether anything gets fixed depends on whether the finding lands in the technician's actual work queue with enough detail to act, and whether anyone checks that it stayed fixed.

Problem 1: nothing works until the points are normalised, and this is most of the project

Every building names its points differently, because every building was commissioned by a different contractor in a different year. One site has AHU1_SAT, another has AH-01.SA_TEMP, a third has a point called TEMP_3 that a technician labelled in a spreadsheet nobody kept. Units differ. Some points are Fahrenheit, some Celsius, a few are raw counts. Equipment hierarchy is implied by naming convention and the convention is not consistent within a single building, let alone across a portfolio.

What a custom build does: treat normalisation as an explicit pipeline with a human in the loop, not as a one-off configuration job. Automated suggestions from point names, units, value ranges and behaviour over time get a technician's confirmation, and the mapping is versioned so a controls upgrade that renames half a building's points is a diff rather than a crisis. This is the second honest application of machine learning in this category: clustering points by behaviour to propose what an unlabelled point probably is, and flagging when a mapping stops making sense. Expect normalisation to be roughly half the effort of onboarding a building, and treat any vendor or developer who says otherwise with suspicion.

Problem 2: getting the data out is a controls problem, not a software problem

Trend data lives in controllers and supervisory devices, often behind a building network with its own access rules, sometimes on hardware from the 1990s that will drop offline if polled too aggressively. BACnet over IP is straightforward, BACnet MS/TP over a serial trunk is not, Modbus devices carry no useful naming at all, and older LonWorks installations need their own gateway. Many portfolios have a Niagara supervisory layer that makes this considerably easier and some do not.

What a custom build does: put an edge collector at each site that buffers locally through network outages, polls at a rate the controls network tolerates, and reports its own health as monitored data. Data gaps must be first-class, because a rule that computes runtime hours over a period with missing data will produce a plausible wrong answer, and plausible wrong answers destroy the engineers' trust in the system faster than any other failure. Fifteen minute intervals catch most scheduling and setpoint faults. Control loop instability and valve behaviour need one to five minutes, which multiplies storage and should be applied selectively to equipment worth that resolution.

Problem 3: a fault list is not useful, a ranked queue with money attached is

Turn on a decent rule library across a portfolio and you will get thousands of faults in the first week. Most are real. Almost none will get fixed, because a facilities team with a fixed headcount cannot triage a thousand items, and the honest response to an unrankable list is to ignore it.

What a custom build does: attach an estimated cost and confidence to every fault, then present a queue ordered by that estimate. Simultaneous heating and cooling on a large air handler running continuously is worth more than a stuck damper on a small unit in a mild climate, and the queue should say so in currency the operations director recognises. Group related faults, since one failed sensor commonly generates twenty downstream symptoms and dispatching twenty work orders for one root cause is how a team loses faith in the tool. Suppress faults during known conditions such as commissioning or a planned shutdown, because false positives during known events cost more credibility than a missed fault.

Problem 4: detection without dispatch and verification changes nothing

The measurable outcome is not faults detected, it is faults corrected and still corrected a season later, which means the finding has to reach the person holding the wrench inside the system they already work in.

What a custom build does: create the work order in whichever maintenance system your operation actually uses, with the evidence attached, the point references included, and a suggested check. Then, and this is the feature that separates a system that pays for itself from a dashboard, automatically re-evaluate the fault condition after the work order closes and reopen it if the behaviour returns. Report on recurrence by fault type, by building and by service contractor. That last report is uncomfortable and it is the one that changes contractor behaviour.

Problem 5: the numbers have to survive a finance conversation

What a custom build does: separate the two claims cleanly. Estimated avoided cost per fault is a triage tool, useful for ranking work, and should be labelled as such everywhere it appears. Measured savings come from whole-building or system-level consumption normalised for weather and occupancy, compared against a baseline period, following an established measurement and verification approach. Those are different numbers with different confidence and conflating them is how programmes lose credibility. Building the normalisation properly, with degree days and an occupancy or production driver, is modest engineering work and it means the annual report is defensible.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A first release covering edge data collection across your controls vendors, point normalisation into a semantic equipment model with a human review workflow, a core fault rule library, cost-ranked triage and basic reporting runs $90,000 to $200,000 and ships in 14 to 20 weeks, typically proven on a pilot group of five to ten buildings before rollout. A full platform adding maintenance system integration with round-trip verification, weather-normalised measurement and verification, comfort correlation, contractor performance reporting and portfolio analytics runs $250,000 to $600,000 phased over 8 to 14 months.

What drives price up in this category: the diversity of controls vendors and vintages, since each additional protocol or gateway is real integration work, and buildings without a supervisory layer are markedly harder than buildings with one. Point count and polling interval, because storage and processing scale with both and one minute data on fifty thousand points is a different engineering problem from fifteen minute data on five thousand. Site network access, which is often the slowest item on the plan for reasons entirely unrelated to software. Central plant complexity, since chiller and boiler plant optimisation rules are far more demanding than air-side rules. And the state of your equipment records, because a portfolio without reliable equipment inventory will spend real time establishing what is actually installed.

Build versus buy, and when buying is right

Buy if you operate fewer than about 15 buildings. SkySpark through a competent integrator, or Clockworks Analytics or KGS Buildings with their existing fault libraries, will find your faults and cost far less than building. Buy if you have no in-house engineering capacity to act on findings, because in that case the constraint is not detection and adding a system will produce a longer list nobody works. Facilio or Switch Automation are reasonable if you want analytics inside a broader operations platform and are content with their operating model.

Build when several of these are true. Your portfolio is large enough that a percentage point of energy cost is a serious number. Your controls estate is heterogeneous enough that vendor onboarding pricing becomes a significant recurring cost. You self-perform maintenance and want findings inside your own dispatch workflow rather than in a separate portal your technicians will not open. You are a service provider delivering analytics to clients, in which case the platform is part of your offering and licensing someone else's is a margin and differentiation question. Or you have tried a packaged deployment and it stalled at the point where thousands of faults met a team of six, which is the most common story we hear in this category.

Our position: the rule engine is not the hard part and it is not where the value is. The value is in normalisation you own, prioritisation tuned to your economics, and a closed loop into your maintenance operation. Those three are exactly the parts a packaged product cannot fit to your business without you doing most of the work anyway.

How to choose a developer for building analytics software

Ask them how they would handle point normalisation across three controls vendors and four naming conventions. If they do not mention a semantic tagging standard such as Haystack or Brick, versioned mappings, and a human confirmation step, they will hardcode a convention and it will break at building eleven.

Ask how a fault gets prioritised. The answer should involve estimated cost using your tariffs and equipment characteristics, grouping of related symptoms, and suppression during known conditions. A severity field with high, medium and low is not prioritisation.

Ask what they have integrated on the controls side and on the maintenance side. BACnet over IP, BACnet MS/TP, Modbus, a Niagara station and an OPC connection are different problems, and a maintenance system round trip that reopens a fault when behaviour returns is different from a one-way work order export. Ask for named systems.

Ask who owns the code and the point mappings, in writing, before kickoff. You should own the repository, the infrastructure accounts, the normalised model and the right to hire anyone else to continue. At Digital Heroes that is the default from the first commit. The normalised model of your portfolio is years of engineering knowledge encoded, and it is far more valuable than the rules that run on top of it.