Inspiration
Factories usually maintain machines in one of two ways: they wait for a breakdown, or they service on a fixed schedule. The first means unplanned downtime, and the second wastes parts and labour. Fixed-threshold alarms don't fix this, because they only fire once a reading is already out of range, which is often too late. We wanted to build a system that notices a machine drifting toward failure early, and tells the maintenance team why it was flagged.
What it does
PredMaintain is an industrial IoT predictive maintenance system. It:
- Streams high-frequency vibration, temperature, and acoustic sensor data in real time
- Detects subtle multivariate drift before physical damage occurs
- Predicts the specific failure mode, not just "something is wrong"
- Computes a Machine Health Index for each machine
- Explains every alert with SHAP root-cause attribution, so engineers can see which sensor signals drove the prediction
In simulation, it reduced downtime by 20% compared to fixed-threshold alarm baselines.
How we built it
- Ingestion: Sensor telemetry is published to Apache Kafka, which decouples producers from consumers and handles high-frequency streams.
- Storage: Readings are written to InfluxDB, a time-series database suited to sensor data.
- Anomaly detection: An LSTM autoencoder is trained on normal operating behaviour. A window of readings is flagged when its reconstruction error is large:
$$e_t = \lVert x_t - \hat{x}_t \rVert^2 > \tau$$
Because the autoencoder sees all channels at once, it catches multivariate drift that per-sensor thresholds miss.
- Failure-mode classification: An XGBoost classifier predicts which failure mode is developing.
- Explainability: SHAP values show which features pushed each prediction, giving maintenance teams a root cause to act on.
- Visualization: Grafana dashboards show live telemetry and machine health.
Challenges we ran into
- Few failure examples: Real failures are rare, which is why we trained the autoencoder on normal behaviour only and used the classifier for labelled failure modes.
- Choosing the alert threshold $\tau$: Too low and operators get alert fatigue, too high and failures slip through.
- Keeping the stream reliable: Getting Kafka, InfluxDB, and the model scoring to work together without dropping or delaying readings.
- Trust: A bare anomaly score isn't actionable, so explainability had to be part of the design.
Accomplishments that we're proud of
- A 20% reduction in simulated downtime versus fixed-threshold alarms
- An end-to-end pipeline from raw sensor stream to a dashboard with explained alerts
What we learned
- Unsupervised anomaly detection and supervised failure classification work well together
- Explainability decides whether engineers actually trust and use a model's alerts
- Streaming systems need as much design effort as the models running on them
What's next
Testing on real machine data, and learning per-machine thresholds that adapt over time.
Built With
- anomaly-detection
- apache-kafka
- autoencoder
- grafana
- influxdb
- iot
- lstm
- machine-learning
- matplotlib
- predictive-maintenance
- python
- scikit
- scikit-learn
- shap
- tensorflow
- xgboost
