Foto von Dmitrijs Safrans auf Unsplash.
Wer nach „automated 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. Automated 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 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 ab). Was über eine Last wahr sein muss, bevor eine dauerhafte automatisierte Anweisung sie unbeaufsichtigt anfassen darf.
Was ist automated demand response?
Automated demand response (ADR) ist Demand Response, bei der ein Signal von einem Versorger, Netzbetreiber oder Aggregator die Anlagen eines Gebäudes automatisch Last abschalten, verschieben oder begrenzen lässt, ohne dass eine Person im Moment entscheidet. Das Signal kommt üblicherweise über einen Standard wie OpenADR. Ein Virtual End Node (VEN) am oder neben dem BMS des Gebäudes empfängt es und führt eine vorprogrammierte Reaktion aus: HVAC-Sollwertänderung, Verschiebung der Kühl-/Tiefkühl-Abtauung, Begrenzung nichtkritischer Prozesse, oder welche Lasten der Standort diesem Signalniveau zugeordnet hat.
Traditionelle oder manuelle Demand Response verlangt weiterhin, dass eine Person eine Ereignismeldung prüft und wählt, ob reagiert wird. Geplantes DSR ist ein enger Verwandter: Das Gebäude verpflichtet sich, zu bekannten Stunden zu reduzieren, aber ein Mensch besitzt weiterhin die Entscheidung am Tag selbst. ADR entfernt diesen Prüfpunkt. Reaktionszeiten sinken von Minuten oder Stunden auf Sekunden, deshalb zahlen viele Programme mehr für automatisierte Teilnahme. Der Trade-off liegt auf der Gebäudeseite. Eine marginale Last, die ein Operator heute auslassen würde, läuft am Tag ohne Aufsicht trotzdem, weil niemand da sein muss. Flexibilität, die nur „die meiste Zeit“ hält, ist ein vernünftiger manueller DSR-Kandidat. Dieselbe Last ist als automatisierte ein Risiko, sofern die Ausnahmen nicht in der Automationslogik selbst leben.
Kurz: ADR ist die automatisierte Form von Demand Response. Die Netzfrage (Anmeldung, Programm, Abrechnung) gehört zu Versorgern und Aggregatoren. Die Gebäudefrage (welche Lasten dieses Signal unbeaufsichtigt wirklich sicher berühren darf) ist, was dieser Artikel behandelt.
Wie automated demand response-Programme zahlen
Versorger und Aggregatoren betreiben ADR-Programme, die Gebäude für garantierte, schnelle Reaktion zahlen. Typische Strukturen kombinieren eine Kapazitäts- oder Verfügbarkeitszahlung (Sie bleiben angemeldet und bereit) mit einer Energie- oder Leistungszahlung, wenn ein Ereignis auslöst und Sie die vertragliche Reduktion liefern. Automatisierte Stufen zahlen oft besser als manuelle, weil die Reaktion vertraglich automatisch ist und nicht davon abhängt, dass ein Operator rechtzeitig handelt.
Tarife, Eignung und Ereignisregeln variieren nach Markt und Programm. Diese Seite erfindet keine Programmtarife. Anmeldung, Messung, Abrechnung und Opt-out-Fenster liegen bei Aggregatoren wie Drax, E.ON, Enel X und GridBeyond (und beim Versorger oder Netzbetreiber dahinter). FrostLogic meldet Gebäude nicht an, bietet keine Flexibilität und rechnet keine Zahlungen ab. Explore gehört früher hin: zu belegen, welche Lasten auf die automatisierte Liste dürfen, ohne Komfort-, Prozess- oder Sicherheitsprobleme zu erzeugen, die das Programm nie sieht.
OpenADR auf Arbeitsebene: was VTN, VEN und Signal tatsächlich tun
OpenADR (Open Automated Demand Response) ist ein Kommunikationsstandard der OpenADR Alliance, der definiert, 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, sodass Versorger, Netzbetreiber oder Aggregator auf der einen Seite und das Automationssystem eines Gebäudes auf der anderen ohne maßgeschneiderte Integration für jedes Paar sprechen können.
Das Modell hat zwei Seiten. Eine VTN (Virtual Top Node) ist der Signalsender, typischerweise von Versorger, Netzbetreiber oder Aggregator betrieben, und sie stellt Ereignisse aus: Startzeit, Dauer, Signalniveau oder Preis, und meist ein Opt-out-Fenster, bevor die Reaktion bindend wird. Eine VEN (Virtual End Node) ist der Signalempfänger, ein Client am oder neben dem BMS oder Energiemanagementsystem des Gebäudes, und sie übersetzt das Signal in eine tatsächliche lokale Reaktion, welche Lasten ihre Programmierung diesem Signalniveau zugewiesen hat.
Was der Standard vollständig der Gebäudeseite überlässt, ist der schwierigere Teil: zu entscheiden, welche Lasten diese VEN tatsächlich berühren darf, unter welchen Bedingungen, und mit welcher Sicherheit, dass das Berühren kein Problem verursacht, das das Signal selbst nicht kennen kann. OpenADR bewegt die Anweisung zuverlässig. Es hat keine Meinung dazu, ob die Anweisung in einem bestimmten Gebäude an einem bestimmten Tag sicher ausführbar ist, und ist dafür nicht ausgelegt. FrostLogic implementiert, betreibt oder zertifiziert keinen VEN-Client; das ist BMS- und Automationslieferanten-Territorium. Explore beantwortet die Frage, die der Standard offen lässt.
Welche Lasten sind tatsächlich sicher zu automatisieren, und welche brauchen zuerst noch einen Menschen
Die Lasttypen, die sich zu automatisieren lohnen, sind weitgehend dieselben, die bereits als flexibel in Demand Side Response identifiziert wurden, aber die Latte für die Automatisierung einer Last liegt höher als die Latte, sie einmal manuell anzubieten. Eine Last ist ein guter Automationskandidat, wenn ihre Flexibilität über ein Spektrum von Bedingungen hält, nicht nur an dem einen Tag, an dem sie zufällig getestet wurde.
HVAC-Vorkühlung und Sollwertflex automatisieren sich vernünftig, sofern die Automationslogik selbst den thermischen Puffer erzwingt, nicht ein fester Zeitplan, der denselben Puffer jeden Tag annimmt. Eine Vorkühlung, bemessen für einen milden Übergangsjahreszeit-Nachmittag und unbeaufsichtigt in einen heißen, voll belegten Tag gelassen, leiht mehr thermische Trägheit, als das Gebäude zurückgeben kann, und niemand fängt es, bis die Beschwerden beginnen.
Nichtkritische Prozesslasten, VFD-Pumpen mit Spielraum, Batch-Kompressoren, Geräte mit echter Zeitplanflexibilität, sind oft die besten Automationskandidaten genau deshalb, weil eine verpasste oder falsche Abschaltung selten Schlimmeres als eine Zeitplanverschiebung verursacht. Kühl-/Tiefkühl-Abtau-Timing automatisiert sich gut innerhalb seines üblichen Minutenfensters, solange die Automation die aktuelle Vitrinentemperatur gegen die Lebensmittelsicherheitsgrenze prüft, bevor sie verschiebt, statt auf einem festen Timer zu verschieben, egal wo die Vitrine tatsächlich steht.
Kältemaschinen-Sequenzierung braucht automatisiert mehr Vorsicht als manuell. Eine Lead-Lag-Anlage mit bestätigtem Spielraum auf der Lag-Maschine ist an Tagen, an denen ein Operator prüft, ein guter manueller Kandidat. Dieselbe Abschaltung zu automatisieren heißt, dass die Automation jedes Mal wissen muss, ob der Spielraum aus dem Test heute unter heutiger Belegung und Außenbedingungen noch existiert, nicht ihn aus einer einmaligen Bewertung annehmen. Lasten an belegungsgebundene Lüftung, Lebenssicherheitssysteme oder jeden Prozess, dessen Unterbrechungskosten die Flexibilitätszahlung übersteigen, bleiben ganz von der Automationsliste, aus denselben Gründen, aus denen sie von Anfang an von der manuellen DSR-Liste sind.
Manuelles DSR versus automatisiertes, OpenADR-ausgelöstes ADR
| Dimension | Manuelles / geplantes DSR | Automatisiertes / OpenADR-ausgelöstes ADR |
|---|---|---|
| Auslösemechanismus | Ein Operator prüft eine Ereignismeldung und entscheidet, ob reagiert wird | Ein VTN-Signal erreicht die VEN und eine vorprogrammierte Reaktion läuft automatisch |
| Typische Reaktionszeit | Minuten bis Stunden, begrenzt dadurch, wie schnell eine Person handeln kann | Sekunden bis Minuten, was für besser bezahlte Programmstufen qualifiziert |
| Risikoprofil | Ein schlechter Entscheid wird meist vor oder während des Ereignisses gefangen | Ein schlechter Entscheid läuft vollständig, unbeaufsichtigt, und wiederholt sich bei jedem künftigen Ereignis, bis jemand es bemerkt |
| Beweis vor der Verpflichtung | Flexibilität mindestens einmal bestätigt, mit Operator-Veto am Tag | Flexibilität über ein Spektrum von Bedingungen bestätigt, mit Konfidenzgrenzen, weil niemand im Moment vetot |
Wo FrostLogics Evidenzschicht endet und automatisiertes Dispatch beginnt
Nichts davon macht FrostLogic Explore Teil der automatisierten Dispatch-Kette, und es ist nicht dafür gebaut. Explore identifiziert, welche Lasten in einem Gebäude tatsächlich sicher zu automatisieren sind, prognostiziert die Wirkung ihrer Abschaltung mit Konfidenzgrenzen und belegt diese Entscheidung so, dass sie unter Bedingungen hält, die der erste 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; Automationsbereitschaft ist eine weitere Frage, die sie beantwortet, kein separates System, das speziell für OpenADR angeschraubt wurde.
Was Explore nicht tut: ein OpenADR-Signal senden, einen VEN-Client betreiben, Flexibilität in einen Markt handeln oder eine DSR-Zahlung abrechnen. Diese Ausführungsschicht sitzt beim eigenen VEN-Client des BMS und bei den Aggregatoren, die Markt- und Dispatch-Seite in einem Maßstab betreiben, den eine Sensoranalyseplattform nicht zu duplizieren braucht, darunter Drax, E.ON, Enel X und GridBeyond, dieselben Aggregatoren, die manuelle DSR-Anmeldung handhaben. Die Übergabe ist die Evidenz: welche Lasten, unter welchen Bedingungen, mit welcher Sicherheit. Was ein Aggregator oder BMS-Anbieter mit dieser Evidenz macht, sie in die Automationsregeln einer VEN verdrahtet, welche Signalniveaus welche Lasten auslösen, ist deren Domäne.
Derselbe Compliance-Überlapp, der für manuelles DSR gilt, gilt hier ebenfalls und zählt vermutlich mehr: eine automatisierte Abschaltung, die gemessenen Verbrauch berührt, der in eine Nachhaltigkeits- oder Energieleistungs-Offenlegung eingeht, pausiert nicht, damit jemand den Überlapp bemerkt, bevor sie ausgeführt wird. Wo diese Schnittstelle Handhabung braucht, gehört sie zur bestehenden Compliance-Arbeit eines Gebäudes, nicht als etwas, das OpenADR-Teilnahme allein einführt.
Wenn Sie kartieren, welche Lasten in Ihrem Bestand einem automatisierten Programm beitreten könnten, ohne die Probleme oben zu erzeugen, sprechen Sie es durch.
Häufige Fragen
Was ist automated demand response? Automated demand response (ADR) ist Demand Response, bei der ein Signal von Versorger, Netzbetreiber oder Aggregator die Anlagen eines Gebäudes automatisch Last abschalten, 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 wählt, ob reagiert wird.
Was ist ein Beispiel für Demand Response? Ein Gewerbegebäude erhält ein Peak-Ereignissignal und hebt automatisch AHU-Sollwerte um ein Grad für zwei Stunden an, oder verschiebt die Kühl-/Tiefkühl-Abtauung eines Supermarkts um fünfzehn Minuten, sodass die gemessene Last während des Ereignisses sinkt, ohne kritische Anlagen abzuschalten. Das ist ein Gebäude-Lastbeispiel, keine Wohnungs-„Stromrechnung“.
Ist Demand Response teuer, und wie funktioniert die Zahlung? Teilnahme wird üblicherweise bezahlt, nicht berechnet: Programme kompensieren Kapazität und/oder gelieferte Reduktion. Automatisierte Stufen zahlen oft mehr als manuelle, weil die Reaktion garantiert ist. Exakte Tarife hängen von Markt und Aggregatorvertrag ab. FrostLogic setzt oder rechnet diese Zahlungen nicht ab; Aggregatoren und Versorger tun das. Das echte Kostenrisiko auf der Gebäudeseite ist, eine Last zu automatisieren, die nie sicher unbeaufsichtigt abzuschalten war.
Was ist open automated demand response (OpenADR)? Open Automated Demand Response ist ein Kommunikationsstandard der OpenADR Alliance, der definiert, wie automatisierte Demand-Response-Signale zwischen einem netsseitigen Sender (VTN) und einem gebäudeseitigen Empfänger (VEN) strukturiert und ausgetauscht werden. „Open“ bezieht sich darauf, dass der Standard offen und herstellerübergreifend interoperabel ist, nicht auf FrostLogics Rolle darin; FrostLogic implementiert oder zertifiziert keine OpenADR-Kommunikation.
Was sind automated demand response programs? Von Versorgern oder Aggregatoren betriebene Programme, die ein Gebäude für automatisierte Teilnahme zahlen, typischerweise zu besseren Tarifen oder schnelleren Reaktionsstufen als manuelles DSR, weil die Reaktion vertraglich garantiert ist und nicht davon abhängt, dass ein Operator rechtzeitig handelt. Anmeldung und Programmwahl handhaben Aggregatoren wie Drax, E.ON, Enel X und GridBeyond, nicht FrostLogic.
Sendet FrostLogic automated demand response-Signale? Nein. FrostLogic Explore identifiziert, welche Lasten sicher zu automatisieren sind, prognostiziert die Wirkung ihrer Abschaltung mit Konfidenzgrenzen und belegt diese Entscheidung. Es sendet keine OpenADR-Signale, betreibt keinen VEN-Client, handelt keine Flexibilität, bietet nicht in Netzmärkte und rechnet keine DSR-Zahlungen ab. Diese Ausführungsschicht sitzt im VEN-Client des BMS oder bei einem Aggregator.
Welche Lasten sind sicher zu automatisieren, ohne einen Menschen in der Schleife? Lasten mit Spielraum, der über ein Spektrum von Bedingungen hält, nicht nur an dem einen Tag, an dem sie getestet wurden, zum Beispiel nichtkritische Prozesslasten mit echtem Zeitplanspielraum, Kühl-/Tiefkühl-Abtauung innerhalb ihrer Temperaturmarge, oder Kältemaschinen-Sequenzierung mit bestätigtem Lag-Maschinen-Spielraum. Lasten, deren Sicherheit von einer täglich wechselnden Bedingung abhängt, belegungsgebundene Lüftung oder eine bereits warm laufende Kältemaschine, brauchen eine Person, die vor dem Automatisieren prüft, nicht nur vor der Anmeldung.
Was ist der Unterschied zwischen manuellem DSR und automatisiertem 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 gefangen wird. Automatisiertes ADR entfernt diese Prüfung: Ein VTN-Signal führt eine vorprogrammierte Reaktion im Moment des Eintreffens aus, jedes Mal, ohne dass jemand eine Abschaltung vetot, die an diesem Tag unsicher ist.
Kann eine automatisierte Abschaltung 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 gefangen wird. Eine Vorkühlung über den thermischen Puffer des Gebäudes hinaus, oder eine Kältemaschinen-Abschaltung ohne echten Spielraum, erzeugt dieselbe Komfortbeschwerde oder Prozessstörung wie ein manueller Fehler, nur dass sie sich bei jedem künftigen Ereignis automatisch wiederholt, bis jemand die Automationslogik bemerkt und 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 und BMS- oder Sensordaten eines Gebäudes, unabhängig davon, ob OpenADR bereits deployed ist. Die VEN-Client-Frage zählt erst, wenn Sie bereit sind, auf Explores Ergebnisse zu handeln, indem Sie Aggregator- oder BMS-seitige Automation verdrahten, um die Abschaltung 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.
