Un ritardo COD BESS è una delle sorprese più costose nello sviluppo di sistemi di accumulo, e il mancato rispetto delle date di entrata in esercizio commerciale è molto più comune di quanto i cronoprogrammi di messa in servizio lascino supporre.
Eppure ogni progetto BESS che ho esaminato ha un cronoprogramma di messa in servizio che dà per scontato che sarà completato in tempo.
Il settore sa che i ritardi sono frequenti. Lo sanno i promotori. Lo sanno gli EPC. Eppure ogni progetto parte dal presupposto di poter battere le probabilità, e poi non ci riesce.
Non si tratta di incompetenza. La messa in servizio di un BESS è davvero più complessa di quella di un impianto fotovoltaico senza accumulo, con più regimi di prova, più dipendenze sequenziali e più punti di contatto normativi. Ma complesso non significa imprevedibile. Le cinque cause alla radice spiegano la stragrande maggioranza dei mancati rispetti della COD dei BESS, sono individuabili con settimane di anticipo e possono essere gestite.
Motivo 1: discrepanze nella versione del firmware BMS
È il guasto di messa in servizio più comune specifico dei BESS, e quasi sempre viene scoperto troppo tardi.
La messa in servizio del sistema di gestione della batteria (BMS) richiede la validazione a livello di cella della logica di controllo del BMS. Per un BESS su scala utility con decine di migliaia di celle, questa operazione richiede molto tempo. Quando il firmware dei moduli consegnati non corrisponde alla versione dei controllori BMS del sito, ogni modulo interessato richiede un aggiornamento e un nuovo collaudo.
Una discrepanza di firmware rilevata in fase di messa in servizio in campo, anziché durante l’ispezione alla consegna, può costare da 7 a 14 giorni di rilavorazione. Su un progetto che ha già consumato 60 giorni di margine di cronoprogramma per ritardi a monte, 14 giorni significano un mancato rispetto della COD.
La soluzione è una verifica del firmware prima della messa in servizio, eseguita non appena vengono confermati i documenti di consegna delle apparecchiature. L’agente di intelligence sui rischi di messa in servizio confronta le versioni di firmware BMS dichiarate con le specifiche di configurazione dei controllori di impianto. Quando compare una discrepanza nei documenti di consegna, l’allerta scatta subito, prima dell’installazione delle apparecchiature e non dopo. L’agente opera sulla piattaforma di IA agentica per fotovoltaico e accumulo di ClearSpot, insieme agli agenti di O&M.
Motivo 2: errori nella sequenza dei relè di protezione
La connessione alla rete richiede la messa in servizio sequenziale dei relè di protezione. Le funzioni di protezione di sovracorrente, differenziale, di guasto a terra e specifiche per le batterie devono essere impostate, collaudate e accettate dal gestore di rete in una sequenza definita.
La modalità di guasto è rappresentata da impostazioni dei relè corrette di per sé ma incompatibili con la specifica configurazione di rete del gestore. I gestori di rete aggiornano le proprie specifiche di messa in servizio, a volte ogni anno. I progetti sviluppati secondo la specifica dell’anno precedente si scontrano con questo ostacolo al collaudo di accettazione.
Questo è particolarmente critico perché l’incompatibilità non sempre si vede nelle impostazioni in sé. Sta nel requisito di sequenza. Un ingegnere che ha configurato correttamente i relè in 15 progetti precedenti lo farà correttamente anche in questo, secondo la specifica che conosce, che potrebbe non essere quella in vigore.
Come lo prevede l’agente: incrocia i requisiti di specifica dei relè contenuti nell’offerta di connessione alla rete con le impostazioni dei relè di protezione riportate nei registri di messa in servizio.
Dove esistono discrepanze, crea un’azione correttiva e ne segue la risoluzione prima che venga programmato il collaudo di accettazione del gestore di rete.
Non come un punto di una checklist che una persona spunta, ma come un controllo incrociato automatico che gira in modo continuo man mano che i registri di messa in servizio vengono aggiornati.
Motivo 3: ritardi nella certificazione del sistema antincendio
Le installazioni BESS richiedono la certificazione del sistema di estinzione incendi prima dell’agibilità, dell’accettazione della connessione alla rete e della maggior parte delle polizze assicurative. Ciò richiede un’ispezione da parte di terzi, condotta da un ingegnere antincendio accreditato.
Il problema strutturale è che, in molte giurisdizioni europee, gli ispettori antincendio accreditati per i BESS hanno tempi di prenotazione di 4-8 settimane. Un progetto che programma l’ispezione antincendio alla settimana 40, quando il primo ispettore accreditato disponibile è alla settimana 46, ha un ritardo strutturale della COD di 6 settimane, visibile già alla settimana 20, ma solo se qualcuno monitora la disponibilità degli ispettori.
Nessuno monitora sistematicamente la disponibilità degli ispettori. È un vincolo di risorse che sembra un ritardo tecnico.
L’agente di intelligence sui rischi di messa in servizio tratta la certificazione antincendio come una linea di rischio distinta, con un modello dei tempi basato sui dati regionali di disponibilità degli ispettori. Quando il cronoprogramma di messa in servizio mostra la certificazione alla settimana 40, l’agente verifica la disponibilità e segnala se il modello dei tempi indica che la data realistica è la settimana 46. Lo fa alla settimana 24, non alla settimana 39.
Motivo 4: lacune nei test di conformità al codice di rete
La conformità al codice di rete per i BESS è sempre più sofisticata. Risposta in frequenza, capacità di potenza reattiva, controllo della rampa, capacità di black start per alcuni contratti e capacità grid-forming per i BESS di grande taglia più recenti richiedono test formali secondo le specifiche del gestore di rete.
La modalità di guasto è semplice: fallisce un test di conformità, tipicamente la capacità di potenza reattiva o la precisione della risposta in frequenza, e l’intera sequenza si azzera. Il gestore di rete riprogramma l’intera suite di test di conformità, non solo l’elemento che ha fallito. Questo aggiunge da 3 a 6 settimane, indipendentemente dalla rapidità con cui si risolve il problema tecnico.
La linea dei test di conformità alla rete richiede una gestione del rischio propria, distinta dalla linea della messa in servizio fisica. Nella maggior parte dei progetti è gestita dallo stesso ingegnere di messa in servizio che segue tutto il resto. In un progetto con criticità simultanee nella chiusura delle non conformità, nella configurazione dei relè di protezione e nella certificazione antincendio, i test di conformità alla rete non ricevono l’attenzione concentrata di cui hanno bisogno finché qualcosa non fallisce.
Per il contesto normativo e di conformità alla rete più ampio in Europa, SolarPower Europe e le linee guida IEA PVPS per l’O&M sono due riferimenti autorevoli su come l’evoluzione dei requisiti dei codici di rete stia trasformando la complessità della messa in servizio sui progetti su scala utility.
Motivo 5: documentazione incompleta nel pacchetto di interconnessione
È il fallimento da mille piccoli tagli. Nessun singolo elemento è catastrofico. Nel complesso, spostano la data del collaudo di accettazione di 2-3 settimane.
Il pacchetto di documentazione pre-messa in servizio richiesto dal gestore di rete comprende schemi unifilari as-built alla revisione corrente, schede di impostazione dei relè di protezione con controllo di versione, certificati di prestazione del BESS, certificazione antincendio, schede tecniche del sistema di gestione dell’energia e piani di test di conformità alla rete. Ogni elemento ha una specifica di formato. Qualsiasi elemento nel formato sbagliato, alla revisione sbagliata o privo di una firma richiesta viene respinto e il pacchetto deve essere ripresentato.
Molti progetti su scala utility presentano questo pacchetto più di una volta prima che venga accettato, e ogni ripresentazione è un ritardo che avrebbe potuto essere evitato.
L’agente di intelligence sui rischi di messa in servizio controlla in modo continuo la completezza della documentazione rispetto ai requisiti del pacchetto del gestore di rete, non solo al momento della presentazione ma durante tutta la fase di messa in servizio. Segnala i problemi di formato e gli elementi mancanti quando c’è ancora tempo per correggerli senza ritardare la finestra di presentazione.
Il filo conduttore
Tutti e cinque i meccanismi di guasto sono prevedibili. Nessuno richiede il senno di poi per essere individuato. Richiedono un sistema che monitori simultaneamente, e in modo continuo, il progresso della messa in servizio lungo tutte e cinque le dimensioni di rischio, e che segnali con sufficiente anticipo da poter agire.
La rete di ClearSpot combina agenti IA autonomi per O&M e messa in servizio con droni autonomi. Per i BESS, la validazione termica con droni dello stato pre-messa in servizio, a livello di rack e di sistema, individua anomalie termiche che causerebbero guasti in fase di energizzazione prima che inizi la sequenza di energizzazione. Lo stesso approccio ha poi individuato un hotspot operativo su un BESS con largo anticipo, e dopo la COD la baseline di messa in servizio alimenta direttamente il software di monitoraggio BESS.
La guida alle best practice di O&M fotovoltaico del NREL rafforza lo stesso principio che vale per la messa in servizio: il monitoraggio strutturato e continuo del rischio a livello di sistema è l’unico modo affidabile per prevenire eventi di guasto che sono tecnicamente visibili prima di diventare finanziariamente rilevanti.
Le penali per ritardo (liquidated damages) sui progetti BESS su scala utility maturano di solito per ogni giorno di ritardo, quindi un singolo slittamento della COD evitato di solito ripaga il monitoraggio continuo della messa in servizio più volte.
Le probabilità non sono difficili da calcolare.
Riflessione finale
Quale di questi cinque meccanismi di guasto ha visto più spesso nei progetti BESS su cui ha lavorato, e che cosa lo ha infine fatto emergere?
Domande frequenti
È uno slittamento della data di entrata in esercizio commerciale (COD) di un progetto di accumulo a batteria, di solito causato da problemi di messa in servizio, certificazione, conformità alla rete o documentazione individuati in ritardo.
Le discrepanze nella versione del firmware BMS sono una delle cause più frequenti di ritardo nella messa in servizio di un BESS.
Richiedono più test sequenziali, più interdipendenze e più passaggi di conformità alla rete.
Sì. Discrepanze di firmware, lacune nella sequenza dei relè, tempi di certificazione antincendio, rischio sui test di conformità alla rete e lacune documentali sono visibili con settimane di anticipo quando i registri di messa in servizio vengono monitorati in modo continuo.
Gli agenti IA di ClearSpot incrociano i registri di messa in servizio con le specifiche, monitorano il rischio di certificazione e documentazione, e attivano la validazione termica con droni prima dell’energizzazione.