Building Analytics and Fault Detection Software Problems: The 7 That Waste Energy and Trust

Why does deploying the whole rule library across the whole portfolio go wrong so often?

The scope failure that defines this category is doing everything at once: connect every building, tag every point, switch on the full rule library, and hand the estate to an energy manager. It sounds like ambition and it behaves like sabotage. Every automation vendor and controller generation in your portfolio is a separate integration risk, so a portfolio wide connection phase means the schedule is set by your worst building rather than your typical one. And a full rule library on an untuned estate produces thousands of findings on day one, most of which are either duplicates or design intent.

The reason this matters more here than in most software is who the user is. A building engineer has a day job and a radio. He will give your tool three or four chances. Generic rules assume a sequence of operations your plant may not run: a rule for economiser faults assumes a particular economiser strategy, a simultaneous heating and cooling rule assumes a reheat configuration, a chiller rule assumes staging logic your plant does differently. When those misfire, he does not report a false positive. He quietly stops looking, and no dashboard quality recovers that.

The fix is to choose 10 to 15 buildings that genuinely represent your estate, and to start with twenty rules that are right rather than two hundred that are noisy. Precision beats coverage every time in the first six months. Tune per site, add suppression so a fault does not re fire every fifteen minutes, and build an explicit feedback path where an engineer marks a finding as design intent and the rule adjusts. Then use the measured result from those buildings, including cost estimates the finance director accepts, to fund the rollout. In our delivery experience a focused first release covering two automation vendors, point normalisation for a defined building set, a rule engine with a tuned starter set and a triaged fault queue runs $95,000 to $200,000 and ships in 14 to 22 weeks.

What goes wrong with point normalisation and tagging?

Point normalisation is the largest single task in almost every deployment and the one most consistently underestimated, because it looks like data entry and behaves like archaeology. Across a real portfolio you will find several automation vendors, multiple controller generations, and point names invented by whichever contractor commissioned each site. The same measurement appears as SAT in one building, SA_TEMP in another, DischAirT in a third. Units are inconsistent. Trending is patchy and set at different intervals site by site. Equipment relationships, meaning which terminal units are served by which air handler, exist in a drawing rather than in data.

Three specific traps recur. The first is assuming a tagging standard does the work for you. Project Haystack and Brick Schema give you a vocabulary and a model for equipment relationships, and using one is far better than inventing your own, but applying a standard to tens of thousands of points in an estate that grew by acquisition is a project with real hours in it. The second is normalising point by point, which does not finish. The third is treating tagging as a one time exercise, when in reality every retrofit and controller replacement adds points that arrive untagged and silently fall out of your rules.

The fix is semi automated normalisation with bulk human confirmation. Name pattern matching and clustering get you a long way, because each commissioning contractor was internally consistent even when they disagreed with every other contractor, so a person confirms a cluster of four hundred points rather than four hundred individual points. Make the equipment model explicit so a rule written once against an air handler applies to every air handler. Then treat tagging as an ongoing process with an intake queue for new and changed points, and report coverage as a live metric, because a rule that silently stops covering a building is worse than no rule at all.

Why do building automation connectors and trend collection break after launch?

Connectivity is where optimistic project plans meet an estate. BACnet over internet protocol is straightforward. Older serial estates, proprietary drivers, and controllers sitting behind a gateway are not, and that is exactly where an acquired portfolio hurts. Connector coverage in every commercial product is excellent for mainstream current systems and thinner as you go back through controller generations, so the buildings that most need attention are frequently the hardest to reach.

After launch the failures are rarely dramatic. A controls contractor performs a retrofit and renames points, so your rules keep running against names that no longer exist and report nothing, which reads as a healthy building. A network change or a firewall rule update severs a site and the data simply stops arriving. A site that only ever offered live values rather than stored trends loses history during an outage, and nobody notices until an analysis needs the period that is missing. Corporate and institutional information technology security review is a genuine schedule item rather than a formality, and access granted once can be revoked during a security programme without anyone telling the energy team.

The fixes are unglamorous and they hold. Monitor data arrival per site per hour and alert on absence, because in this category silence is the dangerous failure and an empty rule result looks identical to a building with no faults. Detect point set changes automatically and raise them into the tagging queue rather than letting them disappear. Collect and store trends yourself where a site only offers live values, since analytics cannot run on data that was never retained. Get information technology into the project at week one rather than at deployment. And publish a coverage dashboard that shows which buildings and which equipment are actually being analysed today, so nobody mistakes a broken connector for a well run plant.

What happens when the work order and verification loop is not covered?

This is the gap that turns a working analytics platform into a report nobody reads. The fault list is not the deliverable. Corrected equipment is. Between the two sits a workflow that most implementations underbuild: prioritising faults by estimated cost and comfort impact, deciding whether the fix is a maintenance job or a controls change, raising it in whatever maintenance system your team actually uses, giving the technician the trend data that shows the fault, and then verifying that the behaviour changed.

