Predicting breakdowns before they halt the line with AWS IoT and ML

The breakdown an ageing line never sees coming

An established manufacturer feels every unplanned stoppage in the same place. A machine on a key line stops mid-shift, the work queued behind it stops with it, and a maintenance team that was halfway through something else drops everything to find out why. The part has to be sourced, sometimes overnight, and the line sits idle until it arrives. On older equipment this is not rare. It is the rhythm of the place.

The frustrating part is that the failure was rarely silent. A bearing had been running warm for a week. A motor had been pulling slightly more current. Vibration had crept up so gradually that nobody on the floor noticed. The signals were there the whole time. What was missing was anything watching them continuously and knowing what normal looked like for that specific machine.

The usual answer is a maintenance schedule based on the calendar or on running hours. It helps, but it is a blunt instrument. Service too often and you waste parts and labour and create downtime of your own. Service too rarely and the machine still fails between intervals, because wear does not follow a calendar. Run-to-failure, the unspoken default on a lot of older equipment, is cheapest right up until the morning it is the most expensive thing in the building. There is a worker-safety dimension too. A bearing or coupling that fails catastrophically is a hazard, not just a cost, and Safe Work Australia obligations make avoiding that failure worth more than the repair bill alone.

Why AWS for the sensors and the models

The aim is simple to state. Watch each machine’s real condition continuously, learn what healthy looks like, and raise a useful warning before a failure becomes a stoppage. We headline these builds on Amazon Web Services because the two hard parts, ingesting a constant stream of sensor data and running machine-learning models over it, live in the same place.

Vibration, temperature and current sensors on the key machines stream their readings into AWS through its IoT services. That stream is steady and never stops, which is exactly the load a managed cloud ingestion layer is built for and exactly the load that breaks a hand-rolled server. From there the data lands in a store the models can read, and machine learning does the watching that a person cannot do around the clock across dozens of machines.

This is the real argument for the approach over reactive run-to-failure. A calendar schedule knows the date. It does not know that this particular motor is drawing more current this week than last. The models learn each machine’s own normal from its history, then flag the drift away from it that precedes a fault. The decision to act moves from “the service is due” to “this machine is changing, and here is the evidence”.

The supporting stack keeps it manageable. The data-processing and model services run in Docker containers, so the same setup that runs in test runs in production and a new machine is onboarded by configuration rather than a rebuild. A PostgreSQL store holds the engineered features, the per-machine baselines and the alert history, which is the record the maintenance team and the model both work from. The sensors are added externally, so an older machine with no network smarts of its own can still be monitored without touching the controls that keep it running.

Building it, and the problem with almost no failures

The hard part of predictive maintenance is not the cloud. It is that good machines almost never fail, so there is almost nothing for a model to learn from.

The obvious approach is supervised learning. Show a model lots of examples of healthy running and lots of examples of a failure, and let it learn to tell them apart. The trouble is the second pile. A well-run machine might fail once in two years, so a manufacturer simply does not have a labelled library of failures to train on. Build a pure classifier on that and it learns next to nothing, because it has barely seen the thing it is meant to catch.

So we changed the question. Instead of asking the model to recognise failures it has never seen, we asked it to learn each machine’s normal in detail and flag anything that drifts away from it. Anomaly detection and remaining-useful-life estimation carry the load, not classification. That sidesteps the missing-failures problem, because learning normal only needs healthy data, which there is plenty of.

The sensor data itself was the second hurdle. Industrial readings are noisy, and they drift for innocent reasons. A hot day, a new batch of material, a different operator, a routine adjustment all move the numbers without anything being wrong. An early version flagged a heatwave as a fault on half the line. The fix was careful per-machine baselining, thresholds tuned to the cost of a miss against the cost of a false alarm, and a feedback loop so every real call-out, whether it found a genuine fault or a false one, sharpened the next judgement. Alarm fatigue is the quiet killer here. A team that gets a nuisance alert every week soon ignores the one that matters, so keeping false alarms low was treated as a core requirement, not a nicety. The sensor data sits within the manufacturer’s own environment, handled under the Privacy Act 1988 where any of it touches people.

What changed on the floor

In a representative deployment, unplanned stoppages on the monitored machines fell by roughly a third, because failures that used to arrive mid-shift were caught early and booked into a planned window instead. On the failure modes the models had learned, warnings came days ahead of a stoppage, enough lead time to order the part and schedule the work rather than scramble for both at once. False alarms stayed low enough that the maintenance team trusted a warning when it came, which is the difference between a system people use and one they switch off.

These figures are illustrative. They describe the pattern we see rather than a published result for a named manufacturer. The shift is the point. Maintenance stops being a fire drill triggered by a dead machine and becomes a planned activity driven by what the machines are actually telling you, with the safety benefit of catching a catastrophic failure before it happens rather than after.

Where this fits

Predictive maintenance on industrial IoT is one application of our Artificial Intelligence service, built on Amazon Web Services, for Australian manufacturing. It suits an established manufacturer with ageing machinery particularly well, because the signals already exist in the equipment and the cost of an unplanned stoppage is easy to measure, which makes the return concrete. If a stopped line is your recurring surprise, the place to start is to pick the handful of machines that hurt most when they fail and decide which signals would have warned you.