Demand response automatizzata: quali carichi sono sicuri da flessibilizzare senza supervisione umana

Foto di Dmitrijs Safrans su Unsplash.

Cerca "demand response automatizzata" e la pagina che compare è 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 pronti per l'ADR come funzione di prodotto. Articoli accademici di Lawrence Berkeley e IEEE analizzano l'economia della rete. Tutto questo tratta l'edificio come l'estremità lontana di un percorso di segnale: ciò che riceve un'istruzione e, in teoria, agisce su di essa. Nessuno di questi chiede la domanda che decide se quell'istruzione dovrebbe poter agire su qualcosa senza che una persona controlli prima.

Abbiamo trattato il lato manuale di questa domanda in demand side response: quali carichi un edificio può flessibilizzare quando una persona decide, evento per evento, se rispondere. La demand response automatizzata elimina quella persona. Arriva un segnale OpenADR, un client VEN sul BMS lo riceve, e un carico si stacca, precoola o limita da solo, senza che nessuno nell'edificio confermi prima che sia sicuro. Questo è tutto l'appeal dell'automazione: nessun evento perso, nessuna corsa manuale, tempi di risposta più rapidi che qualificano per i programmi di risposta rapida meglio pagati. È anche il motivo per cui sbagliare la domanda di fondo, se questo specifico carico è davvero sicuro da staccare adesso, costa di più, non di meno.

Questo pezzo riprende dove quell'altro si è fermato. Non cos'è OpenADR, l'Alliance lo documenta con precisione. Non come iscriversi a un programma automatizzato, GridPoint e gli aggregatori coprono già bene quel terreno. Cosa deve essere vero su un carico prima che sia sicuro lasciare che un'istruzione automatizzata permanente lo tocchi senza supervisione.

La demand response automatizzata chiede di più a un edificio del DSR manuale

In un evento DSR manuale, una scelta sbagliata viene intercettata. Un operatore vede l'avviso, controlla l'impianto e decide che il refrigeratore non è un buon candidato oggi perché sta già girando caldo. L'evento procede senza quel carico, o l'operatore lo segnala e va avanti. L'errore, se c'è, si ferma nel punto in cui qualcuno lo rivede.

L'automazione rimuove quel checkpoint di proposito. Questo è il valore: la risposta avviene in secondi, non nel tempo che una persona impiega a notare un avviso di evento, accedere e agire. Ma significa che un carico marginale oggi, e accettabile da includere in un giorno in cui qualcuno vigila, viene eseguito lo stesso nel giorno in cui nessuno vigila, perché non serve che ci sia nessuno. Lo stesso errore che sarebbe stato intercettato una volta in un programma manuale ora si ripete a ogni evento finché qualcuno nota il pattern, di solito dopo un reclamo sul comfort o un problema di processo, non prima.

Questa è la distinzione reale tra DR manuale e automatizzata, e non riguarda quale sia migliore. L'automazione cambia cosa conta come evidenza sufficiente prima che un carico entri in lista. Un carico flessibile la maggior parte del tempo, con eccezioni occasionali che una persona intercetterebbe, è un candidato DSR manuale ragionevole. Lo stesso carico è un rischio come automatizzato a meno che le eccezioni non siano anche gestite nella logica di automazione stessa, non lasciate a qualcuno da notare.

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 sono strutturati e scambiati i segnali di DR automatizzata. Non decide quali carichi staccare né come un edificio dovrebbe rispondere; standardizza la messaggistica così che una utility, un gestore di rete o un aggregatore da un lato e il sistema di automazione di un edificio dall'altro possano parlarsi senza un'integrazione personalizzata per ogni coppia.

Il modello ha due lati. Una VTN (Virtual Top Node) è il mittente del segnale, tipicamente gestito da una utility, un gestore di rete o un aggregatore, e emette eventi: un'ora di inizio, una durata, un livello di segnale o un prezzo, e di solito una finestra di opt-out prima che la risposta diventi vincolante. Una VEN (Virtual End Node) è il ricevitore del segnale, un client in esecuzione sul BMS di un edificio o accanto ad esso, o sul suo software di gestione energetica, ed è responsabile di tradurre quel segnale in una risposta locale effettiva, quali carichi la sua programmazione abbia assegnato a quel livello di segnale.

Ciò che lo standard lascia interamente al lato edificio è la parte più difficile: decidere quali carichi quella VEN dovrebbe davvero poter toccare, in quali condizioni, e con quale confidenza che toccarli non causi un problema che il segnale stesso non ha modo di conoscere. OpenADR trasmette l'istruzione in modo affidabile. Non ha un'opinione se l'istruzione sia sicura da eseguire in un edificio specifico in un giorno specifico, e non è progettato per questo. FrostLogic non implementa, gestisce o certifica un client VEN; questo è territorio del BMS e del fornitore di automazione. Explore risponde 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 nella demand side response, ma la soglia per automatizzarne uno è più alta che per offrirlo 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.

Precooling HVAC e flessibilità dei setpoint si automatizzano ragionevolmente bene, a patto che la logica di automazione stessa imponga il buffer termico, non un programma fisso che assume lo stesso buffer ogni giorno. Un precooling dimensionato per un pomeriggio mite di mezza stagione e lasciato senza supervisione in una giornata calda e pienamente occupata prende in prestito più inerzia termica di quanta l'edificio possa restituire, e nessuno se ne accorge finché non iniziano i reclami.

Carichi di processo non critici, pompe VFD con margine, compressori a batch, equipaggiamento 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. La tempistica dello sbrinamento frigorifero si automatizza bene entro la sua solita finestra di pochi minuti, purché l'automazione controlli la temperatura attuale della cella contro la soglia di sicurezza alimentare prima di spostare, piuttosto che spostare su un timer fisso indipendentemente da dove si trovi realmente la cella.

La sequenza dei refrigeratori richiede più cautela automatizzata che manuale. Un impianto lead-lag con margine confermato sulla macchina di riserva è un buon candidato manuale nei giorni in cui un operatore lo controlla. Automatizzare lo stesso stacco significa che l'automazione deve sapere, ogni volta, se il margine esistente durante il test esiste ancora oggi, con l'occupazione e le condizioni esterne di oggi, non assumere dal risultato di una valutazione una tantum. Carichi legati a ventilazione basata sull'occupazione, sistemi di sicurezza della vita o qualsiasi processo dove il costo dell'interruzione supera il pagamento per flessibilità restano completamente fuori dalla lista di automazione, 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 livello 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 dello staccarli con bande di confidenza, e documenta quella decisione così che regga in condizioni che il test iniziale non copriva. Quel lavoro gira sullo stesso software di gestione energetica 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.

Domande frequenti

Cos'è la demand response automatizzata? La demand response automatizzata (ADR) è la demand response in cui un segnale, di solito inviato 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. Si distingue dal DSR manuale o programmato, dove un operatore rivede un avviso di evento e sceglie se rispondere; vedi il nostro pezzo sulla demand side response per quel lato del quadro.

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 demand response automatizzata? 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 demand response automatizzata? 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.