Guía técnica para evitar incidentes en BESS: thermal runaway, separación, ventilación, detección, supresión, respuesta a emergencias y trazabilidad de seguridad.
Un BESS no falla como una subestación y no arde como un tanque. Su riesgo característico es más incómodo: está diseñado para almacenar energía en un volumen pequeño y liberarla con precisión, pero cuando una celda entra en degradación acelerada, el sistema puede producir calor, gases y presión más rápido de lo que la instalación es capaz de disipar. Ese es el núcleo del “thermal runaway”: no es un incendio convencional que se combate “apagando”, es un evento de liberación interna que se gestiona conteniendo propagación, controlando gases, evitando presurización peligrosa y protegiendo exposición a terceros.
La reputación de un proyecto BESS no se destruye por el primer humo. Se destruye por la secuencia posterior: evacuación tardía, respuesta de emergencia improvisada, puertas abiertas que alimentan oxígeno, falta de distancias, supresión que no coincide con el modo de falla, y un expediente técnico incapaz de explicar qué pasó y por qué no debía escalar. En banca, seguros y permisos, esa secuencia pesa más que la marca del integrador.
NFPA 855 funciona aquí como marco de diseño y gobernanza: obliga a convertir el riesgo en decisiones de ingeniería verificables. El estándar no es una “cita de cumplimiento”, es una forma de demostrar que el proyecto se diseñó para fallar sin volverse noticia.
En un BESS, el peligro no se explica por “alta energía” a secas, sino por tres fenómenos acoplados. Primero, la generación de gases calientes y potencialmente inflamables cuando falla una celda o un módulo. Segundo, la posibilidad de que esos gases se acumulen si la ventilación y el manejo de presión están mal resueltos. Tercero, la propagación térmica hacia celdas vecinas si la separación interna, el aislamiento y el diseño de contención no están alineados con el peor caso.
Por eso el error típico es copiar la lógica de una sala eléctrica. En una subestación, la prioridad es despejar falla y aislar. En un BESS, la prioridad es evitar propagación, controlar atmósferas peligrosas y mantener la intervención humana dentro de un plan que asume que el evento puede durar más de lo que el instinto operativo tolera. Si el diseño obliga al personal a abrir un contenedor “para ver qué pasa”, el proyecto ya quedó mal planteado.
El BESS bancable empieza por un modelo de escenarios creíble, no por una carpeta de fichas técnicas. HAZID o HAZOP solo aportan si se usan para traducir modos de falla en barreras específicas. El enfoque que más “amarra” decisiones suele ser un bow-tie bien hecho: del lado izquierdo, causas plausibles (defecto de celda, daño mecánico, sobrecarga, falla de BMS, error de mantenimiento, intrusión de agua, sobretemperatura ambiental); del lado derecho, consecuencias y escalamiento (propagación a racks, acumulación de gas, deflagración, exposición tóxica, impacto a terceros, pérdida total del sitio). El valor está en las barreras, no en el diagrama.
En términos prácticos, el stack de seguridad en un BESS se ve así:
1) Prevención y detección temprana antes del fuego.
Los proyectos serios no esperan a la flama. Incorporan detección de condición anómala: temperatura bien instrumentada, lógica de BMS con umbrales robustos, y, cada vez más, detección de off-gas como señal temprana de degradación. Esto reduce el número de eventos que pasan de “incidente controlable” a “situación de emergencia”.
2) Separación y diseño para que el evento no se propague.
La separación no es estética de layout. Es un mecanismo para que un evento en una unidad no se convierta en evento de sitio. Distancias entre contenedores, sectorización, barreras térmicas, y criterios de exposición deben justificar por qué un contenedor puede entrar en evento sin “encender” su vecino. Aquí NFPA 855 empuja a usar criterios que se soportan con evidencia y pruebas, no con suposiciones.
3) Ventilación, manejo de presión y control de atmósferas.
La parte más subestimada es el comportamiento de gases. Un BESS puede generar mezclas peligrosas y presiones internas. Ventilar “para enfriar” no necesariamente resuelve el riesgo si el diseño no controla rutas de salida, puntos de ignición y acumulación. En interiores, esto se vuelve crítico: un BESS mal ubicado y sin ingeniería de deflagración puede convertir una maniobra de puerta o compuerta en el disparador del peor escenario.
4) Supresión y estrategia de respuesta consistente con el modo de falla.
La supresión no se decide por catálogo. Se decide por objetivo: proteger exposición, evitar propagación, permitir enfriamiento y mantener integridad de adyacencias. En muchos casos, la mejor práctica no es “apagar” inmediatamente el núcleo, sino permitir que el evento termine contenido, mientras se protege el entorno y se controla el perímetro. Esa estrategia debe estar escrita, entrenada y alineada con bomberos locales, no solo con el integrador.
5) E-Stop, aislamiento, y procedimientos que no empujen al error humano.
Un BESS debe poder entrar a estado seguro con lógica clara: qué se desconecta, qué queda energizado, qué no se debe tocar, y cómo se confirma. Si la operación requiere interpretaciones, el riesgo sube cuando más importa.
Un propietario que quiere un proyecto bancable no compra “capacidad”, compra control del riesgo. Eso se vuelve exigible en tres frentes: pruebas, documentación y operación.
En pruebas, el punto de inflexión es evidencia de comportamiento bajo thermal runaway. No basta con certificaciones genéricas del producto. El propietario debe exigir resultados de pruebas que expliquen propagación, generación de calor y gases, y desempeño de mitigaciones a escala relevante. En la práctica, UL 9540A es el lenguaje de mercado para demostrar qué pasa cuando el sistema falla y qué diseño lo contiene. Si el integrador no puede entregar evidencia entendible y trazable de pruebas, el proyecto se vuelve un acto de fe, y el seguro lo tratará como tal.
En documentación, la exigencia es un expediente que conecte diseño con operación. Planos de layout con criterio de separación, memoria de ventilación y rutas de alivio, filosofía de detección y alarmas, secuencias de paro, matriz causa-efecto, y manuales de operación que no dependan de “técnicos del proveedor” para funcionar. Lo que no está documentado, no existe cuando hay incidente.
En operación, el dueño debe exigir un programa de integridad que sobreviva a la rotación de personal: capacitación, simulacros, permisos de trabajo, control de cambios, y un esquema de mantenimiento que incluya verificación funcional de detección, supresión y BMS. La seguridad del BESS no es un hito de comisionamiento. Es una disciplina.
Un BESS “sin incidentes” no se demuestra con meses sin alarmas. Se demuestra con trazabilidad, porque la trazabilidad es lo único que convence a seguros, autoridades y comunidades cuando ocurre un evento menor y se pregunta si pudo ser mayor.
Esa trazabilidad tiene forma concreta: bitácoras de condiciones ambientales, registros de alarmas y eventos del BMS con retención adecuada, inspecciones programadas con hallazgos y cierres, resultados de pruebas funcionales de detección y supresión, calibraciones, termografías o inspecciones equivalentes cuando aplique, y control de cambios de firmware, setpoints y reemplazos de módulos. También incluye disciplina de “lecciones aprendidas”: no como presentación, sino como modificación verificable de procedimiento o setpoint.
Cuando existe ese expediente, el proyecto puede defenderse. Cuando no existe, cualquier olor a electrolito se convierte en argumento para detener operación.
Asegurabilidad no depende solo de tecnología. Depende de si el riesgo está reducido y, sobre todo, demostrable. Los aseguradores y bancos buscan evidencia de que el sitio no está a una mala decisión de volverse pérdida total. Por eso les importan pruebas, separación, estrategia de respuesta y disciplina de mantenimiento. Un BESS con “papeles bonitos” pero sin pruebas y sin programa operativo consistente tiende a pagar primas más altas, deducibles más duros o exclusiones críticas.
La aceptación comunitaria se decide por confianza. Los vecinos no evalúan estándares; evalúan señales: distancia a viviendas, claridad de protocolos, coordinación con emergencias, y ausencia de improvisación. Un incidente pequeño, si está bien gestionado y documentado, puede no escalar reputacionalmente. Uno mal gestionado sí.
En permisos y continuidad operativa, la lógica es simple: la autoridad y los stakeholders toleran menos incertidumbre que riesgo. Un proyecto que puede explicar su riesgo y su mitigación tiene margen. Uno que no puede, se detiene ante la primera presión social o el primer evento de humo.
Todos los campos son obligatorios *
Escríbenos a
[email protected]
