Automatiserad efterfrågeflexibilitet: Vilka laster är säkra att flexa utan mänsklig övervakning

Foto av Dmitrijs Safrans på Unsplash.

Sök på "automated demand response" och sidan som kommer upp är skriven för elbolag, aggregatorer och standardiseringsorgan. GridPoint förklarar vad ADR är. OpenADR Alliance dokumenterar sitt eget protokoll. Wikipedia har historien. En kylmaskinsleverantör säljer ADR-redo styrning som en produktfunktion. Akademiska artiklar från Lawrence Berkeley och IEEE går igenom nätekonomin. Allt detta behandlar fastigheten som den bortre änden av en signalväg: det som tar emot en instruktion och, i teorin, agerar på den. Inget av det ställer frågan som avgör om instruktionen ska tillåtas agera på något utan att en person kontrollerar det först.

Vi täckte den manuella sidan av denna fråga i efterfrågeflexibilitet: vilka laster en fastighet kan flexa när en person avgör, händelse för händelse, om den ska svara. Automated demand response tar bort den personen. En OpenADR-signal anländer, en VEN-klient på BMS:et tar emot den, och en last kopplas bort, förkyls eller begränsas på egen hand, utan att någon i fastigheten bekräftar att det är säkert först. Det är poängen med automatisering: inga missade händelser, ingen manuell brådska, snabbare svarstider som kvalificerar för de bättre betalande snabbresponsprogrammen. Det är också varför det blir dyrare, inte billigare, att ha fel på den underliggande frågan (är just den här lasten faktiskt säker att koppla bort just nu).

Denna text tar vid där den andra slutade. Inte vad OpenADR är (det dokumenterar Alliance exakt). Inte hur man ansluter sig till ett automatiserat program (GridPoint och aggregatorerna täcker redan den marken). Vad som måste vara sant om en last innan det är säkert att låta en stående automatiserad instruktion röra den obevakat.

Vad är automated demand response?

Automated demand response (ADR) är efterfrågeflexibilitet där en signal från ett elbolag, en nätoperatör eller en aggregator utlöser att en fastighets utrustning kopplar bort, flyttar eller begränsar last automatiskt, utan att en person avgör i stunden. Signalen kommer vanligtvis över en standard som OpenADR. En Virtual End Node (VEN) på eller bredvid fastighetens BMS tar emot den och kör ett förprogrammerat svar: ändring av HVAC-börvärde, förskjutning av kyl/frys-avfrostning, begränsning av icke-kritisk process, eller vilka laster anläggningen har kopplat till den signalnivån.

Traditionell eller manuell demand response ber fortfarande en person att granska ett händelsemeddelande och välja om den ska svara. Schemalagd DSR är en nära kusin: fastigheten åtar sig att minska vid kända timmar, men en människa äger fortfarande beslutet samma dag. ADR tar bort den kontrollpunkten. Svarstiderna sjunker från minuter eller timmar till sekunder, vilket är varför många program betalar mer för automatiserat deltagande. Avvägningen ligger på fastighetssidan. En marginal last som en operatör skulle hoppa över idag körs ändå den dag ingen övervakar, eftersom ingen behöver göra det. Flexibilitet som bara håller "det mesta av tiden" är en rimlig manuell DSR-kandidat. Samma last är en risk som automatiserad om undantagen inte finns i själva automationslogiken.

Kort sagt: ADR är den automatiserade formen av demand response. Nätfrågan (hur man ansluter, vilket program, hur avräkning fungerar) hör hemma hos elbolag och aggregatorer. Fastighetsfrågan (vilka laster som faktiskt är säkra att låta signalen röra obevakat) är vad den här artikeln täcker.

Hur automated demand response-program betalar

