System Safety and ISO 26262 Compliance for Automotive Lithium-Ion Batteries

William Taylor, Gokul Krithivasan, and Jody J. Nelson kVA

Greenville, SC USA bill.taylor@kvausa.com

Abstract—Lithium ion batteries pave the way for today’s plug-in hybrid and electric vehicles. However, these batteries contain the potential of thermal runaway, posing a higher safety risk from thermal incidences than NiMH batteries. Thermal runaway can be mitigated using electronic control systems, which are intended to maintain a safe state of the battery under all operating conditions. When safety depends on these control systems, any malfunction of the system or its elements (such as sensors, microcontrollers, contactors, software, etc.) may lead to a dangerous state. The newly published ISO 26262 standard provides processes and methods for the proper design, development and manufacturing of E/E automotive systems to ensure functional safety. In this paper, the ISO 26262 standard is applied to several example scenarios involving lithium-ion batteries for plug-in vehicles. Key concepts are explored and conclusions drawn regarding several of the standard’s required processes, including hazard analysis and risk assessment, functional safety concept, functional safety and technical safety requirements, and related topics.

Keywords- Battery management systems; Electric vehicles; Product safety; Vehicle safety

I. INTRODUCTION Lithium-ion (Li-ion) batteries are becoming the most

common electrical energy storage device used for electrical propulsion today. They hold twice as much energy as their predecessor, nickel based battery technologies, and nearly four times that of a lead acid battery. The technology is strengthened by its low maintenance, low self-discharge and environment-friendliness.

The groundbreaking work for lithium-based battery technology began under G. N. Lewis in 1912 [1], but only recently have they become the technology of choice for plug-in vehicles [2]. Today, Li-ion based traction batteries for plug-in electric vehicles are undergoing continual technological development. Improvements in energy density, long-term durability, and cost reduction activities are some of the key drivers of technology investment [3,4,5]. With these improvements under development in the laboratory, and a growing market for plug-in vehicles, the Li-ion market is forecasted to grow into a multi-billion dollar market in coming years [6].

With all new and evolving technologies, safety takes a particular significance and must be considered from the beginning. Some key safety hazards of a Li-ion battery during operation include fire, explosion, heat and smoke. Some of the

unsafe events that could lead to these hazards are over-charging, over-discharging, over temperature, intrusion of metallic dust (e.g., in the manufacturing process), and mechanical damage. In the context of electric vehicles that employ traction batteries made with Li-ion technology, these hazards are a major safety concern. Several standards are employed for the safety of battery systems in hybrid, plug-in hybrid and electric vehicles including ISO 12405, ISO 6469, SAE J2929, SAE J246, SAE J2380, SAE J2289 and SAE J1766 safety standards. However, these standards typically consider safety of battery packs and construction and are not generally meant to address the risk of electronic malfunction of the battery controller or vehicle system. The recently published ISO 26262 standard, which addresses functional safety in E/E systems for passenger cars, is meant to bridge this gap and ensure the system safety of passenger vehicles in general, including plug-in vehicles equipped with large-scale battery packs [7].

II. ISO 26262 FOR AUTOMOTIVE FUNCTIONAL SAFETY ISO 26262 addresses the possible hazards caused by the

malfunctioning behavior of all electrical and electronic related systems in the vehicle, including their interaction. The standard is general in nature, and applies to a range of hazards arising from electronic malfunction of vehicle systems. Most active systems, such as steer-by-wire, brake-by-wire, airbag, throttle control, and many other systems are subject to the standard. However, ISO 26262 does not directly address hazards such as electric shock, fire, smoke, corrosion, toxicity, and similar hazards, unless the hazard is caused by malfunctioning behavior of E/E safety- related systems.

In the case of a high voltage battery storage system in a vehicle, there are multiple opportunities for E/E system malfunctions to create hazardous situations. For example, failure of the hardware electronics controlling the battery contactors may lead the contactors to fail closed, thereby disabling a fail-safe thermal protection mechanism. This could result in potentially dangerous temperatures and conditions for the Li-ion cells. Such a failure may also be the result of a systematic software failure, either in the battery management system (BMS) or a related control system such as an onboard charger or powertrain inverter. Note that the ISO 26262 standard addresses both hardware and software failures. It also addresses systematic and random hardware failures. Fig. 1

