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

Foto av American Public Power Association på Unsplash.

Søk på "demand side response" i dag, og hele første side prøver å registrere deg. Drax, E.ON, Enel X, GridBeyond, NESO, gov.uk, det britiske parlamentet og Association for Decentralised Energy svarer alle på det samme spørsmålet: hvordan får en bygning betalt for å redusere nettforbruket på forespørsel. Det er et legitimt spørsmål, og hver kilde svarer godt. Det er heller ikke spørsmålet de fleste bygningsoperatører faktisk sitter fast i.

Spørsmålet ingen av dem svarer på kommer tidligere og er vanskeligere: hvilke av lastene mine kan jeg faktisk redusere eller flytte, uten å bryte komfort, prosess eller en compliance-forpliktelse jeg ikke får omforhandle? En aggregator kan fortelle deg hva en fleksibilitetskontrakt betaler. Den kan ikke, ut fra bygningens egne data, si om kjølemaskinen du ville nominere til en toppehendelse faktisk kan slås av uten en komfortklage en time senere, eller om en last som ser fleksibel ut på et datablad i praksis bærer last på måter databladet aldri viser.

Det er gapet denne artikkelen fyller. Ikke enda en gjennomgang av hva DSR er, NESO og gov.uk eier allerede det området, og det er ingen grunn til å gjenforklare det de allerede har publisert godt, men det operative spørsmålet som må besvares før et aggregatorforhold i det hele tatt gir mening.

Hva demand side response faktisk krever av en bygning

På mekanismenivå er DSR en forpliktelse: redusere eller flytte forbruk med et definert beløp, innen et definert vindu, når du blir bedt om det, i bytte mot betaling eller unngått avgift. Forpliktelsene knyttet til den forpliktelsen, målenøyaktighet, verifisering av responstid, sanksjonsrisiko ved en missede eller delvise hendelse, dokumenteres i detalj i NESO sitt materiale om fleksibilitetsmarkeder og hos aggregatorne som selger deltakelse. Hvis du trenger mekanikken rundt påmelding, avregningsvinduer eller hvilket program som betaler hva dette kvartalet, er det deres materiale å lese direkte, ikke vårt å parafrasere.

Det materialet antar, rimelig nok, at du allerede vet hvilke laster du tilbyr. Det antagelsen er der det meste av den faktiske vanskeligheten ligger.

Laster som er genuint fleksible, og de som bare ser slik ut

En generator eller et batteri er entydig fleksibelt. Den har enten lagret kapasitet å frigjøre eller ikke, og det tallet er kjent på forhånd. Nesten ingenting annet i et næringsbygg er så rent.

HVAC-forkjøling og setpoint-flex er eksemplet enhver DSR-introduksjon tar opp, og det er ofte et reelt, men bare innenfor et bånd bygningens egen termiske masse setter. Forkjøl en etasje to grader under setpoint før en ettermiddagshendelse, og du låner termisk treghet bygningen må gi tilbake i timen som følger. Press forkjølingen lenger enn bufferen tåler, og du har ikke fleksert en last. Du har skapt en komfortklage med en innebygd forsinkelse.

Kjøleanleggssekvensering er en annen reell kandidat. Et lead-lag-anlegg med faktisk kapasitet på lagmaskinen kan ofte absorbere en reduksjon på lead-enheten uten at rommet merker det, forutsatt at staging-dødbåndet og den nedstrøms termiske bufferen begge er dimensjonert for det. Det er et bygningsspesifikt svar, ikke et kategoribredt: den samme anleggskonfigurasjonen i en annen bygning, med et smalere dødbånd eller en mindre buffertank, kan mangle kapasitet helt.

Ikke-kritiske prosesslaster er de mest konsekvent oversette kandidatene, og ofte de beste. En batchkompressor med slack i timeplanen, en pumpe som kjører på en frekvensomformer langt under nominell belastning, et kjøleskap hvis avrimingssyklus kan flyttes noen minutter uten risiko. Ingen av disse dukker opp på en typisk DSR-kortliste, fordi kortlisten vanligvis starter og stopper ved HVAC.

