⚡ electrical engineering

Fire Safety Engineering of Battery Energy Storage Systems: Barrier Degradation, Emergency Response Interfaces, and Community Exposure in Documented Failure Incidents

This study analyzes 80 documented BESS failure incidents to propose a comprehensive fire safety engineering framework that addresses the interplay of barrier degradation, emergency response constraints, and community exposure, ultimately advocating for enhanced design and operational safety requirements.

Original authors: Karim Hardy

Published 2026-07-10

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Karim Hardy

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a massive, high-tech battery farm not as a single giant brick, but as a bustling city of tiny, energetic cells living inside metal containers. When things go wrong, it's rarely just one cell having a bad day; it's more like a domino effect where the whole neighborhood gets caught in the chaos. That's the big picture Karim Hardy paints in this study of 80 documented battery fire incidents (with 25 of them getting a super-close look).

The paper suggests that we've been looking at these battery fires the wrong way. Instead of just asking, "Did the battery catch fire?" we need to ask, "Why did the safety net fail?"

The "Safety Net" That Got Tangled

Think of a battery system like a castle with multiple layers of defense: early warning alarms, fire sprinklers, walls to stop the fire from spreading, and a clear map for the firefighters. The study found that in most of these 80 incidents, the castle didn't fall because the dragon (the fire) was too strong. It fell because the safety nets were degraded, delayed, or missing entirely.

It's like trying to put out a kitchen fire, but the smoke alarm is broken, the fire extinguisher is stuck, the door to the kitchen is locked, and the firefighters show up without a map of where the gas lines are. The paper argues that these "barrier degradations" are the real villains. For instance, the study notes that detection was often delayed or unclear, meaning the "smoke alarm" didn't ring until the fire was already too big. Ventilation systems sometimes failed to clear out dangerous gases, turning a small fire into a potential explosion trap. And isolation—the ability to cut the power and stop the energy flow—was often unclear or inaccessible to the people trying to save the day.

The Firefighters' "Black Box" Problem

One of the most vivid findings is about the "Emergency Response Interface." Imagine a firefighter arriving at a burning building. In a normal house, they know where the stairs are and where the gas meter is. But with these battery systems, the paper suggests responders often faced a "black box." They didn't know:

What kind of "fuel" was inside (the specific battery chemistry).
How much "energy" was still stored (the state of charge).
If the building was about to explode due to trapped gases.
How to safely turn the system off.

The study points out that in many cases, like the famous McMicken incident in Arizona, responders had to guess or wait for specialists because the information wasn't there. This forced them to play it safe, often staying outside and just spraying water from a distance (a "defensive" strategy) rather than going in to stop the fire at the source. The paper suggests this isn't just a training issue; it's a design flaw. The battery systems need to come with a clear, easy-to-read "user manual" for emergencies that tells firefighters exactly what they are dealing with.

The Ripple Effect: It's Not Just a Factory Fire

Here's where it gets really big. The paper argues that a battery fire isn't just a problem for the factory owner; it's a community event. When these batteries burn, they don't just make smoke; they can release toxic gases that drift over neighborhoods.

The study highlights cases like Moss Landing in California, where the fire turned into a regional public health issue. It wasn't just about putting out flames; it was about telling nearby schools to close their windows, ordering evacuations, and monitoring the air for days. The paper suggests that we can't treat these fires like normal industrial accidents. We need to plan for the "smoke plume" and the "toxic cloud" just as carefully as we plan for the fire itself. In some of the 25 deep-dive cases, the community had to deal with road closures, shelter-in-place orders, and long-term cleanup concerns.

