Functional Safety Requirements for Battery Management ......2019/09/25  · Functional Safety...

Post on 18-Nov-2020

3 views 0 download

Transcript of Functional Safety Requirements for Battery Management ......2019/09/25  · Functional Safety...

Lithium Balance A/S

Functional Safety Requirements for Battery

Management Systems in Electric cars

Purpose of a Battery Management System

Source: www.mpoweruk.com

• To protect the battery from working outside its safe operating area, SOA

• To monitor the state of the battery and to calculate secondary data (SOC, SOH, etc)

• To report / communicate battery data (To a vehicle control unit / the driver)

• To control the battery environment (initiate/instigate heating/cooling)

• To perform balancing of the cells to maximize the use of the battery

Focus of this presentation:Focus of this presentation:

Safety Purpose of a BMS: To maintain SOA

Source: www.mpoweruk.com

SOASOA

Safe Operating Area

SOA = f(V, T, I)

Short Intro - What is Functional Safety (FS)?

• FS is a characteristic of any system, where failure avoidance/detection is present

• A good FS implementation tries to keep a system w/ failures

going. For instance by applying a “limp home” strategy:

• FS tries at least to detect and inform about it, if an effect of a failure cannot be avoided

1. Detection measure:

2. Avoidance measure:

or

Flat tyre

Airless tyres

Pressure monitoring

ISO 26262 Road vehicles — Functional safety

• 26262 is a standard for handling functional safety of electrical/electronic circuits in cars, i.e. how to avoid/react on system failure – for cars driving on public roads (not for golf carts etc)

• 26262 defines requirements for management, development, production, operation, service, and decommissioning (the whole life cycle)

• 26262 requires that the fulfilment of all requirements are proven (Documented, reviewed, verified/validated)

• 26262 requires that potential failures are analyzed, and risks specified and quantified

• 26262 defines maximum values for error likelihood depending on the potential effect of errors/hazards (Operates with exposure, controllability, and severity): ASIL A to ASIL D (QM)

• 26262 deals with reaction to system failure, whereas the new standard, ISO/PAS 21448: Road Vehicles — Safety of the Intended Functionality (SOTIF) (Jan 2019) Safety of automated vehicles (AV) deals without a (actual) system failure.

ISO 26262 Management of Functional safety

BMS Concept Phase: ITEM Definition (DRAFT)

BMSBMS

BMS Concept Phase: ITEM Definition

BMS Concept Phase: Functional concept

Safety Goal :Safety Goal :Safety Functions Safety Functions

for maintaining SOA for maintaining SOA

(Functional Safety Requirement, FSR) (Functional Safety Requirement, FSR)

Safety support Safety support

Functions (FSR)Functions (FSR)

BMS Concept Phase: SOA Violation Detection/Avoidance

BMS Product Development: H/W and S/W development

(System level)

• Derive technical safety requirements from Functional Concept

• Make system design/architecture

• Define safety mechanisms – for detection/avoidance of failures

• Safety analysis at system level: FMEA (Failure Mode and Effect Analysis), FAT (Fault tree analysis)

BMS Product Development: H/W and S/W development

( FMEA - System level)

BMS Product Development: H/W and S/W development

(FMEA - System level)

BMS Product Development: H/W and S/W development

(Hardware level)

• Derive Hardware Safety requirements and test specfication

• Make detailed hardware design, HW/SW interface specification and test specification

• Safety analysis at hardware level FMEDA (Failure Mode, Effects and Diagnostics Analysis)

• Safety analysis at hardware level, quantitative FTA

• Make DFA (Dependent Failure Analysis)

BMS Product Development: H/W and S/W development

(FTA -Hardware level)

BMS Product Development: H/W and S/W development

(FMEDA prerequisites - Hardware level)

BMS Product Development: H/W and S/W development

(FMEDA - Hardware level)

BMS Product Development: H/W and S/W development

(Software level)

• Derive Software requirements and test specification

• Make detailed software design and unit test

• Prove Freedom from Interference (Between safety critical parts and non safety critical parts)

• Perform qualification of all SW tools (To prove that they are working correctly)

BMS Product Development: H/W and S/W development

(Test and production release)

• Perform Environmental tests

• Perform EMC Tests

• Perform System Integration Test, including Fault Injection (To invoke safety mechanisms)

• PRODUCTION RELEASE!

Summary & conclusion

• The main purpose of a Battery Management System is to maintain operation of the battery

within its safe operating area (SOA).

• To use a Battery Management System for public road vehicles the system must comply with

the requirements of the ISO 26262 standard, which requires:

• All Hazards and risks must be identified and mitigated, and top-down requirements

must be derived from system level to component level

• The Battery Management System must respond to all failures in a well-defined way by

avoidance or detection measures.

• The failure likelihood of the Battery Management System must be quantified and held

below values corresponding to the risk level!