Automatiseret Demand Response: Hvilke laster er sikre at flekse uden en person der overvåger

Foto af Dmitrijs Safrans på Unsplash.

Søg på "automated demand response," og siden der kommer tilbage er skrevet for forsyningsselskaber, aggregatorer og standardiseringsorganer. GridPoint forklarer, hvad ADR er. OpenADR Alliance dokumenterer sin egen protokol. Wikipedia har historien. En kølemaskineleverandør sælger ADR-klar styring som en produktfunktion. Akademiske artikler fra Lawrence Berkeley og IEEE gennemgår netøkonomien. Det hele behandler bygningen som den fjerne ende af en signalvej: det, der modtager en instruktion og, i teorien, handler på den. Ingen af dem stiller spørgsmålet, der afgør, om den instruktion skal have lov til at handle på noget uden at en person tjekker først.

Vi dækkede den manuelle side af dette spørgsmål i demand side response: hvilke laster en bygning kan flekse, når en person beslutter, hændelse for hændelse, om der skal reageres. Automated demand response fjerner den person. Et OpenADR-signal ankommer, en VEN-klient på BMS'et modtager det, og en last afkobles, forkøles eller begrænses af sig selv, uden at nogen i bygningen først bekræfter, at det er sikkert. Det er appellen ved automatisering: ingen mistede hændelser, intet manuelt kapløb, hurtigere responstider der kvalificerer til de bedre betalende hurtig-respons-programmer. Det er også hvorfor det bliver dyrere, ikke billigere, at have det underliggende spørgsmål forkert (er denne specifikke last faktisk sikker at afkoble lige nu).

Dette stykke tager over hvor det andet stoppede. Ikke hvad OpenADR er (det dokumenterer Alliance præcist). Ikke hvordan man tilmelder sig et automatiseret program (GridPoint og aggregatorerne dækker allerede det). Hvad der skal være sandt om en last, før det er sikkert at lade en stående automatiseret instruktion røre den uovervåget.

Hvad er automated demand response?

Automated demand response (ADR) er demand response, hvor et signal fra et forsyningsselskab, en netoperatør eller en aggregator udløser, at en bygnings udstyr afkobler, flytter eller begrænser last automatisk, uden at en person beslutter i øjeblikket. Signalet kommer typisk over en standard som OpenADR. En Virtual End Node (VEN) på eller ved siden af bygningens BMS modtager det og kører en forprogrammeret respons: HVAC-setpunktsændring, forskydning af køle-/frys- afrimning, begrænsning af ikke-kritisk proces, eller hvilke laster anlægget har mappet til det signalniveau.

Traditionel eller manuel demand response beder stadig en person om at gennemgå en hændelsesmeddelelse og vælge, om der skal reageres. Planlagt DSR er en nær fætter: bygningen forpligter sig til at reducere på kendte timer, men et menneske ejer stadig dagens beslutning. ADR fjerner det kontrolpunkt. Responstider falder fra minutter eller timer til sekunder, hvilket er derfor mange programmer betaler mere for automatiseret deltagelse. Afvejningen ligger på bygningssiden. En marginal last, som en operatør ville springe over i dag, udføres alligevel den dag ingen overvåger, fordi ingen skal. Fleksibilitet der kun holder "det meste af tiden" er en rimelig manuel DSR-kandidat. Den samme last er en risiko som automatiseret, medmindre undtagelserne lever i selve automationslogikken.

Kort sagt: ADR er den automatiserede form for demand response. Netspørgsmålet (hvordan man tilmelder sig, hvilket program, hvordan afregning fungerer) hører hjemme hos forsyningsselskaber og aggregatorer. Bygningsspørgsmålet (hvilke laster der faktisk er sikre at lade signalet røre uovervåget) er hvad denne artikel dækker.

Hvordan automated demand response-programmer betaler

