Demand-Response-Baselines und Messung

Ein Demand-Response-Programm vergütet eine Änderung des Strombezugs. Um diese Änderung zu bestimmen, braucht es einen Vergleichswert: die Baseline. Sie wird aus früheren Tagen berechnet, nicht gemessen. Das Verfahren entscheidet daher mit, wie viel der Reaktion angerechnet wird.

Dieser Leitfaden gehört zur Reihe über Flexibilität. Der Leitfaden zu IoT in Demand Response verfolgt ein ganzes Ereignis von der Anweisung bis zur Abrechnung.

Durchgerechnetes Beispiel

Ein Standort im britischen Demand Flexibility Service (DFS) senkt seinen Bezug an einem Werktag für eine Abrechnungsperiode von 17:00 bis 17:30. Er ist ein Zählpunkt innerhalb einer gebündelten DFS-Einheit, denn die Mindesteinheit beträgt 0,1 MW. Die DFS-P376-Baseline für diese halbe Stunde ist der Mittelwert derselben halben Stunde an den zehn jüngsten geeigneten Werktagen. An diesen Tagen bezog der Standort 98, 102, 100, 97, 105, 99, 101, 103, 96 und 99 kWh. Die Summe beträgt 1.000 kWh, die Baseline also 100 kWh.

DFS-Dateien enthalten kWh je Abrechnungsperiode. Die mittlere Leistung ergibt sich aus der Energie geteilt durch 0,5 h. NESO bewertet die Lieferung der gesamten DFS-Einheit gegenüber der angenommenen Menge. Zwischen 50 % und 120 % dieser Menge gibt es keine Kürzung. Zwischen 25 % und 50 % sinkt die Zahlung, unter 25 % ist sie null und oberhalb von 120 % wird die Lieferung gedeckelt. Die NESO-Leitlinie nennt eine Einheit, die 36,7 % von 15 MWh lieferte: Abgerechnet wurden 23,3 % oder 3,5 MWh.

Ein Fehler der Baseline geht eins zu eins in das Ergebnis ein. Setzen zwei besonders arbeitsreiche Wochen den historischen Wert um 5 % zu hoch, also auf 210 kW, werden dem Standort 60 kW angerechnet: 20 % mehr als tatsächlich geliefert. Liegt die Baseline um 5 % zu niedrig, bei 190 kW, sinkt die Gutschrift auf 40 kW.

Der Nachholeffekt ist der zusätzliche Bezug nach dem Ereignis, wenn verschobene Last zurückkehrt: Kältemaschinen stellen die Temperatur wieder her, unterbrochene Prozesse laufen weiter. DFS vergütet nur die Lieferung in den vereinbarten Abrechnungsperioden. Der Nachholeffekt danach liegt außerhalb dieser Zahlung, erscheint aber auf der Stromrechnung des Standorts und kann eine neue Lastspitze setzen. Der folgende Rechner ergänzt das Beispiel um zwei Nachholperioden. Während des Ereignisses vermeidet der Standort 25 kWh und verbraucht in der folgenden Stunde 17 kWh über der Baseline. Netto bleiben 8 kWh Einsparung.

Verfahren zur Baseline-Berechnung

Die Mittelwertbildung funktioniert gut, wenn sich die Last von Tag zu Tag wiederholt. California ISO rechnete Demand Response bis 2017 mit einem Werktagsmittel aus zehn von zehn Tagen ab und deckelte die Anpassung auf 20 %. Die Baseline-Studie zeigte, dass das für große gewerbliche Standorte ohne starke Wetterabhängigkeit einigermaßen funktionierte. Bei wetterabhängigen gewerblichen Standorten und Wohngebäuden wurde die Reaktion unterschätzt.

P376 verlangt eine Mindesthistorie. Gibt es im 60-Tage-Fenster fünf bis neun geeignete Werktage, nutzt DFS sie alle. Bei weniger als fünf kann der Zählpunkt nicht genutzt werden: Seine Baseline wird auf den tatsächlich gemessenen Wert gesetzt, sodass er keine Lieferung ausweist. Ereignistage sind ungeeignet. Dazu zählen Tage mit einem DFS-Ereignis, einer DNO-Flexibilitätsanweisung mit höchstens 48 Stunden Vorlauf, einem Capacity-Market-Ereignis oder der Lieferung für einen weiteren kombinierten Dienst mit höchstens 48 Stunden Vorlauf. Häufige Ereignisse verschieben das Mittelwertfenster dadurch auf ältere, weniger repräsentative Tage.

Seit dem 9. April 2026 können industrielle und gewerbliche Zählpunkte sowie Zählpunkte fluktuierender erneuerbarer Erzeugung in DFS eine selbst gemeldete Baseline verwenden. Der Teilnehmer reicht eine kWh-Prognose für jede halbe Stunde des Liefertags ein. Die Datei darf frühestens 24 Stunden vor der Veröffentlichung des Dienstbedarfs durch NESO und spätestens bei dieser Veröffentlichung eingehen. NESO nutzt die jüngste Version. Haushaltszählpunkte bleiben bei P376. Dieselbe Änderung senkte die Mindestgröße der DFS-Einheit von 1 MW auf 0,1 MW. Am Ereignistag gibt es für die Prognose noch keine Historie, mit der sie sich prüfen ließe. Bewahren Sie Prognosemodell, Eingaben und Fehler an ereignisfreien Tagen auf. DFS verlangt, dass der Teilnehmer die Baseline jedes abgerechneten Zählpunkts für eine Prüfung vorhält.