Elbolag och aggregatorer driver ADR-program som betalar fastigheter för garanterad, snabb respons. Typiska strukturer kombinerar en kapacitets- eller tillgänglighetsbetalning (du är ansluten och redo) med en energi- eller prestationsbetalning när en händelse utlöses och du levererar den avtalade minskningen. Automatiserade nivåer betalar ofta bättre än manuella eftersom svaret är kontraktsmässigt automatiskt snarare än beroende av att en operatör agerar i tid.

Tariffer, behörighet och händelseregler varierar per marknad och program. Den här sidan hittar inte på programtariffer. Anslutning, mätning, avräkning och opt-out-fönster ligger hos aggregatorer som Drax, E.ON, Enel X och GridBeyond (och hos elbolaget eller nätoperatören bakom dem). FrostLogic ansluter inte fastigheter, bjuder inte in flexibilitet och avräknar inte betalningar. Där Explore passar in är tidigare: att evidensbasera vilka laster som kan gå med på den automatiserade listan utan att skapa komfort-, process- eller säkerhetsproblem som programmet aldrig ser.

OpenADR på arbetande nivå: vad en VTN, en VEN och en signal faktiskt gör

OpenADR (Open Automated Demand Response) är en kommunikationsstandard, underhållen av OpenADR Alliance, som definierar hur automatiserade DR-signaler struktureras och utbyts. Den avgör inte vilka laster som ska kopplas bort eller hur en fastighet ska svara; den standardiserar meddelandena så att ett elbolag, en nätoperatör eller en aggregator på ena sidan och en fastighets automationssystem på den andra kan prata utan en skräddarsydd integration för varje parning.

Modellen har två sidor. En VTN (Virtual Top Node) är signalsändaren, typiskt driven av ett elbolag, en nätoperatör eller en aggregator, och den utfärdar händelser: starttid, varaktighet, signalnivå eller pris, och vanligtvis ett opt-out-fönster innan svaret blir bindande. En VEN (Virtual End Node) är signalmottagaren, en klient som körs på eller bredvid en fastighets BMS eller energihanteringssystem, och den ansvarar för att översätta signalen till ett faktiskt lokalt svar, vilka laster dess programmering har tilldelat den signalnivån.

Det standarden lämnar helt till fastighetssidan är den svårare delen: att avgöra vilka laster den VEN faktiskt ska få röra, under vilka villkor, och med vilken tillförsikt att röra dem inte orsakar ett problem som signalen själv inte kan känna till. OpenADR flyttar instruktionen tillförlitligt. Den har ingen åsikt om huruvida instruktionen är säker att utföra i en specifik fastighet en specifik dag, och den är inte utformad för det. FrostLogic implementerar, driver eller certifierar inte en VEN-klient; det är BMS- och automationsleverantörernas territorium. Vad Explore gör är att svara på frågan som standarden lämnar öppen.

Vilka laster är faktiskt säkra att automatisera, och vilka behöver fortfarande en människa först

Lasttyperna som är värda att automatisera är i stort sett desamma som redan identifierats som flexibla i efterfrågeflexibilitet, men ribban för att automatisera en är högre än ribban för att erbjuda den manuellt en gång. En last är en bra automationskandidat när dess flexibilitet håller över ett spann av villkor, inte bara den enda dag den råkade testas.

HVAC-förkylning och börvärdesflex automatiseras rimligt väl, förutsatt att själva automationslogiken upprätthåller den termiska bufferten, inte ett fast schema som antar att samma buffer finns varje dag. En förkylning dimensionerad för en mild axelsäsongseftermiddag och lämnad obevakad in i en het, fullbelagd dag lånar mer termisk tröghet än fastigheten har att ge tillbaka, och ingen fångar det förrän klagomålen börjar.

Icke-kritiska processlaster, VFD-pumpar med slack, batchkompressorer, utrustning med verklig schemaflexibilitet, är ofta de bästa automationskandidaterna just för att en missad eller felaktig bortkoppling sällan orsakar något värre än en schemaförskjutning. Kyl/frys-avfrostningstiming automatiseras väl inom sitt vanliga minutskalafönster, så länge automationen kontrollerar aktuell disketemperatur mot livsmedelssäkerhetströskeln innan den förskjuter, snarare än att förskjuta på en fast timer oavsett var disken faktiskt är.

