Predictive Maintenance

Every maintenance regime is one of three postures, and it is worth naming them precisely because most buildings muddle them. Reactive (run-to-failure) means you fix a thing when it breaks. It is the cheapest to plan and the most expensive to suffer: a failed chiller on the hottest day is an emergency call-out, collateral damage to other components, spoiled comfort and sometimes a closed building. Preventive maintenance services equipment on a fixed schedule - every 3 months, every 2,000 run-hours - regardless of condition. It is the honest workhorse of facilities management and vastly better than reactive, but it is a blunt instrument: you replace belts and filters that still had life, you send technicians to healthy machines, and you still miss the failures that do not respect the calendar.

Predictive maintenance (PdM) replaces the calendar with the machine's own condition. You continuously watch signals that reveal health, detect the early signature of a developing fault, and schedule the fix into a planned window - before failure, but without throwing away good component life. The prize is real: fewer unplanned outages, longer effective asset life, smaller spares inventory and calmer maintenance teams. The catch is equally real - PdM needs sensors, data plumbing, models and the discipline to act on what they say. It is not free, and it is not magic.

Predictive maintenance stands on condition monitoring - streaming the physical signals that betray a machine's health. The classic ones are vibration (imbalance, misalignment and bearing wear in rotating plant - pumps, fans, chillers, motors), temperature (bearings, windings, refrigerant lines, electrical connections), electrical signature (motor current and power factor drifting as a load struggles), acoustics / ultrasound (steam-trap leaks, compressed-air leaks, arcing), and simple run-time and cycle counts. Building HVAC adds its own tells: rising differential pressure across a clogging filter, a valve that has to open further each week to hold the same temperature, approach temperatures creeping on a fouling heat exchanger.

A lot of this data already exists. A BMS speaking BACnet or Modbus is quietly logging supply and return temperatures, valve positions, fan speeds and status points - a rich, free feed of condition data most buildings never mine. Where the BMS is blind, cheap IoT sensors on LoRaWAN, Zigbee or wired buses fill the gaps: clamp-on vibration pucks, current transformers, dew-point and pressure sensors. The art is choosing signals that actually lead failure rather than merely confirm it, and giving each point real meaning so an algorithm knows a number is a chiller's condenser approach, not just point AI-0421. This is exactly where Brick Schema and Project Haystack tagging earn their keep.

The idea that makes PdM tractable is the P-F curve. Every failure has a moment - P, the potential-failure point - where it first becomes detectable, and a later moment - F - where the equipment actually stops doing its job. The gap between them is the P-F interval, and it is your entire opportunity: the window in which you can see the fault coming and plan a fix. Vibration and ultrasound tend to reveal P very early; temperature and audible noise reveal it late, sometimes only just before F. Choosing an earlier-warning signal literally buys you more planning time.

From condition trends, analytics estimate remaining useful life (RUL) - how long until this asset crosses into failure. RUL turns a vague worry into a schedulable task: this fan bearing has roughly six weeks; fit it into the shutdown in three. Methods range from simple threshold-and-trend rules, through fault detection and diagnostics (FDD) that compares live behaviour against expected, to machine-learning models trained on histories of healthy and failing runs. Be honest about the limits: RUL is a probabilistic estimate with error bars, not a countdown clock. Treat a confident-looking single number with suspicion - the credible output is a range and a confidence, and a good system says I am not sure rather than inventing precision.

A prediction is the visible tip of a data pipeline, and each stage can make or break it. At the bottom, acquisition: condition signals arrive from BMS points over BACnet or Modbus and from IoT sensors over MQTT, LoRaWAN or Zigbee. They land in a time-series database built for exactly this - high-volume, timestamped readings queried by range - which is the backbone of any building-analytics platform. But raw points are meaningless without context: point AI-0421 has to be known as the condenser-approach temperature of chiller 2, which is the job of a semantic model like Brick Schema or Project Haystack. That tagging is what lets one fault rule or ML model be written once and applied across a whole portfolio instead of hand-configured building by building.

On top sit the analytics themselves, and they form a ladder of sophistication. The simplest and often most valuable are rules and thresholds - a filter's differential pressure past a limit, a bearing temperature trending up - which are transparent and easy to trust. Above them, FDD compares live behaviour to an expected model and isolates which fault is occurring. At the top, machine-learning models trained on histories of healthy and failing equipment estimate RUL and catch subtle multivariate patterns a human would miss. The honest sequencing matters: most buildings get the majority of the value from good tagging plus solid rules and FDD, and should exhaust those before reaching for ML. A machine-learning model on top of dirty, unlabelled, gap-ridden data does not rescue it - it launders bad data into confident-looking predictions, which is worse than no prediction at all.

Picture a rooftop chiller feeding an office. Its condenser-water pump has a BACnet status point, a current sensor and a clamp-on vibration puck streaming over LoRaWAN into the building's time-series platform. For months the vibration spectrum is quiet. Then a small peak appears at the bearing's characteristic frequency and grows week over week; motor current creeps up as the bearing drags. FDD flags an anomaly; an ML model puts RUL at four to seven weeks. The CMMS (computerised maintenance management system) auto-raises a work order, the part is ordered, and the bearing is swapped during a planned Saturday window. No heatwave call-out, no cooked motor, no closed floor. That is PdM delivering.

Now the failure modes of the method itself. Bad or sparse data poisons everything - a mislabelled point, a dead sensor reading a plausible-but-wrong value, or gaps in the stream. Alarm fatigue: a jumpy model that cries wolf gets muted, and then misses the real event. No closed loop: many buildings generate beautiful alerts that no one is resourced to act on - insight with no hands attached is theatre. And the honest ROI question - instrumenting a small, cheap, redundant fan may never pay back; PdM earns its cost on assets that are critical, expensive to fail, or expensive to over-maintain. Start there. A useful discipline is to score candidate assets on three axes before instrumenting anything: criticality (what breaks downstream if this fails), consequence (safety, cost, downtime), and detectability (does a leading signal exist with a usefully long P-F interval). Assets that rate high on all three - central chillers, primary pumps, major air handlers, lifts - are where PdM belongs; a cheap, redundant, quick-to-swap fan rates low and is better left on simple preventive care. Predictive maintenance is a discipline, not a dashboard: its value is the fix that happened at the right time, not the graph that predicted it.