Building Analytics and Fault Detection Software: Why 4,000 BAS Alarms a Day Tell You Nothing

Why a portfolio can waste energy for months in plain sight

An energy manager responsible for 60 buildings opens the building automation front end on a Monday. There are several thousand active alarms. Most are duplicates of each other, many are from sensors that failed years ago and were never removed, and a large share are threshold alarms configured by a contractor at handover who set them conservatively so nobody would blame him. Nobody triages this list because it is not triageable. It has been ignored for so long that ignoring it is now the documented process.

Meanwhile, in one of those buildings, an air handling unit has been heating and cooling the same air at once since the spring, because a valve is passing and a damper is stuck at minimum position. No alarm fires, because no single point is out of range. Everything is doing what it was told. The building is comfortable. The bill is high, and it has been high for long enough that it looks normal on a year over year chart.

This is the shape of the problem in almost every portfolio we have worked in. The waste is not dramatic failure, it is correct looking equipment running an incorrect sequence, plus schedule overrides someone applied for a weekend event in February that nobody removed. Alarms cannot find these because alarms watch points. Faults live in relationships between points.

Problem 1: your points have no common language and that is the actual project

Across a real portfolio you will find several automation vendors, multiple generations of controller, and point names invented by whichever contractor commissioned each site. The same measurement might be called SAT, SA_TEMP, DischAirT, or AHU3.SAtmp depending on the building. Units are inconsistent, and trending is patchy and set at different intervals site by site. Equipment relationships, meaning which VAV boxes are served by which air handler, exist in a drawing rather than in data.

No analytics can run before that is fixed, and no product fixes it for you. Tagging standards exist and they help. Project Haystack and Brick Schema both give you a vocabulary and a model for equipment relationships, and using one is much better than inventing your own. But applying a standard to 40,000 points in an estate that grew by acquisition is a data project with real hours in it, and any vendor implying otherwise is selling you the demo rather than the deployment.

What a good build does: an ingestion layer per protocol and vendor, then a normalisation and tagging workflow that is semi automated. Name pattern matching and clustering get you a long way, since contractors are internally consistent even when they are inconsistent with each other, and a human confirms in bulk rather than point by point. Then the equipment model is explicit, so a rule can be written once against an air handler and applied to every air handler in the estate.

Problem 2: generic rule libraries misfire on real equipment

Every fault detection product ships a rule library. The rules are reasonable and the failure mode is not that they are wrong, it is that they assume a sequence of operations your building may not run. A rule for economiser faults assumes a particular economiser strategy. A simultaneous heating and cooling rule assumes a reheat configuration. A rule for a chiller assumes staging logic your plant does differently.

The result is a false positive problem, and false positives are fatal in this category. An engineer who investigates three faults that turn out to be design intent will stop opening the tool, and no amount of dashboard quality recovers that trust.

ASHRAE Guideline 36 is worth knowing here because it defines standardised high performance sequences for common HVAC systems, and where a building actually runs those sequences, rules can be written against a known intent. Where a building does not, and most existing buildings do not, the rules have to be written against what that plant is genuinely supposed to do, which requires reading the sequence of operations and talking to the person who maintains it.

What a good build does: a rule engine where rules are parameterised by equipment type and tuned per site, with suppression logic so a fault does not re fire every fifteen minutes, and an explicit feedback path where an engineer marks a fault as design intent and the rule adjusts. Precision matters more than coverage. Twenty rules that are right beat two hundred that are noisy.

Problem 3: what SkySpark, Clockworks, Switch, KODE Labs and Facilio actually do

These are real products and several are very good. SkySpark has a strong analytics engine with deep roots in the Haystack tagging model and it will do sophisticated rule work if someone is committed to developing and maintaining rules in it. That last clause is the point: it is a platform, usually delivered through a systems integrator, and the outcome depends heavily on who is holding it. Clockworks Analytics pairs fault detection with an analyst service, which suits organisations that want findings rather than a tool. Switch Automation, KODE Labs and Facilio each combine data integration with dashboards, workflow and operations features, and they are credible choices for a portfolio that wants a packaged operating layer.

