Automatisert forbruksrespons: Hvilke laster er trygge å flekse uten et menneske som overvåker

Foto av Dmitrijs Safrans på Unsplash.

Søk på "automated demand response," og siden som kommer tilbake er skrevet for nettselskaper, aggregatorer og standardiseringsorganer. GridPoint forklarer hva ADR er. OpenADR Alliance dokumenterer sin egen protokoll. Wikipedia har historien. En kjølemaskinleverandør selger ADR-klar styring som en produktfunksjon. Akademiske artikler fra Lawrence Berkeley og IEEE går gjennom nettøkonomien. Alt sammen behandler bygningen som den fjerne enden av en signalvei: det som mottar en instruksjon og, i teorien, handler på den. Ingen av dem stiller spørsmålet som avgjør om den instruksjonen skal få lov til å handle på noe uten at en person sjekker først.

Vi dekket den manuelle siden av dette spørsmålet i forbrukssiderespons: hvilke laster en bygning kan flekse når en person avgjør, hendelse for hendelse, om det skal responderes. Automated demand response fjerner den personen. Et OpenADR-signal ankommer, en VEN-klient på BMS-et mottar det, og en last kobles ut, forkjøles eller begrenses av seg selv, uten at noen i bygningen først bekrefter at det er trygt. Det er appellen ved automatisering: ingen mistede hendelser, ingen manuell kamp, raskere responstider som kvalifiserer til de bedre betalende hurtigresponsprogrammene. Det er også hvorfor det blir dyrere, ikke billigere, å ha det underliggende spørsmålet feil (er denne spesifikke lasten faktisk trygg å koble ut akkurat nå).

Denne teksten tar over der den andre sluttet. Ikke hva OpenADR er (det dokumenterer Alliance presist). Ikke hvordan man melder seg på et automatisert program (GridPoint og aggregatorene dekker allerede det). Hva som må være sant om en last før det er trygt å la en stående automatisert instruksjon røre den uten tilsyn.

Hva er automated demand response?

Automated demand response (ADR) er forbruksrespons der et signal fra et nettselskap, en nettoperatør eller en aggregator utløser at en bygnings utstyr kobler ut, forskyver eller begrenser last automatisk, uten at en person avgjør i øyeblikket. Signalet kommer vanligvis over en standard som OpenADR. En Virtual End Node (VEN) på eller ved siden av bygningens BMS mottar det og kjører en forhåndsprogrammert respons: HVAC-setpunktsendring, forskyvning av kjøl/frys-avriming, begrensning av ikke-kritisk prosess, eller hvilke laster anlegget har mappet til det signalnivået.

Tradisjonell eller manuell demand response ber fortsatt en person om å gjennomgå en hendelsesmelding og velge om det skal responderes. Planlagt DSR er en nær fetter: bygningen forplikter seg til å redusere på kjente timer, men et menneske eier fortsatt dagens beslutning. ADR fjerner det kontrollpunktet. Responstidene synker fra minutter eller timer til sekunder, som er derfor mange programmer betaler mer for automatisert deltakelse. Avveiningen ligger på bygningssiden. En marginal last som en operatør ville hoppet over i dag, utføres likevel den dagen ingen overvåker, fordi ingen trenger å være der. Fleksibilitet som bare holder «det meste av tiden» er en rimelig manuell DSR-kandidat. Samme last er en risiko som automatisert med mindre unntakene lever i selve automasjonslogikken.

Kort sagt: ADR er den automatiserte formen for demand response. Nettspørsmålet (hvordan man melder seg på, hvilket program, hvordan avregning fungerer) hører hjemme hos nettselskaper og aggregatorer. Bygningsspørsmålet (hvilke laster som faktisk er trygge å la signalet røre uten tilsyn) er det denne artikkelen dekker.

Hvordan automated demand response-programmer betaler

Nettselskaper og aggregatorer driver ADR-programmer som betaler bygninger for garantert, rask respons. Typiske strukturer kombinerer en kapasitets- eller tilgjengelighetsbetaling (du er påmeldt og klar) med en energi- eller ytelsesbetaling når en hendelse utløses og du leverer den avtalte reduksjonen. Automatiserte nivåer betaler ofte bedre enn manuelle fordi responsen er kontraktmessig automatisk snarere enn avhengig av at en operatør handler i tide.

