Demand response automatizzata: quali carichi sono sicuri da flettere senza sorveglianza umana

Foto di Dmitrijs Safrans su Unsplash.

Cerca “automated demand response” e la pagina che torna è scritta per utility, aggregatori e organismi di standardizzazione. GridPoint spiega cos’è l’ADR. OpenADR Alliance documenta il proprio protocollo. Wikipedia ha la storia. Un produttore di refrigeratori vende controlli ADR-ready come funzione di prodotto. Articoli accademici di Lawrence Berkeley e IEEE lavorano l’economia di rete. Tutto tratta l’edificio come l’estremo lontano di un percorso di segnale: ciò che riceve un’istruzione e, in teoria, agisce su di essa. Niente di tutto questo pone la domanda che decide se quell’istruzione debba poter agire su qualcosa senza che una persona controlli prima.

Abbiamo coperto il lato manuale di questa domanda in demand side response: quali carichi un edificio può flettere quando una persona decide, evento per evento, se rispondere. Automated demand response rimuove quella persona. Arriva un segnale OpenADR, un client VEN sul BMS lo riceve, e un carico si stacca, si precool o si limita da solo, senza che nessuno nell’edificio confermi prima che sia sicuro. Quello è l’appeal dell’automazione: nessun evento perso, nessuna corsa manuale, tempi di risposta più rapidi che qualificano per programmi di risposta rapida meglio pagati. È anche perché sbagliare la domanda di fondo (questo carico specifico è davvero sicuro da staccare adesso?) diventa più costoso, non meno.

Questo pezzo riparte dove quello si è fermato. Non cos’è OpenADR (l’Alliance lo documenta con precisione). Non come iscriversi a un programma automatizzato (GridPoint e gli aggregatori coprono già quel terreno). Cosa deve essere vero di un carico prima che sia sicuro lasciare che un’istruzione automatizzata permanente lo tocchi senza supervisione.

Cos'è automated demand response?

Automated demand response (ADR) è demand response in cui un segnale da una utility, un gestore di rete o un aggregatore fa sì che l’equipaggiamento di un edificio stacchi, sposti o limiti carico automaticamente, senza che una persona decida nel momento. Il segnale arriva di solito su uno standard come OpenADR. Un Virtual End Node (VEN) sul o accanto al BMS dell’edificio lo riceve e esegue una risposta preprogrammata: cambio di setpoint HVAC, spostamento dello sbrinamento frigorifero, limitazione di processo non critico, o i carichi che il sito ha mappato a quel livello di segnale.

La demand response tradizionale o manuale chiede ancora a una persona di rivedere un avviso di evento e scegliere se rispondere. Il DSR programmato è un cugino stretto: l’edificio si impegna a ridurre a ore note, ma un umano resta proprietario della decisione del giorno. L’ADR rimuove quel checkpoint. I tempi di risposta scendono da minuti o ore a secondi, ed è per questo che molti programmi pagano di più per la partecipazione automatizzata. Il trade-off sta dal lato edificio. Un carico marginale che un operatore saltarebbe oggi si esegue comunque il giorno in cui nessuno sorveglia, perché nessuno deve esserci. La flessibilità che regge solo «la maggior parte del tempo» è una candidata ragionevole di DSR manuale. Lo stesso carico è un rischio come automatizzato a meno che le eccezioni vivano nella logica di automazione stessa.

In breve: l’ADR è la forma automatizzata di demand response. La domanda di rete (come iscriversi, quale programma, come funziona il settlement) appartiene a utility e aggregatori. La domanda di edificio (quali carichi sono davvero sicuri da lasciare toccare a quel segnale senza supervisione) è ciò che questo articolo copre.

Come pagano i programmi di automated demand response

Utility e aggregatori gestiscono programmi ADR che pagano gli edifici per risposta garantita e rapida. Le strutture tipiche combinano un pagamento di capacità o disponibilità (resti iscritto e pronto) con un pagamento di energia o performance quando scatta un evento e consegni la riduzione contrattuale. I livelli automatizzati spesso pagano meglio di quelli manuali perché la risposta è automatica per contratto, non dipende da un operatore che agisce in tempo.

Tariffe, eleggibilità e regole di evento variano per mercato e programma. Questa pagina non inventa tariffe di programma. Iscrizione, metering, settlement e finestre di opt-out stanno agli aggregatori come Drax, E.ON, Enel X e GridBeyond (e all’utility o gestore di rete dietro di loro). FrostLogic non iscrive edifici, non offre flessibilità e non regola pagamenti. Dove Explore entra è prima: evidenziando quali carichi possono entrare in quella lista automatizzata senza creare problemi di comfort, processo o sicurezza che il programma non vede mai.

OpenADR a livello operativo: cosa fanno davvero VTN, VEN e segnale

OpenADR (Open Automated Demand Response) è uno standard di comunicazione, mantenuto da OpenADR Alliance, che definisce come i segnali di DR automatizzata sono strutturati e scambiati. Non decide quali carichi staccare né come un edificio debba rispondere; standardizza i messaggi così che utility, gestore di rete o aggregatore da un lato e il sistema di automazione di un edificio dall’altro possano parlare senza un’integrazione custom per ogni accoppiamento.