Anpassung am Ereignistag

Ein historischer Mittelwert kennt die Last des Ereignistags nicht. Eine Anpassung am selben Tag, oft „Morning Adjustment“ genannt, korrigiert die Baseline anhand der Standortlast in den Stunden vor dem Ereignis. Bei der multiplikativen Form wird die gemessene Energie durch die unveränderte Baseline-Energie im Anpassungsfenster geteilt. Das Verhältnis skaliert die Baseline. Eine additive Variante addiert die Differenz in kW. Die 2017 für CAISO vorgeschlagenen Regeln nutzten ein zweistündiges Fenster, das zwei Stunden vor dem Ereignis endet, und ein zweites zweistündiges Fenster, das zwei Stunden danach beginnt. Die Abstände halten Vorkühlung, vorzeitiges Abschalten und Nachholeffekt aus der Anpassung heraus.

Im Beispiel betrachten wir nur das Fenster vor dem Ereignis. Zwischen 13:00 und 15:00 bezog der Standort 360 kWh bei einer unveränderten Baseline von 383 kWh. Das Verhältnis beträgt 0,94. Die angepasste Baseline ist 0,94 × 200 kW = 188 kW. Die angerechnete Reduktion sinkt von 50 auf 38 kW.

Programme deckeln das Verhältnis. Die CAISO-Baseline „10 von 10“ erlaubte ±20 %, also ein Verhältnis von 0,8 bis 1,2. Der Vorschlag von 2017 zum Wettervergleich erlaubte 0,71 bis 1,4. Die CAISO-Studie nennt zwei Gründe für eine Deckelung: Sie verringert die Streuung der Schätzung und begrenzt, wie weit ein Standort seine eigene Baseline durch Laständerungen vor dem Ereignis verschieben kann. Ohne Abstand und Deckelung erhöht zusätzliche Last im Anpassungsfenster die Baseline. Bei einem Verhältnis von 1,2 steigt die Beispiel-Baseline auf 240 kW und die angerechnete Reduktion auf 90 kW.

Coughlin und Kollegen am Lawrence Berkeley National Laboratory prüften sieben Baseline-Modelle an 33 gewerblichen Gebäuden in Kalifornien. Ein Morning Adjustment verringerte den systematischen Fehler und verbesserte die Genauigkeit aller sieben Modelle. Bei Gebäuden mit stark schwankender Last lieferte kein Modell ein zufriedenstellendes Ergebnis. Mittelwertverfahren waren dort am genauesten, hatten aber nicht den geringsten systematischen Fehler.

Die DFS-Leitlinie, Version 18 vom August 2026, beschreibt für die P376-Baseline keine Anpassung am Ereignistag. Prüfen Sie das Verfahren in den aktuellen Unterlagen des Programms, an dem Sie teilnehmen.

Baseline vor dem ersten Ereignis prüfen

Testen Sie das Verfahren an Tagen ohne Ereignis. Jede Differenz zwischen Baseline und gemessenem Bezug ist dann ein Fehler. Die CAISO-Studie nutzt zwei Kennzahlen. Der mittlere prozentuale Fehler ist der mittlere Fehler mit Vorzeichen geteilt durch die mittlere Last; er zeigt eine systematische Verzerrung. Ein positiver Wert bedeutet, dass die Baseline zu hoch prognostiziert. CV(RMSE) ist die Wurzel aus dem mittleren quadratischen Fehler geteilt durch die mittlere Last; die Kennzahl zeigt die Streuung einzelner Tage.

Vergleichen Sie beides mit der zugesagten Reduktion, nicht mit der Gesamtlast. Der CAISO-Bericht rechnet vor: Reduziert ein Standort seine Last um 20 %, meldet eine um 2 % zu hohe Baseline eine Reduktion von 22 %, also 110 % des wahren Werts. Im Beispiel entsprechen 5 % CV(RMSE) einer 200-kW-Baseline 10 kW an einem typischen Tag, einem Fünftel der zugesagten 50 kW.

Der Zähler ist selten die größte Fehlerquelle. Für Klasse-0.5S-Zähler nach IEC 62053-22 beträgt die Fehlergrenze unter Referenzbedingungen ±0,5 %, bei 200 kW also 1 kW. Eine um 5 % falsche Baseline liegt um 10 kW daneben.

Was die Standortdaten belegen müssen

