Demand side response: hvilke laster kan din bygning faktisk fleksere?

Foto af American Public Power Association på Unsplash.

Søg på "demand side response" i dag, og hele første side forsøger at tilmelde dig. Drax, E.ON, Enel X, GridBeyond, NESO, gov.uk, det britiske parlament og Association for Decentralised Energy besvarer alle det samme spørgsmål: hvordan får en bygning betaling for at reducere netefterspørgslen på anmodning. Det er et legitimt spørgsmål, og hver kilde besvarer det godt. Det er heller ikke det spørgsmål, de fleste bygningsoperatører faktisk sidder fast i.

Spørgsmålet, ingen af dem besvarer, kommer tidligere og er sværere: hvilke af mine laster kan jeg faktisk reducere eller flytte, uden at bryde komfort, proces eller en compliance-forpligtelse, jeg ikke får lov at genforhandle? En aggregator kan fortælle dig, hvad en fleksibilitetskontrakt betaler. Den kan ikke, ud fra din egen bygnings data, sige om den kølemaskine, du ville nominere til en peak-begivenhed, faktisk kan slukkes uden en komfortklage en time senere, eller om en last, der ser fleksibel ud på et datablad, i praksis bærer last på måder, databladet aldrig viser.

Det er det hul, dette stykke sidder i. Ikke endnu en gennemgang af, hvad DSR er, NESO og gov.uk ejer allerede det område, og der er ingen grund til at genforklare, hvad de allerede har publiceret godt, men det operative spørgsmål, der skal besvares, før et aggregatorforhold overhovedet giver mening.

Hvad demand side response faktisk kræver af en bygning

På mekanismeniveau er DSR en forpligtelse: reducere eller flytte forbrug med et defineret beløb, inden for et defineret vindue, når du bliver kaldt, i bytte mod betaling eller undgået afgift. Forpligtelserne knyttet til den forpligtelse, målenøjagtighed, verifikation af responstid, sanktionsrisiko ved en missede eller delvise begivenhed, dokumenteres i detaljer i NESO's materiale om fleksibilitetsmarkeder og hos aggregatorerne, der sælger deltagelse. Hvis du har brug for mekanikken omkring tilmelding, afregningsvinduer eller hvilket program der betaler hvad dette kvartal, er det deres materiale at læse direkte, ikke vores at parafrasere.

Det materiale antager, rimeligt nok, at du allerede ved, hvilke laster du tilbyder. Det antagelse er, hvor det meste af den faktiske vanskelighed ligger.

Laster, der er ægte fleksible, og dem der bare ser sådan ud

En generator eller et batteri er entydigt fleksibelt. Den har enten lagret kapacitet at frigive, eller den har ikke, og det tal er kendt på forhånd. Næsten intet andet i en erhvervsbygning er så rent.

HVAC-forkøling og setpoint-flex er eksemplet, enhver DSR-introduktion når efter, og det er ofte et rigtigt, men kun inden for et bånd, bygningens egen termiske masse sætter. Forkøl en etage to grader under setpoint foran en eftermiddagsbegivenhed, og du låner termisk træghed, bygningen skal give tilbage i den følgende time. Skub forkølingen længere end den buffer understøtter, og du har ikke fleksere en last. Du har skabt en komfortklage med en indbygget forsinkelse.

Køleanlægssekvensering er en anden rigtig kandidat. Et lead-lag-anlæg med reel kapacitet på lagmaskinen kan ofte absorbere en reduktion på lead-enheden uden at rummet mærker det, forudsat at staging-dødbåndet og den nedstrøms termiske buffer begge er dimensioneret til det. Det er et bygningsspecifikt svar, ikke et kategoribredt: den samme anlægskonfiguration i en anden bygning, med et snævrere dødbånd eller en mindre buffertank, kan mangle kapacitet helt.

Ikke-kritiske proceslaster er de mest konsekvent oversete kandidater, og ofte de bedste. En batchkompressor med slack i skemaet, en pumpe, der kører på en frekvensomformer langt under nominel belastning, et køleskab, hvis afrimningscyklus kan flyttes få minutter uden risiko. Ingen af disse dukker op på en typisk DSR-kortliste, fordi kortlisten normalt starter og stopper ved HVAC.

