Data Readiness for Anomaly Detection on BMS Telemetry

The pitch is appealing and the technology is real. Point a model at your building telemetry and it will learn normal behaviour and tell you when something departs from it. What usually happens next is that the model finds a great many departures, most of them turn out to be gaps in collection, sensors in a faulted state, units that changed halfway through the history, or a point that was remapped last spring, and six weeks later the pilot is quietly shelved with a conclusion about the technology that was actually a conclusion about the data.

The message up front: run the readiness checks before you choose a method, because they decide whether any method can work and they tell you which points are candidates. You need identity you can trust, units and semantics recorded, a known sampling expectation, measured completeness, quality flags preserved, a documented history of changes to the instrument and the mapping, and enough history at a usable resolution to cover the operating conditions the model will be asked to recognise. Where those are missing, fix the data, and narrow the pilot to the points where they hold.

1. What actually goes wrong

The failures are consistent across estates, and none of them are modelling failures.

• Gaps read as events. A period where data stopped arriving looks like a change in behaviour to anything that does not know the difference, which is why completeness has to be measured and carried, per data completeness KPIs.
• Known-bad readings treated as real. Devices frequently report that they do not believe their own values, and a pipeline that dropped those flags has thrown away the cheapest possible filter, as set out in BACnet data quality flags.
• Silent unit or scaling changes. A multiplier applied in a new place, or a point whose unit was corrected, produces a step in the series that is a configuration event rather than plant behaviour, which is the problem in sensor units and scaling.
• Instrument changes nobody recorded. A replaced or recalibrated sensor creates a legitimate discontinuity, and without the record it is indistinguishable from a change in the equipment, per sensor replacement and BMS history.
• Identity that moved. A point remapped to a different asset makes one series describe two things, which is the reason for the discipline in point naming and cross-system joins.

What these have in common is that they are all data history problems rather than data volume problems, and no amount of additional telemetry addresses any of them.

2. The readiness checks

3. How much history, and of what

The question always asked is how much data is needed, and it is the wrong question. What matters is coverage of conditions rather than duration.

A building's behaviour varies with outdoor conditions, with occupancy, with operating mode and with the seasonal configuration of the plant. A history that spans only one of those regimes describes normal for that regime, and a model built on it will report the arrival of a different regime as an anomaly. That is not a modelling error; it is a true statement about the data it was given.

So the useful inventory is not months of history but which regimes are represented, which are absent, and whether the absent ones will occur during the pilot. If a mode is missing, the honest options are to wait, to exclude that mode from evaluation, or to accept that its first occurrence will produce alerts and plan to handle them. Choosing in advance is the difference between a known limitation and a credibility problem.

4. Handling the gaps and the known-bad

Two decisions here do more for a pilot than any choice of technique.

• Mark gaps, never fill them. Interpolating across missing data creates plausible values that were never measured, and everything downstream treats them as observations. If an approach cannot accept missing values, that is a constraint on the approach.
• Exclude flagged readings before anything else, and record how many were excluded. A point that is substantially flagged is an instrumentation work order, not a modelling candidate.
• Exclude known operational periods explicitly. Planned shutdowns, commissioning and testing are not anomalies, and the suppression record from planned shutdown suppression is the cheapest source of those dates.
• Treat late-arriving data deliberately. Buffered readings that land after a window has been evaluated will change the picture retrospectively, which is the behaviour described in late and out-of-order readings.

5. Choosing the points to start with

Readiness is assessed per point, not per estate, and that is good news, because it means a pilot does not need a clean estate. It needs a clean subset.

• Pick points with high completeness and few flags over points that are more interesting but worse measured. The interesting ones can follow.
• Prefer points on critical assets, so that a true finding is worth acting on, using the classification in asset criticality.
• Prefer points whose asset mapping is verified, because an alert nobody can route is an alert nobody acts on, per point-to-asset mapping.
• Avoid points with a recent instrument or mapping change unless the change is dated and can be handled explicitly.
• Include a few deliberately poor points as a control, unflagged to whoever evaluates the output. If the method reports them as anomalous, that is informative about the method rather than about the plant.

6. The pipeline has to be watched too

A readiness assessment describes the data you have. It says nothing about the data you will have next month, and a detection service is a continuously consuming system whose inputs degrade.

The failure mode is specific and quiet: collection deteriorates, completeness falls, and the detection output either goes silent or fills with artefacts, and in both cases somebody draws a conclusion about the building. The protection is to monitor the inputs as a first-class part of the service, with the flow and expectation checks from ingestion monitoring, and to publish the completeness of the evaluation window alongside every result so a thin week is visible rather than implied. The ongoing version of this question is covered in monitoring drift.

The idea to walk away with

Anomaly detection on building telemetry is constrained by data history rather than by data volume, and the usual failure is that the method spends its effort rediscovering collection gaps, flagged readings and undocumented configuration changes.

Run the readiness checks first, per point rather than per estate, mark gaps instead of filling them, inventory which operating regimes the history covers, scope the pilot to the points that pass, and monitor the inputs continuously because readiness is a statement about a moment.

Final thoughts

Pick the one point you would most want a model to watch, pull two years of it, and try to account for its ten largest excursions.

That exercise takes an afternoon and settles the question. If the excursions are mostly data events, you have found the actual project and saved a pilot. If they are mostly unexplained plant behaviour, you have a strong candidate and a head start on the evaluation, which is a far better position than starting with a tool.

Related reading: Data completeness KPIs, Data quality flags, Pilot planning, Thresholds versus statistical methods, Units and scaling, AI anomaly detection overview.