Building Automation Fault Detection Software Problems: The 7 That Stall a Rollout, and How to Avoid Them

Why does point normalisation get scoped as configuration when it is half the project?

The largest scope failure in this category is treating normalisation as setup. It reads like setup: map the points, then run the rules. What it actually is, is establishing that a controller point called TEMP_3 is the discharge air temperature of a specific air handler serving specific terminal units in a specific zone, across a portfolio where every building was commissioned by a different contractor in a different year. Names differ, units differ, some points are Fahrenheit and some Celsius, a few are raw counts, and equipment hierarchy is implied by a naming convention that is not consistent inside a single building.

No rule can run until that meaning exists, which is why a project that under scoped it stalls in a way that looks like the rules being wrong. They are not wrong. They are running on a model that describes a building nobody has.

The fix is to treat normalisation as an explicit pipeline with a person in the loop rather than a one time configuration job. Automated suggestions from point names, units, value ranges and behaviour over time get a technician's confirmation, and every mapping is versioned so a controls upgrade that renames half a building is a difference to review rather than a crisis. Insist on a recognised tagging standard such as Haystack or Brick, and budget normalisation at roughly half the effort of onboarding each building. A vendor or developer who says otherwise has either not done it or is not counting it.

What goes wrong when historical trend data is migrated into a new platform?

Trend history is the asset that makes the first month useful, because a rule needs a baseline and a baseline needs a past. Moving it is where analytics projects lose their credibility early, and the reasons are unglamorous. Timestamps arrive in local time, in coordinated universal time, or in whatever the installer configured, and daylight saving transitions produce duplicated and missing hours that nothing downstream questions. Older data has often been rolled up to save space, so a point that reads every five minutes for the last year reads hourly before that, and any rule computing runtime or cycling over the boundary produces a plausible wrong answer.

Plausible wrong answers are the specific danger. An engineer who checks three findings and disproves two stops checking, and no amount of later accuracy recovers that.

The fix is to make data gaps and interval changes first class rather than invisible. Store the sampling interval with the data, refuse to evaluate a rule across a period where the underlying data does not support it, and say so on the finding rather than producing a number quietly. Normalise timestamps to a single reference at ingest while keeping the original, so a timezone error is correctable rather than baked in. Then validate against something known: pick two buildings, take a month where the chief engineer remembers what happened, and check that the system tells that story back.

Why do BACnet, Niagara and maintenance system integrations break after launch?

Because you are attached to systems that change without telling you. A controls contractor performs an upgrade and half a building's points are renamed, which breaks mappings silently rather than loudly. A site network is re-segmented and the edge collector loses its route. Older serial trunks drop offline when polled too aggressively, and the fix a site technician applies is to unplug something. On the maintenance side, a one way work order export keeps working perfectly while delivering no value, because nothing ever comes back to say whether the fault was corrected.

The characteristic failure here is a system that appears healthy while going blind. Missing data does not raise an error, it just stops arriving, and a building with no faults looks like a good building.

The fix is to monitor the collector as an asset in its own right, alerting on the absence of expected data per building and per point group rather than on failures. Put a data freshness figure on every dashboard, so nobody reports savings from a site that stopped reporting three weeks ago. Version your mappings so a renaming event produces a review queue. And make the maintenance integration a round trip: the work order carries the evidence and the point references out, and the closure event triggers a re-evaluation of the fault condition on the way back.

What happens when prioritisation and verification are not covered?

This is the gap that ends deployments, and it is not a detection problem. Without prioritisation, the queue is unusable. Simultaneous heating and cooling on a large air handler running continuously and a stuck damper on a small unit in a mild climate appear as two rows, and the team works whichever is nearest the top. Without grouping, one failed sensor generates twenty downstream symptoms and twenty work orders, which is how a team decides the tool is wasting their time.

Without verification, you cannot tell corrected from closed. A work order closes, the fault is marked resolved, and the behaviour returns within a season because the fix addressed a symptom. Nobody knows, because nothing looked again.

The fix is to attach an estimated cost and a confidence to every fault using your tariffs and equipment characteristics, rank the queue by it, and label the number as an estimate everywhere it appears. Group related symptoms to one root cause. Suppress findings during commissioning and planned shutdowns, because false positives during known events cost more credibility than missed faults do. Then re-evaluate automatically after closure and reopen when behaviour returns, and report recurrence by fault type, by building and by service contractor. That last report is uncomfortable and it is the one that changes contractor behaviour.

Should you build custom or configure what you already own?

Buy if you operate fewer than roughly fifteen 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 a build. Their rule content reflects years of practice you would otherwise develop from scratch, and reproducing it is not where your money goes furthest.

Buy, and fix your operating model instead, if you have no in house engineering capacity to act on findings. In that case detection is not your constraint and adding a system produces a longer list nobody works. Switch Automation and Facilio are reasonable if you want analytics inside a broader operations platform and their operating model suits you.

Before commissioning anything, ask your existing platform vendor in writing what the product does that you are not using. A share of the gaps we are asked to fill turn out to be unconfigured: cost parameters never entered, grouping never set up, maintenance integration licensed but never connected.

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 per building onboarding pricing has become a significant recurring cost. You self perform maintenance and want findings inside your own dispatch workflow rather than a portal your technicians will not open. Or you deliver analytics to clients as part of your own service offering, which makes the platform a margin and differentiation question rather than a tooling one.

How do hidden costs get into the quote?

The engineering is rarely what moves the number. These are.

• Controls diversity and vintage. Each additional protocol or gateway is real integration work, and buildings without a supervisory layer are markedly harder than buildings with one.
• Point count multiplied by interval. One minute data on fifty thousand points is a different storage and processing problem from fifteen minute data on five thousand, and quotes rarely state which was assumed.
• Site network access. Getting a collector onto a building network is often the slowest item on the plan, for reasons entirely unrelated to software.
• Central plant rules. Chiller and boiler plant analytics are considerably more demanding than air side rules, and a quote covering air side only should say so.
• Equipment records. A portfolio with no reliable equipment inventory spends real time establishing what is actually installed before any rule can be trusted.
• Rule tuning after launch. Thresholds need adjustment per building for the first few months, and if that is nobody's job the false positive rate stays where it started.

What separates a building analytics build that works from one that fails?

Ask a prospective developer how they would normalise points across three controls vendors and four naming conventions. If the answer does not mention a semantic tagging standard, 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, it is a label.

Ask what they have integrated by name on both sides. BACnet over internet protocol, BACnet over a serial trunk, Modbus, a Niagara station and a connection to your maintenance system are different problems, and a round trip that reopens a fault when behaviour returns is different from a one way export.

Then settle ownership before kickoff, covering the repository, the infrastructure accounts and the normalised model. The model matters more than the rules, because it is years of engineering knowledge about your specific buildings written down, and rebuilding it elsewhere would cost most of the original project. Successful rollouts are also phased: five to ten buildings proven end to end, with faults reaching technicians and closing, before anyone onboards the rest.