På den andre siden av linjen: livssikkerhetssystemer, ventilasjonshastigheter knyttet til tilstedeværelse eller innendørs luftkvalitet, og kjøling som kjører nær en mattrygghetsterskel, er ikke kandidater. Heller ikke prosessutstyr der et avbrudd koster mer enn enhver realistisk fleksibilitetsbetaling kan oppveie. Feilen verdt å navngi direkte er å behandle "stor last" og "fleksibel last" som det samme. Et stort kjøleanlegg er et stort tall på et datablad. Om det faktisk kan kobles fra nettet i førti minutter uten konsekvens, er et spørsmål om den spesifikke bygningens termiske buffer, den dagens tilstedeværelse og den timens utendørsforhold, ikke om maskinens merkeeffekt.

Hvordan du faktisk ville vite det, ut fra bygningens egne data

Det er her en gjennomgangsinspeksjon går tom for svar. Et facility-team kan liste kandidatlaster med blotte øyet. Det øyeinspeksjon ikke kan gjøre, er å si, for et spesifikt hendelsesvindu på en spesifikk dag, om reduksjon av en gitt last vil holde eller feile, og med hvilken margin.

Avviksdeteksjon er det første inputet verdt å ha: å vite hvordan en lasts normale driftsmønster ser ut, godt nok til å merke når den allerede kjører utenfor det mønsteret. En kjølemaskin som allerede kjører varm, eller en kompressor som allerede short-cycler, er en dårligere kandidat til reduksjon i dag enn dens historiske profil antyder, og en kortliste bygget alene på historikk fanger det ikke.

Lastprognoser med konfidensintervaller er det andre inputet. Ikke "denne lasten trekker typisk X kW kl. 15", men en prognose med et feilbånd ærlig om hvor mye det estimatet faktisk kan stoles på, for denne bygningen, denne dagen, under dette været. En fleksibilitetsforpliktelse gjort mot et rent punktestimat, uten angitt usikkerhet, er en forpliktelse gjort i blinde.

What-if-simulering er det tredje inputet, og det som faktisk svarer på operatørens spørsmål. FrostDynamics™, den fysikkbaserte modellen under Explore sine prognoser, finnes for å svare nøyaktig på dette: hvis denne lasten reduseres i dette vinduet, hva skjer med komfort, med neste last i sekvensen, med bygningens evne til å komme seg før neste befolkede time. Det er en simulering kjørt mot bygningens egne målte termiske og elektriske atferd, ikke en tommelfingerregel overført fra en annen bygnings datablad. Prognosearbeidet kjører på den samme programvaren for energistyring som Explore allerede leverer for bygningens daglige kostnads- og forbrukssbilde; DSR-beredskap er enda et spørsmål den svarer på, ikke et separat modul boltet på for anledningen. Det er det som forvandler "dette ser fleksibelt ut" til "dette er fleksibelt, med så mye, under disse forholdene", før noen forplikter seg til en hendelse.

Hvor FrostLogic sitt jobb slutter, og aggregatorens begynner

Ingenting av dette er et marked, og Explore later som noe annet. FrostLogic Explore handler ikke fleksibilitet, byr ikke en last inn i et nettprogram og avregner ikke DSR-betaling. Det er et beslutningslag som sitter oppstrøms det markedet, ikke en deltaker i det. Påmelding, budgivning i hvilket program som passer til en bygnings profil, verifisering og avregning av en hendelse ligger hos selskapene bygget for nettopp det: Drax, E.ON, Enel X og GridBeyond blant dem, som driver aggregasjons- og markedssiden av DSR i en skala FrostLogic ikke har grunn til å duplisere.

Overleveringen er bevisst smal. Explore sitt jobb stopper ved å produsere en evidensbasert, rangert liste over hvilke laster i en gitt bygning som faktisk er fleksible, under hvilke forhold, med hvilken konfidens, og hva reduksjon av hver koster operativt. Hva en aggregator gjør med den listen, hvilket program å melde den inn i, hvordan man strukturerer et bud, hvordan avregning håndteres, er deres domene, og bedre håndtert av et selskap bygget for nettopp det enn av en sensoranalyseplattform som improviserer et handelskontor den ikke har forretning med å drive.

