The problem
An unplanned failure on an industrial conveyor stops a line, and a stopped line is expensive. Most mechanical failures announce themselves in advance, through changes in vibration and temperature that drift before a component breaks. The difficulty is that the signal only helps if something is watching it continuously, and people cannot watch sensor streams all day.
Detection is also only half of the job. Planners need to turn early warnings into maintenance schedules, which means pulling together sensor readings, maintenance history and documentation. That work is slow, and it is where a warning can easily turn into a missed opportunity.
What we built
A predictive maintenance system for industrial conveyors that addresses both halves: it detects anomalies in the sensor signal, and it gives planners retrieval and forecasting so they can act on what it finds. The work covered the machine-learning models, the LangGraph workflow and deployment on Databricks.
How it works
Anomaly detection
Models monitor vibration and temperature continuously and flag readings that depart from normal behaviour. The practical challenge is defining “normal”. A reading that is alarming for one conveyor may be ordinary for another, and normal behaviour shifts with load and conditions. Detection therefore has to learn what normal looks like rather than rely on fixed thresholds.
Forecasting
Detection says something is changing. Forecasting estimates where that change is heading, which is what lets planners schedule maintenance ahead of need rather than react after a breakdown.
Retrieval for planners
A LangGraph workflow lets planners ask questions and get answers grounded in the relevant data and documentation. Instead of assembling context by hand from several systems, a planner can ask about a flagged asset and receive an answer drawn from its readings, history and documentation.
Platform
The system is built in Python and deployed on Databricks, which suits the combination of large volumes of sensor data and machine-learning workloads.
Why combine detection with retrieval
Many predictive maintenance projects stop at detection and produce alerts. Alerts alone tend to fail in practice: they arrive without context, planners learn to distrust them, and they are eventually ignored. Pairing detection with retrieval means every warning arrives with the information needed to decide what to do about it. That is what turns a signal into a scheduled repair.
What the results mean
The system meant fewer unplanned stoppages and a shorter planning cycle. The first measures failures caught before they stopped the line. The second measures how much faster planners can move from warning to schedule, which is the retrieval half of the system doing its job.
Where it can go wrong
- Alert fatigue. Too many false alarms and people stop responding. Precision matters as much as coverage.
- Sensor faults. A failing sensor can look like a failing machine. The system has to distinguish the two.
- Grounding. Answers for planners must come from the actual data and documentation. A fluent answer that is wrong about a physical asset is dangerous.
When this approach fits
Predictive maintenance pays off where unplanned downtime is expensive, failures have measurable precursors, and there is enough sensor history to learn normal behaviour. Where failures are genuinely random, or downtime is cheap, scheduled maintenance may be the better choice.
Questions to ask before building one
If you are considering a system like this, these are the questions we would want answered first.
- How much sensor history do you have? Anomaly detection needs enough data to learn what normal looks like for each asset.
- What does an hour of unplanned downtime cost? That number decides whether predictive maintenance is worth the investment.
- What will planners do with an alert? Design the response alongside the detection, or alerts will be ignored.
- How will you tell a failing sensor from a failing machine? The system needs a way to separate the two.