Ask any plant head in an Indian manufacturing cluster about predictive maintenance and you will hear the same story. A vendor came, mounted a few wireless sensors, showed a dashboard with a health score, and for six months everyone was hopeful. Then the alerts started coming at the wrong time, the maintenance team stopped trusting them, and the project quietly became a line item nobody renews. This post is about why that happens and what the plants that actually get to production do differently.
The three ways a predictive maintenance pilot dies
We have seen a lot of pilots, in Germany and increasingly in India, and the failure modes are remarkably consistent. It is rarely the algorithm. It is almost always what happens around it.
1. The model was trained on someone else's machines
Generic products ship with models pre-trained on a library of bearings, pumps and motors. That library was recorded on different machines, different mounts, different loads and different acoustic environments. A CNC hall running three shifts with compressors next door does not sound like the reference lab. The model sees drift on day one and does what any classifier does under distribution shift: it becomes confidently wrong.
2. Nobody defined what a good alert looks like
"Detect failures early" is not a target. Early by how much? For which failure modes? At what false-alarm rate is the maintenance team still willing to walk to the machine? Without a number agreed up front, every result is arguable and the project cannot pass or fail. Projects that cannot fail also cannot succeed.
3. The data left the plant, and the plant lost control
Cloud dashboards are convenient until the IT security team asks where the vibration data of the hot-forging line is stored, who owns the model, and what happens when the subscription ends. Many Indian conglomerates now have explicit policies about process data leaving the site. A pilot that ignores this cannot scale, however good the demo.
What the plants that reach production do differently
The successful projects we have been part of share a pattern that has little to do with picking the right vendor and a lot to do with running the project like an engineering programme.
- They start with a feasibility study, not a purchase order. Two to ten days on existing data or a short measurement campaign answers the only question that matters: is the failure signature actually visible in the signal we can afford to measure?
- They agree on metrics before modelling. Detection lead time, false-alarm budget per week, and a clear go / no-go gate. Engineers on both sides sign it.
- They measure on their own machines. The dataset is built on the plant's process, with the plant's noise, and versioned so it can be reused. It belongs to the plant.
- They deploy on the edge, on-premise. Inference runs on a device next to the machine. Raw data stays on site. The IT team can audit everything.
- They hand over, deliberately. The maintenance team learns how the alerts are produced and how to retrain. Support after the project is a defined arrangement, not a hope.
Why acoustic and vibration sensing changes the economics
Most predictive maintenance today is vibration-only, contact-mounted, one sensor per bearing. That is the right choice for large rotating assets. It is the wrong choice for a lot of what an Indian plant actually worries about: welding cells, extruders, presses, conveyors, compressors and electrical panels. Airborne acoustic sensing, from audible frequencies up to ultrasound, covers several machines from one position, needs no contact mounting and picks up phenomena vibration misses, such as leaks, arcing, partial discharge and process changes. Combined with vibration, vision and environmental sensing across the same platform, the coverage per rupee changes completely.
The question is no longer "can AI predict failures?" It is "can we build a sensing setup that is robust to our noise, and a model that we own and can keep running?"
A realistic timeline for an Indian plant
For a single line or a critical asset group, we typically see: a free discovery call; a feasibility study of two to ten days; a proof of concept of two to eight weeks with a validated prototype on the plant's data; then a pilot line with sensor units and edge AI over a few months, followed by roll-out. Most of that work happens remotely with on-site visits at the measurement and deployment steps. That fits the CET / IST overlap comfortably.
If your last pilot stalled, the good news is that the data you collected is probably still useful. A feasibility study on that data is often the cheapest way to find out whether the problem was the physics or the project.
Key takeaways
- Pilots fail on distribution shift, undefined success metrics and data governance, not on algorithms.
- Start with a feasibility study and a signed go / no-go gate.
- Build the dataset on your own machines and keep it; it is an asset.
- Deploy on the edge, on-premise, with a handover plan for your maintenance team.
- Multi-modal acoustic plus vibration sensing covers more failure modes per sensor than vibration alone.
If any of this matches a problem on your line, the fastest way to find out what is possible is a free discovery call followed, where it makes sense, by a feasibility study of two to ten days.