PV Ertragsprognose mit KI - Feature Engineering

Feature Engineering - Parameterauswahl

Feature Engineering hat als Ziel, die passenden Parameter zu erkennen, auszuwählen und ggf. zu bereinigen. Des Weiteren können durch logische Überlegungen bewusst Unschärfen aus dem Modell genommen werden. Das ist ein iterativer Prozess, der sehr viel Sorgfalt erfordert.

Meine Überlegungen zur Parameterauswahl finden Sie hier.

Datenquellen

Die Suche nach verlässlichen Datenquellen ist die Erste zu lösende Aufgabe. Hierzu habe ich mir folgende Fragen gestellt:

• Mit welchen Parametern kann eine Leistungsprognose sinnvoll erstellt werden?
• Welche nutzbaren Parameter sind in meinem Smart Home (FHEM) verfügbar, um auf „historisches Wissen“ zurückzugreifen - sprich: das Modell zu trainieren?
• Aus welchen Quellen können verlässlich und kontinuierlich fehlende Parameter bezogen werden?

Belastbare historische Daten

Folgende historische Daten stehen zur Verfügung:

• EnergyHour *) … PV-Ertrag der letzten Stunde [kW/h]
• Brightness **) … Durchschnittswert der Helligkeit der letzten Stunde [Lux]
• Temp **) … Durchschnittswert der Außentemperatur der letzten Stunde [°C]
• SunAlt ***) … Höhenwinkel der Sonne über dem Horizont [Dezimalgrad]
• SunAz ***) … Sonnenwinkel in Bezug auf Süden unter Berücksichtigung des Azimuth der eigenen PV-Anlage [Dezimalgrad]

*) … Quelle: SBFSpot ⇒ MQTT ⇒ FHEM
**) … Quelle: Eltako Multisensor MS ⇒ FHEM
***) … Quelle: Berechnung über das Astro-Modul in FHEM

Vorhersagedaten

Für die Vorhersage habe ich auf Wetterdaten des DWD (Deutscher Wetterdienst) zurückgegriffen. Der DWD bietet über das MOSMIX-System öffentlich zugängliche Vorhersagedaten an, die ebenfalls in FHEM eingebunden werden können. Der DWD aktualisiert die Daten regelmäßig gg. 4, 10 und 16 Uhr, weshalb es sich anbietet, kurz danach eine neue Prognose anzustoßen. Die nächstgelegene Wetterstation des DWD (Flughafen Nürnberg) ist 13km Luftlinie von unserem Wohnort entfernt. Der hieraus resultierende Fehler ist tolerabel.

Als am Besten geeignete DWD-Parameter haben sich herauskristallisiert:

• SunD1 … Sonnenscheindauer der letzten Stunde [s]
• Rad1h … absolute Globalstrahlung der letzten Stunde [% (0..80)]
• RRad1 … Globale Einstrahlung [kJ/m2]
• TTT … Temperatur 2m über der Oberfläche [°C]

Um dem Ergebnis noch ein klein wenig mehr Präzision zu geben, habe ich noch folgende Parameter einbezogen:

• Neff … Effective cloud cover [% (0..100)] - Quelle: DWD
• CloudCover (clouds.all) … Cloudiness [% (0..100)] - Quelle: OpenWeather

Interessant war, dass OpenWeather laut deren Website für Deutschland auf die Daten des DWD referenziert. Somit müsste Neff und CloudCover eigentlich identisch sein. Das sind sie aber nicht. Der CloudCover-Wert von OpenWeather macht aber durch den visuellen Vergleich (Blick aus dem Fenster) den passenderen Eindruck. Vielleicht liegt es auch nur daran, dass von OpenWeather die Werte stündlich aktualisiert werden, wohingegen der DWD seine Daten nur dreimal täglich aktualisiert. Aus diesem Grunde habe ich CloudCover als Attribut mit einbezogen. Neff schreibe ich parallel nur mit, damit ich eine Rückfallposition habe, falls der Abruf über OpenWeather irgendwann einmal nur noch kostenpflichtig möglich wäre.