Tariffer, berettigelse og hendelsesregler varierer per marked og program. Denne siden finner ikke på programtariffer. Påmelding, måling, avregning og opt-out-vinduer ligger hos aggregatorer som Drax, E.ON, Enel X og GridBeyond (og hos nettselskapet eller nettoperatøren bak dem). FrostLogic melder ikke på bygninger, byr ikke inn fleksibilitet og avregner ikke betalinger. Der Explore passer inn er tidligere: å evidensbasere hvilke laster som kan komme på den automatiserte listen uten å skape komfort-, prosess- eller sikkerhetsproblemer programmet aldri ser.

OpenADR på arbeidende nivå: hva en VTN, en VEN og et signal faktisk gjør

OpenADR (Open Automated Demand Response) er en kommunikasjonsstandard, vedlikeholdt av OpenADR Alliance, som definerer hvordan automatiserte DR-signaler struktureres og utveksles. Den avgjør ikke hvilke laster som skal kobles ut eller hvordan en bygning skal respondere; den standardiserer meldingene slik at et nettselskap, en nettoperatør eller en aggregator på den ene siden og en bygnings automasjonssystem på den andre kan snakke uten en skreddersydd integrasjon for hver paring.

Modellen har to sider. En VTN (Virtual Top Node) er signalsenderen, typisk drevet av et nettselskap, en nettoperatør eller en aggregator, og den utsteder hendelser: starttid, varighet, signalnivå eller pris, og vanligvis et opt-out-vindu før responsen blir bindende. En VEN (Virtual End Node) er signalmottakeren, en klient som kjører på eller ved siden av en bygnings BMS eller energistyringssystem, og den er ansvarlig for å oversette signalet til en faktisk lokal respons, hvilke laster dens programmering har tildelt det signalnivået.

Det standarden overlater helt til bygningssiden er den vanskeligere delen: å avgjøre hvilke laster den VEN faktisk skal få lov til å røre, under hvilke betingelser, og med hvilken tillit til at det ikke forårsaker et problem signalet selv ikke kan vite om. OpenADR flytter instruksjonen pålitelig. Den har ingen mening om hvorvidt instruksjonen er trygg å utføre i en spesifikk bygning på en spesifikk dag, og den er ikke designet for det. FrostLogic implementerer, driver eller sertifiserer ikke en VEN-klient; det er BMS- og automasjonsleverandørenes territorium. Det Explore gjør er å svare på spørsmålet standarden lar stå åpent.

Hvilke laster er faktisk trygge å automatisere, og hvilke trenger fortsatt et menneske først

Lasttypene som er verdt å automatisere er i stor grad de samme som allerede er identifisert som fleksible i forbrukssiderespons, men lista for å automatisere en er høyere enn lista for å tilby den manuelt én gang. En last er en god automasjonskandidat når dens fleksibilitet holder over et spenn av betingelser, ikke bare den ene dagen den tilfeldig ble testet.

HVAC-forkjøling og setpunktsfleks automatiseres rimelig godt, forutsatt at selve automasjonslogikken håndhever den termiske bufferen, ikke en fast tidsplan som antar at samme buffer finnes hver dag. En forkjøling dimensjonert for en mild skuldersesong-ettermiddag og etterlatt uten tilsyn inn i en varm, fullt belagt dag låner mer termisk treghet enn bygningen har å gi tilbake, og ingen fanger det før klagene starter.

Ikke-kritiske prosesslaster, VFD-pumper med slark, batchkompressorer, utstyr med reell tidsplanfleksibilitet, er ofte de beste automasjonskandidatene nettopp fordi en misset eller feil utkobling sjelden forårsaker noe verre enn et tidsplansskift. Kjøl/frys-avrimingstiming automatiseres godt innenfor sitt vanlige minuttskalavindu, så lenge automasjonen sjekker aktuell disktemperatur mot mattrygghetsterskelen før den forskyver, snarere enn å forskyve på en fast timer uansett hvor disken faktisk er.