Erzeugung und Speicher innerhalb der Messgrenze ändern, was angerechnet wird. Für eine Lastsenkung berechnet DFS die Lieferung als (Baseline-Bezug − Baseline-Einspeisung) − (gemessener Bezug − gemessene Einspeisung). Beispiel: Ein Standort mit 80 kW PV hat 40 kW Nettobezug. Er schaltet 60 kW Last ab; an der Grenze entstehen 20 kW Netzeinspeisung. Die Lieferung ist (40 − 0) − (0 − 20) = 60 kW und wird vollständig gezählt. Aus demselben Grund kann eine selbst gemeldete Baseline für eine Import-MPAN negativ sein. Startet während des Ereignisses ein Speicher oder Generator innerhalb der Messgrenze, zählt der Grenzzähler dessen Leistung als Reaktion. Ein Unterzähler an der gesteuerten Last zählt nur diese Last.

Verspätete Daten müssen nach Messzeit, nicht nach Eintreffzeit einsortiert werden. Duplikate dürfen nicht doppelt zählen. Der Leitfaden zu Zeitstempeln erläutert beides.

Ungewöhnliche Tage

Feiertag, Produktionsstopp oder ausgefallene Kältemaschine verändern den Bezug unabhängig von einem Ereignis. Die Baseline-Regel bestimmt, was mit solchen Tagen geschieht. Unter P376 fällt ein Ereignistag aus dem Pool; der nächste ältere geeignete Tag im 60-Tage-Fenster rückt nach. Die DFS-Leitlinie schließt nur Ereignistage aus. Ein Werktag mit Produktionsstopp bleibt daher im Pool und drückt die Baseline für die nächsten zehn Werktage. Dokumentieren Sie den Grund für jeden ungewöhnlichen Tag. Bis er aus dem Pool fällt, kann der Teilnehmer eine kleinere Menge für die Einheit anbieten oder einen industriellen oder gewerblichen Zählpunkt auf eine selbst gemeldete Baseline umstellen. Erlaubt das Programm eine Schätzung fehlender Werte, markieren Sie jeden geschätzten Wert ausdrücklich.

Steuerungsnachweis getrennt halten

Eine bestätigte Abrufanweisung zeigt, dass die Anweisung eingetroffen ist. Die Rückmeldung der Anlage zeigt, dass sie reagiert hat. Die gemessene Änderung zeigt, was das Netz gesehen hat. Für einen Zählpunkt mit manuellem Opt-in verlangt DFS den ersten Nachweis: Der Teilnehmer muss eine Bestätigung dieses Zählpunkts vorhalten, die zwischen Gebot und Lieferbeginn einging. Sonst kann der Zählpunkt nicht abgerechnet werden. Bei einer direkt angesteuerten Last gilt die Anweisung als Bestätigung; der Teilnehmer muss sie aufbewahren.

Streitfälle über Messdaten haben konkrete Ursachen: Im Baseline-Fenster fehlt ein Intervall. Eine Logger-Uhr liegt um ein Intervall daneben, sodass die Reduktion in der falschen Abrechnungsperiode landet. Ein geschätzter Wert wird als gemessen eingereicht. Der Leitfaden zur BESS-Befehlsverifikation behandelt die Steuerungsseite.

Auf ein Programm vorbereiten

1. Besorgen Sie das aktuelle Baseline-Verfahren, Abrechnungsintervall, Dateiformat und die Vorzeichenregel vom Aggregator oder Programm. Der Leitfaden zum virtuellen Kraftwerk erklärt die Zuständigkeiten.
2. Messen Sie am Standort im Abrechnungsintervall oder feiner. Für P376 beginnen Sie mindestens drei Wochen vor dem ersten Ereignis, damit nach Feiertagen zehn geeignete Werktage verbleiben. Für einen Wettervergleich brauchen Sie Messdaten über den Temperaturbereich der möglichen Ereignisse.
3. Berechnen Sie die Baseline für mindestens zehn ereignisfreie Tage und vergleichen Sie sie mit dem gemessenen Bezug. Dokumentieren Sie systematischen Fehler und CV(RMSE) in kW und vergleichen Sie beides mit der zugesagten Reduktion.
4. Führen Sie ein Testereignis aus. Vergleichen Sie die berechnete Reduktion an der Messgrenze mit der gemessenen Änderung an jeder gesteuerten Anlage.
5. Speichern Sie Quellintervalle, Baseline-Berechnung und Verfahrensversion zusammen.

Messung und Steuerung mit EpiSensor

Ein ZDR Demand Response Controller misst eine dreiphasige Versorgung mit Klasse 0.5S (IEC 62053-22) und steuert die daran angeschlossene Last: Ein Relais schaltet eine Last ab oder startet einen Generator; ein Modbus-Sollwert steuert eine Batterie. Die Klasse 0.5S gilt für Controller und Stromwandler zusammen. Steuerungsaktion und gemessene Änderung werden auf einer gemeinsamen Zeitbasis aufgezeichnet. Modelle mit GPS/GNSS-Zeitsynchronisation erfassen Ereignisse mit 20 ms Auflösung. ZEM-Strommonitore messen andere Stromkreise in derselben Klasse und liefern damit einen Unterzähler-Nachweis je gesteuerter Last. Ein Gateway mit Edge hält die Intervallhistorie einschließlich der Messzeit jedes Werts vor Ort und sendet sie über MQTT oder HTTP an die Plattform des Aggregators. Die Demand-Response-Lösung zeigt das Gesamtsystem.