Predict machine failure before it happens

Two questions, not one

Predictive maintenance is usually sold as a single question — which machine is about to break? — and that framing is why so many programmes stall. A ranked list of at-risk machines tells a maintenance planner where to look. It does not tell them what to actually change.

This build answers both, because it’s two models over the same five sensor readings:

• A classifier that scores each machine’s failure probability — when to intervene.
• Clustering that groups the fleet by operating mode — which intervention.

Take them in that order and the second one reframes the first.

Which machines are at risk now

The classifier turns five readings into a probability. Reading its output on a sample of machines:

Machine 6341 — tool wear 210 minutes, the highest in the sample — scores 0.9996 and failed. Machine 4685 scores 0.6314 and failed. Machine 4743, tool wear 14 minutes, scores 0.0061 and ran fine. The model separates the extremes cleanly.

The interesting row is 5203: predicted failure at 0.7370 confidence, and it didn’t fail. That single false positive is the whole design conversation. A missed failure stops the line; an unnecessary inspection costs an hour. Those are not the same cost, so the threshold is a business decision, not a modelling one — and you set it deliberately rather than accepting 0.5 because it’s the default.

With a 3.4% failure rate, a model that predicts “never fails” is 96.6% accurate. Accuracy is the wrong question.

Why they’re at risk — and what to do about it

Clustering the same 10,000 machines by speed and torque produces four operating modes, and the failure rates are not close:

Operating mode	Machines	Speed	Torque	Failure rate
High-speed, low-torque	2,543 (25.4%)	1,621 rpm	33.0 Nm	0.51%
Medium-speed, high-torque	3,226 (32.3%)	1,446 rpm	45.6 Nm	6.26%
Medium-speed, medium-torque	3,386 (33.9%)	1,460 rpm	44.4 Nm	2.57%
Very high-speed, very low-torque	845 (8.5%)	1,961 rpm	21.8 Nm	4.38%

The high-torque segment fails at 12× the rate of the high-speed, low-torque one. Run the arithmetic across the fleet and the concentration is stark: that segment is 32.3% of machines but roughly 60% of all failures, while the safest quarter of the fleet contributes under 4%.

Torque load is the strongest single correlate here — but read the table and it clearly isn’t the whole story. The very-high-speed segment runs at the lowest torque in the fleet (21.8 Nm) and still fails at 4.38%, well above the medium-torque group’s 2.57%. Failure rate isn’t monotone in load, so at least two distinct stress mechanisms are in play, and clustering shows you where failures concentrate — not what causes them.

Now cluster the same fleet on tool wear and process temperature instead, and something more useful appears — the failures split by cause:

Risk profile	Machines	Failure rate
Low wear, normal temp	2,434 (24.3%)	1.03%
High wear, normal temp	2,529 (25.3%)	3.60%
Low wear, high temp	2,548 (25.5%)	3.45%
High wear + high temp	2,489 (24.9%)	5.42%

Look at the two middle rows. They fail at almost the same rate — 3.60% and 3.45% — and a risk score would rank them identically. But one group is degrading because its tooling is worn, and the other because it’s running too hot. Same number, opposite fix: replace tools, or fix cooling.

That distinction is invisible to a classifier and obvious to a segmentation. The critical group — high wear and high temperature, at 163.9 minutes of wear and 311.3 K — carries a 5.42% failure rate and 135 of the fleet’s failures on its own.

Why it’s worth solving

Unplanned downtime is expensive in a way that scheduled maintenance is not. The part is rarely the cost; the stopped line, the idle shift, the missed delivery and the collateral damage of a component that failed under load are. Predictive maintenance is worth doing because it converts an unplanned stop into a planned one — the same repair, at a time you chose.

But the sharper argument here is concentration. Failures are not spread evenly across a fleet, and this data shows exactly how unevenly: a third of the machines produce around 60% of the failures. That single fact changes what a maintenance budget can buy. Inspect everything on a fixed calendar and a quarter of that effort goes to the 25% of machines behind under 4% of failures. Target the high-torque segment and the same hours cover most of the actual risk.

The second clustering then decides what those hours are spent on. Tool replacement and cooling upgrades have different costs, different lead times and different suppliers — and picking the wrong one on a machine that’s thermally stressed means paying for tooling and still having the failure.

A risk score tells you which machine. A segment tells you which problem. You need both to spend a maintenance budget well.

None of this requires new instrumentation. Air temperature, process temperature, speed, torque and tool wear are readings most plants already collect and mostly discard. The value isn’t in more sensors — it’s in asking these five columns a question they can already answer.

How Langsat builds this

Two projects over the same table.

1. The classifier — a Data Science project with a binary-classification target (Machine failure). Point Langsat at the sensor table, pick the target column, and train. No feature engineering; no infrastructure to stand up.
2. Set the threshold to your costs. Langsat reports the metrics that fit an imbalanced classification, so you can choose the probability cut-off where a missed failure and a false alarm balance the way your plant experiences them — rather than inheriting 0.5.
3. The segmentation — a clustering task on the same data, requested in plain English (“cluster machines by their operational characteristics”). Both clusterings above came from that, along with the operating-mode dashboard you can share with the maintenance team by link.
4. Serve it. Every machine gets a live failure probability through the prediction API, so the score lands in the scheduling system rather than in a report nobody opens.

The whole thing runs on Langsat’s secure cloud — your data isolated to your account, encrypted in transit and at rest, and never used to train models for anyone else.