Predictive maintenance is the easiest thing in IoT to sell and one of the hardest to deliver. The pitch is straightforward, the sensors are cheap, and the historical data usually exists. The projects still fail, and they fail for the same reason.
Failure data is rare and badly described
By definition, the event you want to predict is the one that happens least. A plant with two hundred machines and eleven years of records might have a few hundred failures in total, spread across a dozen failure modes. That is not a large dataset for any of them individually.
Worse, the descriptions are free text written by different technicians over a decade. On one project, the same spindle bearing fault appeared under four distinct phrasings, plus two abbreviations and one misspelling that a search would never match. Any model trained on that treats one failure mode as seven, each with too few examples to learn from.
What we do first
- Build a controlled vocabulary with the maintenance leads, not with a script.
- Re-label the history against it, accepting that some records are unrecoverable and marking them so.
- Check timestamp integrity — a repair logged the following Monday is a label attached to the wrong day.
- Establish a statistical baseline before anything is called machine learning, so improvements have something to beat.
On the CNC project this took five weeks and felt, at the time, like an expensive detour. The first model trained on the cleaned labels beat every architectural improvement we tried afterwards on the raw data. Five weeks of vocabulary work was the entire project.
Then decide what a false alarm costs
Precision and recall are not abstract here. If a false positive means a planner glances at a machine, you can afford to be sensitive. If it means stopping a line, you cannot. That number should be established with the operations team before any threshold is chosen, because it determines what a good model even looks like.
A model that cries wolf is ignored within a fortnight, and once it has been ignored it is very hard to get trusted again.
Run in shadow mode
Deploy the model so it runs and is scored, but nobody is paged by it. Six weeks is a reasonable minimum. You learn its real-world precision, the maintenance team watches it be right without any consequence for being wrong, and by the time it goes live it has already earned the credibility it needs.