Efterfrågeflexibilitet: vilka laster kan din byggnad faktiskt flexa?

Foto av American Public Power Association på Unsplash.

Sök på "efterfrågeflexibilitet" idag och hela första sidan försöker få dig att skriva på. Drax, E.ON, Enel X, GridBeyond, NESO, gov.uk och Association for Decentralised Energy svarar alla på samma fråga: hur får en byggnad betalt för att minska nätefterfrågan på begäran. Det är en legitim fråga, och varje av dessa källor svarar bra på den. Det är också inte frågan de flesta fastighetsoperatörer faktiskt fastnar på.

Frågan ingen av dem besvarar kommer tidigare och är svårare: vilka av mina laster kan jag faktiskt minska eller flytta, utan att bryta komfort, process, eller en efterlevnadsskyldighet jag inte får omförhandla? En aggregator kan berätta vad ett flexibilitetsavtal betalar. Den kan inte berätta, från din egen byggnads data, om kylmaskinen du skulle nominera för en topphändelse faktiskt kommer att kunna stängas av utan ett komfortklagomål en timme senare, eller om en last som ser flexibel ut på ett specifikationsblad är bärande på sätt specifikationsbladet aldrig visar.

Det är gapet den här texten sitter i. Inte ännu en genomgång av vad DSR är, NESO och gov.uk äger redan den marken, och det finns ingen anledning att förklara om det de redan publicerat väl, men den operativa frågan som måste besvaras innan något aggregatorförhållande överhuvudtaget är meningsfullt.

Vad efterfrågeflexibilitet faktiskt kräver av en byggnad

På mekanismnivå är DSR ett åtagande: minska eller flytta förbrukning med en definierad mängd, inom ett definierat fönster, när det efterfrågas, i utbyte mot betalning eller en undviken avgift. Skyldigheterna knutna till det åtagandet, mätnoggrannhet, verifiering av svarstid, straffexponering för en missad eller partiell händelse, är dokumenterade i detalj av NESOs material om flexibilitetsmarknader och av aggregatorerna som säljer deltagande. Om vad du behöver är mekaniken för anmälan, avräkningsfönster eller vilket program som betalar vad detta kvartal, är det deras material att läsa direkt, inte vårt att omformulera.

Vad det materialet antar, rimligen, är att du redan vet vilka laster du erbjuder. Det antagandet är där den mesta faktiska svårigheten bor.

Lasterna som genuint är flexibla, och de som bara ser ut så

En generator eller ett batteri är obestridligt flexibelt. Den håller antingen lagrad kapacitet att släppa eller inte, och det talet är känt i förväg. Nästan inget annat i en kommersiell byggnad är så rent.

HVAC-förkylning och börvärdesflex är exemplet varje DSR-introduktion tar till, och det är ofta ett äkta ett, men bara inom ett band byggnadens egen termiska massa sätter. Förkyl ett plan två grader under börvärdet inför en eftermiddagshändelse och du lånar termisk tröghet byggnaden kommer behöva ge tillbaka under den följande timmen. Tryck förkylningen längre än den bufferten stödjer och du har inte flexat en last. Du har skapat ett komfortklagomål med en fördröjning inbyggd.

Kylmaskinssekvensering är en andra äkta kandidat. En primär-sekundär-anläggning med genuint utrymme på den sekundära maskinen kan ofta absorbera en avstängning på den primära enheten utan att lokalen märker det, förutsatt att stegningens dödband och den nedströms termiska bufferten båda är dimensionerade för att täcka det. Det är ett byggnadsspecifikt svar, inte ett kategoriomfattande: samma anläggningskonfiguration i en annan byggnad, på ett snävare dödband eller en mindre buffertank, kan ha inget utrymme alls.

Icke-kritiska processlaster är de mest konsekvent förbisedda kandidaterna, och ofta de bästa. En satskompressor med slack i sitt schema, en pump som körs på en frekvensomriktare långt under nominell drift, en kylmontervarm vars avfrostningscykel kan flyttas med minuter utan risk. Inget av detta dyker upp på en typisk DSR-shortlist, eftersom listan vanligtvis börjar och slutar vid HVAC.

