Air Filter Prediction System
Predictive maintenance service
A production service that predicts AC air filter health from sensor data, built during an internship at Iinvsys with Flask REST APIs serving real-time predictions.
0+
Pipeline stages
0+
Model heads
0+
API endpoints
- Python
- Flask
- TSMixer
- REST APIs
- Docker
Problem
AC air filters were serviced on a fixed calendar schedule, which is wrong in both directions: clean filters get replaced early, and filters in dusty environments degrade well before their service date, quietly costing efficiency. The sensor data needed to tell the difference already existed but was not being used to decide anything.
- Fixed-interval servicing ignores actual operating conditions
- Degradation shows up in sensor trends before it shows up in symptoms
- Any prediction only matters if an application can consume it in real time
Solution
A service that turns sensor time series into two answers: a continuous health estimate and a discrete replace/do-not-replace classification. A TSMixer-based regression head handles the trend, a classification head handles the decision boundary, and both are exposed behind a Flask REST API so the surrounding systems can act on them.
- Regression pipeline estimating filter health over time
- Classification pipeline producing an actionable service decision
- Flask REST API serving predictions synchronously to client systems
- Web interface for visualising predictions against recent sensor history
Features
- Flask REST APIs with versioned prediction and health endpoints
- Real-time prediction serving with warm model loading
- Feature engineering over rolling sensor windows
- Production deployment with containerised, reproducible builds
- System integration with the existing data collection layer
- Monitoring support — request logging, latency and input drift signals
Architecture
Sensor readings land in storage, a preprocessing stage builds windowed features, and the Flask service loads trained artefacts once at startup and serves predictions over HTTP. Visualisation reads the same API.
Swipe sideways to see the full diagram · tapHover or focus a node to trace its outbound calls
Implementation
Most of the engineering effort went into the boundary between training and serving, which is where this class of system usually breaks.
- The same feature-engineering code path is used for training and inference, so the two cannot diverge
- Scalers and encoders are versioned alongside model weights and loaded as one artefact bundle
- Models load once at process start rather than per request, keeping latency predictable
- Input validation rejects malformed or out-of-range sensor windows before inference
- Endpoints return the prediction plus the model version that produced it, which makes results traceable
- Request/latency logging and basic input-distribution checks feed the monitoring layer
Challenges
Training/serving skew
The first deployment produced predictions that did not match validation results. The cause was a preprocessing difference between the notebook and the service. Extracting the transformation into a single shared module, imported by both, removed the class of bug entirely.
Latency under synchronous requests
Loading model artefacts per request made responses unusable. Moving to warm, process-lifetime model loading with a health endpoint to confirm readiness brought response times into a range the client systems could call inline.
Turning a continuous score into a decision
A health percentage is not an action. Pairing the regressor with a classifier, and reporting both, let the consuming system show a trend while still receiving an unambiguous replace/keep signal.
Deploying reproducibly
Python dependency drift made builds non-deterministic across machines. Pinning the environment and containerising the service made deployments repeatable, which mattered once other people needed to run it.
Result
The system was deployed during the internship and served predictions through its REST API to the surrounding application, with a web interface for inspecting predicted filter health against recent sensor history. My contribution spanned preprocessing, feature engineering, model training, API development and the deployment path.
Lessons Learned
The model was never the hard part. Reproducible environments, one shared preprocessing path, and versioned artefacts are what made it a service rather than an experiment. Next time I would put a schema contract on the sensor input from the first commit, because every ambiguity there eventually surfaced as a production bug.
Screens
Next project
Smart Career Guide
AI Resume & Job Matcher