Il modello ha due lati. Una VTN (Virtual Top Node) è il mittente del segnale, tipicamente gestita da utility, gestore di rete o aggregatore, e emette eventi: ora di inizio, durata, livello di segnale o prezzo, e di solito una finestra di opt-out prima che la risposta sia vincolante. Una VEN (Virtual End Node) è il ricevitore del segnale, un client che gira su o accanto al BMS o al sistema di energy management dell’edificio, ed è responsabile di tradurre quel segnale in una risposta locale reale, i carichi che la sua programmazione ha assegnato a quel livello di segnale.

Ciò che lo standard lascia interamente al lato edificio è la parte più dura: decidere quali carichi quella VEN possa davvero toccare, in quali condizioni, e con quale confidenza che toccarli non causi un problema che il segnale stesso non può conoscere. OpenADR muove l’istruzione in modo affidabile. Non ha opinione su se l’istruzione sia sicura da eseguire in un edificio specifico in un giorno specifico, e non è progettato per questo. FrostLogic non implementa, non gestisce e non certifica un client VEN; quello è territorio BMS e vendor di automazione. Ciò che Explore fa è rispondere alla domanda che lo standard lascia aperta.

Quali carichi sono davvero sicuri da automatizzare, e quali hanno ancora bisogno di un umano prima

I tipi di carico che vale la pena automatizzare sono in gran parte quelli già identificati come flessibili in demand side response, ma l’asticella per automatizzarne uno è più alta dell’asticella per offrirla manualmente una volta. Un carico è un buon candidato all’automazione quando la sua flessibilità regge su un range di condizioni, non solo il giorno in cui è stato testato per caso.

Il precooling HVAC e la flessione dei setpoint si automatizzano ragionevolmente bene, purché la logica di automazione stessa obblighi il buffer termico, non un programma fisso che assume che lo stesso buffer esista ogni giorno. Un precool dimensionato per un pomeriggio mite di mezza stagione e lasciato senza supervisione in un giorno caldo a piena occupazione chiede più inerzia termica di quanta l’edificio possa restituire, e nessuno lo intercetta finché non partono i reclami.

Carichi di processo non critici, pompe VFD con slack, compressori a batch, attrezzature con vera flessibilità di programma, sono spesso i migliori candidati all’automazione proprio perché uno stacco mancato o sbagliato raramente causa qualcosa di peggio di uno spostamento di programma. Il timing dello sbrinamento frigorifero si automatizza bene entro la sua usuale finestra a scala di minuti, purché l’automazione controlli la temperatura attuale della vetrina contro la soglia di sicurezza alimentare prima di spostare, invece di spostare su un timer fisso indipendentemente da dove sia davvero la vetrina.

La sequenza refrigeratori richiede più cautela automatizzata che manuale. Un impianto lead-lag con margine confermato sulla macchina di riserva è un buon candidato manuale i giorni in cui un operatore lo controlla. Automatizzare lo stesso stacco significa che l’automazione deve sapere, ogni volta, se il margine esistito in test esiste ancora oggi, sotto occupazione e condizioni esterne di oggi, non assumerlo da una valutazione una tantum. Carichi legati a ventilazione occupancy-linked, sistemi life-safety, o qualsiasi processo in cui il costo di interruzione supera il pagamento di flessibilità restano fuori dalla lista di automazione del tutto, per le stesse ragioni per cui sono fuori dalla lista DSR manuale fin dall’inizio.

DSR manuale versus ADR automatizzata attivata da OpenADR

Dove finisce il layer di evidenza di FrostLogic e inizia il dispatch automatizzato

Niente di quanto sopra rende FrostLogic Explore parte della catena di dispatch automatizzato, e non è costruito per esserlo. Explore identifica quali carichi in un edificio sono davvero sicuri da automatizzare, prevede l’impatto di staccarli con bande di confidenza, e documenta quella decisione così che regga sotto condizioni che il test iniziale non copriva. Quel lavoro gira sullo stesso software di energy management che Explore già fornisce per l’immagine quotidiana di costo e consumo di un edificio; la prontezza all’automazione è un’altra domanda a cui risponde, non un sistema separato applicato specificamente per OpenADR.

Explore non invia un segnale OpenADR, non esegue un client VEN, non commercia flessibilità su un mercato né regola un pagamento DSR. Quel livello di esecuzione sta nel client VEN del BMS stesso, e negli aggregatori che gestiscono mercato e dispatch a una scala che una piattaforma di analisi sensori non ha motivo di duplicare, tra cui Drax, E.ON, Enel X e GridBeyond, gli stessi aggregatori che gestiscono l’iscrizione al DSR manuale. Il passaggio di consegne è l’evidenza: quali carichi, in quali condizioni, con quale confidenza. Cosa un aggregatore o un fornitore BMS fa con quell’evidenza, collegarla alle regole di automazione di una VEN, strutturare quali livelli di segnale attivano quali carichi, è il loro dominio.

