IEEE Power & Energy Magazine - November/December 2020 - 95

methodology is valuable in the development of new, complex
systems. STPA is conducted in four parts:
1) Identify the accidents and hazards to be prevented in
the system.
2) Draw all the control structures in the system.
3) Determine unsafe control actions.
4) Identify causal scenarios, i.e., linkages, between faults.
This fourth step can lead to the relevant indicators for predictive maintenance. Rosewater and Williams in the "For
Further Reading" section provide a more detailed explanation
of this process.
Different companies prefer different methodologies during
the system-design phase. In the previous section, we provided
a few examples rather than recommending a specific approach.
Many methodologies are rooted in the (appropriate) foundation
of protecting human safety, with hazard-mitigation responses
that tend to render the system unrecoverable. Predictive monitoring accepts that faults may occur through degradation
due to long-term operation or from the impact of an external
issue that may damage a component. Predictive maintenance
requires identifying the cascading chain of faults that leads to
failure and specifying which faults are recoverable.

Identifying Indicator-Fault Relationships
Using Data Analytics on Fielded Systems
The second layer of identifying indicator-fault relationships for
predictive maintenance involves using field data. During the
design phase, developers evaluate the system based on institutional or historical knowledge; however, they may not be aware
of everything they need to consider. With data analytics, the
goal is to process field data and examine them from different
perspectives to identify new relationships. The original system
design may not have coverage of all the necessary signals, so
a developer may need to integrate different data sets to understand what is going wrong. Once a developer identifies a new
indicator-fault relationship from the postprocessing of field
data, it becomes another signal to respond to in real time.

Figure 4 offers a case study for developing such a predictive maintenance approach from system integrator NEC
Energy Solutions. The company first used FMEA during the
system-design phase to identify critical components and failure
pathways and determine data needs. Their cloud infrastructure enables data collection and storage from BESSs deployed
around the world. Historical data from all the sites are used in
predictive-analytics algorithms. One algorithm, used to identify
anomalies in battery modules, parses historical data from each
rack for a site and associates indicators in the rack data (e.g.,
cell voltages, current, battery capacity, and operation hours)
with system operations. These anomalies represent recoverable issues that could potentially lead to nonrecoverable faults.
Examples include capacity degradation or a cell short circuit/
thermal runaway that causes a system fire hazard (to date, NEC
installations have not experienced any catastrophic events or fire
hazards). Notifications about this anomalous behavior prompt
further analysis to remove any false positives. If the engineers
identify a real anomaly, they place the offending battery rack
out of service until the module is replaced. In summary, predictive maintenance has allowed NEC to identify misbehaving
battery modules before they trigger safety hazards, negatively
impact system availability, or reduce system capacity. The
approach has also led to a reduction in maintenance costs by
allowing the service team to plan visits more efficiently in each
geographic region.

Opportunities for Collaboration in
Identifying Indicator-Fault Relationships
Because the goal of predictive maintenance is to reduce
catastrophic outages of ESSs and improve safety, the tools
for the process must be available to all BESS operators. The
most critical asset is a comprehensive list of indicator-fault
relationships. System integrators can identify some of these
relationships during the system-design phase; however,
substantial data sets for further analytics are not broadly
available. In some cases, these data may be considered

table 4. An excerpt from a conventional, safety-focused FMEA for a BESS.
System or
Component

Failure Mode

Hazard
Effect

Consequence

Prevent

Detect

Probability;
Severity

Value
for Risk

BMS

System does not operate Fire
safely through normally
expected temperature
operating range

Safety incident BMS testing

Independent
temperature
sensor

3; 10

Battery cell

Group of failures

Fire

Safety incident Abuse testing

Fire alarm

3; 9

Battery
pack

Group of failures

Fire

Safety incident Abuse testing

Fire alarm

2; 10

BMS

Battery damage due to
BMS malfunction

Fire or loss of Safety incident Fusing, inverter EMS fault on
functionality
protection
BMS behavior

2; 7

Inverter

Inverter fails to detect/
Loss of
react to overtemperature functionality
in insulated-gate bipolar
transistors

EMS fault
3; 4
on inverter
temperature rise
or inverter fault

november/december 2020

Power output
derating

Reliance on
supplier

ieee power & energy magazine

IEEE Power & Energy Magazine - November/December 2020

Table of Contents for the Digital Edition of IEEE Power & Energy Magazine - November/December 2020