Catch Equipment Faults Before They Cost You: Fault Detection on EnergyOS
Most equipment does not fail without warning. A compressor starts short-cycling weeks before it quits. A motor pulls more current than it used to. A supply fan drifts out of balance and starts shaking its own bearings loose. The signals are there in the data. The problem is that nobody is watching them around the clock, and by the time a person notices, the failure has already turned into a service call, a warm walk-in, or a room full of unhappy tenants.
Fault detection and diagnostics, or FDD, is how you close that gap. On EnergyOS it runs continuously against every piece of equipment you care about, comparing how a machine is behaving right now against how it normally behaves, and raising an alert while there is still time to act.
The takeaway: FDD moves your maintenance from reactive to condition-based, so a technician gets a specific, routed alert about a developing problem before it becomes a breakdown.
What FDD actually is, in plain terms
Every failure mode has a signature. A chiller that short-cycles turns on and off far more often than a healthy one. A pump that is losing efficiency draws its motor current in a pattern that looks different from a good day. A fan with a failing bearing vibrates in a way a balanced fan does not. These signatures are known and repeatable.
FDD is the practice of writing those signatures down as rules and then checking live equipment data against them, continuously, without a human having to remember to look. When the data matches a fault signature, the system flags it. That is the whole idea. The value comes from doing it reliably across dozens or hundreds of assets at once, which is exactly the kind of monotonous watchfulness software is good at and people are not.
How the rules work on EnergyOS
EnergyOS ships with a library of FDD rule templates. Each template captures a known failure pattern and is mapped to a logic evaluator that decides, from the incoming data, whether the fault condition is present.
When you bring a site online, those templates get deployed as rule instances against the specific equipment at that site. A rule instance is a template pointed at a real asset, with parameter overrides that fit that asset. Your rooftop unit and your walk-in condenser are not the same machine, so the thresholds and timing that count as abnormal for one are not the thresholds for the other. The override step is where the general pattern becomes a check tuned to your equipment.
From there the rules run against continuous submeter and sensor data. When a rule evaluates true, a fault event is recorded and surfaced so it does not get lost. You end up with a running history of what tripped, on which asset, and when, which is useful both in the moment and later when you are looking for a recurring problem.
A few examples of what a rule can encode:
- A chiller or compressor short-cycling, turning over far more often than its normal duty pattern.
- A motor or pump drawing more current than its own established baseline, which points to added mechanical load, wear, or a developing electrical problem.
- A fan running out of balance, which shows up as a vibration signature well before the bearing gives out.
Why baselines matter more than fixed thresholds
A common mistake in equipment monitoring is picking one fixed number and calling anything past it a fault. That produces noise. Equipment behaves differently on a hot afternoon than on a mild morning, and a busy kitchen loads its refrigeration harder than a slow one.
EnergyOS judges abnormal against a weather-normalized baseline built from the equipment's own history. The question is not whether a reading crossed some universal line. It is whether this machine is behaving unlike how it normally behaves under similar conditions. That keeps the alerts meaningful and cuts down on the false alarms that train people to ignore the system.
Machine health, not just performance
Some faults show up in energy data. Others show up in how a machine moves. EnergyOS pairs the FDD rules with machine-health sensing so both are covered.
Vibration and accelerometer baselines let the platform learn what a healthy fan, pump, or motor feels like, then flag the drift when imbalance or wear starts to set in. Current-draw monitoring watches the electrical side, so a motor that is starting to labor gets noticed early. Together these give you a read on mechanical condition, which is often where the earliest warning of a failure lives. A bearing does not announce itself by tripping a breaker. It announces itself by shaking a little more than it used to, and that is exactly the kind of change a vibration baseline is built to catch.
From fault to a technician who can act
Detecting a fault only helps if the right person hears about it. On EnergyOS, a fault feeds the alerting layer, which is where detection turns into action.
Alerts are driven by configurable rules and go out as real-time notifications. Routing is multi-channel, so an alert can reach people by text, email, or phone call depending on urgency and who needs to know. Escalation policies handle the case where the first person does not respond, moving the alert up the chain so a critical fault does not sit unread overnight.
The equipment registry and maintenance logging tie it together. Every asset is a known record, so an alert says which unit at which site is affected, not just that something somewhere is off. When a technician responds, the work gets logged against that asset, which builds the maintenance history you use to spot chronic bad actors and plan replacements before they force your hand.
Why catching it early pays off
The economics of condition-based maintenance are straightforward. A fault caught early is usually a scheduled, planned repair during business hours. The same fault caught late is an emergency call at a premium rate, plus whatever the failure took down with it.
For a food service operator, late detection on refrigeration can mean spoiled inventory and a health code problem. For a property owner, a failed rooftop unit means uncomfortable tenants and after-hours crews. For a healthcare facility, it can put a critical space at risk. For light industrial operations, a downed motor can stall a line and idle a crew. In each case the pattern holds. Early warning turns an emergency into a work order, protects the product or the space the equipment is there to serve, and stretches the life of assets you would rather not replace ahead of schedule.
Because Emergent Metering delivers this as a managed service on EnergyOS, you are not standing up rule engines or babysitting sensors yourself. The templates, the baselines, the alerting, and the equipment records come as part of the service, tuned to your sites and your equipment.
If you want to see fault detection running against real equipment data, schedule a platform demo.
Schedule a Platform Demo: 215-645-7141