When we say a system “learns” a building’s behaviour, that isn’t a vague marketing phrase — it’s a specific, explainable process, and it’s worth seeing clearly before anyone hands over building operations to it.
The baseline: what counts as “normal”?
The first step isn’t fault-finding, it’s mapping normal operation. From a few weeks of measurement data, the system builds a weather-normalised baseline for every metered zone and system: how much energy a given zone uses at a given outdoor temperature, time of day, and day of week.
This step matters because a building’s consumption naturally fluctuates — a cold weekend needs more heating energy than a mild weekday, and that isn’t a fault, it’s expected behaviour.
What counts as a deviation?
Once the baseline exists, the system compares every new data point against that model, not against a fixed threshold. That distinction matters:
- A fixed threshold (“alert if consumption rises 20%”) produces false alarms on cold days and misses real faults on mild ones.
- A model-based comparison asks: at this time of day, at this temperature, is this consumption normal for this zone?
The goal isn’t to flag every fluctuation — it’s to flag only the ones that actually matter.
Specific fault types this reveals
In practice, this approach typically surfaces the following kinds of problems, often weeks or months before anyone would file a complaint:
- A stuck valve or damper — heating or cooling stays partially open, creating a continuous extra load without ever failing outright.
- Schedule drift — a timer gradually slips away from the actual usage pattern, often after maintenance or a software update.
- Gradually degrading efficiency — a unit’s performance slowly declines in a way no single day would reveal, but that adds up over weeks.
We wrote about these patterns, and why measurement tells a different story than a static document, in an earlier post.
What to expect from good anomaly detection
- It should be explainable: not just “there’s a problem,” but which zone, when it started, and how large it is.
- It should account for weather and calendar patterns — weekends, holidays, seasonal transitions.
- It should rank alerts by energy impact, not just statistical significance.
Why it isn’t a “black box”
It’s worth being clear: the goal isn’t to hand a building over to an unexplainable AI model. In BIS’s system, every alert traces back to the underlying measurement and the specific deviation from the baseline — the operator sees exactly why the system flagged something, not just that it did.
This whole process is one part of a larger, five-step cycle — we cover measurement, analysis, intervention, optimisation, and verification in more detail in this post.
If you’re curious what patterns the system would find in your building, get in touch.