Intelligentes Prognose- und Warnsystem für den Kraftstoffverbrauch
Telekomstandorte in Kamerun verloren Diesel, und niemand sah wo. Das System sagt vorher, was ein Standort verbrauchen sollte, und meldet die Standorte, die mehr verbrauchen. Der Betrieb nutzt es bis heute.
Überblick
Stack: Python, Flask, Scikit-Learn, Pygal, Pandas
Betrieb: Render.com
Ergebnis: 84 617 Liter Kraftstoff nachgewiesen, und die Berichtszeit von Tagen auf Sekunden gesenkt.
Telekom-Basisstationen in Kamerun laufen auf Dieselgeneratoren, weil das Netz oft und lange ausfällt. Das bedeutet hohen Kraftstoffverbrauch, verschwindenden Kraftstoff und ein Logistikproblem, das niemand klar genug sah, um es zu lösen. Dieses Projekt hat dem Betrieb das Bild gegeben: was ein Standort verbrauchen sollte, und welche Standorte mehr verbrauchen.
Der Branchenkontext und die Aufgabe
2018 gab es fast keine Arbeit mit Machine Learning zu den Kraftwerken, von denen abgelegene Standorte abhängen. Die Forschung zielte auf Fahrzeugmotoren.
Die Methoden übertragen. Ich habe die Modellierungstechniken für den Kraftstoffverbrauch von Fahrzeugen genommen und auf stationäre Generatoren übertragen. Daraus wurde eines der ersten Systeme zur vorausschauenden Wartung von Telekom-Basisstationen in der Region.
Die technische Lösung
1. Der Kern im Machine Learning
Die erste Aufgabe war eine Referenz: was ein Standort unter seinen Bedingungen verbrauchen sollte.
- Algorithmus. Ein Random-Forest-Regressor (Scikit-Learn).
- Güte. Nash-Sutcliffe-Effizienz (NSE) von 0,986.
- Abweichungswarnung. Die Schwelle liegt beim Mittelwert plus 2 Standardabweichungen. Ein Standort darüber wird zur Prüfung gemeldet, und das Team bestätigt die Meldung, bevor sie eine Wartung oder eine Änderung in der Logistik auslöst. Ziel ist eine kurze Spanne zwischen der Abweichung und dem Handeln.
2. Technik und Architektur (Flask)
Die Anwendung läuft im Betrieb auf Render.com.
fuel_prediction_app/
├── columns_app.py
├── config.py
├── pkl_objects/
│ └── filename.joblib
├── 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 Ein modularer Aufbau
Die Anwendung nutzt Flask Blueprints, um die API-Logik von der Visualisierung zu trennen.
- utils/ hält reine Python-Logik (Validierung, Feature-Engineering) ohne Abhängigkeit vom Web-Framework, also außerhalb eines Flask-Kontexts testbar.
- routes/ verarbeitet die HTTP-Anfragen, mit getrennten Routen für Visualisierung und Export, damit jede Datei lesbar bleibt.
- pkl_objects/ hält das Random-Forest-Modell, mit Joblib serialisiert und beim Start einmal in den Speicher geladen statt bei jeder Anfrage.
- Dynamische Spaltenzuordnung. Abbildung 1 zeigt sie: Nutzende ordnen die Spalten ihres eigenen Datensatzes den Eingaben des Modells zu, also funktioniert eine Tabelle mit anderen Überschriften ohne Vorverarbeitung. Die Quelldateien haben die Dinge nie zweimal gleich benannt.
- Diagramme im Browser. Pygal erzeugt leichte SVG-Diagramme, die in der Seite interaktiv bleiben.
Was das Dashboard zeigt
Die Anwendung macht aus der Modellausgabe 4 Ansichten, auf die eine Betriebsleitung reagieren kann, alle über die obere Navigation erreichbar:
- Cluster-Ansicht. Der Kraftstoffverbrauch, nach Region zusammengefasst.
- Standort-Ansicht (Top 20). Die Standorte mit dem höchsten Verbrauch, damit die Wartung dorthin geht, wo sie sich lohnt.
- Verteilungsanalyse. Histogramme zur Streuung des Verbrauchs.
- Zeitreihen. Verbrauchsverläufe über die Zeit, dort zeigen sich die saisonalen Muster.
Abbildung 3 zeigt den prognostizierten Verbrauch je Cluster, und das ist der schnellste Weg, ein auffälliges Cluster zu erkennen.
Export und Berichte
Audits und Präsentationen für die Leitung finden außerhalb der Anwendung statt, also exportiert sie, was dafür gebraucht wird:
- Rohdaten. CSV- und Excel-Dateien für die Archivierung und weitere Auswertungen.
- Diagramme. SVG- und PNG-Dateien in hoher Auflösung, die direkt in eine Präsentation oder einen technischen Bericht passen.
Der betriebliche Nutzen
- Kostensicherheit. Über die Abweichungen, die das System sichtbar machte, ließen sich 84 617 Liter Kraftstoff nachweisen. Die Zeitreihenansicht macht eine langsame Drift sichtbar, neben den saisonalen Ausschlägen und den einzelnen Spitzen.
- Logistik. Die Kraftstoffplanung kam dem Problem zuvor, und die Notlieferungen gingen zurück.
- Effizienz. Die automatische Aufnahme der Protokolle senkte die Berichtszeit von Tagen auf Sekunden.
MLOps: Monitoring im Betrieb
Ein Modell, das ohne Monitoring live geht, ist ein Modell, dem nach 6 Monaten niemand mehr traut. Die Anwendung bringt ein Monitoring-Dashboard mit, das über die laufende Pipeline berichtet:
- Modellgüte. Der NSE-Wert auf dem aktuellen Datenstand (0,981), damit ein Abfall gegenüber den 0,986 aus dem Training sichtbar wird statt erschlossen.
- Systemzustand. Die Erfolgsquoten der API und die Verarbeitungslatenz.
- Cache-Kennzahlen. Der Zustand des serverseitigen Caches, der große Datensätze auf der Gratisstufe von Render.com vor Zeitüberschreitungen bewahrt.