Why predictive maintenance is a product problem, not only an ML problem
Unplanned downtime is expensive, but the harder challenge is deciding which asset needs attention, when, and why. Preventive maintenance replaces components on a calendar; reactive maintenance waits for failure. Predictive maintenance uses operating data to estimate degradation early enough for a team to inspect, repair, or schedule a replacement.
For Indian manufacturers and industrial software founders, the opportunity is substantial across pumps, compressors, motors, CNC machines, transformers, fleets, rail assets, and renewable-energy equipment. Yet a useful system is not created by attaching sensors and training a neural network. It must fit plant workflows, tolerate unreliable connectivity, explain its recommendations, and prove that an alert changed an operational outcome.
The strongest products start with one asset class and one costly failure mode. A focused system for motor-bearing failure is easier to validate than a generic platform claiming to monitor every machine.
Define the maintenance decision first
Begin with the decision your customer wants to improve:
- Inspection prioritisation: Which asset should a technician inspect today?
- Failure-risk alerting: Is the probability of failure unusually high in the next seven or 30 days?
- Remaining useful life (RUL): How much operating time remains under current conditions?
- Work-order planning: When should labour, a spare, and a shutdown slot be booked?
- Fleet comparison: Which sites or machines are deteriorating faster than their peers?
This definition determines the data, model, interface, and evaluation metric. If the customer only has a few documented failures, do not promise precise RUL forecasts. Start with ranked anomaly alerts and validate whether technicians find real issues faster. For infrastructure operators, the same principles apply to specialised use cases such as AI predictive maintenance for railway infrastructure assets.
Reference architecture for an industrial AI system
A production system usually contains six connected layers.
1. Asset and sensor layer: Collect vibration, temperature, current, pressure, acoustic, oil-quality, or position data. Add operating context such as load, speed, ambient temperature, production batch, and runtime.
2. Edge gateway: Buffer readings, timestamp events, run basic quality checks, and continue operating during network outages. Industrial sites should not depend on continuous cloud connectivity for safety-critical decisions.
3. Ingestion and storage: Use protocols such as MQTT or OPC UA at the plant boundary, then stream validated events into a time-series database or lakehouse. Preserve raw data separately from cleaned and aggregated features.
4. Feature and labelling layer: Align sensor windows with inspections, breakdowns, component changes, and maintenance notes. Record asset identity and replacement history carefully; a model cannot learn degradation if sensor data is attached to the wrong machine.
5. Model and decision layer: Produce anomaly scores, failure probabilities, RUL ranges, or recommended inspection actions. Include confidence and the evidence behind each alert.
6. Workflow layer: Push alerts into a CMMS, ERP, email, messaging channel, or technician application. A prediction has no business value if it remains in a dashboard nobody uses.
For teams building the platform with open-source components, the engineering discipline described in building high performance AI applications with open source tools is relevant: keep interfaces modular, monitor latency and cost, and design for reproducible deployments.
Select models according to data maturity
Anomaly detection for the cold start
Most plants have abundant normal-operation data and very few labelled failures. Isolation Forest, robust statistical baselines, One-Class SVM, and autoencoders can learn normal behaviour. Use operating-state segmentation first: a pump starting up should not be compared with the same pump at steady load.
Anomaly detection is useful for discovering unknown failure modes, but an anomaly is not automatically a fault. Combine the score with persistence rules, sensor-quality checks, and engineer review before creating a work order.
Supervised classification and risk scoring
If maintenance records identify failure types and lead times, use gradient-boosted trees, calibrated logistic regression, or temporal models to estimate near-term risk. Handle class imbalance with appropriate sampling and threshold selection rather than relying on accuracy. Precision at the number of inspections a team can actually perform is often more useful than a generic F1 score.
RUL and time-to-event modelling
RUL regression requires consistent run-to-failure histories, which are uncommon in well-maintained Indian plants. Consider survival models or degradation curves when censoring is significant—that is, many assets are repaired or replaced before failure. Report a range and confidence level, not a falsely precise date.
Deep sequence models can help with high-frequency signals and long histories, but they should earn their complexity. A gradient-boosted model using well-designed vibration and load features is often easier to deploy, explain, and maintain than an LSTM.
Build the data foundation before scaling sensors
A practical pilot needs an asset register, sensor map, event taxonomy, and maintenance-history format. Standardise identifiers across SCADA, ERP, CMMS, and spreadsheets. Capture not only breakdowns but also inspections that found no issue, parts replaced preventively, operating conditions, and the time between alert and intervention.
Sensor placement matters as much as sensor selection. A vibration sensor mounted poorly can create more noise than signal. Establish sampling rates based on the failure mode: low-frequency temperature trends and high-frequency bearing signatures need different collection strategies. Add automated checks for missing readings, flatlined sensors, clock drift, impossible values, and calibration changes.
India-specific deployment conditions deserve explicit design attention. Plants may operate in heat, dust, humidity, or unstable power environments; factories outside major metros may have limited connectivity; and technicians may prefer mobile or vernacular instructions over a desktop dashboard. For civil and transport assets, lessons from real-time bridge health monitoring systems in India illustrate why sensing, field operations, and reliability engineering must be designed together.
Evaluate alerts in operational terms
Offline model metrics are necessary but insufficient. Run a time-based evaluation that prevents future data from leaking into training. Measure:
- Lead time before confirmed failure or intervention
- Precision among the top alerts reviewed by technicians
- False alerts per asset per month
- Missed critical failures
- Inspection hours saved
- Downtime avoided and spare-parts cost reduced
- Alert acknowledgement and work-order completion rates
Use a silent or shadow deployment first. Compare the model’s recommendations with existing maintenance practice, then run a controlled pilot on selected assets. Account for intervention cost: an alert that requires a shutdown may need a much higher confidence threshold than one that triggers a visual inspection.
Explainability, safety, and governance
Maintenance teams need evidence, not a score. Show the trend that changed, the relevant operating state, comparable historical episodes, and the sensors contributing most to the alert. SHAP can help explain tabular models, while signal-level visualisations can show changes in frequency bands or temperature gradients. Treat explanations as decision support, not proof of causality.
Set clear boundaries: predictive maintenance should not directly override safety interlocks or autonomous controls without a separate safety case. Log model versions, data windows, alert thresholds, user actions, and outcomes. Protect plant data with role-based access, encryption, network segmentation, and retention policies. If a generative assistant is added later, constrain it to approved maintenance documents and machine records; building distributed systems with AI agents offers useful architectural context, but an agent should not invent a diagnosis or issue an unsafe command.
A realistic roadmap for Indian builders
Weeks 1–4: Scope the wedge. Choose one asset class, one site, and one measurable failure or inspection problem. Interview maintenance supervisors and quantify downtime, labour, and spare-part costs.
Weeks 5–10: Instrument and baseline. Connect existing SCADA data where possible, retrofit only the sensors required, create data-quality checks, and establish rule-based or statistical baselines.
Weeks 11–16: Pilot the decision loop. Train a small set of models, deliver alerts through the customer’s existing workflow, and have technicians label outcomes. Track false positives openly.
After validation: Scale carefully. Add sites only after accounting for sensor variation, machine configuration, seasonal conditions, and changes in operating regimes. Offer deployment options that support on-premises or edge processing when data residency or connectivity requires it.
A strong industrial AI company usually wins through integration, domain knowledge, and trusted outcomes rather than model novelty. Its moat may be a clean failure taxonomy, years of labelled interventions, reliable retrofitting, or deep integration with procurement and maintenance workflows.
FAQ
Can I start without failure data? Yes. Begin with normal-operation baselines and anomaly detection, while building a disciplined failure and intervention log. Do not market anomaly scores as guaranteed failure predictions.
How many sensors are needed? There is no universal number. Instrument the failure mechanism, validate placement, and add context sensors only when they improve decisions. Existing PLC, SCADA, and maintenance data may be more valuable than an unnecessarily large sensor rollout.
Should I use cloud or edge AI? Use a hybrid design in most cases. Edge systems handle buffering, quality checks, and low-latency actions; cloud infrastructure supports fleet analytics, retraining, and reporting. Safety-critical controls should remain governed by industrial control systems.
How should ROI be calculated? Compare avoided downtime, reduced emergency work, longer component life, lower inventory, and technician productivity against sensors, integration, software, connectivity, and change-management costs. Validate benefits against a baseline, not a best-case estimate.
For Indian founders developing industrial AI, AI Grants India can help identify funding and ecosystem support as you move from a validated pilot to a deployable product.