Foto von Dmitrijs Safrans auf Unsplash.
Wer nach „automatisierte Demand Response“ sucht, findet Seiten für Versorger, Aggregatoren und Standardisierungsgremien. GridPoint erklärt, was ADR ist. Die OpenADR Alliance dokumentiert ihr eigenes Protokoll. Wikipedia liefert die Geschichte. Ein Kälteanlagenhersteller verkauft ADR-fähige Regelungen als Produktmerkmal. Akademische Arbeiten von Lawrence Berkeley und IEEE arbeiten die Netzökonomie durch. All das behandelt das Gebäude als das ferne Ende eines Signalpfads: das, was eine Anweisung empfängt und sie theoretisch ausführt. Nichts davon stellt die Frage, die entscheidet, ob diese Anweisung ohne vorherige menschliche Prüfung auf etwas wirken darf.
Die manuelle Seite dieser Frage haben wir in Demand Side Response behandelt: welche Lasten ein Gebäude flexibel halten kann, wenn eine Person Ereignis für Ereignis entscheidet, ob reagiert wird. Automatisierte Demand Response entfernt diese Person. Ein OpenADR-Signal trifft ein, ein VEN-Client am BMS empfängt es, und eine Last wird abgeschaltet, vorgekühlt oder begrenzt, ohne dass jemand im Gebäude vorher bestätigt, dass es sicher ist. Das ist der ganze Reiz der Automatisierung: keine verpassten Ereignisse, kein manuelles Hasten, schnellere Reaktionszeiten, die für besser bezahlte Schnellreaktionsprogramme qualifizieren. Deshalb wird ein Fehler bei der zugrunde liegenden Frage, ob genau diese Last gerade sicher abgeschaltet werden kann, teurer, nicht billiger.
Dieser Text setzt dort an, wo jener aufhörte. Nicht, was OpenADR ist, das dokumentiert die Alliance präzise. Nicht, wie man sich für ein automatisiertes Programm anmeldet, das decken GridPoint und die Aggregatoren bereits gut ab. Was über eine Last wahr sein muss, bevor eine dauerhafte automatisierte Anweisung sie unbeaufsichtigt anfassen darf.
Automatisierte Demand Response verlangt mehr vom Gebäude als manuelles DSR
Bei einem manuellen DSR-Ereignis wird ein schlechter Entscheid gefangen. Ein Operator sieht die Mitteilung, prüft die Anlage und entscheidet, dass der Kälteverdichter heute kein guter Kandidat ist, weil er bereits warm läuft. Das Ereignis läuft ohne diese Last weiter, oder der Operator markiert sie und geht weiter. Der Fehler, falls es einen gibt, stoppt dort, wo jemand ihn prüft.
Automatisierung entfernt diesen Prüfpunkt absichtlich. Das ist das Wertversprechen: Die Reaktion erfolgt in Sekunden, nicht in der Zeit, die eine Person braucht, um eine Ereignismeldung zu bemerken, sich anzumelden und zu handeln. Es bedeutet aber auch, dass eine heute marginale Last, die an einem Tag mit Aufsicht noch in Ordnung wäre, an dem Tag ohne Aufsicht trotzdem ausgeführt wird, weil niemand da sein muss. Derselbe Fehler, der in einem manuellen Programm einmal auffallen würde, wiederholt sich jetzt bei jedem Ereignis, bis jemand das Muster bemerkt, meist nach einer Komfortbeschwerde oder einem Prozessproblem, nicht vorher.
Das ist der eigentliche Unterschied zwischen manueller und automatisierter DR, und es geht nicht darum, welche besser ist. Automatisierung ändert, was als ausreichender Nachweis gilt, bevor eine Last auf die Liste kommt. Eine Last, die meist flexibel ist, mit gelegentlichen Ausnahmen, die eine Person erkennen würde, ist ein vernünftiger manueller DSR-Kandidat. Dieselbe Last ist als automatisierte ein Risiko, sofern die Ausnahmen nicht auch in der Automatisierungslogik selbst berücksichtigt sind, statt dass jemand sie bemerken soll.
OpenADR auf Arbeitsebene: was VTN, VEN und Signal tatsächlich tun
OpenADR (Open Automated Demand Response) ist ein Kommunikationsstandard, gepflegt von der OpenADR Alliance, der festlegt, wie automatisierte DR-Signale strukturiert und ausgetauscht werden. Er entscheidet nicht, welche Lasten abgeschaltet werden oder wie ein Gebäude reagieren soll; er standardisiert die Nachrichten, damit Versorger, Netzbetreiber oder Aggregator auf der einen Seite und das Automatisierungssystem eines Gebäudes auf der anderen ohne individuelle Integration für jedes Paar miteinander sprechen können.
Das Modell hat zwei Seiten. Eine VTN (Virtual Top Node) ist der Signalgeber, typischerweise betrieben von Versorger, Netzbetreiber oder Aggregator, und stellt Ereignisse aus: Startzeit, Dauer, Signalpegel oder Preis, und meist ein Opt-out-Fenster, bevor die Reaktion verbindlich wird. Eine VEN (Virtual End Node) ist der Signalempfänger, ein Client auf oder neben dem BMS oder Energiemanagementsystem eines Gebäudes, und ist dafür verantwortlich, dieses Signal in eine tatsächliche lokale Reaktion zu übersetzen, welche Lasten seine Programmierung diesem Signalpegel zugeordnet hat.
Was der Standard vollständig der Gebäudeseite überlässt, ist der schwierigere Teil: zu entscheiden, welche Lasten diese VEN tatsächlich anfassen darf, unter welchen Bedingungen und mit welcher Sicherheit, dass das Anfassen kein Problem verursacht, von dem das Signal selbst nichts wissen kann. OpenADR übermittelt die Anweisung zuverlässig. Es hat keine Meinung dazu, ob die Anweisung in einem bestimmten Gebäude an einem bestimmten Tag sicher auszuführen ist, und ist auch nicht dafür ausgelegt. FrostLogic implementiert, betreibt oder zertifiziert keinen VEN-Client; das ist BMS- und Automatisierungsanbieter-Territorium. Explore beantwortet die Frage, die der Standard offen lässt.
Welche Lasten wirklich sicher zu automatisieren sind und welche zuerst einen Menschen brauchen
Die Lasttypen, die sich zu automatisieren lohnen, sind weitgehend dieselben, die bereits als flexibel in Demand Side Response identifiziert wurden, aber die Hürde für die Automatisierung ist höher als die für einmaliges manuelles Anbieten. Eine Last ist ein guter Automatisierungskandidat, wenn ihre Flexibilität über ein Spektrum von Bedingungen hält, nicht nur an dem Tag, an dem sie zufällig getestet wurde.
HVAC-Vorkühlung und Sollwertflexibilität lassen sich vernünftig automatisieren, sofern die Automatisierungslogik selbst den thermischen Puffer erzwingt, nicht ein fester Zeitplan, der jeden Tag denselben Puffer annimmt. Eine Vorkühlung für einen milden Übergangszeit-Nachmittag, die unbeaufsichtigt in einen heißen, voll belegten Tag hineinlaufen darf, leiht sich mehr thermische Trägheit, als das Gebäude zurückgeben kann, und niemand merkt es, bis die Beschwerden kommen.
Nicht-kritische Prozesslasten, VFD-Pumpen mit Spielraum, Chargenkompressoren, Anlagen mit echter Zeitplanflexibilität, sind oft die besten Automatisierungskandidaten, gerade weil ein verpasster oder falscher Abwurf selten etwas Schlimmeres verursacht als eine Zeitplanverschiebung. Kühlentfrostungszeiten lassen sich gut innerhalb ihres üblichen Minutenfensters automatisieren, solange die Automatisierung die aktuelle Gehäusetemperatur gegen den Lebensmittelsicherheitsgrenzwert prüft, bevor sie verschiebt, statt nach festem Timer unabhängig vom tatsächlichen Gehäusezustand zu verschieben.
Kälteanlagen-Sequenzierung braucht automatisiert mehr Vorsicht als manuell. Eine Lead-Lag-Anlage mit bestätigtem Spielraum auf der Nachlaufmaschine ist an Tagen, an denen ein Operator sie prüft, ein guter manueller Kandidat. Dieselbe Abschaltung zu automatisieren bedeutet, dass die Automatisierung jedes Mal wissen muss, ob der Spielraum aus dem Test heute noch besteht, unter heutiger Belegung und Außenbedingungen, statt ihn aus einer einmaligen Bewertung anzunehmen. Lasten, die an belegungsgebundene Lüftung, Lebenssicherheitssysteme oder Prozesse gekoppelt sind, bei denen die Unterbrechungskosten die Flexibilitätsvergütung übersteigen, bleiben vollständig von der Automatisierungsliste fern, aus denselben Gründen wie von der manuellen DSR-Liste.
Manuelles DSR versus automatisierte, OpenADR-ausgelöste ADR
| Dimension | Manuelles / geplantes DSR | Automatisierte / OpenADR-ausgelöste ADR |
|---|---|---|
| Auslösemechanismus | Ein Operator prüft eine Ereignismeldung und entscheidet, ob reagiert wird | Ein VTN-Signal erreicht die VEN, und eine vorprogrammierte Reaktion wird automatisch ausgeführt |
| Typische Reaktionszeit | Minuten bis Stunden, begrenzt durch die Geschwindigkeit einer Person | Sekunden bis Minuten, wodurch schneller bezahlte Programmstufen qualifiziert werden |
| Risikoprofil | Ein schlechter Entscheid wird meist vor oder während des Ereignisses erkannt | Ein schlechter Entscheid wird vollständig unbeaufsichtigt ausgeführt und wiederholt sich bei jedem künftigen Ereignis, bis jemand es bemerkt |
| Vor Commitment nötiger Nachweis | Flexibilität mindestens einmal bestätigt, mit Operator, der am Tag vetoieren kann | Flexibilität über ein Spektrum von Bedingungen bestätigt, mit Konfidenzgrenzen, weil niemand im Moment vetoieren kann |
Wo FrostLogics Evidenzebene endet und automatisierter Dispatch beginnt
Nichts davon macht FrostLogic Explore zu einem Teil der automatisierten Dispatch-Kette, und es ist auch nicht dafür gebaut. Explore identifiziert, welche Lasten in einem Gebäude tatsächlich sicher zu automatisieren sind, prognostiziert die Auswirkungen ihres Abwurfs mit Konfidenzgrenzen und belegt diese Entscheidung so, dass sie unter Bedingungen hält, die der anfängliche Test nicht abdeckte. Diese Arbeit läuft auf derselben Energiemanagement-Software, die Explore bereits für das tägliche Kosten- und Verbrauchsbild eines Gebäudes liefert; Automatisierungsreife ist eine weitere Frage, die sie beantwortet, kein separates System, das speziell für OpenADR angeflanscht wurde.
Was Explore nicht tut: ein OpenADR-Signal senden, einen VEN-Client betreiben, Flexibilität auf einem Markt handeln oder eine DSR-Zahlung abwickeln. Diese Ausführungsebene liegt beim eigenen VEN-Client des BMS und bei Aggregatoren, die Markt- und Dispatch-Seite in einem Maßstab betreiben, den eine Sensor-Analyseplattform nicht zu duplizieren braucht, darunter Drax, E.ON, Enel X und GridBeyond, dieselben Aggregatoren, die auch manuelle DSR-Anmeldungen bearbeiten. Die Übergabe ist der Nachweis: welche Lasten, unter welchen Bedingungen, mit welcher Konfidenz. Was ein Aggregator oder BMS-Anbieter mit diesem Nachweis macht, ihn in die Automatisierungsregeln einer VEN zu verdrahten, welche Signalpegel welche Lasten auslösen, ist deren Domäne.
Dieselbe Compliance-Überschneidung, die für manuelles DSR gilt, gilt auch hier, und ist möglicherweise wichtiger: ein automatisierter Abwurf, der gemessenen Verbrauch berührt, der in eine Nachhaltigkeits- oder Energieleistungsoffenlegung fließt, pausiert nicht, damit jemand die Überschneidung bemerkt, bevor er ausgeführt wird. Wo diese Schnittstelle behandelt werden muss, gehört sie zur bestehenden Compliance-Arbeit eines Gebäudes, nicht dazu, als etwas behandelt zu werden, das OpenADR-Teilnahme von sich aus einführt.
Häufige Fragen
Was ist automatisierte Demand Response? Automatisierte Demand Response (ADR) ist Demand Response, bei der ein Signal, meist von Versorger, Netzbetreiber oder Aggregator gesendet, Gebäudeanlagen automatisch Last abwerfen, verschieben oder begrenzen lässt, ohne dass eine Person im Moment entscheidet. Sie unterscheidet sich von manuellem oder geplantem DSR, bei dem ein Operator eine Ereignismeldung prüft und entscheidet, ob reagiert wird; siehe unseren Text zu Demand Side Response für diese Seite des Bildes.
Was ist Open Automated Demand Response (OpenADR)? Open Automated Demand Response ist ein Kommunikationsstandard, gepflegt von der OpenADR Alliance, der festlegt, wie automatisierte Demand-Response-Signale zwischen einem netzseitigen Sender (VTN) und einem gebäudeseitigen Empfänger (VEN) strukturiert und ausgetauscht werden. „Open“ bedeutet, dass der Standard offen und herstellerübergreifend interoperabel ist, nicht FrostLogics Rolle darin; FrostLogic implementiert oder zertifiziert keine OpenADR-Kommunikation.
Was sind automatisierte Demand-Response-Programme? Von Versorgern oder Aggregatoren betriebene Programme, die ein Gebäude für automatisierte Teilnahme bezahlen, typischerweise zu besseren Sätzen oder schnelleren Reaktionsstufen als manuelles DSR, weil die Reaktion vertraglich garantiert ist statt davon abhängig, dass ein Operator rechtzeitig handelt. Anmeldung und Programmauswahl werden von Aggregatoren wie Drax, E.ON, Enel X und GridBeyond bearbeitet, nicht von FrostLogic.
Versendet FrostLogic automatisierte Demand-Response-Signale? Nein. FrostLogic Explore identifiziert, welche Lasten sicher zu automatisieren sind, prognostiziert die Auswirkungen ihres Abwurfs mit Konfidenzgrenzen und belegt diese Entscheidung. Es versendet keine OpenADR-Signale, betreibt keinen VEN-Client, handelt keine Flexibilität, bietet nicht in Netzmärkte und wickelt keine DSR-Zahlungen ab. Diese Ausführungsebene liegt im VEN-Client des BMS oder bei einem Aggregator.
Welche Lasten sind sicher ohne Mensch in der Schleife zu automatisieren? Lasten mit Spielraum, der über ein Spektrum von Bedingungen hält, nicht nur an dem Tag, an dem sie getestet wurden, zum Beispiel nicht-kritische Prozesslasten mit echtem Zeitplanspielraum, Kühlentfrostung innerhalb ihrer Temperaturmarge oder Kälteanlagen-Sequenzierung mit bestätigtem Nachlaufmaschinen-Spielraum. Lasten, bei denen die Sicherheit von einer sich täglich ändernden Bedingung abhängt, belegungsgebundene Lüftung oder ein bereits warm laufender Kälteverdichter, brauchen menschliche Prüfung vor der Automatisierung, nicht nur vor der Anmeldung.
Was ist der Unterschied zwischen manuellem DSR und automatisierter ADR? Manuelles DSR gibt einer Person ein Fenster, eine Ereignismeldung zu prüfen und zu entscheiden, ob reagiert wird, sodass ein schlechter Entscheid vor oder während des Ereignisses erkannt wird. Automatisierte ADR entfernt diese Prüfung: ein VTN-Signal führt eine vorprogrammierte Reaktion in dem Moment aus, in dem es eintrifft, jedes Mal, ohne dass jemand einen Abwurf vetoieren kann, der sich an genau diesem Tag als unsicher erweist.
Kann ein automatisierter Abwurf ein Komfort- oder Sicherheitsproblem verursachen, wenn eine Last nicht wirklich bereit ist? Ja, und der Fehlermodus ist schlimmer als das manuelle Äquivalent, weil er im Moment nicht erkannt wird. Eine Vorkühlung über den thermischen Puffer des Gebäudes hinaus oder ein Kälteanlagen-Abwurf ohne echten Spielraum erzeugt dieselbe Komfortbeschwerde oder Prozessstörung wie ein manueller Fehler, nur dass er sich bei jedem künftigen Ereignis automatisch wiederholt, bis jemand es bemerkt und die Automatisierungslogik korrigiert.
Brauche ich ein BMS mit bereits installiertem OpenADR-VEN-Client, um FrostLogic Explore zu nutzen? Nein. Explores Prognose- und Evidenzarbeit läuft auf den vorhandenen Zählern eines Gebäudes und BMS- oder Sensordaten, unabhängig davon, ob OpenADR bereits ausgerollt ist. Die VEN-Client-Frage zählt erst, wenn Sie bereit sind, auf Explores Erkenntnisse zu reagieren, indem Sie Aggregator- oder BMS-seitige Automatisierung verdrahten, um den Abwurf auszuführen.
FrostLogic Explore bringt Sensor Intelligence, Szenariosimulation und Grounded AI in Gewerbe- und Industriegebäude. Mehr über Sensor Intelligence erfahren oder sprechen Sie es mit uns durch.
Neugierig, wie das bei Ihrem Gebäude aussehen würde?
Was verrät Ihnen Ihr Gebäude nicht?
Sagen Sie uns, was Sie herausfinden wollen: schleichend steigender Energieverbrauch, ein BMS, dem Sie nicht trauen, Compliance, der Sie hinterherlaufen. Wir hören erst zu und sagen Ihnen dann offen, ob Explore hilft. 30 oder 60 Minuten, Sie entscheiden. In jedem Fall unverbindlich.
