Preventive maintenance, fault detection, and predictive models build on each other. A staged route for OEMs and service companies, where the first stage pays from day one.
Connected equipment catches failures while they are still small and cheap to fix. Equipment makers and service companies are building that capability into their product lines through three approaches, preventive schedules, fault detection and diagnostics (FDD), and predictive maintenance, which answer different questions and build on each other.
If you're deciding what to build into your own product line, the practical question is what each capability needs from you and what it pays back. The three form a natural build sequence: fault detection produces value from the day you connect, the fleet it runs on accumulates operating history, and genuine failure prediction arrives on top of exactly that history.
A preventive program needs an OEM service schedule and a way to track completion. No sensors, no connectivity, no models. It also leaves a lot on the table: a landmark study of aircraft component reliability found that only about 11 percent of the ways equipment fails are age-related, so most failures develop between scheduled visits, invisible to any calendar. Seeing them takes live data, and that is what connecting the equipment unlocks: from the day a unit is connected, fault detection starts working.
Most of the work in fault detection is already done for you, because the rules are public and free. ASHRAE Guideline 36 encodes manufacturer-agnostic fault conditions for air handlers. NIST's APAR rule set uses physics-based consistency checks that need no training data, only the sensor points a typical controller already exposes.
What the rules catch is common and expensive. Field studies have found nearly two in three packaged rooftop units running with malfunctioning economizers, a fault that raises cooling energy use by around 37 percent on average. Berkeley Lab measured roughly 550 buildings running analytics and FDD software and found median site energy savings of 8 to 9 percent, measured in the field rather than projected. You can see this kind of monitoring running on commercial rooftop units at smarthvac.io.
HeatMaster, a Canadian solid-fuel furnace OEM building on Blynk, connected 190 furnaces in its first full heating season, six months from decision to branded apps. The connected data identified the root cause of an issue early enough to avoid an estimated $100,000 in recall risk, and it ended the manual data collection and fly-out troubleshooting the team estimates was heading for $50,000 to $60,000 a year in support costs.
Plan for one real piece of work at this stage: data normalization. Getting consistent point naming and units across every equipment variant you ship is often more effort than the fault rules themselves. Budget for it up front and stage two stays a fast win.
Prediction adds the question fault detection can't answer: not whether a unit is misbehaving now, but whether it's heading toward failure and when.
What it needs is history. Models want a baseline of normal operation first, typically four to eight weeks per equipment family in practitioner reports, and then failure examples to learn from. Failure examples are the scarce ingredient, since industrial equipment is designed not to fail.
The route solves this for you. A fleet running fault rules is also a fleet accumulating exactly the baselines and failure history that models require, so the training data arrives as a side effect of stage two.
Build in order. Ship the rules first, then let the fleet they run on accumulate the history that prediction needs.
There's a proven way to make the final climb, and we use it ourselves. A laboratory refrigeration manufacturer we work with runs prediction models on Blynk in shadow mode: the models run live on real equipment data, but customer-facing alerts stay off while false positives are counted against reality. On the first day of silent operation, the system flagged a real issue, a unit reset followed by reconnection, that would otherwise have gone unnoticed.
Practitioner-reported false-positive rates run 15 to 25 percent early and fall below 8 percent only after months of technician feedback, and an alert channel that cries wolf in a technician's inbox for a month is dead, along with the product built on it. Shadow mode lets you measure precision before customers ever see an alert.
The build-versus-buy line is clearer than it used to be. Sensors, connectivity, dashboards, native mobile apps, and fleet-scale device management are solved problems; your defensible asset is domain knowledge about your equipment plus the fleet data it generates. A low-code IoT platform provides the rest as ready-to-use, scalable cloud infrastructure: over-the-air firmware updates, data converters that connect existing controllers without firmware changes, white-label apps, and SOC 2 Type II compliance. Blynk connects millions of devices across 178 countries for equipment makers like Raypak (commercial boilers). That leaves your engineering effort on the rules and models only you can write.
Your competitors are connecting their equipment now, and moves at the Carrier and Copeland level are public. A fleet only starts accumulating the baselines and failure history that prediction needs on the day it is connected, so every quarter of waiting is a quarter of training data a competitor has and you don't.
If you're adding monitoring to an equipment line, the route is short and each stage pays: ship the rules, run the models in shadow mode, and turn alerts on once the measured precision supports them. Talk to us about your project at blynk.io.
.png)