The verification step is the one almost everyone skips, and it is where credibility is won or lost. A fault that reappears three weeks after a work order was closed tells you the fix did not hold, and only an automatic re check catches it. Without that, faults quietly recur, the same finding is raised four times a year, and the engineering team concludes the tool generates noise rather than outcomes.

The second half of this gap is cost attribution. An engineer knows the damper is stuck. A finance director wants a number. Without one, faults compete for maintenance budget on the basis of who complained loudest, and analytics never gets a second phase.

The fix is to build fault to work order with the trend evidence attached and a scheduled re check after the close date that either confirms the fix or reopens the finding. Alongside it, estimate cost honestly: a comparison between observed consumption and a reasonable counterfactual for that equipment under those conditions, priced at your actual tariff including demand charges, with assumptions visible and reconciled against metered and billed consumption at building level. Any tool that hands you a precise savings figure with no stated assumptions is inviting a challenge from finance that it will lose.

Should you build custom or configure what you already own?

Plenty of portfolios should buy rather than build, and it is worth saying so plainly. A modest estate on one mainstream automation vendor, with no unusual plant and no internal appetite to develop rules, will get further faster with a packaged product, and the licensing will be affordable at that point count. If what you want is findings delivered rather than a system to run, an analyst backed offering such as Clockworks Analytics is a sensible purchase and building would be an expensive way to acquire an outcome you can subscribe to.

Before building, also exhaust what you already own. Many estates have a building automation system whose trending was never configured, whose alarm thresholds were set by a commissioning contractor to avoid blame and never revisited, and whose dead sensors have never been removed. Cleaning that up is weeks of work rather than months and it improves every subsequent option. SkySpark in particular is a capable analytics engine and will do sophisticated rule work if someone is genuinely committed to developing and maintaining rules in it, so the question is less whether the product can do it and more whether you have the person who will.

Build when the economics or the fit break. When point count makes per point licensing untenable across five years, and it keeps growing because adding points is what makes analytics better. When a meaningful share of your estate uses controllers no product connects to cleanly. When your plant runs sequences the rule libraries misread and false positives have already killed one deployment. When fault data needs to join systems the products do not reach. Or when analytics is one part of a wider operations platform you already own. Building here does not mean writing a time series database. It means assembling proven components and putting your equipment model, your rules and your workflow on top.

How do hidden costs get into the quote?

The costs that surprise people in this category are almost never the analytics engine.

The first is that price scales with the number of automation vendors and controller generations rather than the number of buildings. The twentieth building on a familiar system is cheap. The first building on an unfamiliar one is not. A quote priced per building has priced the wrong unit.

The second is trend availability. A site that only exposes live values needs a collection layer built and running before any analysis can start, and that is infrastructure with an operating cost, not a feature.

The third is information technology and security review. In corporate, healthcare and higher education estates this is a real schedule item with its own approvals, and projects routinely lose six to ten weeks there while nobody is coding.

The fourth is meter and submeter coverage. Cost attribution that reconciles to the utility bill requires metering that many portfolios do not have, and installing it is capital work on a different timeline.

The fifth is rule depth. Central plant rules involving chillers, boilers, pumping and staging are considerably more involved than terminal unit rules, and a quote that treats rules as a uniform quantity has estimated the easy ones.

The sixth is the ongoing tagging of new and changed points, which is a permanent low level cost rather than a project phase. Ask bidders to price vendors, protocols, trend collection and rule depth separately, and to name the specific controller generations at your worst site rather than your best one.

What separates a build that works from one that fails here?

The deployments that work look different from the start, and the differences are testable before you sign.

Ask how they would normalise tens of thousands of points across four vendors. If the answer is manual tagging, the project stalls at building six. If it involves pattern clustering with bulk human confirmation and a standard vocabulary such as Haystack or Brick, they have done this before.

Ask how they prevent false positives. The right answer includes tuning per site, suppression windows and a feedback loop where an engineer marks design intent. If the pitch is the size of the rule library, they are selling volume where you need precision.

Ask what they have actually connected to, by vendor and controller generation, and ask about your worst building rather than your flagship. Knowing whether a building runs standardised high performance sequences of the kind described in ASHRAE Guideline 36 changes how rules are written, because where those sequences are in place rules can be written against a documented intent and applied broadly, and where they are not the rules have to be written against what that specific plant is supposed to do.

Ask who acts on a fault. A deployment with no named person on the maintenance side, no route into the work order system and no verification step produces findings and no savings, and that is the most common way these projects fail while appearing to succeed.

And settle ownership in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. The equipment model and the tuned rule set you accumulate over several years is a genuine portfolio asset, and it should never sit inside a licence you have to keep renewing in order to read it.