Difference between revisions of "BESS Failure Incident Database"

From EPRI Storage Wiki
Jump to navigation Jump to search
Tag: Manual revert
 
(56 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:BESS Failure Incident Database}}
<div class="responsivediv">
<div class="responsivediv">
[[File:Fire Safety Supplemental.PNG|right|class=responsiveimg]]
[[File:Fire Safety Supplemental.PNG|right|class=responsiveimg]]
</div>
</div>
=About EPRI's Battery Energy Storage System Failure Incident Database=
The database compiles information about stationary battery energy storage system (BESS) failure incidents. There are two tables in this database:
* Stationary Energy Storage Failure Incidents – this table tracks utility-scale and commercial and industrial (C&I) failures.
* Other Storage Failure Incidents – this table tracks incidents that do not fit the criteria for the first table. This could include failures involving the manufacturing, transportation, storage, and recycling of energy storage. 
Residential energy storage system failures are not currently tracked.
If you would like to be notified when a new event is added to this database or are interested in other EPRI energy storage safety research resources and opportunities please reach out to [mailto:Storage-Safety@epri.com Storage-Safety@epri.com]. For more information on energy storage safety, visit the [https://storagewiki.epri.com/index.php/Storage_Safety Storage Safety Wiki Page]. 
==About the BESS Failure Incident Database==
The BESS Failure Incident Database<ref>This database was formerly known as the BESS Failure Event Database. It has been renamed to the BESS Failure Incident Database to align with language used by the emergency response community. An ‘incident’ according to the Federal Emergency Management Agency (FEMA) is an occurrence, natural or man-made, that requires an emergency response to protect life or property, while an ‘event’ is a planned, non-emergency activity. The use of incident is prevalent, for example, in referring to the Incident Command, or Incident Command System used by public and private agencies to coordinate incident management operations. See
https://www.fema.gov/pdf/emergency/nrf/nrf-glossary.pdf</ref> was initiated in 2021 as part of a wider suite of BESS safety research after the concentration of lithium ion BESS fires in South Korea and the Surprise, AZ, incident in the US. The database was created to inform energy storage industry stakeholders and the public on BESS failures.
Tracking information about systems that have experienced an incident, including age, manufacturer, chemistry, and application, could inform R&D actions taken by the industry to improve storage safety. The focus of the database is on incidents that had a wider public health and safety impact, rather than on operational failures. Some helpful definitions follow:
* BESS: A stationary energy storage system using battery technology. The focus of the database is on lithium ion technologies, but other battery technology failure incidents are included.
* Failure incident: An occurrence caused by a BESS system or component failure which resulted in increased safety risk. For lithium ion BESS, this is typically a thermal risk such as fire or explosion.
* Utility-scale: This refers to systems and projects that are interconnected to the grid.
* C&I: This includes systems and projects that are behind-the-meter installations. Residential system failures are not currently tracked. Note that the Stationary Energy Storage Failure Incidents table tracks both utility-scale and C&I system failures.
==The Data in Context==
[[File:Failure Deployment graph.png|450px|right]]
It is instructive to compare the number of failure incidents over time against the deployment of BESS. The graph to the right looks at the failure rate per cumulative deployed capacity, up to 12/31/2023. The global installed capacity of utility-scale BESS has dramatically increased over the last five years. While failure incidents continue to occur, the overall rate of incidents has sharply decreased, as lessons learned from early failures have been incorporated into the latest designs and best practices.
The battery industry continues to engage in R&D activities to improve risk reduction measures.
==Root Cause Categorization==
The database includes the cause of failure for each incident, where available. EPRI, TWAICE, and the Pacific Northwest National Laboratory (PNNL) collaborated on an effort to classify the root cause of each incident in the database. The team used the best available information to categorize root cause (e.g., design; manufacturing; integration, assembly & construction; operation; or combination thereof) and the physical location of failure (e.g., cell/module, controls, balance-of-system equipment) to broadly classify the incidents for later comparison and contrast. These are based on technical details in the publicly available reporting, personal communications with entities involved and engineering judgement by industry experts. The published report [https://www.epri.com/research/products/000000003002030360 Insights from EPRI’s Battery Energy Storage Systems (BESS) Failure Incident Database: Analysis of Failure Root Cause] contains the methodology and results of this root cause analysis.
==Database Methodology==
The information in this database is gathered from media reports and other public documents, such as released root cause analyses (RCA) or corporate press releases. Source documents are identified by active searching of global English-language media, and passive collection of reports through keyword flagging on internet websites and RSS feeds. Crowdsourced information that can be verified through publicly available documentation is also incorporated.
All linked citations have been downloaded (or subsequently re-located on InternetArchive or WayBackMachine after removal), to preserve the available information from each incident.
The database was begun in 2021, though it includes incidents as far back as 2011. EPRI engages in every effort to ensure that the information in the database is complete and accurate. Outside of online media, EPRI has used academic publications and collaborated with other organizations tracking failures to ensure all known incidents are captured. However, many incidents are not reported in news media, especially before 2018-19 when there was a renewed industry focus on safety. EPRI cannot guarantee that the database captures every relevant BESS failure incident, nor can we guarantee that all project data related to an incident is captured. If you are aware of missing data, please contact our [mailto:Storage-Safety@epri.com Storage-Safety@epri.com].
Once an incident is identified, EPRI reaches out to involved parties for interviews whenever possible, and then links to formal reports released by any investigative entities once they are published. EPRI is also occasionally involved in RCAs or technical evaluations of incidents directly. For example, EPRI provided technical support for the investigation of the [https://storagewiki.epri.com/index.php/Failure_Event_-_UK,_Liverpool_-_15_Sep_2020 Carnegie Road, UK incident] in 2020, and published a [https://www.epri.com/research/products/000000003002026396 report] on the findings.
The included incidents are intended to reflect global activity. As of January 2024 for example, 2 from China and 2 from Taiwan, 9 from Europe, and tens of incidents from South Korea, including 4 in 2022, are currently included. However, the database is necessarily limited to public reporting, and may have missed incidents with minimal or local-only media coverage. Our automated alerts may not capture local language sources, which is why we engage in outreach and publicizing of the database. EPRI has reports from several recent incidents in Taiwan and South Korea that use local language sources and have paid to get translations where applicable. Substantial time has been spent to make sure incident information is accurate, and EPRI continues to corroborate incidents using other sources and update incidents (both new and old) regularly.
==Database Citation==
You are welcome and encouraged to use this database and cite it; the preferred format is below:


This is a public resource for documenting publicly-available data on battery energy storage failure events from around the world. All information included is available in the linked public documents. If there is a public event that is not included in the BESS Fire Event Database, please email the relevant information and link to supporting info to our [mailto:Storage-Safety@epri.com Storage Safety email].  
EPRI BESS Failure Incident Database. Accessed MM/DD/YYYY. https://storagewiki.epri.com/index.php/BESS_Failure_Incident_Database.  


If you would like to be notified when a new event is added to this database or are interested in other EPRI energy storage safety research resources and opportunities please reach out to our [mailto:Storage-Safety@epri.com Storage Safety email].  
If the database is the centerpiece of an analysis, we request that you reach out to EPRI at [mailto:Storage-Safety@epri.com Storage-Safety@epri.com] for review of the data application. We have a wealth of information on many [https://storagewiki.epri.com/index.php/Storage_Safety BESS safety topics] that can bolster your study and provide needed context. We are also tracking applications of the database to solicit continued EPRI support for maintenance. If you find this useful, please let us know!


=Stationary Energy Storage Failure Events=
=Stationary Energy Storage Failure Incidents=
This table tracks utility and C&I scale energy storage failure events with publicly available information.
This table tracks utility and C&I scale energy storage failure incidents with publicly available information.  
* [https://storagewiki.epri.com/resources/assets/BESS_Failure_Database/Failure_DB_List.csv Click here to download a csv version of the data in this table.]


:''Note: Missing values in this table reflect unknowns.''
''Note: Missing values in this table reflect unknowns.''
{{#ask:
{{#ask:
  [[Category:Failure Event]]
  [[Category:Failure Event]]
Line 41: Line 99:
</html>
</html>


=Other Energy Storage Failure Events=
=Other Energy Storage Failure Incidents=
This table tracks other energy storage failure events for scenarios that do not fit the criteria of the table above. This could include energy storage failures in settings like electric transportation, recycling, manufacturing, etc.  
This table tracks other energy storage failure incidents for scenarios that do not fit the criteria of the table above. This could include energy storage failures in settings like electric transportation, recycling, manufacturing, etc.  


:''Note: Missing values in this table reflect unknowns.''
:''Note: Missing values in this table reflect unknowns.''
Line 65: Line 123:
  |headers=show
  |headers=show
}}
}}
----
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-07-18 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-07-18 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-07-19 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-07-19 -->
Line 76: Line 137:
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-09-20 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-09-20 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-09-20 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-09-20 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-09-20 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-04 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-04 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-06 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-18 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-18 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-24 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-24 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-24 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-30 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-30 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-31 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-31 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-31 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-31 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-10-31 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-11-01 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-11-01 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-11-07 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-12-11 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-12-11 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2023-12-11 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-15 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-15 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-15 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-15 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-15 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-16 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-01-16 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-02-27 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-04-10 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-04-26 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-04-26 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-06 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-06 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-06 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-06 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-06 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-16 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-16 -->
<!-- This is an automated comment to force the "last edited" timestamp to update. Feel free to delete these! - 2024-05-16 -->

Latest revision as of 18:16, 26 August 2024


Fire Safety Supplemental.PNG

About EPRI's Battery Energy Storage System Failure Incident Database

The database compiles information about stationary battery energy storage system (BESS) failure incidents. There are two tables in this database:

  • Stationary Energy Storage Failure Incidents – this table tracks utility-scale and commercial and industrial (C&I) failures.
  • Other Storage Failure Incidents – this table tracks incidents that do not fit the criteria for the first table. This could include failures involving the manufacturing, transportation, storage, and recycling of energy storage.

Residential energy storage system failures are not currently tracked.

If you would like to be notified when a new event is added to this database or are interested in other EPRI energy storage safety research resources and opportunities please reach out to Storage-Safety@epri.com. For more information on energy storage safety, visit the Storage Safety Wiki Page.

About the BESS Failure Incident Database

The BESS Failure Incident Database[1] was initiated in 2021 as part of a wider suite of BESS safety research after the concentration of lithium ion BESS fires in South Korea and the Surprise, AZ, incident in the US. The database was created to inform energy storage industry stakeholders and the public on BESS failures.

Tracking information about systems that have experienced an incident, including age, manufacturer, chemistry, and application, could inform R&D actions taken by the industry to improve storage safety. The focus of the database is on incidents that had a wider public health and safety impact, rather than on operational failures. Some helpful definitions follow:

  • BESS: A stationary energy storage system using battery technology. The focus of the database is on lithium ion technologies, but other battery technology failure incidents are included.
  • Failure incident: An occurrence caused by a BESS system or component failure which resulted in increased safety risk. For lithium ion BESS, this is typically a thermal risk such as fire or explosion.
  • Utility-scale: This refers to systems and projects that are interconnected to the grid.
  • C&I: This includes systems and projects that are behind-the-meter installations. Residential system failures are not currently tracked. Note that the Stationary Energy Storage Failure Incidents table tracks both utility-scale and C&I system failures.

The Data in Context

Failure Deployment graph.png

It is instructive to compare the number of failure incidents over time against the deployment of BESS. The graph to the right looks at the failure rate per cumulative deployed capacity, up to 12/31/2023. The global installed capacity of utility-scale BESS has dramatically increased over the last five years. While failure incidents continue to occur, the overall rate of incidents has sharply decreased, as lessons learned from early failures have been incorporated into the latest designs and best practices.

The battery industry continues to engage in R&D activities to improve risk reduction measures.








Root Cause Categorization

The database includes the cause of failure for each incident, where available. EPRI, TWAICE, and the Pacific Northwest National Laboratory (PNNL) collaborated on an effort to classify the root cause of each incident in the database. The team used the best available information to categorize root cause (e.g., design; manufacturing; integration, assembly & construction; operation; or combination thereof) and the physical location of failure (e.g., cell/module, controls, balance-of-system equipment) to broadly classify the incidents for later comparison and contrast. These are based on technical details in the publicly available reporting, personal communications with entities involved and engineering judgement by industry experts. The published report Insights from EPRI’s Battery Energy Storage Systems (BESS) Failure Incident Database: Analysis of Failure Root Cause contains the methodology and results of this root cause analysis.

Database Methodology

The information in this database is gathered from media reports and other public documents, such as released root cause analyses (RCA) or corporate press releases. Source documents are identified by active searching of global English-language media, and passive collection of reports through keyword flagging on internet websites and RSS feeds. Crowdsourced information that can be verified through publicly available documentation is also incorporated.

All linked citations have been downloaded (or subsequently re-located on InternetArchive or WayBackMachine after removal), to preserve the available information from each incident.

The database was begun in 2021, though it includes incidents as far back as 2011. EPRI engages in every effort to ensure that the information in the database is complete and accurate. Outside of online media, EPRI has used academic publications and collaborated with other organizations tracking failures to ensure all known incidents are captured. However, many incidents are not reported in news media, especially before 2018-19 when there was a renewed industry focus on safety. EPRI cannot guarantee that the database captures every relevant BESS failure incident, nor can we guarantee that all project data related to an incident is captured. If you are aware of missing data, please contact our Storage-Safety@epri.com.

Once an incident is identified, EPRI reaches out to involved parties for interviews whenever possible, and then links to formal reports released by any investigative entities once they are published. EPRI is also occasionally involved in RCAs or technical evaluations of incidents directly. For example, EPRI provided technical support for the investigation of the Carnegie Road, UK incident in 2020, and published a report on the findings.

The included incidents are intended to reflect global activity. As of January 2024 for example, 2 from China and 2 from Taiwan, 9 from Europe, and tens of incidents from South Korea, including 4 in 2022, are currently included. However, the database is necessarily limited to public reporting, and may have missed incidents with minimal or local-only media coverage. Our automated alerts may not capture local language sources, which is why we engage in outreach and publicizing of the database. EPRI has reports from several recent incidents in Taiwan and South Korea that use local language sources and have paid to get translations where applicable. Substantial time has been spent to make sure incident information is accurate, and EPRI continues to corroborate incidents using other sources and update incidents (both new and old) regularly.

Database Citation

You are welcome and encouraged to use this database and cite it; the preferred format is below:

EPRI BESS Failure Incident Database. Accessed MM/DD/YYYY. https://storagewiki.epri.com/index.php/BESS_Failure_Incident_Database.

If the database is the centerpiece of an analysis, we request that you reach out to EPRI at Storage-Safety@epri.com for review of the data application. We have a wealth of information on many BESS safety topics that can bolster your study and provide needed context. We are also tracking applications of the database to solicit continued EPRI support for maintenance. If you find this useful, please let us know!

Stationary Energy Storage Failure Incidents

This table tracks utility and C&I scale energy storage failure incidents with publicly available information.

Note: Missing values in this table reflect unknowns.


Figure 1. A breakdown of the stationary energy storage failure events from the above table.

Other Energy Storage Failure Incidents

This table tracks other energy storage failure incidents for scenarios that do not fit the criteria of the table above. This could include energy storage failures in settings like electric transportation, recycling, manufacturing, etc.

Note: Missing values in this table reflect unknowns.


  1. ↑ This database was formerly known as the BESS Failure Event Database. It has been renamed to the BESS Failure Incident Database to align with language used by the emergency response community. An ‘incident’ according to the Federal Emergency Management Agency (FEMA) is an occurrence, natural or man-made, that requires an emergency response to protect life or property, while an ‘event’ is a planned, non-emergency activity. The use of incident is prevalent, for example, in referring to the Incident Command, or Incident Command System used by public and private agencies to coordinate incident management operations. See https://www.fema.gov/pdf/emergency/nrf/nrf-glossary.pdf
Retrieved from "https://storagewiki.epri.com/index.php?title=BESS_Failure_Incident_Database&oldid=5193"