978-1-4673-1033-8/12/$31.00 ©2012 IEEE

illustrates several malfunctions of an autstorage system that come under the scope of IS

This paper applies the necessary steps anprescribed by ISO 26262 to the development large-format Li-ion battery pack for automapplications. Specifically, system-level cocontained in Part 3 (Concept phase) and development at the system level) are develsome additional insights from other parts of 26262 standard.

Fig. 1. Overview of the need for ISO 26262 in a batte

III. ISO 26262 APPLICATION FOR AUTOMOION BATTERIES

ISO 26262 assigns a list of requireengineering development process. The paper ion battery based examples for a subrequirements and work products. Each topic wusing specific examples typical of battery syvehicles. By illustrating these critical proceduby ISO 26262, the paper will provide usefinsight to safety engineers with responsibivehicles and battery packs.

A. Item Definition (ISO 26262 Part 3, ClauseTo begin the development process accor

26262 standard, the item being developed mThis step clarifies the boundaries of the produand documents preliminary assumptions aboutand functionality of the system. The ISO 262several aspects of item definition; for exampelements within the item, the interfaces betwits environment, and the functionality ofelements. Note that ISO 26262 specifies thasystem “to which ISO 26262 is applied.” By d

tomotive battery SO 26262. nd procedures as of a hypothetical

motive powertrain onsiderations as Part 4 (Product loped here, with the ten-part ISO

ery storage system.

OTIVE LITHIUM-

ements for the will provide Li-

bset of critical will be addressed ystems in plug-in ures as prescribed ful guidance and ility for plug-in

e 5) rding to the ISO must be defined. uct development,

ut the components 262 standard lists le describing the

ween the item and f the item and at an “item” is a defining the item,

the scope of the development is deion battery and BMS in the carchitecture for a plug-in electrical v

Fig. 2. Typical powertrain system archvehicles showing the relationship of the

(BMS) to the pow

To define the item of a hypothetwo supporting methods are emplodiagram can be developed, showinthe battery. This diagram is dearchitecture, a part of the item definNote that this preliminary architecone simplified configuration that ithe concept. This will be the case fothroughout the paper, as this hydeveloped. In this, the paper followISO 26262’s Safety Element omethodology.

In this example, the battery syfollowing main elements:

• battery cells C1 through Ccells are connected in seriesuitable for powering automare used for illustration purhigh voltage battery systemcells, arranged in a combinarrangements. Each batteryfor cell voltage, temperasignals run to the battelectronic control unit, or B

• BMS ECU – this is the maiand is responsible for mohealth, balancing cell-to-celcontrolling the main conta

efined. Fig. 2 shows the Li-ontext of the powertrain vehicle.

hitecture for plug-in electrical Battery Management System

wertrain.

etical Li-ion battery system, oyed. First, a simple block ng the key elements within efined as the preliminary nition. It is shown in Fig. 3. cture is just an example of is provided to demonstrate or all methods and analyses ypothetical item is further ws a process similar to the out of Context (SEooC)

ystem is comprised of the

C6 – these electrochemical es to achieve high voltages motive drive loads. Six cells rposes. A production intent

m would contain many more nation of series and parallel y cell has internal sensors ature, and current. These tery management system MS ECU. n controller for the battery,

onitoring battery state and ll variation in voltages, and

actor module that connects

the battery pack to the high voltage direct-current (HVDC) bus. It includes two elements: o the sensor signal processor, electronic hardware

that converts analog sensor signals from battery cells into digital data and provides digital sensor signals to the battery controller

o the battery controller, a processor that performs the BMS functions, including voltage balancing between cells, state-of-charge (SOC) and state of health (SOH) monitoring, and actuation of the main contactor(s) between the battery and HVDC bus.

• cell balance interconnect module – this electronic module is a network of FETs and passive components that actively balance voltage between and among cells. This module can be configured in various ways; however it is not a focus of this paper.

• HV contactor module – this actuator connects the battery to the HVDC bus when closed, and isolates the battery from the HVDC bus when opened. It is a module which may include sensors and/or redundant contactor switches, depending on the needs of the system.

Fig. 3. Preliminary architecture of the hypothetical Li-ion battery

system.

Interfaces are an important part of the item definition. In this case, two primary interfaces are described:

• The HVDC bus; • The powertrain CAN, or other communication, bus

that provides powertrain and vehicle information to

the battery system, and also uses battery system information to help control the vehicle.

These interfaces are shown as an example. Item definition should specify these interfaces as clearly as possible; e.g., with the voltage level and power capability of the HVDC bus, the CAN protocol, the specific signal information, etc.

To describe the functionality of the item, a list of the key functions and malfunctions of the battery system are described. These functions are critical to the understanding of the item, what it does, and what the item does not do. In this case note that while the battery provides and accepts power, to and from the HVDC bus, the power flow is not actively controlled by the battery system. The current flowing to and from the HVDC bus will be determined, at any given time, by the powertrain controller, battery charger and power inverters. However, flow of power can be enabled or disabled using the main contactor which, when closed, makes the electrical connection between the battery system and the HVDC bus. The battery also limits cell temperatures by monitoring current, voltage and temperature, and engaging interconnect circuits based on either passive or active measures [8,9].

Note that along with functions, additionally malfunctions are specified at this stage. Defining specific malfunctions is a critical step in understanding the following stages of ISO 26262. A summary of functions and malfunctions for the battery system is shown in Fig. 4.

Fig. 4. List of some functions and malfunctions of the hypothetical Li-ion

battery system.

B. HARA - Hazard Analysis and Risk Assessment (ISO 26262 Part 3, Clause 7) The Hazard Analysis and Risk Assessment (HARA) is a

critical feature defined early within the ISO 26262 standard. The HARA process defined within the standard is driven by four key activities:

• Identifying potential hazards associated with E/E system malfunction. These are to be defined at the vehicle level and not the item level; although they may

FUNCTION F001 Provide Power to HVDC Bus

malfunction mf001power not provided to HVDC bus when required

malfunction mf002 unintended power delivery to HVDC bus

FUNCTION F002 Accept Power from HVDC Bus

malfunction mf003Power from HVDC bus not accepted as required

malfunction mf004Charging of battery pack beyond allowable energy storage

malfunction mf005Charging of battery pack beyond allowable current

FUNCTION F003 Limit Cell Temperatures

malfunction mf006cell overtemperature due to internal short

malfunction mf007cell overtemperature due to thermal management failure

malfunction mf008cell overtemperature due to overcurrent

be a direct result of item level malfunctions. It is helpful, though not required, to specify the item level malfunction that would cause the identified hazard.

• Determining the Severity Rating (S) associated with the hazard. The severity rating is meant to reflect the severity of the hazard, based on its likely impact to human injury or fatality. The rating is made on a scale from 0 to 3, with S0 reflecting a hazard that will not cause injury or harm, and S3 reflecting a hazard that will likely cause severe injury or a fatality.

• Determining the Exposure Rating (E) associated with the hazard. The exposure rating reflects the probability of the vehicle operating under conditions when the hazardous event may occur. Note this is not the probability of the E/E fault which leads to the failure. The rating is made on a scale of E0 to E4, with E0 reflecting conditions that are never seen or seen only in extreme cases by vehicles, and E4 reflecting conditions seen by the majority of drivers in nearly every drive cycle.

• Determining the Controllability (C) associated with the hazard. The controllability rating reflects the relative ability of a driver to control (and thereby mitigate) the hazardous situation if it occurs. The rating is made on a scale from C0 to C3, with C0 reflecting a case where the great majority of drivers could bring the situation under control, and C3 reflecting a situation where the driver would be highly unlikely to bring the situation under control.

The three underlying ratings, S, E and C are the sole determinants of the ASIL of the hazard. Every hazard is assigned an ASIL rating of A, B, C or D; or alternately noted as a “QM”, which is addressed simply through quality management processes and not formally addressed by ISO 26262 requirements. In the example case considered here, only a limited subset of potential hazards are considered. A full HARA considering all potential hazards would likely contain hundreds of lines. The example HARA is shown in Fig. 5.

Note in Fig. 5 that similar hazards are listed repeatedly for different operating conditions. In the example shown, the controllability of the fire hazard depends on the ability of the driver to stop the vehicle quickly in a safe location and to exit the car, along with the passengers. This in turn is dependent on the vehicle speed. Therefore, variants of the hazard are captured as separate lines in the HARA, and each is ultimately assigned a different ASIL in this illustration.

For each ASIL-rated hazard, a safety goal is applied. The safety goal is often phrased as the opposite of the hazard. Safety goals become the highest level safety requirement in the ISO 26262 standard, from which other safety requirements are derived. In this simplified battery example, three safety goals are proposed:

• Battery overcharging shall be prevented. • Battery overcurrent shall be prevented. • Battery over-temperature shall be prevented.

Focus in this paper will be on the first of these, battery overcharging shall be prevented. A full ISO 26262 development process would include all safety goals in a full development process.

Fig. 5. Excerpt from a simplified Hazard Analysis and Risk Assessment

(HARA).

C. Functional Safety Concept (ISO 26262 Part 3, Clause 8) In the words of the ISO 26262 standard, “The functional

safety requirements shall be derived from the safety goals and safe states, taking into account the preliminary architectural assumptions.” These requirements are then allocated to the elements of the preliminary architecture. Each safety goal requires at least one functional safety requirement (FSR) to prevent violation of the safety goal. Note that the requirements still apply at the system, or element, level and are not yet broken down into hardware and software requirements.

In this example, the specification of functional safety requirements is applied to the safety goal “battery overcharging shall be prevented.” If a malfunction led to battery overcharging, then the safety goal would be violated. Fig. 2 and Fig. 3 illustrate two paths to prevent overcharging: the BMS through the contactor and the powertrain controller through control of power transfer to the Li-ion battery. The functional safety concept for this safety goal must derive functional safety requirements (FSR) to address these two system elements. The FSRs contributing to the BMS are as follows:

• “indication of overcharge shall be computed and communicated to the powertrain controller” represents an indication of overcharge calculated by the BMS and communicated to the powertrain controller so that it knows when to stop charging. Current should not be sent to the battery if this limit has been reached and the FSRs for this would then be allocated to the powertrain controller;

• “if overcharge condition is detected, current shall be interrupted within X ms” represents a fallback safety requirement, which reacts to prevent overcharging conditions in the case that the charger, or inverter through regenerative braking, continues to charge the battery even when the condition of the overcharging

vehicle speed malfunction hazard S E C ASIL

<10km/h

charging of battery pack beyond

allowable energy storage

overcharge causes thermal

eventS3 E3 C1 A

>10km/h, <50km/h

charging of battery pack beyond

allowable energy storage

overcharge causes thermal

eventS3 E3 C2 B

>50 km/h

charging of battery pack beyond

allowable energy storage

overcharge causes thermal

eventS3 E3 C3 C

limit has been exceeded. This FSR ECU to protect for overcharge in the these external controllers, or somethinsystem, malfunctions.

D. Allocation of Requirements to Elements (IS3, Clause 8.4.3) After defining the FSRs, each one is alloc

of the preliminary architecture. This allocbriefly in Fig. 6. Critically, when a furequirement carrying an ASIL rating is element, then that element must be designrequirements of that ASIL rating. In thielements contributing to the FSRs include elemECU), element 2 (the HV contactor moduleC1-C6 (the battery cells). For the safety goal the cell balance interconnect circuit is not asrating. Note, however, that this lack ofinterconnect circuit is purely a result of the safety goals. A complete HARA and a compgoals would very likely require a high ASIL rbalance interconnect circuit, as shorts betwcause cell over-temperature and associated the

Fig. 6. FSRs and allocation to elemen

E. Technical Safety Requirements (ISO 26262clause 6) Functional safety requirements are bro

technical safety requirements (TSR), whiassigned to more specific elements in the aprogression is illustrated in Fig. 7. Note that thmaintained through the flow of requiremetechnical safety requirements are also assignecase. This in turn drives specific requiremenassurance requirements of hardware andexample, in ISO 26262 Part 6 (Product devsoftware level) Table 5, independent parallelerror checking in software is “strongly recASIL D software; “recommended” for ASIL

allows the BMS event that one of

ng else within the

SO 26262 Part

cated to elements cation is shown functional safety

allocated to an ned to meet the is example, the ment 1 (the BMS e), and elements considered here,

ssigned an ASIL f ASIL for the simplification of

plete set of safety rating for the cell

ween circuits can ermal events.

nts.

2 Chapter 4,

oken down into ich in turn are architecture. This he ASIL rating is

ents, so that the ed ASIL C in this nts for the safety d software. For velopment at the l redundancy for commended” for L C and ASIL B

software; and no such recommendsoftware. Many similar examplessoftware and hardware safety mprocesses. In some cases decompothe ASIL level by redundantly appoto independent elements.

In the contents of this paper, celbeen determined by the battery mindication of overcharging, to meet the BMS. Therefore the computaSOC, and the required hardware toof the TSRs. The SOC then would of the powertrain controller to previon battery. To comply with the seovercharge is needed and additinterrupt current going into the battwill then be the basis to derive tsafety requirements.

Fig. 7. Development of TSRs based on t

IV. CONCLUSIONS AND R1) The ISO 26262 standard ad

