Kraftwerksfahrplan-Optimierung mit KI
Unit Commitment und Economic Dispatch: Welche Kraftwerke laufen wann, in welcher Leistungsstufe, zu welchen Grenzkosten? ML-Modelle optimieren den Einsatz thermischer Anlagen und Speicher kontinuierlich auf Spotmarktpreise, CO₂-Kosten und Netzengpässe — und erzielen 2–5% besseres Betriebsergebnis.
Es ist Mittwoch, 13:30 Uhr. Petra, Disponentin im Kraftwerkseinsatz bei einem regionalen Energieversorger mit 1,2 GW thermischer Kapazität in Süddeutschland, öffnet den Day-Ahead-Preis-Feed für Donnerstag. Die EPEX-Stunde 7 kostet 91 Euro/MWh, Stunde 15 nur 38 Euro/MWh, Stunde 21 wieder 87 Euro/MWh. Gas steht bei 32 Euro/MWh, CO₂-Zertifikate bei 68 Euro pro Tonne. Sie öffnet das Kalkulationstool, das ihr Vorgänger vor sieben Jahren in Excel gebaut hat.
Das Tool berechnet Grenzkosten für drei GuD-Blöcke, ein Heizkraftwerk und eine Pumpspeicher-Einheit. Was es nicht kann: die gegenseitige Abhängigkeit zwischen Spot-Fahrplan und FCR-Vorhaltung berechnen. Was Petra heute Mittag nicht weiß: Sie hat Kapazität für FCR-Vorhaltung, die über regelleistung.net (beim zuständigen Übertragungsnetzbetreiber TransnetBW/TenneT) angemeldet werden müsste — aber das Tool zeigt ihr das nicht. Sie plant konservativ, meldet nichts an.
Donnerstag, 7 Uhr: Strom kostet 91 Euro/MWh. Alle drei GuD-Blöcke laufen auf 100%. Pumpspeicher entleert sich maximal. Optimal — aber FCR-Vorhaltung wurde verschenkt. Erlöspotenzial aus Regelenergie Donnerstag: ca. 12.000 Euro. Nicht realisiert, weil das Kalkulationstool die Kopplung nicht abbildet.
Über ein Jahr, auf drei Anlagen: Das ist der Unterschied zwischen einer manuell optimierten und einer ML-optimierten Einsatzplanung.
Das echte Ausmaß des Problems
Im deutschen Stromsystem entscheidet die Merit Order, welche Kraftwerke zu welcher Stunde Strom erzeugen: Die günstigsten Erzeuger laufen zuerst, die teuersten werden nur dann zugeschaltet, wenn der Bedarf es erfordert. Wer seine Erzeugungskosten falsch einschätzt oder seine Grenzkosten nicht optimal positioniert, verliert täglich Marge — ohne es direkt zu sehen.
Für einen Versorger mit 800 MW thermischer Erzeugung und einem Durchschnitts-Day-Ahead-Preis von 70 Euro/MWh bedeuten 2% schlechtere Fahrplanoptimierung bei 6.000 Volllaststunden jährlich: 800 MW × 6.000 h × 70 €/MWh × 0,02 = 6,72 Mio. Euro jährlich verschenktes Optimierungspotenzial. Das ist die konservative Schätzung — ohne die zusätzlichen Erlöse aus Regelenergiemärkten.
Regelenergie macht die Komplexität noch größer. FCR (Primärregelleistung), aFRR (automatische Sekundärregelleistung) und mFRR (manuelle Tertiärregelleistung) bieten bei richtiger Vorhaltung erhebliche Zusatzerlöse — aber sie binden Kapazität, die nicht mehr für den Day-Ahead-Markt verfügbar ist. Gleichzeitig kann dieselbe Kapazität nicht doppelt genutzt werden. Die Optimierung über mehrere Märkte hinweg — Spot, Intraday, FCR, aFRR, mFRR — überfordert manuelle Planungstools strukturell.
Ein veröffentlichtes Forschungsprojekt (Applied Energy, 2023) zeigt: Die Kombination aus Mixed Integer Programming und Machine Learning in Form von Deep Reinforcement Learning für Unit Commitment in Niedrigemissions-Energiesystemen reduziert die Optimierungskosten gegenüber reinen MIP-Ansätzen um 8–48% — je nach Systemgröße und erneuerbarer Durchdringung. In Deutschland, wo volatile Erneuerbare zunehmend die Spotpreise bewegen, ist der Effekt besonders relevant.
Mit vs. ohne KI — ein ehrlicher Vergleich
| Kennzahl | Manuelle / regelbasierte Planung | ML-optimierter Fahrplan |
|---|---|---|
| Berücksichtigte Märkte simultan | Spot oder Regelenergie, selten beide | Spot + FCR + aFRR + mFRR simultan optimiert |
| Reaktionszeit auf Intraday-Preisentwicklung | Stunden (manuelle Anpassung) | Minuten (automatisches Redispatch) |
| Berücksichtigung von Mindestlaufzeiten und Anlaufkosten | Vereinfacht oder ignoriert | Vollständig als Hard Constraint modelliert |
| CO₂- und Gaspreisintegration | Tagesparameter, manuell gepflegt | Echtzeit-Integration aus Marktdaten-Feeds |
| Betriebsergebnis-Optimierungstiefe | Erfahrungsbasiert, 60–75% des Optimums | 85–92% des theoretischen Optimums (backtested) |
Einschätzung auf einen Blick
Zeitersparnis — mittel (3/5) Disponenten werden entlastet — weniger manuelle Iterationsschleifen, weniger zeitkritische Entscheidungen unter Zeitdruck. Aber der Dispatch-Planungsprozess läuft sowieso täglich, mit oder ohne Optimierungssystem. Die Zeitersparnis ist real, aber sie ist nicht der Haupthebel — das Betriebsergebnis ist es.
Kosteneinsparung — sehr hoch (5/5) Bei GW-großen Erzeugungsportfolios sind 2–5% Optimierungsverbesserung ein dreistelliger Millionenbetrag pro Jahr. Kein anderer Anwendungsfall in der Energiebranche hat einen vergleichbar direkten und großen absoluten Kostenhebel. Kleinere Versorger sehen entsprechend kleinere absolute Effekte, aber die relative Verbesserung ist strukturell ähnlich.
Schnelle Umsetzung — sehr langsam (1/5) Das ist das aufwändigste Implementierungsprojekt in der gesamten Kategorie. Datenintegration zwischen ERP, SCADA, Trading-System und Marktdaten-Feeds, Modellierung aller Anlagentechnik-Constraints, Validierung gegen historische Einsatzdaten, Parallelbetrieb, Disponent-Akzeptanz — realistisch 12–18 Monate bis produktivem Vollbetrieb.
ROI-Sicherheit — hoch (4/5) Backtesting ist die Methode: Das Modell optimiert retrospektiv auf historischen Marktpreisen und vergleicht das Ergebnis mit dem tatsächlich realisierten Fahrplan. Dieser Unterschied ist der nachweisbare ROI. Was fehlt: Die Backtesting-Zahlen gelten für die Vergangenheit — wie gut das Modell in zukünftigen Marktregimes performt, hängt von Marktstrukturveränderungen ab, die nicht modelliert werden können. Daher 4 statt 5.
Skalierbarkeit — mittel (3/5) Das Modell wächst mit dem Portfolio: Neue Kraftwerke werden als Einheiten hinzugefügt, neue Märkte als Dimensionen ergänzt. Aber: Jede neue Anlage erfordert Modellierung ihrer spezifischen Technologie-Constraints (Mindestlast, Rampenraten, Anlaufzeiten, Brennstoffcharakteristik). Das ist kein lineares Wachstum — es ist ingenieursmäßige Arbeit je Anlage.
Richtwerte — stark abhängig von Portfoliogröße, Marktpreisvolatilität und vorhandener SCADA-Datenbasis.
Was das System konkret macht
Der technische Kern der Kraftwerksfahrplan-Optimierung ist ein zweischichtiger Ansatz, der klassische Optimierungsmathematik mit Machine Learning kombiniert:
Schicht 1: Mixed Integer Programming (MIP) als Optimierungsrahmen
Unit Commitment ist im Kern ein kombinatorisches Optimierungsproblem: Welche Kraftwerke werden wann an- und abgefahren? Jedes Kraftwerk hat Einschaltkosten, Mindestlaufzeiten nach Anfahren, Mindest-Aus-Zeiten nach Abschalten, Rampenratenbeschränkungen (wie schnell kann die Last geändert werden?) und eine technisch erzwungene Mindestlast. Diese Constraints machen das Problem zu einem Mixed Integer Problem, das nicht analytisch lösbar ist, sondern numerisch optimiert werden muss.
Standard-MIP-Solver (Gurobi, CPLEX) lösen solche Probleme — aber für große Portfolios mit vielen Einheiten und langen Planungshorizonten dauern die Rechenläufe Stunden. Das ist für Intraday-Anpassungen zu langsam.
Schicht 2: ML-Warmstart für schnellere Lösung
ML-Modelle, trainiert auf historischen Optimierungsläufen, lernen, welche Kraftwerke unter welchen Marktbedingungen typischerweise laufen. Diese Einschätzung wird als Startlösung (Warmstart) in den MIP-Solver eingegeben — der Solver muss dadurch nicht von Null beginnen, sondern optimiert ausgehend von einer bereits guten Näherung. Publizierte Forschung zeigt Rechenzeitreduktionen von 40–70% ohne Qualitätsverlust.
Reinforcement Learning für dynamischen Intraday-Dispatch
Für kurzfristige Intraday-Anpassungen — das Netz hat mehr oder weniger Wind als prognostiziert, ein Kraftwerk fährt aus technischen Gründen ab, Intraday-Preise verschieben sich — ist MIP zu langsam. Hier kommen Reinforcement-Learning-Agenten ins Spiel: Sie lernen in simulierten Marktumgebungen, auf Preissignale und Netzzustandsänderungen schnell zu reagieren. Die Ausgabe ist keine optimale Lösung im mathematischen Sinne, aber eine sehr gute, die in Sekunden berechnet wird.
Integration in SCADA und Trading-System
Die Fahrplanvorschläge fließen in das SCADA-System (als Sollwerte für Kraftwerkssteuerung) und in das Trading-System (als Handelspositionierung für Spot und Regelenergiemärkte). Der Disponent sieht den Vorschlag, kann ihn freigeben oder übersteuern, und die Ausführung erfolgt automatisch. Wie bei der Wasserstoff-Produktionssteuerung gilt: Das System gibt Sollwerte vor, der SPS-Layer der Anlage setzt Sicherheitsgrenzen. Die KI-Empfehlung ist außen, nicht im Sicherheits-Loop.
Datenqualität als Voraussetzung
Die häufigste Ursache für Projektverzögerungen und enttäuschende Ergebnisse ist nicht die Algorithmusqualität, sondern die Datenintegration. Ein typischer mittelgroßer Versorger hat seine Einsatzdaten über drei Systeme verteilt:
SCADA: Tatsächliche Erzeugungslastgänge, Anlagenzustand, Betriebsmeldungen — oft im eigenen Datenformat des SCADA-Anbieters (Siemens Spectrum Power, ABB Symphony, OSIsoft PI). APIs vorhanden? Dokumentiert? Aktuell? Das klärt sich erst bei der Implementierung.
ERP (SAP PM / SAP IS-U): Revisionskalender, Wartungsplanungen, historische Störungsmeldungen, Anlagenstammdaten. Diese Informationen sind für die Fahrplanoptimierung kritisch — ein Kraftwerk, das nächste Woche in Revision geht, darf nicht für FCR-Vorhaltung eingeplant werden.
Trading-System (ETRM): Bereits gebuchte Positionen an Spot- und Regelenergiemärkten, die das Optimierungssystem als Constraints einbeziehen muss. Ohne diese Integration plant das System in ein Portfolio, das es nicht vollständig kennt.
Die Integration dieser drei Systeme — jedes mit eigenem Datenmodell, eigener API-Qualität und eigenem Aktualisierungsrhythmus — ist die eigentliche Ingenieurstätigkeit in diesem Projekt.
Konkrete Werkzeuge — was wann passt
PyPSA — Open-Source-Framework für Unit Commitment und Economic Dispatch, entwickelt an TU Berlin und KIT. Vollständige MIP-Formulierung, flexible Solver-Integration (HiGHS kostenlos, Gurobi für große Modelle). Geeignet für Versorger mit eigenem Data-Science-Team; gute Ausgangsbasis für Eigenentwicklung.
Siemens Spectrum Power — Integrierte Einsatzplanungsmodule für Versorger, die bereits auf Siemens SCADA laufen. Vorteil: keine separate SCADA-Integration. Nachteil: weniger Flexibilität bei der Optimierungstiefe und weniger Transparenz über die Modelllogik.
AVEVA PI System — OSIsoft PI / AVEVA PI ist der De-facto-Standard für Zeitreihendaten in Industrieanlagen. Als Datenbasis für historische Erzeugungsprofile und Echtzeit-Messwerte unverzichtbar; kommt fast immer als Datenschicht vor dem eigentlichen Optimierungsmodell.
C3.ai — Enterprise-KI-Plattform mit Energie-spezifischen Applikationen für Demand Forecasting und Energy Management. Für Konzerne mit komplexer Dateninfrastruktur und dem Budget für eine vollständig verwaltete Lösung. Preislich im siebenstelligen Bereich, Implementierung 6–12 Monate.
AWS SageMaker / Azure ML — Cloud-ML-Plattformen für Modellentwicklung und -Training. Wenn die interne Infrastruktur für GPU-intensive Trainingsläufe nicht vorhanden ist, sind EU-Regionen dieser Plattformen eine praktische Option für die Entwicklungsphase. Produktionsbetrieb muss die Frage On-Premise vs. Cloud explizit klären.
Power BI — Für das Monitoring-Dashboard: Fahrplan vs. Ist, Spot-Margen-Entwicklung, Regelenergie-Erlöse, Modell-Performance-Tracking. Unverzichtbar für den ROI-Nachweis — Disponenten und Handelsleiter brauchen Transparenz über das Optimierungssystem.
Datenschutz und Datenhaltung
Kraftwerks-Betriebsdaten und Handelspositionen sind hochsensible Wettbewerbsinformationen — keine DSGVO-Problematik (keine Personendaten), aber erhebliche Vertraulichkeitsanforderungen. Grenzkosten-Strukturen und Portfoliopositionen gehen keine Cloud, wenn der Betreiber in aktiven Märkten handelt.
On-Premise-Betrieb ist hier die natürliche Architektur: Das Optimierungsmodell läuft auf internem Server, SCADA-Daten bleiben im Netzwerk, Handelspositionen kommen aus dem internen ETRM-System. Für Modelltraining auf historischen Daten ist temporärer Cloud-Zugriff denkbar, wenn die Daten vorher anonymisiert oder aggregiert werden.
KRITIS-Anforderungen: Wenn der Versorger als kritische Infrastruktur eingestuft ist, gelten BSI-Grundschutz-Anforderungen für alle Systeme, die in die Kraftwerkssteuerung eingreifen. Das KI-Optimierungssystem, das Sollwerte für SCADA generiert, ist ein solches System — IT-Sicherheitskonzept und BSI-Grundschutz-Nachweis sind Pflicht.
Was es kostet — realistisch gerechnet
Implementierungskosten:
- Datenintegration (SCADA, ERP, Trading-System): 80.000–150.000 Euro
- Modellentwicklung und Kalibrierung: 100.000–200.000 Euro
- Backtesting und Validierung (6 Monate Parallelbetrieb): 50.000–80.000 Euro
- SCADA-Integration und Sicherheitsarchitektur: 40.000–70.000 Euro
- Gesamtimplementierung: 270.000–500.000 Euro, 12–18 Monate
Laufende Kosten:
- Modellpflege, Retraining, Anlagen-Updates: 40.000–80.000 Euro/Jahr
- Infrastruktur (Server, Software-Lizenzen Solver): 20.000–50.000 Euro/Jahr
ROI-Rechnung am Beispiel: Versorger mit 800 MW thermischer Kapazität, 5.500 Volllaststunden, Durchschnitts-Day-Ahead-Preis 70 Euro/MWh. Jahresumsatz aus Erzeugung: ca. 308 Mio. Euro. Optimierungsverbesserung 2,5% (konservativ, Backtesting belegt): 7,7 Mio. Euro/Jahr Zusatzerlös. Systemkosten: 400.000 Euro einmalig + 60.000 Euro/Jahr laufend. Amortisation: unter 8 Wochen Betrieb.
Wie du den ROI tatsächlich misst: Backtesting ist die Methode. Lass das Modell auf den letzten 24 Monaten historischer Marktpreise optimal optimieren — was wäre der Fahrplan gewesen? Vergleiche diesen theoretisch optimalen Fahrplan mit dem tatsächlich realisierten. Die Differenz, monetarisiert über tatsächliche Marktpreise, ist der nachweisbare Optimierungsbetrag. Das ist keine Schätzung — das ist eine Rückrechnung auf realen Zahlen.
Vier typische Einstiegsfehler
1. Datensilo-Problem unterschätzen. Das ist der häufigste Projektabbruchsgrund. SCADA, ERP und Trading-System haben alle ihre eigenen Datenmodelle, und die Schnittstellen sind oft schlechter dokumentiert als erwartet. Wer sechs Monate für die Datenintegration statt der geplanten zwei Monate braucht, hat entweder schlechte SCADA-APIs vorgefunden oder unterschätzt, wie unterschiedlich die Systeme Zeitstempel, Einheiten und Anlagencodes definieren. Eine Datenintegrations-Studie als Projektphase 0 ist kein optionaler Luxus.
2. Technologie-Constraints nicht vollständig modelliert. Mindestlaufzeiten nach Anfahren, Mindest-Aus-Zeiten, Rampenraten, Mindestlast — wenn auch nur eine dieser Restriktionen im Optimierungsmodell fehlt oder falsch eingestellt ist, produziert das System Fahrpläne, die technisch nicht realisierbar sind. Das Betriebsteam merkt es, übersteuert systematisch und verliert das Vertrauen in das System. Technische Validierung des Modells gegen tatsächliche Betriebserfahrung ist Pflicht, bevor das System Einfluss auf echte Fahrpläne nimmt.
3. Regelenergiemärkte als Afterthought behandeln. Oft werden Spot-Optimierung und Regelenergie als separate Projekte geplant. Das ist falsch: Die Optimierung über beide Märkte gleichzeitig ist der Haupthebel, nicht die Addition zweier separat optimierter Systeme. Ein Fahrplan, der Spot maximiert ohne Regelenergie-Vorhaltung zu berücksichtigen, lässt Erlöspotenzial liegen. Plane die Regelenergie-Integration von Beginn an.
4. Kein Retraining nach Marktstrukturveränderungen. Das Modell wird auf historischen Marktpreisen trainiert. Wenn sich die Marktstruktur ändert — neue erneuerbare Kapazität im Netz, veränderte CO₂-Preisdynamik, neue Regelenergiemarkt-Design-Änderungen — degradiert das Modell. Halbjährliches Retraining auf den aktuellsten 18–24 Monaten ist Minimum. Zuständigkeit klar benennen: Wer startet den Retraining-Prozess, wer validiert das neue Modell?
Was mit der Einführung wirklich passiert — und was nicht
Der erste Schock ist fast immer die Qualität der historischen SCADA-Daten. Messlücken, Sprünge durch Sensortausch ohne Kalibrierung, Anlagencodierungen, die über die Jahre mehrfach geändert wurden — das sind Realitäten, mit denen jedes Projekt zu kämpfen hat. Plane explizit 2–3 Monate für Datenbereinigung als eigene Projektphase.
Was bei erfahrenen Disponenten passiert: Sie sind skeptisch, und das ist berechtigt. Sie kennen Situationen, in denen das Excel-Tool falsch lag. Ein Modell-Vorschlag, der sich in der ersten Woche als suboptimal herausstellt, kostet monatelang Vertrauen. Daher ist der Parallelbetrieb so wichtig: Das System macht Vorschläge, der Disponent entscheidet. Über Wochen sieht der Disponent, wie oft das System besser lag als die eigene Einschätzung. Das ist der Vertrauensaufbau, der nicht beschleunigt werden kann.
Was Monate nach dem Produktivstart oft überrascht: Die wertvollsten Insights kommen nicht aus der täglichen Dispatch-Optimierung, sondern aus der Analyse über Monate — was waren die 20 teuersten Entscheidungen, die das alte System getroffen hat? Diese Rückblick-Analyse zeigt, wo strukturelle Schwächen im alten Planungsprozess lagen, und informiert sowohl das Modell als auch die Disponent-Ausbildung.
Realistischer Zeitplan mit Risikohinweisen
| Phase | Dauer | Was passiert | Typisches Risiko |
|---|---|---|---|
| Datenstudie und Systemanalyse | Monat 1–3 | SCADA-, ERP- und ETRM-APIs ausloten, historische Datenqualität bewerten, Anlagen-Constraint-Katalog erstellen | SCADA-API undokumentiert oder veraltet — Hersteller-Support mit langer Antwortzeit |
| Modellentwicklung und Backtesting | Monat 3–9 | MIP-Modell auf Basis des Constraint-Katalogs entwickeln, ML-Warmstart trainieren, Backtesting auf 24 Monaten | Backtesting-ROI kleiner als erwartet — Marktpreise im Backtesting-Zeitraum nicht repräsentativ für Zukunft |
| Parallelbetrieb | Monat 9–14 | System macht Vorschläge parallel zu Disponenten-Entscheidung; Abweichungen täglich dokumentiert | Disponenten übersteuern systematisch — Vertrauensaufbau-Phase nicht überspringen |
| Vollbetrieb und erstes Retraining | Ab Monat 15 | System übernimmt Fahrplanvorschlag, Disponent gibt frei; erstes Retraining auf aktuellsten 24 Monaten | Marktstrukturveränderung (neue EE-Kapazität) verändert Modell-Performance — Retraining früher als geplant nötig |
Häufige Einwände — und was dahintersteckt
„Unsere Disponenten wissen besser, was mit dem Netz passiert, als jedes Modell.” Das stimmt für lokale, unstrukturierte Informationen: Wartungsfenster, die noch nicht ins ERP eingepflegt sind, lokale Netzbetreiber-Information, die informell übermittelt wurde. Modelle sind strukturell besser in der simultanen Berücksichtigung vieler quantitativer Parameter — Spot-Preiskurve, CO₂-Preis, FCR-Kapazitätspreise, Anlagentechnik-Constraints über 48 Stunden. Das ist keine Konkurrenz, sondern Arbeitsteilung: Disponenten pflegen strukturierte Ausnahmen ein, das Modell optimiert auf Basis dieser Inputs.
„Wir haben das schon mal versucht und das System hat Unfug vorgeschlagen.” Das ist ernst zu nehmen. In der Mehrzahl der Fälle liegt es an einem von drei Problemen: Technologie-Constraints nicht korrekt modelliert (Fahrplan technisch nicht realisierbar), fehlende Daten aus einem Quellsystem (ERP-Revisionsplanung nicht integriert), oder das Modell wurde auf einem Zeitraum trainiert, der nicht repräsentativ für aktuelle Marktbedingungen war. Das sind lösbare Probleme — aber sie erfordern ehrliche Diagnose, keine Pauschalurteile über die Technologie.
„Das Intraday-Pricing ist zu volatil — ein Modell kann das nicht vorhersagen.” Niemand behauptet, dass das Modell Intraday-Preise vorhersagt. Das Modell optimiert einen Fahrplan auf Day-Ahead-Basis und gibt Anpassungsempfehlungen bei Intraday-Abweichungen — auf Basis von Preissignalen, die bereits bekannt sind. Die Preisprognose (welche Richtung entwickeln sich Intraday-Preise?) ist eine separate Frage, die von Energiehandelsprognose besser beantwortet wird.
Woran du merkst, dass das zu dir passt
- Du betreibst thermische oder Speicher-Erzeugungsanlagen ab 100 MW installierter Leistung — unter diesem Schwellenwert ist der absolute ROI zu klein für den Implementierungsaufwand
- Dein Einsatzplanungsprozess ist heute stundenweise manuell oder regelbasiert, ohne dynamische simultane Optimierung über mehrere Märkte (Spot + Regelenergie)
- Du hast mindestens 2 Jahre historische SCADA-Einsatzdaten in ausreichender Qualität — das ist die Mindestbasis für Modelltraining und Backtesting
- Es gibt ein Data-Engineering- oder Data-Science-Team im Haus, oder du bist bereit, das extern einzukaufen
Wer noch nicht soweit ist:
- Reine Windpark- oder Solarparkbetreiber ohne Speicher und ohne Regelenergie-Vorhaltung: Unit Commitment ist für stochastische Einspeiser kein primäres Problem — die Erneuerbare-Einspeise-Prognose ist relevanter
- Versorger unter 100 MW thermischer Kapazität: Der absolute ROI rechtfertigt den Implementierungsaufwand von 300.000–500.000 Euro nicht
- Unternehmen ohne Zugang zu SCADA-Echtzeit-Daten oder mit schlechter historischer Datenbasis: Zuerst die Dateninfrastruktur aufbauen, dann die Optimierungsschicht
- Teams ohne jemanden, der das Modell technisch versteht und betreibt: Das Projekt scheitert nicht an der Technologie, sondern an der fehlenden Betriebskompetenz
Das kannst du heute noch tun
Führe eine einfache Backtesting-Analyse durch, ohne ein Modell zu brauchen: Nimm die letzten 30 Handelstage. Vergleiche den realisierten Day-Ahead-Erlös deiner Anlagen mit dem theoretischen Erlös bei perfekter Information (Stunden mit Preis > Grenzkosten 100%, darunter 0%). Die Differenz — in Prozent des theoretischen Maximums — ist dein aktueller Optimierungsgrad. Alles unter 85% ist ein Signal für relevantes Verbesserungspotenzial.
Mitarbeiter:in
KI-Assistent
Quellen & Methodik
- Applied Energy (2023): “Reinforcement learning and mixed-integer programming for power plant scheduling in low carbon systems: Comparison and hybridisation” — ScienceDirect, doi 10.1016/j.apenergy.2023.121659
- INFORMS Journal on Computing (2023): “Use of Machine Learning Models to Warmstart Column Generation for Unit Commitment” — pubsonline.informs.org
- Arxiv (2024): “An Open Source Stochastic Unit Commitment Tool using the PyPSA-Framework” — arxiv.org/abs/2405.06490
- EWI Universität Köln (2025): EWI Merit-Order Tool Dokumentation — Methodik für Merit-Order-Modellierung im deutschen Stromsystem
- ENTSO-E Transparency Platform: Historische Day-Ahead-Preise und Marktdaten für Backtesting-Analysen — transparency.entsoe.eu
- Regelenergiemarkt-Preise: regelleistung.net — FCR, aFRR, mFRR Kapazitäts- und Arbeitspreise
- EU AI Act (2024): Klassifikation industrieller KI-Steuerungssysteme für kritische Infrastruktur (Anhang III)
- IT-Sicherheitsgesetz 2.0 (2021): BSI-Grundschutz-Anforderungen für KRITIS-Betreiber mit KI-Systemen im Steuerungsbereich
Du willst wissen, wie viel Optimierungspotenzial in eurem Erzeugungsportfolio liegt — und was ein realistisches Backtesting auf eurer Historik ergibt? Meld dich — die erste Analyse ist mit euren SCADA-Exports in einem Gespräch machbar.
Diesen Inhalt teilen:
Interesse an diesem Use Case?
Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.
Weitere Use Cases
Lastprognose für Energieversorger
KI-Modelle prognostizieren Stromlast stundenscharf — für niedrigere Ausgleichsenergiekosten und bessere Einsatzplanung.
Mehr erfahrenPredictive Maintenance Windkraft
KI erkennt Verschleiß an Windkraftanlagen Wochen vor dem Ausfall — für planbare Wartung statt teurem Notfalleinsatz.
Mehr erfahrenEnergiehandelsprognose
KI prognostiziert EPEX-Spotmarktpreise für bessere Handelsentscheidungen — mit Szenario-Bändern statt Einzelpunkten.
Mehr erfahren