Lo stesso overlap di compliance che vale per il DSR manuale vale anche qui, e probabilmente conta di più: uno stacco automatizzato che tocca consumo misurato che alimenta una disclosure di sostenibilità o di prestazione energetica non si ferma perché qualcuno noti l’overlap prima di eseguire. Dove quell’intersezione va gestita, appartiene al lavoro di compliance esistente di un edificio, non va trattata come qualcosa che la partecipazione OpenADR introduce da sola.

Se stai mappando quali carichi del tuo patrimonio potrebbero entrare in un programma automatizzato senza creare i problemi sopra, parliamone.

Domande frequenti

Cos'è automated demand response? Automated demand response (ADR) è demand response in cui un segnale da utility, gestore di rete o aggregatore fa sì che l’equipaggiamento di un edificio stacchi, sposti o limiti carico automaticamente, senza che una persona decida nel momento. Si distingue dal DSR manuale o programmato, dove un operatore rivede un avviso di evento e sceglie se rispondere.

Qual è un esempio di demand response? Un edificio commerciale riceve un segnale di evento di punta e alza automaticamente i setpoint AHU di un grado per due ore, o sposta di quindici minuti lo sbrinamento frigorifero di un supermercato, così la domanda misurata scende durante l’evento senza spegnere impianti critici. È un esempio di carico lato edificio, non una lettura residenziale di «bolletta elettrica».

La demand response è costosa, e come funziona il pagamento? La partecipazione di solito viene pagata, non addebitata: i programmi compensano capacità e/o riduzione consegnata. I livelli automatizzati spesso pagano di più di quelli manuali perché la risposta è garantita. Le tariffe esatte dipendono da mercato e contratto aggregatore. FrostLogic non fissa né regola quei pagamenti; lo fanno aggregatori e utility. Il vero rischio di costo lato edificio è automatizzare un carico che non era mai sicuro da staccare senza supervisione.

Cos'è open automated demand response (OpenADR)? Open Automated Demand Response è uno standard di comunicazione, mantenuto da OpenADR Alliance, che definisce come i segnali di demand response automatizzata sono strutturati e scambiati tra un mittente lato rete (VTN) e un ricevitore lato edificio (VEN). «Open» si riferisce allo standard aperto e interoperabile tra vendor, non al ruolo di FrostLogic; FrostLogic non implementa né certifica comunicazioni OpenADR.

Cosa sono i programmi di automated demand response? Programmi gestiti da utility o aggregatori che pagano un edificio per la partecipazione automatizzata, tipicamente a tariffe migliori o livelli di risposta più rapidi del DSR manuale perché la risposta è garantita contrattualmente piuttosto che dipendente da un operatore che agisce in tempo. Iscrizione e selezione del programma sono gestite da aggregatori come Drax, E.ON, Enel X e GridBeyond, non da FrostLogic.

FrostLogic invia segnali di automated demand response? No. FrostLogic Explore identifica quali carichi sono sicuri da automatizzare, prevede l’impatto dello staccarli con bande di confidenza, e documenta quella decisione. Non invia segnali OpenADR, non esegue un client VEN, non commercia flessibilità, non offre su mercati di rete né regola pagamenti DSR. Quel livello di esecuzione sta nel client VEN del BMS o presso un aggregatore.

Quali carichi sono sicuri da automatizzare senza un umano nel loop? Carichi con margine che regge su un range di condizioni, non solo il giorno in cui sono stati testati, ad esempio carichi di processo non critici con vero slack di programma, sbrinamento frigorifero entro il suo margine di temperatura, o sequenza refrigeratori con margine confermato sulla macchina di riserva. Carichi dove la sicurezza dipende da una condizione che cambia giorno per giorno, ventilazione legata all’occupazione o un refrigeratore già caldo, hanno bisogno che una persona controlli prima di automatizzare, non solo prima di iscriversi.

Qual è la differenza tra DSR manuale e ADR automatizzata? Il DSR manuale dà a una persona una finestra per rivedere un avviso di evento e decidere se rispondere, così una scelta sbagliata viene intercettata prima o durante l’evento. L’ADR automatizzata rimuove quel controllo: un segnale VTN esegue una risposta preprogrammata nel momento in cui arriva, ogni volta, senza che nessuno veti uno stacco che si rivela non sicuro in quel giorno particolare.

Uno stacco automatizzato può causare un problema di comfort o sicurezza se un carico non è davvero pronto? Sì, e la modalità di fallimento è peggiore dell’equivalente manuale perché non viene intercettata nel momento. Un precooling spinto oltre il buffer termico dell’edificio, o uno stacco refrigeratori sequenziato senza margine reale, produce lo stesso reclamo sul comfort o interruzione di processo che un errore manuale, tranne che si ripete automaticamente a ogni evento futuro finché qualcuno non lo nota e corregge la logica di automazione.

Ho bisogno di un BMS con client VEN OpenADR già installato per usare FrostLogic Explore? No. Il lavoro di previsione ed evidenza di Explore gira sui contatori esistenti di un edificio e sui dati BMS o sensori, indipendentemente dal fatto che OpenADR sia già deployato. La domanda sul client VEN conta solo quando sei pronto ad agire sui risultati di Explore collegando l’automazione lato aggregatore o BMS per eseguire lo stacco.