The honest constraints are consistent across all of them. Connector coverage is excellent for mainstream systems and thinner as you go back through older controller generations, which is exactly where an acquired estate hurts. Licensing is commonly related to point count, so a large portfolio with dense trending faces a cost curve that keeps growing as you add the points that make analytics better. The tagging and equipment modelling work is yours regardless of the product. And the rules that matter most are the ones specific to your plant, which means you are doing rule development inside someone else's environment.

None of that makes buying wrong. It means the buy decision should be made on total cost across five years including point growth, on whether your team can develop rules in that environment, and on whether the connectors reach your worst buildings, not on a demo of a good looking dashboard.

Problem 4: a fault that does not become a work order is a report nobody reads

The fault list is not the deliverable. The deliverable is corrected equipment. Between those two sits a workflow that most implementations underbuild: prioritising faults by estimated cost and comfort impact, deciding whether it 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 verifying afterwards that the behaviour changed.

That last step is the one almost everyone skips, and it is where credibility is won. A fault that reappears three weeks after a work order was closed tells you the fix did not hold, and only automatic verification catches it. In the building analytics work we have delivered, verification is usually what converts an engineering team from sceptical to committed, because it proves the tool is measuring outcomes rather than generating findings.

What a good build does: fault to work order with the evidence attached, and a scheduled re check that reopens or confirms based on the data after the close date.

Problem 5: nobody can put a number on a fault, so nothing gets funded

An engineer knows the damper is stuck. A finance director wants to know what it costs. Without a cost estimate, faults compete for maintenance budget on the basis of who complained loudest.

Estimating fault cost honestly is possible and it needs care. It is a comparison between observed consumption and a reasonable counterfactual for that equipment under those conditions, priced at your actual tariff including any demand charges. It should be presented as an estimate with its assumptions visible, and it should reconcile at building level against the utility bill rather than living in a separate world. Any tool that hands you a precise savings figure with no visible assumptions is inviting a challenge from your finance team that it will lose.

What a good build does: a defensible estimate per fault, aggregation to building and portfolio level, and reconciliation to metered and billed consumption so the numbers survive scrutiny.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release covering ingestion from two automation vendors, point normalisation and tagging for a defined building set, a rule engine with a tuned starter rule set, and a triaged fault queue runs $95,000 to $200,000 and ships in 14 to 22 weeks. A full platform adding cost attribution, utility reconciliation, maintenance system integration with verification, additional protocols and vendors, and portfolio reporting runs $240,000 to $650,000 phased over 9 to 16 months.

What drives price up specifically here: the number of automation vendors and controller generations, not the number of buildings, since the twentieth building on a familiar system is cheap and the first building on an unfamiliar one is not. Whether trend data exists at all, because a site that only offers live values needs a collection layer before analytics can start. Network access and IT security review, which in corporate and institutional estates is a genuine schedule item rather than a formality. Meter and submeter coverage. And rule depth, since central plant rules are considerably more involved than terminal unit rules.

What keeps price down: choosing 10 to 15 buildings that represent your estate, proving faults and their cost estimates there, and using that result to fund the rollout instead of buying a portfolio wide deployment on a promise.

Build versus buy, and when buying is right

Buy if you have a modest estate on one mainstream automation vendor, no unusual plant, and no internal appetite to develop rules. A packaged product will get you further faster and the licensing will be affordable at your point count. Buy the service model, as with an analyst backed offering, if you want findings delivered rather than a system to run.

Build when the economics or the fit break. Specifically: when point count makes per point licensing untenable over five years, when a meaningful part 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 you need fault data joined to systems the products do not reach, or when analytics is part of a wider operations platform you already own. Note that building does not mean writing a time series database. It means assembling proven open components and putting your equipment model, your rules, and your workflow on top.

How to choose a developer for building analytics software

Ask them how they would normalise 40,000 points across four vendors. If the answer is manual tagging, the project will stall 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. BACnet over IP is straightforward, and older serial estates, proprietary drivers, and controllers behind a gateway are not. Ask for specific vendors and specific controller generations, especially for your worst site rather than your best one.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts, and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and in this category the equipment model and rule set you build up over years is a genuine asset that should never sit inside someone else's licence.