På den anden side af linjen: livssikkerhedssystemer, ventilationshastigheder knyttet til tilstedeværelse eller indendørs luftkvalitet, og køling, der kører tæt på en fødevaresikkerhedstærskel, er ikke kandidater. Heller ikke procesudstyr, hvor et afbrydelse koster mere end enhver realistisk fleksibilitetsbetaling kan opveje. Fejlen værd at navngive direkte er at behandle "stor last" og "fleksibel last" som det samme. Et stort køleanlæg er et stort tal på et datablad. Om det faktisk kan kobles fra nettet i fyrre minutter uden konsekvens, er et spørgsmål om den specifikke bygnings termiske buffer, den dags tilstedeværelse og den times udendørsforhold, ikke om maskinens mærkeeffekt.

Hvordan du faktisk ville vide det, ud fra din egen bygnings data

Det er her en gennemgangsinspektion løber tør for svar. Et facility-team kan liste kandidatlaster med det blotte øje. Det øjeninspektion ikke kan gøre, er at sige, for et specifikt begivenhedsvindue på en specifik dag, om reduktion af en given last vil holde eller fejle, og med hvilken margin.

Afvigelsesdetektion er det første input værd at have: at vide, hvordan en lasts normale driftsmønster ser ud, godt nok til at bemærke, når den allerede kører uden for det mønster. En kølemaskine, der allerede kører varm, eller en kompressor, der allerede short-cycler, er en dårligere kandidat til reduktion i dag end dens historiske profil antyder, og en kortliste bygget alene på historik fanger det ikke.

Lastprognoser med konfidensintervaller er det andet input. Ikke "denne last trækker typisk X kW kl. 15", men en prognose med et fejlbånd ærligt om, hvor meget det estimat faktisk kan stoles på, for denne bygning, denne dag, under dette vejr. En fleksibilitetsforpligtelse lavet mod et rent punktestimat, uden angivet usikkerhed, er en forpligtelse lavet i blinde.

What-if-simulering er det tredje input, og det, der faktisk besvarer operatørens spørgsmål. FrostDynamics™, den fysikbaserede model under Explore's prognoser, findes for at besvare præcis dette: hvis denne last reduceres i dette vindue, hvad sker der med komfort, med næste last i sekvensen, med bygningens evne til at komme sig inden næste befolkede time. Det er en simulering kørt mod bygningens egne målte termiske og elektriske adfærd, ikke en tommelfingerregel overført fra en anden bygnings datablad. Prognosearbejdet kører på den samme energistyringssoftware, som Explore allerede leverer til bygningens daglige omkostnings- og forbrugsbillede; DSR-beredskab er endnu et spørgsmål, den besvarer, ikke et separat modul boltet på for lejligheden. Det er det, der forvandler "dette ser fleksibelt ud" til "dette er fleksibelt, med så meget, under disse forhold", før nogen forpligter sig til en begivenhed.

Hvor FrostLogics job slutter, og aggregatorens begynder

Intet af dette er en marked, og Explore lader som om andet. FrostLogic Explore handler ikke fleksibilitet, byder ikke en last ind i et netprogram og afregner ikke DSR-betaling. Det er et beslutningslag, der sidder opstrøms det marked, ikke en deltager i det. Tilmelding, budgivning i hvilket program der passer til en bygnings profil, verifikation og afregning af en begivenhed ligger hos virksomhederne bygget til netop det: Drax, E.ON, Enel X og GridBeyond blandt dem, der driver aggregations- og markedssiden af DSR i en skala, FrostLogic ikke har grund til at duplicere.

Overleveringen er bevidst smal. Explore's job stopper ved at producere en evidensbaseret, rangeret liste over, hvilke laster i en given bygning der faktisk er fleksible, under hvilke forhold, med hvilken konfidens, og hvad reduktion af hver koster operationelt. Hvad en aggregator gør med den liste, hvilket program at tilmelde den i, hvordan man strukturerer et bud, hvordan afregning håndteres, er deres domæne, og bedre håndteret af en virksomhed bygget til netop det end af en sensoranalyseplatform, der improviserer et handelskontor, den ikke har forretning med at drive.