Kjølemaskinsekvensering krever mer forsiktighet automatisert enn manuell. Et lead-lag-anlegg med bekreftet slark på lag-maskinen er en fin manuell kandidat de dagene en operatør sjekker det. Å automatisere samme utkobling betyr at automasjonen må vite, hver gang, om slarken som fantes under test fortsatt finnes i dag, under dagens belegg og utendørsforhold, ikke anta det fra en engangsevaluering. Laster knyttet til beleggsstyrt ventilasjon, livssikkerhetssystemer, eller enhver prosess der avbruddskostnaden overstiger fleksibilitetsbetalingen, blir helt utenfor automasjonslisten, av samme grunner de er utenfor den manuelle DSR-listen fra starten.

Manuell DSR versus automatisert, OpenADR-utløst ADR

Der FrostLogics evidenslag slutter og automatisert dispatch begynner

Ingenting av det ovenstående gjør FrostLogic Explore til en del av den automatiserte dispatch-kjeden, og det er ikke bygget for det. Explore identifiserer hvilke laster i en bygning som faktisk er trygge å automatisere, prognostiserer effekten av å koble dem ut med konfidensgrenser, og evidensbaserer den beslutningen slik at den holder under betingelser det innledende testet ikke dekket. Det arbeidet kjører på den samme programvaren for energistyring Explore allerede leverer for en bygnings daglige kostnads- og forbruksbilde; automasjonsberedskap er ett spørsmål til den svarer på, ikke et separat system skrudd på spesifikt for OpenADR.

Det Explore ikke gjør er å sende et OpenADR-signal, kjøre en VEN-klient, handle fleksibilitet inn i et marked eller avregne en DSR-betaling. Det utførelseslaget ligger hos BMS-ets egen VEN-klient, og hos aggregatorene som driver markeds- og dispatch-siden i en skala en sensoranalyseplattform ikke har noen grunn til å prøve å duplisere, blant dem Drax, E.ON, Enel X og GridBeyond, de samme aggregatorene som håndterer manuell DSR-påmelding. Overleveringen er beviset: hvilke laster, under hvilke betingelser, med hvilken tillit. Hva en aggregator eller BMS-leverandør gjør med det beviset, koble det inn i en VENs automasjonsregler, strukturere hvilke signalnivåer som utløser hvilke laster, er deres domene.

Samme etterlevelses-overlapp som gjelder for manuell DSR gjelder også her, og betyr trolig mer: en automatisert utkobling som rører målt forbruk som fôrer en bærekrafts- eller energiprestasjonsrapport, tar ikke pause for at noen skal merke overlappet før den utføres. Der dette krysningspunktet må håndteres, hører det til en bygnings eksisterende etterlevelsesarbeid, ikke behandles som noe OpenADR-deltakelse introduserer av seg selv.

Hvis du kartlegger hvilke laster i porteføljen din som kan bli med i et automatisert program uten å skape problemene ovenfor, snakk det gjennom.

Ofte stilte spørsmål

Hva er automated demand response? Automated demand response (ADR) er forbruksrespons der et signal fra nettselskap, nettoperatør eller aggregator utløser at en bygnings utstyr kobler ut, forskyver eller begrenser last automatisk, uten at en person avgjør i øyeblikket. Det skiller seg fra manuell eller planlagt DSR, der en operatør gjennomgår en hendelsesmelding og velger om det skal responderes.

Hva er et eksempel på demand response? Et næringsbygg mottar et peak-hendelsessignal og hever automatisk AHU-setpunkter med én grad i to timer, eller forskyver en dagligvarebutikks kjøl/frys-avriming med femten minutter, så målt effektbehov synker under hendelsen uten å stenge kritisk anlegg. Det er et eksempel på last på bygningssiden, ikke en bolig-«strømregning».