when vehicle E/E systems malfuncbatteries, this includes failures of impact charging and discharging, assystems. Non-E/E factors, such aoutside the scope of ISO 26262 astandards.

2) The HARA is used to derive through the entire lifecycle. Safetythe HARA and serve as the highest

dation is given for ASIL A s can be applied to both

mechanisms and assurance osition is utilized to reduce ointing safety requirements

l state-of-charge (SOC) has manufacturer as the proper

one of the FSR assigned to ation and transmission of support this, becomes part need to be used in the TSR

vent overcharging of the Li-cond FSR, the detection of tionally the capability to tery is required. These TSR the hardware and software

he FSRs allocated to the BMS.

RECOMMENDATIONS ddresses hazards that arise ction. In the case of Li-ion

control systems that may s well as thermal protection s mechanical damage, are and addressed by different

ASIL ratings, which carry y goals are also defined by level requirement.

3) Safety goals apply to overcharge, overcurrent, and temperature limiting for Li-ion batteries. Only overcharge is addressed within this paper; however the methodology established can be applied to all the safety goals.

4) The paper has shown how a HARA is applied to a Li-ion battery pack and establishes the flow, as defined by ISO 26262, from the safety goal down to the technical safety requirements.

5) Future work should focus on implementation of hardware and software to achieve this safety goal, as well as further development of the other two safety goals and a completed HARA.