Den opdeling har en compliance-kant værd at navngive direkte. Deltagelse i et DSR-program kan skære rapporteringsforpligtelser, en bygning allerede bærer, især hvor en reduktionsbegivenhed berører målt forbrug, der også føder en bæredygtigheds- eller energipræstationsoplysning. Hvor den overlap har brug for egen håndtering, hører den hjemme sammen med resten af bygningens compliance-arbejde, ikke behandles som en DSR-specifik eftertanke, ingen ejer.

Lastfleksibilitet efter type: hvad ser sandt ud, og hvad holder

Ofte stillede spørgsmål

Hvad er demand side response? Demand side response er en forpligtelse til at reducere eller flytte elforbrug på anmodning, i bytte mod betaling eller undgået afgift, normalt koordineret via en aggregator eller direkte med en netoperatør. NESO og gov.uk publicerer mekanikken for britiske fleksibilitetsmarkeder i detaljer; denne side fokuserer på det operative spørgsmål under den forpligtelse, hvilke laster en bygning faktisk kan tilbyde.

Er FrostLogic en DSR-aggregator? Nej. FrostLogic Explore handler ikke fleksibilitet, byder ikke laster ind i netmarkeder og afregner ikke DSR-betalinger. Den identificerer og evidensierer, hvilke laster i en bygning der faktisk er fleksible, og prognostiserer effekten af at reducere dem. Tilmelding, budgivning og afregning håndteres af aggregatorer som Drax, E.ON, Enel X og GridBeyond.

Hvordan ved jeg, hvilke laster jeg faktisk kan fleksere? Start fra bygningens egne data snarere end en generisk kandidatliste. Afvigelsesdetektion viser, om en last allerede kører uden for sit normale mønster, lastprognoser med konfidensintervaller estimerer, hvad en reduktion faktisk ville spare, og what-if-simulering mod bygningens fysik viser, hvad der sker med komfort eller næste last i sekvensen, hvis du reducerer den. En last, der ser fleksibel ud på et datablad, er ikke bekræftet fleksibel, før den er testet mod bygningens egen adfærd.

Kan HVAC-forkøling bryde komfort, hvis jeg gør det forkert? Ja. Forkøling låner termisk træghed, bygningen skal give tilbage, og det sikre bånd afhænger af bygningens termiske masse, tilstedeværelse og udendørsforholdene den dag. Skub en forkøling eller setpoint-flex længere end bygningens buffer understøtter, og resultatet er en komfortklage, normalt med en forsinkelse på en time eller mere mellem reduktionen og symptomet.

Hvilke laster bør aldrig tilbydes til et DSR-program? Livssikkerhedssystemer, ventilationshastigheder knyttet til tilstedeværelse eller indendørs luftkvalitet, køling, der kører tæt på en fødevaresikkerhedstærskel, og procesudstyr, hvor afbrydelsesomkostningen overstiger realistisk fleksibilitetsbetaling. Dette er ikke skønsmæssige valg; den regulatoriske eller sikkerhedsmæssige gulvgrænse afgør dem, før økonomien gør det.

Påvirker deltagelse i DSR min compliance-rapportering? Det kan, hvor en reduktionsbegivenhed berører målt forbrug, der også føder bæredygtigheds- eller energipræstationsoplysninger. Den overlap er værd at tjekke mod bygningens eksisterende compliance-forpligtelser snarere end at behandle DSR-deltagelse som en rent kommerciel beslutning.

Erstatter FrostLogic mit aggregatorforhold? Nej. Explore producerer evidensen, hvilke laster der er fleksible, under hvilke forhold, med hvilken konfidens, der gør et aggregatorforhold mere forsvarligt. Aggregatoren håndterer stadig tilmelding, markedsbudgivning og afregning; Explore konkurrerer ikke med den rolle eller forsøger at replikere den.

Hvilke data har jeg brug for for at begynde at identificere fleksible laster? Normalt det, et BMS, energimålere og eksisterende bygningssensorer allerede indsamler: HVAC-setpoints og zonatemperaturer, køle- og AHU-last og sekvenseringsdata, og duty-cycle-data for større procesudstyr. Hullet er sjældent instrumentation. Det er normalt, at ingen har kørt en prognose eller what-if-simulering mod de data, før man forpligter en last til en DSR-begivenhed.