Forsyningsselskaber og aggregatorer driver ADR-programmer, der betaler bygninger for garanteret, hurtig respons. Typiske strukturer kombinerer en kapacitets- eller tilgængelighedsbetaling (du er tilmeldt og klar) med en energi- eller præstationsbetaling, når en hændelse udløses, og du leverer den aftalte reduktion. Automatiserede niveauer betaler ofte bedre end manuelle, fordi responsen er kontraktligt automatisk snarere end afhængig af, at en operatør handler i tide.

Tariffer, berettigelse og hændelsesregler varierer per marked og program. Denne side opfinder ikke programtariffer. Tilmelding, måling, afregning og opt-out-vinduer ligger hos aggregatorer som Drax, E.ON, Enel X og GridBeyond (og hos forsyningsselskabet eller netoperatøren bag dem). FrostLogic tilmelder ikke bygninger, byder ikke fleksibilitet ind og afregner ikke betalinger. Hvor Explore passer ind er tidligere: at dokumentere, hvilke laster der kan komme på den automatiserede liste uden at skabe komfort-, proces- eller sikkerhedsproblemer, som programmet aldrig ser.

OpenADR på arbejdende niveau: hvad en VTN, en VEN og et signal faktisk gør

OpenADR (Open Automated Demand Response) er en kommunikationsstandard, vedligeholdt af OpenADR Alliance, der definerer, hvordan automatiserede DR-signaler struktureres og udveksles. Den beslutter ikke, hvilke laster der skal afkobles, eller hvordan en bygning skal reagere; den standardiserer beskederne, så et forsyningsselskab, en netoperatør eller en aggregator på den ene side og en bygnings automationssystem på den anden kan tale uden en skræddersyet integration for hver parring.

Modellen har to sider. En VTN (Virtual Top Node) er signalsenderen, typisk drevet af et forsyningsselskab, en netoperatør eller en aggregator, og den udsteder hændelser: starttid, varighed, signalniveau eller pris, og normalt et opt-out-vindue, før responsen bliver bindende. En VEN (Virtual End Node) er signalmodtageren, en klient der kører på eller ved siden af en bygnings BMS eller energistyringssystem, og den er ansvarlig for at oversætte signalet til en faktisk lokal respons, hvilke laster dens programmering har tildelt det signalniveau.

Det standarden efterlader helt til bygningssiden er den sværere del: at beslutte, hvilke laster den VEN faktisk må røre, under hvilke betingelser, og med hvilken tillid til, at det ikke forårsager et problem, signalet selv ikke kan vide om. OpenADR flytter instruktionen pålideligt. Den har ingen mening om, hvorvidt instruktionen er sikker at udføre i en specifik bygning på en specifik dag, og den er ikke designet til det. FrostLogic implementerer, driver eller certificerer ikke en VEN-klient; det er BMS- og automationsleverandørernes territorium. Det Explore gør er at besvare det spørgsmål, standarden efterlader åbent.

Hvilke laster er faktisk sikre at automatisere, og hvilke har stadig brug for et menneske først

Lasttyperne værd at automatisere er stort set dem, der allerede er identificeret som fleksible i demand side response, men barren for at automatisere en er højere end barren for at tilbyde den manuelt én gang. En last er en god automationskandidat, når dens fleksibilitet holder over et spænd af betingelser, ikke kun den ene dag den tilfældigvis blev testet.

HVAC-forkøling og setpunktsfleks automatiseres rimeligt godt, forudsat at selve automationslogikken håndhæver den termiske buffer, ikke en fast tidsplan der antager, at samme buffer findes hver dag. En forkøling dimensioneret til en mild mellemsæson-eftermiddag og efterladt uovervåget ind i en varm, fuldt belagt dag låner mere termisk inerti, end bygningen har at give tilbage, og ingen fanger det, før klagerne starter.

Ikke-kritiske proceslaster, VFD-pumper med slack, batchkompressorer, udstyr med reel tidsplanfleksibilitet, er ofte de bedste automationskandidater netop fordi en misset eller forkert afkobling sjældent forårsager noget værre end et tidsplansskift. Køle-/frys-afrimningstiming automatiseres godt inden for sit sædvanlige minutskala-vindue, så længe automationen tjekker aktuel disktemperatur mod fødevaresikkerhedstærsklen, før den forskyder, snarere end at forskyde på en fast timer uanset hvor disken faktisk er.