Kylmaskinsekvensering kräver mer försiktighet automatiserad än manuell. En lead-lag-anläggning med bekräftat utrymme på lag-maskinen är en fin manuell kandidat de dagar en operatör kontrollerar den. Att automatisera samma bortkoppling betyder att automationen måste veta, varje gång, om det utrymme som fanns under testet fortfarande finns idag, under dagens beläggning och utomhusförhållanden, inte anta det från en engångsutvärdering. Laster kopplade till beläggningsstyrd ventilation, livssäkerhetssystem, eller någon process där avbrottskostnaden överstiger flexibilitetsbetalningen stannar helt utanför automationslistan, av samma skäl de är utanför den manuella DSR-listan från början.

Manuell DSR kontra automatiserad, OpenADR-utlöst ADR

Där FrostLogics evidenslager slutar och automatiserad dispatch börjar

Inget av ovanstående gör FrostLogic Explore till en del av den automatiserade dispatch-kedjan, och det är inte byggt för det. Explore identifierar vilka laster i en fastighet som faktiskt är säkra att automatisera, prognostiserar effekten av att koppla bort dem med konfidensgränser, och evidensbaserar det beslutet så att det håller under villkor som det inledande testet inte täckte. Det arbetet körs på samma programvara för energihantering som Explore redan tillhandahåller för en fastighets dagliga kostnads- och förbrukningsbild; automationsberedskap är en fråga till som den svarar på, inte ett separat system som skruvats på specifikt för OpenADR.

Vad Explore inte gör är att skicka en OpenADR-signal, köra en VEN-klient, handla flexibilitet in i en marknad eller avräkna en DSR-betalning. Det utförandelagret ligger hos BMS:ets egen VEN-klient, och hos aggregatorerna som driver marknads- och dispatch-sidan i en skala som en sensoranalysplattform inte har skäl att försöka duplicera, bland dem Drax, E.ON, Enel X och GridBeyond, samma aggregatorer som hanterar manuell DSR-anslutning. Överlämningen är evidensen: vilka laster, under vilka villkor, med vilken tillförsikt. Vad en aggregator eller BMS-leverantör gör med den evidensen, kopplar in den i en VENs automationsregler, strukturerar vilka signalnivåer som utlöser vilka laster, är deras domän.

Samma compliance-överlapp som gäller manuell DSR gäller här också, och spelar troligen större roll: en automatiserad bortkoppling som rör mätt förbrukning som matar en hållbarhets- eller energiprestandaredovisning pausar inte för att någon ska märka överlappet innan den körs. Där den skärningspunkten behöver hanteras hör den till en fastighets befintliga compliance-arbete, inte behandlas som något OpenADR-deltagande introducerar på egen hand.

Om du kartlägger vilka laster i ditt bestånd som kan gå med i ett automatiserat program utan att skapa problemen ovan, prata igenom det.

Vanliga frågor

Vad är automated demand response? Automated demand response (ADR) är efterfrågeflexibilitet där en signal från elbolag, nätoperatör eller aggregator utlöser att en fastighets utrustning kopplar bort, flyttar eller begränsar last automatiskt, utan att en person avgör i stunden. Det skiljer sig från manuell eller schemalagd DSR, där en operatör granskar ett händelsemeddelande och väljer om den ska svara.

Vad är ett exempel på demand response? En kommersiell fastighet tar emot en topphändelsesignal och höjer automatiskt AHU-börvärden med en grad i två timmar, eller förskjuter en stormarknads kyl/frys-avfrostning med femton minuter, så att mätt effektbehov sjunker under händelsen utan att stänga kritisk anläggning. Det är ett exempel på last på fastighetssidan, inte en bostads-"elräkning".

