Building Analytics Basics

The clearest way to think about building analytics is as a ladder of four rungs, each harder than the last and each worth more. Descriptive analytics answers what happened: the dashboards, trends and reports that show yesterday's energy, this hour's temperatures, last month's peak demand. Almost every BMS gives you this, and most buildings never climb past it. Diagnostic analytics answers why: it correlates and drills down, so instead of just seeing the energy spike you find it coincided with a chiller short-cycling. Predictive analytics answers what will happen next: forecasting tomorrow's load, this week's occupancy, or when a bearing is likely to fail. Prescriptive analytics answers what to do about it: recommending or automatically taking the action - reset this setpoint, pre-cool now, schedule this repair.

The value rises as you climb, but so does the difficulty and the trust required. A useful discipline is to know which rung a given tool actually sits on. A great many products sold as AI-driven or predictive are, honestly, dressed-up descriptive dashboards. There is nothing wrong with descriptive analytics - a clear, timely chart is genuinely useful - but you should not pay for a crystal ball and receive a rear-view mirror.

The rungs also build on one another, which is why so few buildings reach the top. You cannot sensibly predict a load without first being able to describe it and diagnose why it behaves as it does, and you certainly should not let software prescribe an action it cannot explain. Each rung demands more data, more modelling and more trust than the one below - and, critically, more organisational maturity: someone to own the insight and act on it. Many buildings stall not because the higher analytics is technically out of reach, but because nobody is set up to use a prediction if they had one. A realistic goal is to climb one honest rung at a time, proving value at each before reaching higher.

Under the hood, building analytics runs on two broad engines: rules and models. A rule is logic you write down: if supply-air temperature is above 14 C while the cooling valve is open, flag a fault. A model is a pattern learned from data: feed a few months of history to an algorithm and it learns what normal looks like, then flags departures from it. The industry loves to talk about the second kind - machine learning, AI - because it sounds advanced. But in real buildings, a surprising share of the value comes from the first.

Rules are transparent, cheap and instant. They work on day one with no training data, they name the fault precisely, and when one fires you know exactly why. Their weakness is that they only catch what someone thought to encode. Models shine where a rule cannot express the pattern - a subtle drift across dozens of variables, an occupancy signature, a load curve. Their cost is that they need data, tuning and a degree of faith. The professional stance is not rules good, models bad or the reverse: it is start with rules, and reach for a model only when the pattern genuinely exceeds what a rule can say. Most building faults are caught by a few dozen well-chosen rules, not by deep learning.

Raw data points are not KPIs. A key performance indicator is a small, stable number that tracks something you care about and can act on - and choosing good ones is half the craft. For energy: energy use intensity (annual energy per unit floor area), peak demand, load factor, and cost per square metre. For comfort and health: hours outside the comfort band, CO2 exceedances, and complaint rates. For plant: equipment runtime, cycles per hour (short-cycling is a killer), and coefficient of performance. For the analytics itself: how many faults were found, how many were real, and how much energy each avoidable one wasted.

A good KPI is normalised so comparisons are fair - energy per degree-day and per operating hour, not just kWh, because a hot month or a longer schedule is not a failure. It is leading where possible, warning you before the bill arrives rather than after. And it is few: a dashboard of two hundred gauges is a descriptive-analytics trap that no one reads. Pick the handful of numbers that would actually change a decision, normalise them honestly, and put them where the people who act on them will see them.

Strip away the hype and a short list of analytics reliably pays for itself. Fault detection and diagnostics (FDD) - the subject of the next lesson - catches equipment running wrong: simultaneous heating and cooling, stuck dampers, valves leaking by, sensors drifting. Energy benchmarking and load analysis finds the wasteful building, the wasteful hour, and the plant that never switches off at night. Anomaly detection flags the meter reading, the runtime or the temperature that does not fit the pattern - often the first sign of a fault or a leak. Setpoint and schedule analytics find the overrides left in place and the zones conditioned when the building is empty, which is astonishingly common and astonishingly cheap to fix.

What unites the winners is that each one serves a decision and closes a loop: it produces a specific, actionable output - a work order, a schedule change, a setpoint reset - and someone (or something) acts on it, and you can measure the result. Analytics that only produces a prettier chart, or an alert nobody triages, is a cost, not a saving. That test - what decision does this serve, and does anyone act on it - is the one to carry through the whole module.

Every technique above rests on a foundation nobody puts in the brochure: data quality and context. An analytic fed bad data produces bad conclusions with total confidence - a temperature sensor drifting three degrees, a meter with gaps, a point mislabelled at commissioning, and your clever rule or model is now wrong in ways that are hard to spot. Practitioners will tell you that the majority of any real analytics project is not the maths at all; it is getting the data clean, complete and correctly named. That is the price of admission.

Two pieces make the foundation solid. First, storage built for the job: building data is overwhelmingly time-series - a value, a timestamp, a point - and it lives in time-series databases and historians tuned to ingest millions of readings and serve fast trends and queries. Sampling rate matters too: fifteen-minute data hides the short-cycling that one-minute data reveals. Second, and more often the bottleneck, is context. A raw point named AHU3-VLV2 means nothing to an analytic asked to run across a whole portfolio. This is exactly why metadata schemas like Brick Schema and Project Haystack exist: they tag every point with a consistent, machine-readable description of what it is and what it relates to, so a rule or KPI can be written once and applied to thousands of points across many buildings. A digital twin's structured model is the richest version of the same idea. The lesson is unglamorous but decisive: before you reach for a clever analytic, earn the right to trust its answer by getting the data foundation right. Garbage in, confident garbage out.