På andra sidan linjen: livssäkerhetssystem, ventilationsflöden knutna till beläggning eller inomhusluftskvalitetsefterlevnad, och kylning som körs nära en livsmedelssäkerhetströskel är inte kandidater. Det är heller inte processutrustning där ett avbrott kostar mer än vad någon realistisk flexibilitetsbetalning skulle kunna kompensera. Misstaget värt att nämna direkt är att behandla "stor last" och "flexibel last" som samma sak. En stor kylmaskinsanläggning är en stor siffra på ett specifikationsblad. Om den faktiskt kan kopplas bort från nätet i fyrtio minuter utan konsekvens är en fråga om den specifika byggnadens termiska buffer, den dagens beläggning och den timmens utomhusförhållanden, inte om maskinens märkskyltseffekt.

Hur du faktiskt skulle veta, från din egen byggnads data

Det är här en genomgångsinspektion tar slut på svar. Ett fastighetsteam kan lista kandidatlaster med ögat. Vad inspektion på ögonnivå inte kan göra är att berätta för dig, för ett specifikt händelsefönster på en specifik dag, om att minska en given last kommer att hålla eller misslyckas, och med vilken marginal.

Avvikelsedetektering är den första insatsen värd att ha: att veta hur en lasts normala driftmönster ser ut väl nog för att märka när den redan körs utanför det mönstret. En kylmaskin som redan kör varm, eller en kompressor som redan korttidscyklar, är en sämre kandidat för en avstängning idag än vad dess historiska profil antyder, och en shortlist byggd enbart på historik kommer inte fånga det.

Lastprognostisering med konfidensgränser är den andra insatsen. Inte "denna last drar typiskt X kW vid 15:00" utan en prognos med en felmarginal ärlig om hur mycket den uppskattningen faktiskt kan lita på, för denna byggnad, denna dag, under detta väder. Ett flexibilitetsåtagande gjort mot en ren punktuppskattning, utan angiven osäkerhet, är ett åtagande gjort blint.

Vad-om-simulering är den tredje insatsen, och den som faktiskt besvarar operatörens fråga. FrostDynamics, den fysikgrundade modellen bakom Explores prognoser, finns för att svara på exakt detta: om denna last minskas för detta fönster, vad händer med komforten, med nästa last i sekvensen, med byggnadens förmåga att återhämta sig innan nästa brukningstimme. Det är en simulering körd mot byggnadens egna uppmätta termiska och elektriska beteende, inte en tumregel överförd från en annan byggnads specifikationsblad. Det prognosarbetet körs på samma programvara för energihantering Explore redan tillhandahåller för en byggnads vardagliga kostnads- och förbrukningsbild; DSR-beredskap är en fråga till den besvarar, inte en separat modul monterad på för tillfället. Det är vad som förvandlar "det här ser flexibelt ut" till "det här är flexibelt, med så mycket, under dessa förhållanden" innan någon åtar sig en händelse.

Var FrostLogics jobb slutar och aggregatorns börjar

Inget av det är en marknad, och Explore låtsas inte annat. FrostLogic Explore handlar inte med flexibilitet, budar inte in en last i ett nätprogram, och avräknar inte en DSR-betalning. Det är ett beslutslager som sitter uppströms om den marknaden, inte en deltagare i den. Arbetet med anmälan, med att buda in i vilket program som passar en byggnads profil, med att verifiera och avräkna en händelse, sitter hos bolagen byggda för exakt detta: Drax, E.ON, Enel X och GridBeyond bland dem, som var och en kör aggregerings- och marknadssidan av DSR i en skala FrostLogic inte har någon anledning att försöka duplicera.

Överlämningen är medvetet smal. Explores jobb slutar vid att producera en evidensbaserad, rangordnad lista över vilka laster i en given byggnad som faktiskt är flexibla, under vilka förhållanden, med vilken konfidens, och vad det kostar operativt att minska varje. Vad en aggregator gör med den listan, vilket program man ska anmäla den till, hur man strukturerar ett bud, hur avräkning hanteras, är deras domän, och bättre hanterat av ett bolag byggt för exakt det än av en sensoranalysplattform som improviserar en handelsavdelning den inte har någon anledning att driva.