Är demand response dyrt, och hur fungerar betalningen? Deltagande betalas vanligtvis, det debiteras inte: programmen kompenserar kapacitet och/eller levererad minskning. Automatiserade nivåer betalar ofta mer än manuella eftersom svaret är garanterat. Exakta tariffer beror på marknad och aggregatoravtal. FrostLogic sätter eller avräknar inte de betalningarna; aggregatorer och elbolag gör det. Den verkliga kostnadsrisken på fastighetssidan är att automatisera en last som aldrig var säker att koppla bort obevakat.

Vad är open automated demand response (OpenADR)? Open Automated Demand Response är en kommunikationsstandard, underhållen av OpenADR Alliance, som definierar hur automatiserade demand response-signaler struktureras och utbyts mellan en nätsidessändare (en VTN) och en fastighetssidmottagare (en VEN). "Open" syftar på att standarden är öppen och interoperabel mellan leverantörer, inte på FrostLogics roll i den; FrostLogic implementerar eller certifierar inte OpenADR-kommunikation.

Vad är automated demand response-program? Program drivna av elbolag eller aggregatorer som betalar en fastighet för automatiserat deltagande, typiskt till bättre tariffer eller snabbare responsnivåer än manuell DSR eftersom svaret är kontraktsmässigt garanterat snarare än beroende av att en operatör agerar i tid. Anslutning och programval hanteras av aggregatorer som Drax, E.ON, Enel X och GridBeyond, inte av FrostLogic.

Skickar FrostLogic automated demand response-signaler? Nej. FrostLogic Explore identifierar vilka laster som är säkra att automatisera, prognostiserar effekten av att koppla bort dem med konfidensgränser, och evidensbaserar det beslutet. Det skickar inte OpenADR-signaler, kör inte en VEN-klient, handlar inte flexibilitet, bjuder inte in på nätmarknader och avräknar inte DSR-betalningar. Det utförandelagret ligger i BMS:ets VEN-klient eller hos en aggregator.

Vilka laster är säkra att automatisera utan en människa i loopen? Laster med utrymme som håller över ett spann av villkor, inte bara den enda dag de testades, till exempel icke-kritiska processlaster med verklig schemaflexibilitet, kyl/frys-avfrostning inom sin temperaturmarginal, eller kylmaskinsekvensering med bekräftat utrymme på lag-maskinen. Laster där säkerheten beror på ett villkor som ändras dag för dag, beläggningsstyrd ventilation eller en kylmaskin som redan går varm, behöver en person som kontrollerar innan automatisering, inte bara innan anslutning.

Vad är skillnaden mellan manuell DSR och automatiserad ADR? Manuell DSR ger en person ett fönster att granska ett händelsemeddelande och avgöra om den ska svara, så att ett dåligt beslut fångas före eller under händelsen. Automatiserad ADR tar bort den kontrollen: en VTN-signal kör ett förprogrammerat svar i samma ögonblick den anländer, varje gång, utan att någon vetoar en bortkoppling som visar sig osäker just den dagen.

Kan en automatiserad bortkoppling orsaka ett komfort- eller säkerhetsproblem om en last inte faktiskt är redo? Ja, och felmoduset är värre än det manuella motsvarigheten eftersom det inte fångas i stunden. En förkylning driven förbi fastighetens termiska buffer, eller en kylmaskinsbortkoppling sekvenserad utan verkligt utrymme, ger samma komfortklagomål eller processstörning ett manuellt misstag skulle ge, förutom att det upprepas automatiskt vid varje framtida händelse tills någon märker och fixar automationslogiken.

Behöver jag ett BMS med en OpenADR VEN-klient redan installerad för att använda FrostLogic Explore? Nej. Explores prognos- och evidensarbete körs på en fastighets befintliga mätare och BMS- eller sensordata oberoende av om OpenADR redan är utrullat. VEN-klientfrågan spelar först roll när du är redo att agera på Explores fynd genom att koppla en aggregator eller BMS-sida automation för att utföra bortkopplingen.