We'll get back to you within 24 hours.
We built an IIoT + ML predictive maintenance system for a Pune auto parts manufacturer — analyzing vibration, temperature, and current sensor data to predict failures 48–72 hours in advance and trigger preventive maintenance.
Industry Context
India's manufacturing sector is undergoing a fundamental transformation driven by the twin pressures of global competitiveness and domestic supply chain expectations. The automotive component industry — which contributes over ₹4.2 lakh crore to GDP annually — is particularly exposed to the cost consequences of unplanned downtime. According to FICCI's Manufacturing Competitiveness report, Indian auto component manufacturers lose an average of 8–11% of potential production output to unplanned equipment failures annually. For a mid-sized plant running at ₹200 Cr revenue, that translates to ₹16–22 Cr in preventable lost output each year. The global Industry 4.0 wave is accelerating this reckoning. Across Germany, Japan, and South Korea, predictive maintenance adoption has crossed 60% of major auto component OEMs. India's adoption, by contrast, sits at roughly 12% according to CII's Smart Manufacturing Survey 2023 — leaving an enormous competitive gap that early adopters can exploit. The shift from preventive to predictive maintenance is not merely a technology upgrade; it is a fundamental change in the relationship between a factory and its machines. Calendar-based preventive maintenance — "service the spindle every 1,000 hours regardless of condition" — wastes maintenance resources on machines that don't need attention while missing machines that are deteriorating rapidly. Condition-based predictive maintenance replaces the calendar with real data: vibration signatures, thermal profiles, current draw patterns, and acoustic emissions that tell you what the machine is actually experiencing, not what the schedule says it should experience. For the Indian auto parts sector specifically, OEM supply contracts are increasingly including uptime guarantees and penalty clauses. Tier-1 suppliers to Maruti, Tata, and Mahindra face penalties of ₹5–10 lakh per day for supply disruptions. This makes unplanned downtime not merely an operational inconvenience but a contract liability.
FICCI data shows Indian auto component plants lose 8–11% of potential annual output to unplanned equipment failures — equivalent to ₹16–22 Cr in lost revenue for a mid-sized plant. This is largely preventable with modern predictive maintenance systems deployed on critical production assets.
CII's Smart Manufacturing Survey 2023 finds that only 12% of Indian auto component manufacturers have deployed any form of predictive or condition-based maintenance. Global competitors in Germany and Japan are at 60%+, creating a significant gap in machine uptime efficiency that is reflected in cost-per-unit comparisons.
McKinsey's industrial maintenance research consistently finds that emergency repair costs average 5–8 times the cost of planned maintenance on the same failure. A bearing replacement scheduled during downtime costs ₹80,000. The same bearing failing catastrophically during production — damaging the spindle, causing oil contamination, requiring emergency spare procurement — costs ₹4–6 lakh.
The Challenge
Our Solution
We deployed vibration, temperature, and current sensors on 24 critical machines and built ML models that detect failure precursors before they're visible to humans.
We installed triaxial vibration sensors (accelerometers sampling at 1kHz), PT100 temperature probes at bearing housings and motor windings, and clip-on current transformers on all three phases of each motor drive. Twenty-four machines were instrumented across the three production lines, with sensor selection specific to each machine's failure modes. All sensors connect via industrial-grade Modbus RTU cabling to local data acquisition units, which then transmit to edge computing nodes via MQTT over the plant's dedicated industrial WiFi network. The decision to use wired sensors (rather than wireless) for the vibration measurements was deliberate: at 1,000 samples per second, wireless bandwidth requirements would have overwhelmed even a high-end industrial WiFi network. Each edge node handles 6 machines and performs local signal processing — FFT (Fast Fourier Transform) conversion of raw vibration signals into frequency domain data — before transmitting feature vectors rather than raw waveforms to the central server. This reduces data transmission by 94% while preserving the diagnostic information that matters.
ML models learned each machine's normal operating signature during a 30-day baseline period. This is not a generic "healthy machine" model pulled from a textbook — it is a model trained specifically on Machine 7 in Plant 2 running at 1,450 RPM with the specific tooling configuration used on that shift. The distinction matters enormously. A generic model raises false alarms every time a machine runs a different product or speed; a machine-specific model understands that vibration increases slightly at changeover and discounts it accordingly. We used Isolation Forest and Autoencoder architectures for anomaly detection — both excel at detecting "this pattern is unusual for this machine" without requiring labeled failure data (which is scarce in the early months). Anomaly scores are calculated every 5 minutes and stored in InfluxDB alongside the raw feature vectors, creating a full time-series history for each machine. During the baseline period, the system runs in "shadow mode" — generating alerts but not distributing them — while we validate that the anomaly detection is sensitive to real changes and not reacting to normal operational variation.
A second-layer model classifies anomalies by failure type (bearing wear, imbalance, electrical fault, overheating) and predicts time-to-failure with 91% accuracy across the failure types trained. This layer was trained on a combination of the client's historical failure records (22 incidents, each with sensor data going back 2 weeks before failure), published bearing vibration signature datasets from SKF and Schaeffler, and synthetic failure data generated by progressively degrading machine parameters in our simulation environment. The model uses a Random Forest classifier for failure type identification (which is highly interpretable — the maintenance engineer can see exactly which frequency bands triggered the classification) and an LSTM network for time-to-failure prediction (which captures the temporal trajectory of degradation, not just the current state). When a failure prediction is generated, the output includes: failure type, confidence score, estimated time to failure (range), recommended maintenance action, and the top 3 sensor readings driving the prediction. This last element — the explainability — was critical to maintenance team adoption. Engineers didn't trust a black box; they trusted a system that could show its reasoning.
Predicted failures auto-create maintenance work orders in SAP PM, notify the maintenance engineer via WhatsApp with failure type and suggested action, and schedule parts procurement if needed. The SAP PM integration uses a custom ABAP function module that accepts the prediction payload (machine ID, failure type, severity, predicted time window) and creates a PM order with the appropriate maintenance activity type, work center, and estimated materials. If the required spare part has inventory below the predicted need, a purchase requisition is automatically created — giving procurement a 48–72 hour window to source the part before the emergency. The WhatsApp notification is contextual: it includes the machine name, current anomaly readings, failure probability, recommended action, and a link to the Grafana dashboard showing the machine's trend for the past 7 days. The maintenance supervisor can acknowledge the alert, escalate it, or snooze it (with a mandatory reason code) — all via WhatsApp reply, without opening a separate system. This conversational interface was a key usability decision: maintenance engineers in the plant were already on WhatsApp all day; we met them where they were.
Implementation Timeline
The project followed a structured six-phase rollout designed to minimize disruption to production schedules while building confidence in the system before full deployment.
Month 1 focused entirely on getting the right hardware in the right places without disrupting production. We conducted a detailed criticality assessment of all 47 machines in the plant, ranking them by downtime impact and failure frequency. The top 24 machines (those responsible for 89% of historical downtime) were selected for instrumentation. Hardware procurement included vibration sensors, temperature probes, current transformers, edge computing units (Raspberry Pi 4 with industrial enclosures), and MQTT broker infrastructure. All installation was completed over 4 weekends to avoid production impact. Factory electrical team was involved from day one — they needed to understand and trust the system they would eventually maintain.
Month 2 established the data pipeline. Six edge computing nodes (one per 4 machines) were commissioned, each running Mosquitto MQTT broker, our custom signal processing pipeline, and a local InfluxDB instance for buffering during network outages. The central InfluxDB cluster was deployed on a dedicated industrial server in the plant IT room. Grafana dashboards were configured for real-time monitoring of all 24 machines' sensor readings. Network reliability was critical — the plant's existing WiFi was supplemented with a dedicated industrial WLAN infrastructure with redundant access points to ensure sensor data was never lost due to connectivity issues.
Month 3 was the baseline learning period. All 24 machines ran under normal production conditions while the system captured their unique operational signatures across the full range of products and speeds they run. The 30-day window was chosen deliberately to capture at least one cycle of the client's production rotation — ensuring the baseline included every product type, shift pattern, and ambient temperature condition. Data quality validation ran daily: we checked for sensor dropouts, anomalous readings (likely sensor installation issues), and completeness. Three sensors required repositioning during this month after reviewing the baseline data and identifying unexpected noise sources.
With 30 days of clean baseline data plus the client's historical failure records, model training commenced in Month 4. Anomaly detection models (Isolation Forest + Autoencoder) were trained for each machine individually. Failure classification models were trained on the combined dataset of historical failures plus published bearing signature datasets. Models were validated using a held-out test set constructed from the 2 weeks of sensor data preceding each of the 22 historical failures — ensuring the model could have predicted those failures had it been running at the time. By end of Month 4, the shadow-mode system had already flagged 3 machines showing anomalous patterns — the maintenance team investigated and confirmed early signs of bearing wear on two of them.
Month 5 connected the prediction models to the maintenance workflow. SAP PM integration was built and tested by the client's SAP team in a sandbox environment before deployment to production. The WhatsApp notification system was tested with the maintenance supervisor and two senior engineers to calibrate alert sensitivity — too many alerts create noise; too few create false confidence. Alert thresholds were tuned based on 3 weeks of parallel running. The maintenance team's response protocols were documented: which alert levels required immediate response, which could wait for the next shift, and how engineers should escalate unresolved alerts. Training sessions for all 11 maintenance engineers covered the dashboard, alert interpretation, and response workflows.
Results
In the 12 months following full deployment, the system predicted and enabled preventive maintenance on 12 failures that would have become major unplanned stoppages under the old reactive regime. These included 7 bearing failures across the CNC turning centers, 3 hydraulic pump degradations on the press lines, and 2 motor insulation failures on the grinding machines. Average lead time between alert and planned maintenance action was 54 hours — well within the 48–72 hour window we designed for. The maintenance team executed each intervention during scheduled maintenance windows, eliminating the chaos of emergency repairs. Estimated downtime prevented: 63 hours, valued at ₹5.04 Cr in preserved production capacity.
Total unplanned downtime fell from 180 hours in the pre-deployment year to 117 hours in Year 1 — a 35% reduction. The remaining downtime was concentrated in two machines that were not included in the initial 24-machine deployment (they were added in Year 2). The trend is strongly positive: as the failure prediction model accumulates more failure event data specific to this plant, accuracy continues to improve. The client's Year 2 target is fewer than 60 hours of unplanned downtime — a further 49% reduction from the Year 1 result. Based on the model's current accuracy trajectory and the Year 2 expansion to all 47 machines, this target is achievable.
Planned maintenance on early-stage failures costs 5–8 times less than emergency repairs on catastrophic failures. When a bearing is caught at 15% degradation and replaced in a planned window, total cost is typically ₹60,000–80,000 in parts and 4 hours of labor. The same bearing failing at 100% degradation damages the spindle housing, contaminates the oil, and often requires a complete spindle rebuild — total cost ₹4–6 lakh, plus 12–18 hours of emergency overtime. Across 12 interventions in Year 1, repair cost reduction totaled ₹1.2 Cr. Year 2 savings are tracking higher as the expanded machine set adds more prevention opportunities.
The human impact of this project extended well beyond cost savings. The maintenance engineering team — 11 technicians ranging from 3 to 22 years of experience — now interact with machine data daily. The senior supervisor's tacit knowledge has been partially codified into the model's failure type classifications: his intuitions about which vibration patterns preceded which failure modes were captured through structured interviews and incorporated into the training data labeling process. Newer engineers describe the system as an "always-on experienced mentor" — a description that captures something profound about how AI can preserve and distribute expert knowledge in an industrial setting. Team morale improved significantly as engineers shifted from emergency firefighting to proactive, planned work.
ROI Breakdown
The return on investment calculation for this project is unusually straightforward because downtime costs are well-documented in automotive component manufacturing. The client tracked downtime meticulously for OEM reporting purposes, giving us accurate baseline data to work from. The cost of the system — ₹38 lakh including hardware, software development, integration, and first-year support — was recovered in the first 3 months of operation through prevented downtime alone. Year 1 blended ROI across all benefit categories is approximately 16x the system investment, making this one of the highest-confidence AI investments available to a manufacturing company.
| Benefit Category | Calculation | Annual Value |
|---|---|---|
| Prevented downtime losses | 63 hours prevented × ₹8L/hour production value | ₹5.04 Cr |
| Repair cost reduction | Planned vs emergency repair cost differential × 12 incidents | ₹1.20 Cr |
| Spare parts inventory optimization | Safety stock reduction from predictive ordering (estimated) | ₹18 L |
| OEM penalty clause avoidance | Supply disruption penalties avoided (estimated from contract) | ₹45 L |
| Total Annual Benefit | ₹6.87 Cr | |
| System Investment (Year 1) | Hardware + development + integration + support | ₹38 L |
| Net Year 1 Return | 16x ROI — payback in under 3 months | ₹6.49 Cr net |
Tech Stack
FAQ
Related Services
Get a free assessment of your production line. We'll identify the top 5 machines most at risk and show you the ROI of predictive maintenance.
Get Free Maintenance AI Assessment