Three years back, a packaging line at a food plant I was supporting went down on a Friday afternoon. Conveyor motor seized. No warning. Crew scrambled for four hours finding a replacement bearing. Production lost that weekend cost them roughly thirty thousand dollars. The plant manager asked me why we had not seen it coming. Honest answer: we were not looking.
That failure pushed us into predictive maintenance. Not the glossy vendor demo version. The real thing where you strap accelerometers to motors, stream vibration data, and build models that learn what normal sounds like so they can scream when something drifts.
The first step was ugly. We installed wireless vibration sensors on twelve critical motors and just collected data for three months without touching a model. Most teams skip this. They want to train a classifier on day one. You cannot. You need to understand your baseline first. What does a healthy motor at full speed actually look like at six in the morning versus midnight when the ambient temperature drops and the bearing housing contracts slightly? Those nuances matter.
We used a simple autoencoder architecture at first. Feed it frequency spectra during normal operation, let it reconstruct the signal, and flag anything where the reconstruction error spikes. No fancy labeling required. That was the key insight for me. Supervised learning on failure data sounds cleaner, but in most plants you have months of healthy operation and maybe two or three recorded failures. You cannot train a random forest on three positive examples. Unsupervised anomaly detection sidesteps that whole problem.
The first real catch came six weeks in. Bearing on the case sealer started showing elevated reconstruction error. Maintenance team checked it. Said it felt fine. I almost pulled the alert. Two weeks later that bearing was loud enough to hear from across the floor. They replaced it during a scheduled changeover. No emergency. No weekend call. That single event paid for the sensor hardware ten times over.
Where teams go wrong is treating the model as the finish line. It is not. The model is the sensor. The workflow around it is what matters. We built a simple triage system: yellow alert goes to the maintenance planner's queue for the next scheduled inspection. Red alert triggers a same-day physical check. Without that pipeline, alerts just become noise and people ignore them. I have seen three separate predictive maintenance projects die because nobody owned the response process.
Another mistake I made early on was ignoring the data pipeline itself. Sensors dropped packets. Timestamps drifted. One gateway had a firmware bug that duplicated every tenth reading. The model started flagging phantom anomalies. We spent a week debugging the model before realizing the data was garbage. Now I tell every team: spend as much time on data quality as on algorithm selection. A simple model on clean data beats a sophisticated model on dirty data every single time.
The plant now runs vibration analytics on forty motors. Unplanned downtime on those assets dropped by roughly seventy percent in the first year. But the number I care about more is mean time to detection. We catch developing failures an average of three weeks before they would have caused a line stop. That window is what makes the difference between a planned bearing swap and a midnight emergency call.
Predictive maintenance is not magic. It is just paying attention to signals you were already generating but never bothered to listen to. The machines have been telling us they are sick for years. We finally built something that speaks their language.