Predictive maintenance (PdM) is one of the most over-promised AI applications in Indian manufacturing. Vendors pitch a future where every machine is monitored, every failure predicted and no line ever stops unexpectedly. The real ROI is narrower and more boring, and that narrow, boring part is where the project actually pays back.
The three failure modes where PdM consistently wins
- Bearing failure. Bearings usually degrade gradually, and vibration analysis picks up the change well before the bearing seizes. How far ahead depends on the machine, its speed and how often you sample. Off-the-shelf accelerometers plus FFT-based features handle most cases, and the payback is fast.
- Lubrication degradation. Oil condition sensors, viscosity tracking and periodic oil analysis catch degradation before it cascades into mechanical wear. Cheap to monitor, expensive to ignore.
- Thermal anomalies. Thermal imaging and temperature sensors, with anomaly detection on the readings, catch electrical faults, overloaded motors and failing insulation before they trip or burn out. Particularly valuable in steel, aluminium and chemicals.
What these share: a physical signal that changes gradually before failure, a sensor that can measure it cheaply, and a maintenance action (re-lubricate, replace, re-align) that costs far less when it is planned.
The failure modes where PdM rarely pays back
Sudden component failures (a bolt shearing in seconds), incidents driven by human error, and quality issues that are not equipment-driven. There is no gradual signal to learn from, so AI has not solved these and probably will not soon. Do not let a vendor scope you a PdM project that includes them.
Indian manufacturing has a specific data problem
Many Indian factories run equipment that pre-dates IoT. PLCs are old, shop-floor networking is patchy, and historical sensor data either does not exist or is locked in vendor-specific systems. The early months of a PdM project are usually instrumentation and data plumbing, not modelling. Plan for that and your ROI is real; ignore it and the project drags. In practice:
- Budget for retrofit sensors and edge gateways rather than assuming the data is available from the PLC.
- Check power quality and network coverage on the shop floor before choosing wired or wireless sensors.
- Start collecting data early, before the model is designed, because baselines need weeks of normal operation.
- Record maintenance events in a structured log. Without labelled failures and repairs, you cannot validate any model.
The minimum-viable PdM stack
- Sensors: vibration, temperature, current draw and oil quality. Pick 3–5 critical assets, not 50.
- Edge gateway: collects raw data, does basic filtering and sends it to a cloud or on-premises time-series database, buffering locally when the network drops.
- Time-series store: TimescaleDB, InfluxDB, or plain Postgres with table partitioning by time.
- Anomaly detection: simple statistical baselines first, such as rolling averages and thresholds per operating mode; machine learning later, if the simple models hit a ceiling. Once models are in production, watching them for drift is part of MLOps, not an afterthought.
- Alerting: Slack, WhatsApp or SMS to the maintenance lead, not a dashboard nobody opens.
A common pattern in stalled PdM projects is over-engineered modelling sitting on top of under-invested instrumentation. Get the boring layer right first.
How to size the business case honestly
Pick one production line and work through it:
- Annual unplanned downtime hours on that line, taken from maintenance logs.
- Cost per downtime hour: lost contribution margin, overtime to catch up, scrap and expedited spares.
- The share of that downtime caused by the three failure modes above, from root-cause records.
- Multiply them. That is your maximum addressable saving. The realistic saving is lower, because not every failure will be caught in time.
A hypothetical example: a line loses 200 hours a year to unplanned stops at ₹1.5 lakh per hour, or ₹3 crore a year. If the records show 40% of those hours came from bearings, lubrication and overheating, the addressable pool is ₹1.2 crore. Set your target as a fraction of that and compare it with the cost of sensors, integration and people. Any business case that promises more than the addressable pool is a sales pitch.
Running a pilot that proves something
- Choose assets with a known failure history and a clear maintenance action.
- Agree up front what counts as a true alert, a false alarm and a missed failure.
- Run long enough to see real events; a quiet month proves nothing.
- Make the maintenance team co-owners. If they do not trust the alerts, they will not act on them.
FAQ
Do we need machine learning from day one?
No. Statistical baselines per operating mode catch many developing faults and are easier for maintenance teams to trust. Bring in machine learning once you have enough labelled events to show where simple rules fall short.
Cloud or on-premises?
Either works. Choose based on network reliability, data policies and who will run the system. Many plants keep alerting at the edge so it keeps working when the internet link does not.
How we approach this at Velura Labs
Our AI and data solutions team builds PdM stacks scoped to the failure modes that actually pay back, not the ones that look good on slides, with the underlying data platform handled by backend and infrastructure. Talk to us if your unplanned downtime is not falling despite a PdM investment, and we will give you an honest assessment.
Velura Labs delivers this for teams across the United States — Seattle (Washington), San Francisco and Los Angeles (California), Austin and Dallas (Texas), and New York — as well as Europe (Paris, Milan, Rome and the wider EU), the Middle East (Dubai, Abu Dhabi and Riyadh) and India. Talk to us wherever you operate.