Un retraso en la COD de un BESS es una de las sorpresas más costosas en el desarrollo de almacenamiento, y el incumplimiento de las fechas de operación comercial es mucho más habitual de lo que suponen los calendarios de puesta en servicio.
Y, sin embargo, cada proyecto BESS que he revisado tiene un calendario de puesta en servicio que da por hecho que terminará a tiempo.
La industria sabe que los retrasos son habituales. Los promotores lo saben. Las EPC también. Y, aun así, cada proyecto arranca suponiendo que vencerá las probabilidades y, al final, no lo consigue.
No se trata de falta de competencia. La puesta en servicio de un BESS es realmente más exigente que la de una planta solar sin almacenamiento, con más regímenes de ensayo, más dependencias secuenciales y más puntos de contacto regulatorios. Pero que sea más exigente no significa que sea impredecible. Las cinco causas raíz explican la gran mayoría de los fallos de COD en BESS, se pueden identificar con semanas de antelación y se pueden gestionar.
Motivo 1: discrepancias en la versión de firmware del BMS
Es el fallo de puesta en servicio más común específico de BESS, y casi siempre se descubre demasiado tarde.
La puesta en servicio del sistema de gestión de baterías (BMS) exige validar a nivel de celda la lógica de control del BMS. En un BESS a gran escala con decenas de miles de celdas, esto lleva mucho tiempo. Cuando el firmware de los módulos entregados no coincide con la versión de los controladores BMS de la planta, cada módulo afectado necesita una actualización y un nuevo ensayo.
Una discrepancia de firmware detectada en la puesta en servicio en campo, en lugar de en la inspección de entrega, puede consumir entre 7 y 14 días de retrabajo. En un proyecto que ya ha agotado 60 días de margen de calendario por retrasos anteriores, 14 días suponen un fallo de COD.
La solución es una verificación previa a la puesta en servicio del firmware, que se ejecuta en cuanto se confirman los registros de entrega de equipos. El agente de inteligencia de riesgos de puesta en servicio compara las versiones de firmware declaradas del BMS con las especificaciones de configuración de los controladores de planta. Cuando aparece una discrepancia en los registros de entrega, la alerta se activa de inmediato, antes de instalar el equipo y no después. El agente funciona sobre la plataforma de IA agéntica para solar y almacenamiento de ClearSpot, junto con los agentes de O&M.
Motivo 2: errores en la secuencia de los relés de protección
La conexión a red exige poner en servicio de forma secuencial los relés de protección. Las funciones de protección por sobreintensidad, diferencial, defecto a tierra y específicas de baterías deben ajustarse, ensayarse y ser aceptadas por el operador de red en un orden definido.
El modo de fallo son ajustes de relés correctos de forma aislada pero incompatibles con la configuración de red concreta del operador. Los operadores de red actualizan sus especificaciones de puesta en servicio, a veces cada año. Los proyectos diseñados según la especificación del año anterior chocan con este obstáculo en el ensayo de aceptación del operador.
Esto es especialmente delicado porque la incompatibilidad no siempre se ve en los ajustes en sí. Está en el requisito de secuencia. Un ingeniero que ha configurado correctamente los relés en 15 proyectos anteriores lo hará bien también en este, según la especificación que conoce, que puede no ser la vigente.
Cómo lo predice el agente: cruza los requisitos de especificación de relés de la oferta de conexión a red con los ajustes de los relés de protección que figuran en los registros de puesta en servicio.
Cuando existen discrepancias, crea una acción correctiva y le hace seguimiento hasta su resolución antes de programar el ensayo de aceptación del operador.
No como un punto de una lista de comprobación que una persona marca, sino como un cruce automático que se ejecuta de forma continua a medida que se actualizan los registros de puesta en servicio.
Motivo 3: retrasos en la certificación del sistema de extinción de incendios
Las instalaciones BESS necesitan la certificación del sistema de extinción de incendios antes de la licencia de ocupación, de la aceptación de la conexión a red y de la mayoría de las pólizas de seguro. Esto exige una inspección por un tercero, realizada por un ingeniero de seguridad contra incendios acreditado.
El problema estructural es que, en muchas jurisdicciones europeas, los inspectores acreditados de seguridad contra incendios en BESS tienen plazos de reserva de 4 a 8 semanas. Un proyecto que programa la inspección de incendios para la semana 40, cuando el primer inspector acreditado disponible está en la semana 46, tiene un retraso estructural de COD de 6 semanas. Es visible en la semana 20, pero solo si alguien controla la disponibilidad de los inspectores.
Nadie controla de forma sistemática la disponibilidad de los inspectores. Es una restricción de recursos que parece un retraso técnico.
El agente de inteligencia de riesgos de puesta en servicio trata la certificación del sistema de extinción de incendios como una línea de riesgo independiente, con un modelo de plazos basado en datos regionales de disponibilidad de inspectores. Cuando el calendario de puesta en servicio muestra la certificación en la semana 40, el agente comprueba la disponibilidad y avisa si el modelo de plazos sugiere que la fecha realista es la semana 46. Lo hace en la semana 24, no en la semana 39.
Motivo 4: lagunas en los ensayos de cumplimiento del código de red
El cumplimiento del código de red para BESS es cada vez más sofisticado. La respuesta en frecuencia, la capacidad de potencia reactiva, el control de rampa, la capacidad de arranque en negro en algunos contratos y la capacidad de formación de red (grid-forming) en los BESS de gran escala más recientes requieren ensayos formales frente a las especificaciones del operador de red.
El fallo es sencillo: falla un ensayo de cumplimiento, normalmente la capacidad de potencia reactiva o la precisión de la respuesta en frecuencia, y toda la secuencia se reinicia. El operador de red reprograma la batería completa de ensayos de cumplimiento, no solo el elemento que ha fallado. Esto añade entre 3 y 6 semanas, independientemente de lo rápido que se resuelva el problema técnico.
La línea de ensayos de cumplimiento de red necesita su propia gestión de riesgos, distinta de la línea de puesta en servicio física. En la mayoría de los proyectos la gestiona el mismo ingeniero de puesta en servicio que lleva todo lo demás. En un proyecto con retos simultáneos en el cierre de la lista de defectos, la configuración de los relés de protección y la certificación contra incendios, los ensayos de cumplimiento de red no reciben la atención concentrada que necesitan hasta que algo falla.
Para el contexto regulatorio y de cumplimiento de red más amplio en Europa, SolarPower Europe y las guías de O&M de IEA PVPS son dos referencias de autoridad sobre cómo la evolución de los requisitos del código de red está transformando la complejidad de la puesta en servicio en proyectos a gran escala.
Motivo 5: documentación incompleta en el paquete de interconexión
Es el fallo de los mil pequeños cortes. Ningún elemento es catastrófico por sí solo. En conjunto, retrasan la fecha del ensayo de aceptación del operador entre 2 y 3 semanas.
El paquete de documentación previa a la puesta en servicio que exige el operador de red incluye diagramas unifilares as-built en revisión vigente, hojas de ajuste de los relés de protección con control de versiones, certificados de rendimiento del BESS, certificación contra incendios, hojas de datos del sistema de gestión de energía y planes de ensayo de cumplimiento de red. Cada elemento tiene una especificación de formato. Cualquier elemento en un formato incorrecto, en una revisión equivocada o sin una firma obligatoria se rechaza y el paquete debe volver a presentarse.
Muchos proyectos a gran escala presentan este paquete más de una vez antes de que sea aceptado, y cada reenvío es un retraso que podría haberse evitado.
El agente de inteligencia de riesgos de puesta en servicio controla de forma continua la integridad de la documentación frente a los requisitos del paquete del operador de red. No lo hace solo en el momento de la presentación, sino durante toda la fase de puesta en servicio. Señala los problemas de formato y los elementos que faltan mientras todavía hay tiempo de corregirlos sin retrasar la ventana de presentación.
El nexo común
Los cinco modos de fallo son predecibles. Ninguno requiere retrospectiva para identificarlo. Lo que requieren es un sistema que supervise el progreso de la puesta en servicio en las cinco dimensiones de riesgo a la vez, de forma continua, y que escale con antelación suficiente para que sea posible actuar.
La malla de ClearSpot combina agentes de IA autónomos para O&M y puesta en servicio con drones autónomos. En BESS, la validación térmica con drones del estado previo a la puesta en servicio, a nivel de rack y de sistema, detecta anomalías térmicas que causarían fallos en la energización antes de que empiece la secuencia de energización. El mismo enfoque detectó después un punto caliente operativo en un BESS con antelación, y tras la COD la línea base de puesta en servicio alimenta directamente el software de monitorización de BESS.
La guía de buenas prácticas de O&M fotovoltaico del NREL refuerza el mismo principio que se aplica en la puesta en servicio: la supervisión estructurada y continua del riesgo a nivel de sistema es la única forma fiable de prevenir eventos de fallo que son técnicamente visibles antes de convertirse en consecuencias financieras.
Las penalizaciones por retraso (liquidated damages) en proyectos BESS a gran escala suelen acumularse por cada día de retraso, así que un único retraso de COD evitado suele amortizar la supervisión continua de la puesta en servicio muchas veces.
Las probabilidades no son difíciles de calcular.
Reflexión final
¿Cuál de estos cinco modos de fallo ha visto con más frecuencia en los proyectos BESS en los que ha trabajado, y qué fue lo que finalmente lo sacó a la luz?
Preguntas frecuentes
Es un desfase en la fecha de operación comercial (COD) de un proyecto de almacenamiento con baterías, normalmente causado por problemas de puesta en servicio, certificación, cumplimiento de red o documentación detectados tarde.
Las discrepancias en la versión de firmware del BMS son una de las causas más habituales de retraso en la puesta en servicio de un BESS.
Requieren más ensayos secuenciales, más interdependencias y más pasos de cumplimiento de red.
Sí. Las discrepancias de firmware, las lagunas en la secuencia de relés, los plazos de certificación contra incendios, el riesgo en los ensayos de cumplimiento de red y las lagunas documentales son visibles con semanas de antelación cuando los registros de puesta en servicio se supervisan de forma continua.
Los agentes de IA de ClearSpot cruzan los registros de puesta en servicio con las especificaciones, siguen el riesgo de certificación y documentación, y despliegan la validación térmica con drones antes de la energización.