In unzähligen Tests und Modellberechnungen haben sich die hier aufgelisteten Parameter als am besten geeignet erwiesen. Das ist eine kleine Vorwegnahme auf das eigentliche Feature-Engineering. Die vielen Iterationsschritte wollte ich dem Leser ersparen.

Es werden zwar deutlich mehr Parameter vom DWD und von OpenWeather angeboten, doch letztendlich ergibt die Verwendung von weiteren Parametern nicht automatisch bessere Ergebnisse.

Feature Engineering - Aufbereitung der Parameter

Um ein qualitativ hochwertiges Ergebnis zu erhalten, ist es von essentieller Bedeutung bereinigte, vollständige und verlässliche Daten zu verwenden.

Dabei helfen üblicherweise:

• Plausibilitätsprüfungen
• Ergänzung von fehlenden Einzelwerten
• Verwendung von Mittelwerten über ein Stundenintervall anstelle von Momentanwerten zum Zeitpunkt x

Ein fester Betrachtungszeitraum ist ebenfalls hilfreich. Ich habe mich für die stündliche Erfassung der Parameter zwischen 4 und 23 Uhr entschieden. Die Nachtstunden berücksichtige ich bewusst nicht, da sie für die PV-Ertragsprognose nicht relevant sind. Als Nebeneffekt umgehe ich hierdurch die Zeitumstellung Sommerzeit / Normalzeit, in der z.B. eine Stunde doppelt erscheinen bzw. eine Stunde fehlen würde. Somit hat mein Betrachtungstag nur 20 anstelle 24 Stunden.

Zusammenhänge und Anomalien lassen sich sehr gut über graphische Darstellungen erkennen. Hierzu gibt es unzählige Beispiele im Netz, die nicht besser werden, wenn ich sie hier wiederhole.

Das komplette Jupyter Notebook zum Feature-Engineering bezogen auf diese Beschreibung finden Sie hier:

• 010_featureengineering.ipynb

Die folgende Matrix zeigt final die Zusammenhänge zwischen den von mir gewählten Parametern. Es ist ersichtlich, dass es einen sehr direkten Zusammenhang zwischen PV-Ertrag (EnergyHour) und der Helligkeit (Brightness) gibt. Leider gibt es keine Wetterstation, die mir die Helligkeit als Vorhersagewert liefert.

Korrelationsmatrix Eingangsparameter

Aus diesem Grunde bin ich kaskadierend vorgegangen. Ich ermittle aus verschiedenen Eingangsparametern die Helligkeit, um in einem zweiten Schritt daraus den PV-Ertrag zu prognostizieren.

Jetzt könnte man sich die Frage stellen:
Wozu ermittle ich zuerst die Helligkeit? Man kann die Eingangsparameter zur Ermittlung der Helligkeit doch gleich zur direkten PV-Ertragsprognose verwenden?

Das mag stimmen und ich hatte diesen Denkansatz zu Beginn auch verfolgt. Die Zahlen sprachen aber letztendlich dagegen. Die direkte PV-Prognose hatte einen R²-Score von 0,86 ergeben. Der kaskadierende Umweg über die Helligkeit ergab letztendlich einen R²-Score von 0,94. Der R²-Score bietet eine Aussage, wie gut Variablen geeignet sind, einen Zusammenhang zu beschreiben. Der Maximalwert des R²-Scores wäre 1,00.

Aus der Korrelationsmatrix ist ebenfalls ersichtlich, dass der Monat (Month) in keinem direkten Zusammenhang mit den Zielgrößen stehen. Nichtsdestotrotz können über den Monat saisonale Effekte abgebildet werden. Dazu mehr im Kapitel Modell Auswahl und Training (Kategorisierung von Daten).

Schritt 1 - Zielgröße: Helligkeit (Brightness)

Für das erste Modell sind folgende Parameter relevant:

• Rad1h … absolute Globalstrahlung der letzten Stunde [% (0..80)]
• RRad1 … Globale Einstrahlung [kJ/m2]
• SunAlt … Sonnenzenitwinkel
• SunAz … Sonnenazimuthwinkel
• SunD1 … Sonnenscheindauer der letzten Stunde [s]
• CloudCover … Bewölkungsgrad [% (0..100)]

Jetzt könnte man annehmen, dass SunD1 und CloudCover redundant sind und einer der beiden Werte völlig ausreichend wäre. Der Praxistest hat aber gezeigt, dass mit beiden Werten genauere Ergebnisse erreichbar sind, auch wenn es aus der Korrelationsmatrix nicht direkt erkennbar ist.

Der negative Wert von CloudCover resultiert daraus, dass er sich gegenläufig zur Helligkeit verhält. Ein hoher Wert von CloudCover (starke Bedeckung) steht in einem Verhältnis zu einer geringen Helligkeit und umgekehrt. CloudCover invers zu verwenden, d.h. CloudCover = (100-CloudCover) würde zwar die Optik beeinflussen, weil in der Matrix ein positiver Wert und die entsprechende Färbung stehen würde. Am Modell würde es aber nichts ändern. So intelligent sind die Algorithmen mittlerweile schon.

Die Einbeziehung der Stunde (Hour) hätte hingegen keinen verbessernden Einfluss. Abgesehen von der kurzen Phase des Sonnenaufgangs und -untergangs kann nicht behauptet werden, dass es mittags heller ist als am Vor- oder Nachmittag. Hier sind andere Parameter ausschlaggebender.

Korrelationsmatrix - Helligkeit (Brightness)

Schritt 2 - Zielgröße: PV-Ertrag (EnergyHour)

Mit der ermittelten Helligkeit ist es möglich, recht präzise in einem zweiten Schritt den PV-Ertrag zu prognostizieren. Hierzu werden folgende Parameter verwendet:

• Brightness … Helligkeit
• SunAlt … Sonnenzenitwinkel
• SunAz … Sonnenazimuthwinkel
• Temp … Temperatur[°C]

Globale Strahlung und Sonnenscheindauer wurden bewusst außen vor gelassen, da diese Parameter bereits bei der Ermittlung der Helligkeit (Brightness) eingeflossen sind und an dieser Stelle keine Verbesserung des Ergebnisses gebracht hätten.

Auf die Stunde (Hour) habe ich wiederum verzichtet, da der Parameter nicht zur Verbesserung des Ergebnisses beigetragen hat. Eine Normierung der Stunde (aus 9, 10, 11, 12, 13, 14, 15, 16, 17 .. mache 9, 10, 11, 12, 13, 12, 11, 10, 9 ..), so dass quasi der größte Wert der Stunde dem Mittag entspricht, hat nicht zur Verbesserung des Ergebnisses beigetragen. Ganz im Gegenteil - die Genauigkeit wurde geringer, da der Einfluss durch den Sonnenstand bereits zur Genüge abgedeckt war und so der Schwerpunkt zu sehr auf den Tagesverlauf verschoben wurde.

Korrelationsmatrix - PV-Ertrag (EnergyHour)

Schlussbemerkung

Das Feature-Engineering beschränkt sich nicht nur auf die reine Parameterauswahl. Insofern war das hier eine etwas verkürzte Darstellung.

Wichtig ist vor allem, dass die Parameter eine hohe Qualität besitzen. Beseitigen Sie Anomalien, Nullwerte und korrigieren Sie Ausreißer. Wenn in Ihrem Modell täglich neue historische Daten hinzufließen, so ist dies ein wiederkehrender Prozess. Die neuen Daten müssen ebenfalls diesem Qualitätscheck unterzogen werden und ggf. muss das Modell auch wieder neu berechnet werden.

Das komplette Jupyter Notebook zu diesem Feature-Engineering finden Sie hier:

• 010_featureengineering.ipynb