What the Paper Says We Should Do (And What It Doesn't)

The authors are careful not to say, "We found the magic cure." Instead, they suggest a new way of building and planning. They propose that safety shouldn't just rely on the battery cells themselves passing a test. It needs to be a system-wide check.

They suggest that we need better "early warning" systems that look for heat and gas before a fire starts, not just smoke after it's burning.
They suggest that we need to design the batteries so that if one part goes bad, it doesn't drag the whole building down (propagation control).
They suggest that the "emergency manual" for firefighters needs to be built into the site design, not just an afterthought.
They suggest that we need to plan for the community impact, including air monitoring and evacuation routes, right from the start.

What they rule out: The paper explicitly argues against the idea that simply having a fire suppression system (like sprinklers) is enough. They found that in many cases, the sprinklers put out the visible flames, but the batteries kept cooking inside, generating gas and heat, leading to reignition or explosions later. So, "putting out the fire" is not the same as "stopping the danger."

How sure are they? The authors are careful with their words. They say their findings are based on documented incidents, not a perfect global database. They note that they can't calculate the exact probability of a battery failing because we don't have data on every single battery in the world. However, they are very sure about the patterns they see: when these things go wrong, it's usually because multiple safety layers failed at once, and the people trying to fix it didn't have the right information.

The Takeaway

In short, this paper is a call to stop treating battery farms like simple boxes of energy. They are complex, high-stakes systems that need a "safety city" built around them. If we want to keep the lights on and the neighborhoods safe, we need to fix the broken safety nets, give firefighters the maps they need, and plan for the smoke before it even rises. The study doesn't promise that battery fires will disappear, but it suggests that if we fix these specific gaps, we can stop small problems from becoming big disasters.

Technical Summary: Fire Safety Engineering of Battery Energy Storage Systems

Problem Statement

Battery Energy Storage Systems (BESS) are critical for grid flexibility and renewable integration, yet their deployment has been accompanied by a rising number of fire, explosion, and thermal runaway incidents. Existing literature often treats these events as isolated component failures (cell or module level) or focuses narrowly on thermal runaway chemistry. However, a gap exists between component-level fire science and the system-level safety engineering required for real-world stationary BESS installations. Current safety outcomes depend not only on ignition but on the complex interaction of detection, suppression, ventilation, isolation, and emergency response capabilities. Furthermore, existing incident evidence is fragmented across technical reports, regulatory documents, and media sources, lacking a structured dataset to analyze recurring failure patterns, barrier degradation, and community exposure.

Methodology

This study employs a structured incident dataset methodology to analyze 80 documented stationary BESS failure incidents involving fire, explosion, smoke, or thermal runaway. The data was aggregated from publicly available sources, including the EPRI BESS Failure Incident Database, agency reports, fire service investigations, operator root-cause analyses, and regulatory working group materials.

The analysis distinguishes between two tiers:

Core Incidents (n=55): Documented events providing sufficient information for basic coding of location, date, system context, and consequence class.
Deep-Dive Cases (n=25): Incidents with enhanced source documentation allowing for expanded analysis of barrier performance and emergency response interfaces.

The coding framework evaluates three primary analytical dimensions:

Barrier Performance: Assessing whether technical or organizational barriers (detection, suppression, ventilation, isolation, etc.) were present, effective, delayed, overwhelmed, or undocumented.
Emergency Response Interface: Evaluating the informational and operational conditions available to responders, including pre-fire plans, chemistry data, isolation procedures, and access routes.
Community Exposure: Documenting off-site consequences such as evacuations, shelter-in-place advisories, smoke plumes, and public health monitoring.

The study explicitly avoids estimating absolute failure probabilities due to inconsistent global reporting, instead focusing on identifying recurring scenarios and deriving engineering requirements.

Key Contributions

The paper makes three specific contributions to the field of BESS safety:

Structured Incident Dataset: It provides a curated, coded dataset of 80 BESS incidents designed specifically for fire safety engineering analysis, bridging the gap between fragmented public reports and systematic safety review.
System-Level Failure Analysis: It reframes BESS failures not merely as component defects but as system-level events driven by the degradation of multiple safety barriers and limitations in the emergency response interface.
Derivation of Engineering Requirements: It translates incident patterns into specific fire safety engineering requirements for design, siting, operation, and emergency planning, moving beyond simple component compliance.

Key Results

1. Incident Scenarios and Consequences

The dataset reveals that BESS incidents frequently involve coupled mechanisms rather than isolated failures. Dominant event classes include fire and thermal runaway propagation, smoke/overheating events, and deflagration/explosion events. While explosions are less frequent than fires, they are operationally significant due to responder injuries and the necessity for defensive firefighting strategies.

2. Barrier Degradation Patterns

A central finding is that incidents rarely result from a single catastrophic failure but from the progressive degradation or absence of multiple barriers. Recurring degraded barriers include:

Detection: Delayed or ambiguous identification of abnormal thermal or electrical conditions.
Propagation Control: Ineffective resistance to thermal runaway spreading between modules, racks, or containers.
Ventilation/Deflagration: Inadequate management of gas accumulation, leading to explosion risks.
Suppression: Systems that control visible flames but fail to stop internal heat generation or reignition.
Isolation: Unclear or inaccessible emergency shutdown procedures.
Post-Fire Monitoring: Lack of defined criteria for incident termination and reignition risk management.

3. Emergency Response Interface Limitations

Responders frequently faced significant operational and informational constraints, leading to defensive operational postures. Key limitations included:

Information Gaps: Missing or unclear battery chemistry, state-of-charge (SOC), and system layout data.
Access Restrictions: Inability to safely enter containers or rooms due to explosion risks or smoke.
Uncertainty: Lack of visibility into internal module status and uncertainty regarding re-entry timing.
Coordination: Delays in accessing specialist technical support or manufacturer data during the incident.

4. Community Exposure

Community exposure is a frequent and significant consequence, even when direct casualties are limited. Incidents often trigger precautionary evacuations, shelter-in-place orders, road closures, and extensive air quality monitoring. The study highlights that large-scale BESS events (e.g., Moss Landing, McMicken) can evolve into regional public health and environmental communication issues, necessitating pre-defined plume monitoring and communication protocols.

5. Deep-Dive Case Insights

Analysis of the 25 deep-dive cases (including McMicken, Moss Landing, and Victorian Big Battery) confirmed that escalation pathways are often coupled: abnormal conditions $\rightarrow$ delayed detection $\rightarrow$ gas accumulation $\rightarrow$ propagation $\rightarrow$ suppression limitations $\rightarrow$ prolonged monitoring. These cases underscored that emergency response effectiveness is heavily dependent on pre-incident coordination and the availability of technical information.

Significance and Proposed Framework

The paper argues that BESS fire safety engineering must shift from a "suppression-centered" logic to a broader system-performance approach. The significance of this work lies in its proposal of a Fire Safety Engineering Framework that links four elements:

Incident Scenario: (e.g., thermal runaway, explosion).
Barrier Degradation: (e.g., delayed detection, overwhelmed suppression).
Emergency Response Interface: (e.g., responder access, information availability).
Derived Safety Requirements: (e.g., multi-parameter detection, defensive firefighting provisions, community exposure thresholds).

The study concludes that safety requirements should be derived from incident learning to address degraded conditions and emergency interfaces. It advocates for stronger requirements in codes and permitting processes, emphasizing that BESS approval should be based on incident scenario performance and system-level resilience, not just component certification. The findings support the integration of community exposure management into the design and permitting stages, treating public safety as an intrinsic engineering requirement rather than a secondary emergency management issue.