Den uppdelningen har en efterlevnadskant värd att nämna direkt. Att delta i ett DSR-program kan korsa rapporteringsskyldigheter en byggnad redan bär, särskilt där en minskningshändelse rör mätad förbrukning som också matar en hållbarhets- eller energiprestandaupplysning. Där den överlappningen behöver sin egen hantering hör den hemma tillsammans med resten av en byggnads efterlevnadsarbete, inte behandlad som en DSR-specifik eftertanke som ingen äger.

Lastflexibilitet, per typ: vad som ser sant ut och vad som håller

Vanliga frågor

Vad är efterfrågeflexibilitet? Efterfrågeflexibilitet är ett åtagande att minska eller flytta elförbrukning på begäran, i utbyte mot betalning eller en undviken avgift, vanligtvis samordnat genom en aggregator eller direkt med en nätoperatör. NESO och gov.uk publicerar mekaniken för brittiska flexibilitetsmarknader i detalj; denna sida fokuserar på den operativa frågan under det åtagandet, vilka laster en byggnad faktiskt kan erbjuda.

Är FrostLogic en DSR-aggregator? Nej. FrostLogic Explore handlar inte med flexibilitet, budar inte laster in i nätmarknader, och avräknar inte DSR-betalningar. Den identifierar och evidensbelägger vilka laster i en byggnad som faktiskt är flexibla och prognostiserar effekten av att minska dem. Anmälan, budgivning och avräkning hanteras av aggregatorer som Drax, E.ON, Enel X och GridBeyond.

Hur vet jag vilka laster jag faktiskt kan flexa? Börja från byggnadens egen data snarare än en generisk kandidatlista. Avvikelsedetektering visar om en last redan körs utanför sitt normala mönster, lastprognostisering med konfidensgränser uppskattar vad en minskning faktiskt skulle spara, och vad-om-simulering mot byggnadens fysik visar vad som händer med komforten eller nästa last i sekvensen om du minskar den. En last som ser flexibel ut på ett specifikationsblad är inte bekräftat flexibel förrän den testats mot byggnadens eget beteende.

Kan HVAC-förkylning bryta komforten om jag gör fel? Ja. Förkylning lånar termisk tröghet byggnaden måste ge tillbaka, och det säkra bandet beror på den byggnadens termiska massa, beläggning och utomhusförhållandena den dagen. Tryck en förkylning eller börvärdesflex längre än byggnadens buffer stödjer och resultatet är ett komfortklagomål, vanligtvis med en fördröjning på en timme eller mer mellan minskningen och symptomet.

Vilka laster bör aldrig erbjudas till ett DSR-program? Livssäkerhetssystem, ventilationsflöden knutna till beläggning eller inomhusluftskvalitetsefterlevnad, kylning som körs nära en livsmedelssäkerhetströskel, och processutrustning där avbrottskostnaden överstiger varje realistisk flexibilitetsbetalning. Dessa är inte bedömningsbeslut; det regulatoriska eller säkerhetsmässiga golvet avgör dem innan ekonomin gör det.

Påverkar deltagande i DSR min efterlevnadsrapportering? Det kan, där en minskningshändelse rör mätad förbrukning som också matar hållbarhets- eller energiprestandaupplysningar. Den överlappningen är värd att kontrollera mot en byggnads befintliga efterlevnadsskyldigheter snarare än att behandla DSR-deltagande som ett rent kommersiellt beslut.

Ersätter FrostLogic mitt aggregatorförhållande? Nej. Explore producerar beviset, vilka laster som är flexibla, under vilka förhållanden, med vilken konfidens, som gör ett aggregatorförhållande mer försvarbart. Aggregatorn hanterar fortfarande anmälan, marknadsbudgivning och avräkning; Explore konkurrerar inte med den rollen eller försöker replikera den.

Vilken data behöver jag för att börja identifiera flexibla laster? Vanligtvis vad ett BMS, energimätare och befintliga byggnadssensorer redan samlar in: HVAC-börvärden och zontemperaturer, kylmaskins- och luftbehandlingslast och sekvenseringsdata, samt driftcykeldata för större processutrustning. Gapet är sällan instrumentering. Det är vanligtvis att ingen har kört en prognos eller en vad-om-simulering mot den datan innan man åtagit en last till en DSR-händelse.