ACKNOWLEDGEMENTS The authors would like to acknowledge the support and

insights from ikv++ technologies ag. The analysis was supported by their software tool, medini analyze.

REFERENCES [1] Davenport, Derek A., "Gilbert Newton Lewis: 1875 - 1946", J. of Chem

Ed., 1984. [2] C. Pillot, “The battery market for HEV, P-HEV and EV 2010-2020”, the

28th International Battery Seminar and Exhibit, March 2011. [3] Santini, D., Gallagher, K., and Nelson, P, “Modeling of Manufacuring

Costs of Lithium-Ion Batteries for HEVs, PHEVs, and EVs” presented at EVS 25 – The 25th World Battery, Hybrid, and Fuel Cell Electric Vehicle Symposium and Exhibition, , Shenzhen, China, November 2010.

[4] Dinger, A., Martin, R., Mosquet, X., Rabl, M., Rizoulis, D., Russo, M., and Sticher, G, “Batteries for Electric Cars: Challenges, Opportunities, and the Outlook to 2020.” Published by the Boston Consuling Group, 2010.

[5] Axsen, J., Kurani, K, and Burke, A., “Are batteries ready for plug-in hybrid buyers?” Transport Policy 17, ppg 173 – 182, 2010.

[6] Anderman, M. “The 2010 Plug-In Hybrid and Electric Vehicle Opportunity Report” published by Advanced Automotive Batteries, Oregon House, CA, 2010.

[7] ISO 26262:2011, "Road vehicles - Functional safety," International Organisation for Standardisation, first edition.

[8] Evanczuk, S. “Teardown: High-voltage Li-Ion battery stack management - the drive for safe power” EDN Network article, www.edn.com, July 31, 2012.

[9] Peterson, S., Apt, J., and Whitacre, J., “Lithium-ion battery cell degradation resulting from realistic vehicle and vehicle-to-grid utilization” Journal of Power Sources 195, ppg 2385 – 2392, 2010.