← ML Engineering & Deep Learning
Forecasting · deployed Live

Intelligent fuel consumption and warning system

Telecom sites in Cameroon were losing diesel and nobody could see where. This predicts what each site should burn and flags the clusters and sites whose predicted use stands out. Operators still run it.

Screen recording of the fuel prediction web app: uploading a dataset, mapping columns, and reading the resulting charts.

Overview

Stack: Python, Flask, Scikit-Learn, Pygal, Pandas
Deployment: Render.com
Result: Helped account for 84,617 liters of fuel, and cut reporting from days to seconds.

Telecom base stations in Cameroon run on diesel generators, because the grid goes down often and for long stretches. That means heavy fuel use, fuel going missing, and a logistics problem nobody could see clearly enough to fix. This project gave the operators the picture: what each site should burn, and which clusters and sites stand out from the rest.

Industry context and the challenge

In 2018 there was almost no machine learning work aimed at the power generation plants that remote sites depend on. The research pointed at automotive engines.

Carrying the methods across. I took the modeling techniques used for vehicle fuel consumption and adapted them to stationary generators. That produced one of the region's first predictive maintenance systems for telecom base stations.

The technical solution

1. The machine learning core

The first job was a baseline: what a site should consume, given its conditions.

  • Algorithm. A gradient-boosting regressor (Scikit-Learn, 600 trees of depth 2, learning rate 0.1). The file is still named Randomforest.pkl, from an earlier model.
  • Performance. Nash-Sutcliffe Efficiency (NSE) of 0.982, as reported in the repository README.
  • Deviation warning. The app sums the predictions per cluster and per site, then sets the threshold at the mean plus 2 standard deviations of those totals. A cluster or site above it gets flagged for investigation, and the team confirms the alert before it triggers maintenance or a logistics change. The point is a short gap between a deviation appearing and someone acting on it.

2. Engineering and architecture (Flask)

The application is deployed and running on Render.com.

fuel_prediction_app/
├── columns_app.py
├── config.py
├── pkl_objects/
│   └── Randomforest.pkl
├── uploads/
├── logs/
├── templates/
├── utils/
│   ├── file_utils.py
│   ├── validation_utils.py
│   ├── data_utils.py
│   ├── model_utils.py
│   ├── metrics_utils.py
│   ├── chart_utils.py
│   └── export_utils.py
└── routes/
    ├── main_routes.py
    ├── visualization_routes.py
    └── export_routes.py

Modular design
The application uses Flask Blueprints to keep API logic apart from visualization.

  • utils/ holds pure Python logic (validation, feature engineering) with no dependency on the web framework, so it can be unit tested outside a Flask context.
  • routes/ handles HTTP requests, with visualization routes kept separate from export routes so each file stays readable.
  • pkl_objects/ holds the gradient-boosting model, serialized with pickle and loaded into memory once at startup rather than per request.
  • Dynamic column mapping. Figure 1 shows it: the user maps their own dataset columns onto the model's inputs, so a spreadsheet with different headers works without preprocessing. Source files never named things the same way twice.
  • Charts in the browser. Pygal generates light SVG charts that stay interactive in the page.

What the dashboard shows

The application turns model output into 5 views a facility manager can act on, all reachable from the top navigation bar:

  • Cluster view. Fuel consumption aggregated by region.
  • Site view (top 20). The highest-consumption sites, so maintenance goes where it pays.
  • Comparison view. Cluster totals stacked by site, so a cluster's total can be traced to the sites that drive it.
  • Distribution analysis. Histograms showing the spread of fuel usage.
  • Time series. Consumption trends over time, which is where seasonal patterns show up.

Figure 2 shows predicted consumption per cluster, which is the fastest way to spot a cluster running hot.

Export and reporting
Audits and management presentations happen outside the app, so it exports what they need:

  • Raw data. CSV and Excel files for archiving and further analysis.
  • Charts. SVG files and 150 dpi PNG files that drop straight into a slide deck or a technical report.

Business value

  • Cost assurance. The discrepancies the system surfaced helped account for 84,617 liters of fuel. The time-series view is what makes a slow drift visible, alongside the seasonal swings and the one-off spikes.
  • Logistics. Fuel planning moved ahead of the problem, and emergency deliveries dropped.
  • Efficiency. Automated log ingestion cut reporting from days to seconds.

MLOps: monitoring in production

A model that ships without monitoring is a model nobody can trust 6 months later. The application carries a monitoring dashboard that reports on the pipeline while it runs:

  1. Model performance. The NSE score on the current batch, computed when the upload carries consumption history (0.9217 on the batch in Figure 4), so a drop against the 0.982 reference is visible rather than inferred.
  2. System health. API success rates and processing latency.
  3. Cache statistics. The state of the server-side cache, which is what keeps large datasets from timing out on the Render.com free tier.
  • Python
  • Flask
  • Scikit-Learn
  • Pygal
  • Pandas
  • Joblib
  • Render.com