Kølemaskinesekvensering kræver mere forsigtighed automatiseret end manuel. Et lead-lag-anlæg med bekræftet slack på lag-maskinen er en fin manuel kandidat de dage en operatør tjekker det. At automatisere samme afkobling betyder, at automationen skal vide, hver gang, om det slack der fandtes under test stadig findes i dag, under dagens belægning og udendørsforhold, ikke antage det fra en engangsevaluering. Laster knyttet til belægningsstyret ventilation, livssikkerhedssystemer, eller enhver proces hvor afbrydelsesomkostningen overstiger fleksibilitetsbetalingen, bliver helt uden for automationslisten, af samme grunde de er uden for den manuelle DSR-liste fra starten.

Manuel DSR versus automatiseret, OpenADR-udløst ADR

Hvor FrostLogics evidenslag slutter, og automatiseret dispatch begynder

Intet af ovenstående gør FrostLogic Explore til en del af den automatiserede dispatch-kæde, og det er ikke bygget til det. Explore identificerer, hvilke laster i en bygning der faktisk er sikre at automatisere, prognostiserer effekten af at afkoble dem med konfidensgrænser, og dokumenterer den beslutning, så den holder under betingelser, det indledende test ikke dækkede. Det arbejde kører på den samme energistyringssoftware Explore allerede leverer til en bygnings daglige omkostnings- og forbrugsbillede; automationsberedskab er et spørgsmål mere, den besvarer, ikke et separat system skruet på specifikt til OpenADR.

Det Explore ikke gør er at sende et OpenADR-signal, køre en VEN-klient, handle fleksibilitet ind på et marked eller afregne en DSR-betaling. Det udførelseslag ligger hos BMS'ets egen VEN-klient, og hos aggregatorerne der driver markeds- og dispatch-siden i en skala, en sensoranalyseplatform ikke har grund til at prøve at duplikere, blandt dem Drax, E.ON, Enel X og GridBeyond, de samme aggregatorer der håndterer manuel DSR-tilmelding. Overleveringen er evidensen: hvilke laster, under hvilke betingelser, med hvilken tillid. Hvad en aggregator eller BMS-leverandør gør med den evidens, kobler den ind i en VENs automationsregler, strukturerer hvilke signalniveauer der udløser hvilke laster, er deres domæne.

Samme compliance-overlap der gælder manuel DSR gælder også her, og betyder trolig mere: en automatiseret afkobling der rører målt forbrug, som føder en bæredygtigheds- eller energipræstationsdisclosure, pauser ikke for at nogen skal bemærke overlappet, før den udføres. Hvor det skæringspunkt skal håndteres, hører det til en bygnings eksisterende compliance-arbejde, ikke behandles som noget OpenADR-deltagelse introducerer af sig selv.

Hvis du kortlægger, hvilke laster i din portefølje der kan komme med i et automatiseret program uden at skabe problemerne ovenfor, tal det igennem.

Ofte stillede spørgsmål

Hvad er automated demand response? Automated demand response (ADR) er demand response, hvor et signal fra forsyningsselskab, netoperatør eller aggregator udløser, at en bygnings udstyr afkobler, flytter eller begrænser last automatisk, uden at en person beslutter i øjeblikket. Det adskiller sig fra manuel eller planlagt DSR, hvor en operatør gennemgår en hændelsesmeddelelse og vælger, om der skal reageres.

Hvad er et eksempel på demand response? En erhvervsbygning modtager et peak-hændelsessignal og hæver automatisk AHU-setpunkter med én grad i to timer, eller forskyder en supermarkeds køle-/frys-afrimning med femten minutter, så målt effektbehov falder under hændelsen uden at lukke kritisk anlæg. Det er et eksempel på last på bygningssiden, ikke en bolig-"elregning".

