Energieflexibilitäts-Dashboard
Ein interaktives Webtool, mit dem Unternehmen aus ihrem Lastgang ablesen können, wie viel Energiekosten sich durch das Verschieben flexibler Produktionsblöcke sparen lassen. Auftraggeberin war Fraunhofer, das Projekt entstand in Zusammenarbeit mit ihnen. Unten: eine eigene, vereinfachte Nachbildung des Prinzips mit erfundenen Daten.
Auftraggeberin war Fraunhofer; das Projekt entstand in Zusammenarbeit mit ihnen. Optimierungsmodell und fachliche Inhalte stammen von Fraunhofer, die Rechte daran liegen dort. Quellcode und Originaldaten sind vertraulich und nicht öffentlich; die Demo hier verwendet erfundene Daten.
Datenblatt
| Sachnummer | JS-2026-05 |
|---|---|
| Zeitraum | Wintersemester 2025/26 (Abgabe 12/2025) |
| Rolle | Einzelarbeit: Softwarearchitektur und Benutzeroberfläche |
| Werkzeuge | Python · Streamlit · pandas · NumPy · Plotly · TypeScript · SVG |
| Kernergebnis | Interaktive Simulation von Verschiebepotenzialen über ein ganzes Jahr (über 35.000 Viertelstundenwerte je Zeitreihe) |
| Status | Abgeschlossen (Seminararbeit Logistikmanagement) |
1Ergebnis
Zone B- Kosten ohne Optimierung
- 23 453 €
- Kosten mit Optimierung
- 19 490 €
- Einsparung (Jahr)
- 3 963 €
- Einsparung relativ
- 16,9 %
Jahresübersicht: Kosten je Monat
Kosten nach Optimierung Einsparung (darauf gestapelt: Gesamthöhe = Kosten ohne Optimierung)
Tagesansicht: Donnerstag, 31. Juli
81,70 € → 57,68 € · Einsparung 24,02 €
Gestrichelt: ursprüngliche Lage. Rot: nach der Optimierung. Der Verlauf oben ist der Strompreis dieses Tages.
2Problem und Motivation
Zone CEnergiepreise sind durch den Ausbau von Wind und Sonne von einer stabilen Planungsgröße zu einem schwankenden Risiko geworden; Einspeisung und Preise ändern sich innerhalb von Stunden. Energieflexibilität heißt, den Verbrauch an das Angebot anzupassen, ohne die Produktionsziele zu gefährden. Gerade kleine und mittlere Unternehmen haben zwar Lastgangdaten, aber keine Werkzeuge, um sie systematisch auszuwerten: Vorhandene Lösungen sind meist zu kompliziert oder zu theoretisch für den Alltag. Das Dashboard soll diese Lücke schließen.
3Aufbau
Zone D- 01Anforderungen: Kick-off, Interaktivität, Performance
- 02Frameworkwahl: React, Plotly Dash, Streamlit
- 03Architektur: Model, View, Controller
- 04Oberfläche: Info, Best Practice, Tools, Kontakt
- 05Performance: Caching und Vektorisierung
Zu Beginn stand ein Kick-off-Gespräch, das die Anforderungen festlegte: Nutzer sollen Parameter wie Verschiebedauer oder Preisannahmen ändern und sofort aktualisierte Ergebnisse sehen; die Software soll sauber aufgebaut, schnell und einfach zu bedienen sein; und die Simulation läuft über ein ganzes Jahr in Viertelstundenwerten (4 × 24 × 365 = 35.040 Punkte pro Zeitreihe). Verglichen wurden drei Ansätze: React mit Node.js (maximale Gestaltungsfreiheit, aber hoher Entwicklungs- und Wartungsaufwand), Plotly Dash (auf Visualisierung ausgelegt, bei Seiten mit viel Text und Bildern langsamer und weniger flexibel) und Streamlit. Gewählt wurde Streamlit: nahtlose Anbindung an pandas, die ganze Entwicklung in Python, schnelles iteratives Arbeiten und gut dokumentiert. Das Optimierungsmodell und die fachlichen Inhalte stellte Fraunhofer; mein Schwerpunkt war die Softwarearchitektur und die nutzerzentrierte Oberfläche.
4Prüfung
Zone EFunktionsprüfung bedeutete hier vor allem Performance: Nutzer sollen nach einer Parameteränderung nicht warten. Zwei Mechanismen sorgen dafür. Ein Adapter zwischen Oberfläche und Rechenkern legt Ergebnisse und Eingangsdaten im Arbeitsspeicher ab (Caching), und der Sitzungszustand merkt sich Ergebnisse und die aktive Seite über Seitenwechsel hinweg. Beim Start lädt ein Ladebalken die großen Datensätze schon im Hintergrund, sodass die Seiten danach ohne Verzögerung öffnen.
Fehlversuch
Der erste Ansatz berechnete die Verschiebung in Schleifen, Block für Block, und war über ein ganzes Jahr viel zu langsam. Die Lösung war die Vektorisierung mit pandas: große Datenblöcke werden gleichzeitig verarbeitet, statt jeden Datensatz einzeln. Außerdem wurden physikalische und wirtschaftliche Randbedingungen direkt in die Datenvorverarbeitung gelegt, etwa das Ausfiltern von Tagen ohne Produktion oder mit zu geringer Grundlast; die Tagesansicht weist darauf hin.
5Erkenntnis und nächste Iteration
Zone F- Trennung der Zuständigkeiten (Model-View-Controller): Der Rechenkern kennt die Oberfläche nicht, jede Seite ist eine eigene Datei, und ein Adapter vermittelt dazwischen. Das hält den Code übersichtlich und die Teile unabhängig.
- Progressive Enthüllung: Zuerst die aggregierte Jahresübersicht, Details bei Bedarf über Expander und Popover. So wird der Nutzer nicht von einer Textwand erschlagen.
- Ehrliche Diagramme: Statt Einsparungen künstlich zu skalieren, steht die Einsparung als gestapelter Balken auf den optimierten Kosten, die Gesamthöhe entspricht den ursprünglichen Kosten. So bleiben auch kleine Einsparungen sichtbar, ohne die Verhältnisse zu verzerren. Die Tagesansicht öffnet direkt mit dem Tag der größten Einsparung.
Nächste Iteration
Das Dashboard ist als erweiterbare Plattform angelegt; weitere Flexibilitätsmaßnahmen und Szenarien lassen sich als zusätzliche Module im Rechenkern ergänzen, ohne die Oberfläche umzubauen.
Technische Details: Projektstruktur und Datenfluss
app.py ist der bewusst minimale Einstiegspunkt: Er baut die Navigation (Seitenleiste) auf und lädt die passende Seite, ohne Berechnungslogik. Eine Sitzungsvariable merkt sich die aktive Seite, weil Streamlit bei jeder Interaktion das Skript neu ausführt.
Die Oberfläche besteht aus vier Seiten: Info und Best Practice (statische Inhalte mit Aufruf-zur-Aktion-Schaltflächen), Tools (Simulation mit Jahres- und Tagesansicht) und Kontakt (Formular, technisch vom Rest getrennt). Die Tools-Seite greift nie direkt auf Dateien oder den Rechenkern zu, sondern fragt den Adapter.
Der Adapter kapselt Aufrufe in Caching-Funktionen. Dahinter liegt die Rechenlogik: ein Daten-Lader (Dateien einlesen, Typen umwandeln) und der Optimierer als reine Python-Klasse ohne Streamlit-Code. Passwörter für den Mailversand liegen in einer geschützten Konfigurationsdatei und nicht im Code.