Er demand response dyrt, og hvordan fungerer betalingen? Deltakelse betales vanligvis, den debiteres ikke: programmer kompenserer kapasitet og/eller levert reduksjon. Automatiserte nivåer betaler ofte mer enn manuelle fordi responsen er garantert. Eksakte tariffer avhenger av marked og aggregatoravtale. FrostLogic setter eller avregner ikke de betalingene; aggregatorer og nettselskaper gjør det. Den reelle kostnadsrisikoen på bygningssiden er å automatisere en last som aldri var trygg å koble ut uten tilsyn.

Hva er open automated demand response (OpenADR)? Open Automated Demand Response er en kommunikasjonsstandard, vedlikeholdt av OpenADR Alliance, som definerer hvordan automatiserte demand response-signaler struktureres og utveksles mellom en nettside-avsender (en VTN) og en bygningsside-mottaker (en VEN). «Open» refererer til at standarden er åpen og interoperabel mellom leverandører, ikke til FrostLogics rolle i den; FrostLogic implementerer eller sertifiserer ikke OpenADR-kommunikasjon.

Hva er automated demand response-programmer? Programmer drevet av nettselskaper eller aggregatorer som betaler en bygning for automatisert deltakelse, vanligvis til bedre tariffer eller raskere responsnivåer enn manuell DSR fordi responsen er kontraktsmessig garantert snarere enn avhengig av at en operatør handler i tide. Påmelding og programvalg håndteres av aggregatorer som Drax, E.ON, Enel X og GridBeyond, ikke av FrostLogic.

Sender FrostLogic automated demand response-signaler? Nei. FrostLogic Explore identifiserer hvilke laster som er trygge å automatisere, prognostiserer effekten av å koble dem ut med konfidensgrenser, og evidensbaserer den beslutningen. Det sender ikke OpenADR-signaler, kjører ikke en VEN-klient, handler ikke fleksibilitet, byr ikke inn på nettmarkeder og avregner ikke DSR-betalinger. Det utførelseslaget ligger i BMS-ets VEN-klient eller hos en aggregator.

Hvilke laster er trygge å automatisere uten et menneske i loopen? Laster med slark som holder over et spenn av betingelser, ikke bare den ene dagen de ble testet, for eksempel ikke-kritiske prosesslaster med reell tidsplanslark, kjøl/frys-avriming innenfor sin temperaturmargin, eller kjølemaskinsekvensering med bekreftet slark på lag-maskinen. Laster der sikkerheten avhenger av en betingelse som endrer seg dag for dag, beleggsstyrt ventilasjon eller en kjølemaskin som allerede går varm, krever et menneske som kontrollerer før automatisering, ikke bare før påmelding.

Hva er forskjellen mellom manuell DSR og automatisert ADR? Manuell DSR gir et menneske et vindu til å gjennomgå en hendelsesmelding og avgjøre om det skal responderes, slik at en dårlig avgjørelse fanges opp før eller under hendelsen. Automatisert ADR fjerner den kontrollen: et VTN-signal utfører en forhåndsprogrammert respons i det øyeblikket det ankommer, hver gang, uten at noen nedlegger veto mot en utkobling som viser seg å være utrygg den spesifikke dagen.

Kan en automatisert utkobling forårsake et komfort- eller sikkerhetsproblem hvis en last ikke faktisk er klar? Ja, og feilmoduset er verre enn det manuelle motstykket fordi det ikke fanges opp i øyeblikket. En forkjøling drevet forbi bygningens termiske buffer, eller en kjølemaskinutkobling sekvensert uten reell slark, gir den samme komfortklagen eller prosessforstyrrelsen en manuell feil ville gitt, bortsett fra at den gjentas automatisk på hver fremtidige hendelse til noen merker og fikser automasjonslogikken.

Trenger jeg et BMS med en OpenADR VEN-klient allerede installert for å bruke FrostLogic Explore? Nei. Explores prognose- og bevisarbeid kjøres på en bygnings eksisterende målere og BMS- eller sensordata uavhengig av om OpenADR allerede er utrullet. VEN-klientspørsmålet betyr først noe når du er klar til å handle på Explores funn ved å koble en aggregator eller BMS-side automasjon til for å utføre utkoblingen.