Er demand response dyrt, og hvordan fungerer betalingen? Deltagelse betales normalt, det debiteres ikke: programmer kompenserer kapacitet og/eller leveret reduktion. Automatiserede niveauer betaler ofte mere end manuelle, fordi responsen er garanteret. Præcise tariffer afhænger af marked og aggregatoraftale. FrostLogic sætter eller afregner ikke de betalinger; aggregatorer og forsyningsselskaber gør. Den reelle omkostningsrisiko på bygningssiden er at automatisere en last, der aldrig var sikker at afkoble uovervåget.

Hvad er open automated demand response (OpenADR)? Open Automated Demand Response er en kommunikationsstandard, vedligeholdt af OpenADR Alliance, der definerer, hvordan automatiserede demand response-signaler struktureres og udveksles mellem en netside-afsender (en VTN) og en bygningsside-modtager (en VEN). "Open" refererer til, at standarden er åben og interoperabel mellem leverandører, ikke til FrostLogics rolle i den; FrostLogic implementerer eller certificerer ikke OpenADR-kommunikation.

Hvad er automated demand response-programmer? Programmer drevet af forsyningsselskaber eller aggregatorer, der betaler en bygning for automatiseret deltagelse, typisk til bedre tariffer eller hurtigere responsniveauer end manuel DSR, fordi responsen er kontraktligt garanteret snarere end afhængig af, at en operatør handler i tide. Tilmelding og programvalg håndteres af aggregatorer som Drax, E.ON, Enel X og GridBeyond, ikke af FrostLogic.

Sender FrostLogic automated demand response-signaler? Nej. FrostLogic Explore identificerer, hvilke laster der er sikre at automatisere, prognostiserer effekten af at afkoble dem med konfidensgrænser, og dokumenterer den beslutning. Det sender ikke OpenADR-signaler, kører ikke en VEN-klient, handler ikke fleksibilitet, byder ikke ind på netmarkeder og afregner ikke DSR-betalinger. Det udførelseslag ligger i BMS'ets VEN-klient eller hos en aggregator.

Hvilke laster er sikre at automatisere uden et menneske i loopen? Laster med slack der holder over et spænd af betingelser, ikke kun den ene dag de blev testet, for eksempel ikke-kritiske proceslaster med reel tidsplanslack, køle-/frys-afrimning inden for sin temperaturmargin, eller kølemaskinesekvensering med bekræftet slack på lag-maskinen. Laster hvor sikkerheden afhænger af en betingelse der ændrer sig dag for dag, belægningsstyret ventilation eller en kølemaskine der allerede kører varm, har brug for et menneske der tjekker før automatisering, ikke kun før tilmelding.

Hvad er forskellen mellem manuel DSR og automatiseret ADR? Manuel DSR giver et menneske et vindue til at gennemgå en hændelsesmeddelelse og beslutte, om der skal reageres, så et dårligt kald fanges før eller under hændelsen. Automatiseret ADR fjerner den kontrol: et VTN-signal udfører en forprogrammeret respons i det øjeblik det ankommer, hver gang, uden at nogen nedlægger veto mod en afkobling der viser sig usikker den særlige dag.

Kan en automatiseret afkobling forårsage et komfort- eller sikkerhedsproblem, hvis en last ikke faktisk er klar? Ja, og fejlmoduset er værre end det manuelle modstykke, fordi det ikke fanges i øjeblikket. En forkøling drevet forbi bygningens termiske buffer, eller en kølemaskineafkobling sekvenseret uden reelt slack, giver den samme komfortklage eller procesforstyrrelse en manuel fejl ville give, undtagen at den gentages automatisk ved hver fremtidig hændelse, til nogen bemærker og fikser automationslogikken.

Har jeg brug for et BMS med en OpenADR VEN-klient allerede installeret for at bruge FrostLogic Explore? Nej. Explores prognose- og evidensarbejde kører på en bygnings eksisterende målere og BMS- eller sensordata uafhængigt af, om OpenADR allerede er udrullet. VEN-klientspørgsmålet betyder først noget, når du er klar til at handle på Explores fund ved at koble en aggregator eller BMS-side automation til for at udføre afkoblingen.