Den inndelingen har en compliance-kant verdt å navngi direkte. Deltakelse i et DSR-program kan skjære rapporteringsforpliktelser en bygning allerede bærer, særlig der en reduksjonshendelse berører målt forbruk som også mater en bærekraft- eller energiprestasjonsoppgave. Der overlappet trenger egen håndtering, hører det hjemme sammen med resten av bygningens compliance-arbeid, ikke behandles som en DSR-spesifikk ettanke ingen eier.

Lastfleksibilitet etter type: hva ser sant ut, og hva holder

Ofte stilte spørsmål

Hva er demand side response? Demand side response er en forpliktelse til å redusere eller flytte strømforbruk på forespørsel, i bytte mot betaling eller unngått avgift, vanligvis koordinert via en aggregator eller direkte med en nettoperatør. NESO og gov.uk publiserer mekanikken for britiske fleksibilitetsmarkeder i detalj; denne siden fokuserer på det operative spørsmålet under den forpliktelsen, hvilke laster en bygning faktisk kan tilby.

Er FrostLogic en DSR-aggregator? Nei. FrostLogic Explore handler ikke fleksibilitet, byr ikke laster inn i nettmarkeder og avregner ikke DSR-betalinger. Den identifiserer og evidensierer hvilke laster i en bygning som faktisk er fleksible, og prognostiserer effekten av å redusere dem. Påmelding, budgivning og avregning håndteres av aggregatorer som Drax, E.ON, Enel X og GridBeyond.

Hvordan vet jeg hvilke laster jeg faktisk kan fleksere? Start fra bygningens egne data snarere enn en generisk kandidatliste. Avviksdeteksjon viser om en last allerede kjører utenfor sitt normale mønster, lastprognoser med konfidensintervaller estimerer hva en reduksjon faktisk ville spare, og what-if-simulering mot bygningens fysikk viser hva som skjer med komfort eller neste last i sekvensen hvis du reduserer den. En last som ser fleksibel ut på et datablad er ikke bekreftet fleksibel før den er testet mot bygningens egen atferd.

Kan HVAC-forkjøling bryte komfort hvis jeg gjør det feil? Ja. Forkjøling låner termisk treghet bygningen må gi tilbake, og det sikre båndet avhenger av bygningens termiske masse, tilstedeværelse og utendørsforholdene den dagen. Press en forkjøling eller setpoint-flex lenger enn bygningens buffer tåler, og resultatet er en komfortklage, vanligvis med en forsinkelse på en time eller mer mellom reduksjonen og symptomet.

Hvilke laster bør aldri tilbys til et DSR-program? Livssikkerhetssystemer, ventilasjonshastigheter knyttet til tilstedeværelse eller innendørs luftkvalitet, kjøling som kjører nær en mattrygghetsterskel, og prosessutstyr der avbruddsomkostningen overstiger realistisk fleksibilitetsbetaling. Dette er ikke skjønnsmessige valg; den regulatoriske eller sikkerhetsmessige gulvgrensen avgjør dem før økonomien gjør det.

Påvirker deltakelse i DSR min compliance-rapportering? Det kan, der en reduksjonshendelse berører målt forbruk som også mater bærekraft- eller energiprestasjonsoppgaver. Det overlappet er verdt å sjekke mot bygningens eksisterende compliance-forpliktelser snarere enn å behandle DSR-deltakelse som en rent kommersiell beslutning.

Erstatter FrostLogic mitt aggregatorforhold? Nei. Explore produserer evidensen, hvilke laster som er fleksible, under hvilke forhold, med hvilken konfidens, som gjør et aggregatorforhold mer forsvarlig. Aggregatoren håndterer fortsatt påmelding, markedsbudgivning og avregning; Explore konkurrerer ikke med den rollen eller forsøker å replikere den.

Hvilke data trenger jeg for å begynne å identifisere fleksible laster? Vanligvis det et BMS, energimålere og eksisterende bygningssensorer allerede samler inn: HVAC-setpoints og zonatemperaturer, kjøle- og AHU-last og sekvenseringsdata, og duty-cycle-data for større prosessutstyr. Gapet er sjelden instrumentation. Det er vanligvis at ingen har kjørt en prognose eller what-if-simulering mot de dataene før man forplikter en last til en DSR-hendelse.