Predicting Machine Failure From Sensor Data When You Have Few Failures

The data problem nobody mentions in vendor demos

Predictive maintenance demos show a model trained on hundreds of recorded failures. A small manufacturer has a compressor that has failed twice in six years, a packing line that jams in ways nobody logged consistently, and three years of vibration and temperature readings stored in a historian nobody opens.

That is the normal starting position, and it rules out the textbook approach. You cannot teach a supervised model what a failure looks like from two examples. It also does not mean the sensor data is useless. It means the question has to change.

Change the question from failure to abnormal

Rather than asking will this machine fail, ask is this machine behaving the way it normally does in these conditions. You have thousands of hours of normal behaviour, which is exactly what you need to answer that.

• Learn the normal relationship between load, speed, temperature, vibration and current draw
• Predict what each sensor should read given the others and the operating mode
• Measure the gap between predicted and actual over time
• Alert when that gap grows steadily, rather than on a single spike

A bearing starting to wear rarely announces itself through one huge reading. It shows up as vibration running a little higher than it should for that load, week after week. Health-baseline models are good at noticing that slow drift, and it is often the earliest usable warning.

What this looks like on a real site

Take a food packaging plant with six filling lines, each with a main motor, a vacuum pump and a conveyor drive. Vibration and temperature sensors were fitted two years ago, sampled every few seconds, stored and mostly ignored. Unplanned stoppages cost several hours of line time each.

A sensible first build models normal behaviour per asset and operating mode, trained on periods the maintenance team confirms were healthy. Each asset gets a daily health score and a trend. Maintenance sees a short list each morning of assets whose behaviour has drifted, with the sensor that drifted most.

The first month typically surfaces a few assets already known to be tired, which builds credibility, and one or two surprises worth an inspection. That is a realistic outcome. Promising that every failure will be predicted weeks in advance is not.

Techniques that work with few failures

Start at the top of the table and only move down when the simpler method is clearly not enough. We would pair engineering thresholds with a normal-behaviour model for most small sites, and leave remaining useful life estimates alone unless you run many identical assets.

Keeping it on a small budget

The expensive part of predictive maintenance is rarely the model. It is sensors, connectivity, data storage and integration. Most of that can be kept lean.

1. Pick the three to five assets whose failure hurts most, not the whole plant
2. Use existing PLC and SCADA data before buying new sensors
3. Sample at the rate the fault needs; minute averages are fine for temperature, not for bearing vibration
4. Run models on a small edge device or a modest cloud server, not a data platform
5. Deliver alerts into the maintenance system or email the team already reads

We wrote more about hardware and connectivity choices in IoT and sensor projects for smaller operations. If you are weighing up the business case for maintenance overall, our post on predictive maintenance for smaller operations covers that.

When not to bother

Some assets are cheaper to run to failure. A conveyor motor that costs a few hundred pounds, swaps in twenty minutes and sits next to a spare is not worth monitoring with machine learning. Keep a spare on the shelf.

It is also not worth it if nobody will act on alerts. If the maintenance team is already stretched with reactive work, health scores become another ignored dashboard. Fix the planned maintenance schedule first, then add prediction.

Start logging failures properly now

Whatever you build, begin recording every stoppage with the asset, the time, the cause and the fix, in a consistent structure. In two years that log turns a normal-behaviour model into something that can learn which drifts actually precede failures.

At SpiderHunts that log is usually the first thing we set up, often as a small addition to an existing maintenance system. Our machine learning work on these projects is deliberately modest in the first phase, because trust from the maintenance team is worth more than model sophistication.

Frequently asked questions