An Introduction to Functional Safety for Electrified ......kVA = engineered safety History of ISO 26262 • IEC 61508 is the basis for ISO 26262, but not specific to Automotive •

An Introduction to Functional Safety for Electrified Powertrains

kVA1708-C Augusta Street, STE 3Greenville, SC [email protected]

copyright kVA, 2016 kVA = engineered safety

Jody J. Nelson, Michael Woon and Agish George

June 27, 2016

kVA = engineered safety

Agenda


Who is kVA?

• kVA is a technical consulting group based in the U.S., focused on functional safety implementation

• kVA focuses primarily on the ISO 26262 and IEC 61508 standards, but also works in other areas such as, ISO 13849, + others in the U.S. and abroad

• kVA has experience in developing production HEV, PHEV, EV and Fuel Cell vehicles including software and hardware development, diagnostics, EMC, HV safety and functional safety

• kVA provides training services, consulting engineering services, audits and assessments, gap analysis, and engineering softwareto enable functional safety for automotive


Training and Certification for Safe Vehicle Design and Development

• kVA has a partnership with TÜV-Nord, a leading German safety organization, to provide functional safety training and certification in the English language.

• kVA staff have all achieved the Functional Safety Certified Automotive Engineer (FSCAE), a designation conferred by TÜV-Nordand recognized internationally.

• kVA trains and certifies the industry in functional safety standards and processes• ISO 26262 • IEC 61508

registered certification stamps for kVA managing partners B. Taylor

and J. Nelson


kVA Delivers ISO 26262 Work Productsand engineering insight to make them relevant

Safety Goals and Safety Requirements

Qualitative Safety Analysis (FTA) Quantitative Safety Analysis

(FMEDA)

Hazard and Risk Analysis (HARA)

Qualitative Safety Analysis (SFMEA)


Introduction to ISO 26262


Safety Standards: Background

• The original designation of “engineer” was driven by safety

• The first role of an engineer was to ensure dangerous equipment (e.g.., boilers, engines) would not fail with catastrophic results

• engineers followed technical standards for safe design of equipment

• Electronic controls in automobiles now perform safety-critical functions

• Engineers must ensure electronic systems do not fail with catastrophic results

• ISO 26262 is the technical standard for safe design of such systems

7


What is ISO 26262?

• ISO 26262 is the state of the art standard for functional safety of E/E systems for passenger vehicles– Strongly intertwined with product development– Strong emphasis on functional safety management– Strong emphasis on the early phases of development– Requires traceability throughout entire lifecycle– Not a reliability standard • failures are allowed...• ...but prevention of a safe state

is not

8


History of ISO 26262

• IEC 61508 is the basis for ISO 26262, but not specific to Automotive

• Ongoing discussions within automotive on functional safety for years

• 2005: approval for New Work Item within ISO

– Working Group 16 (Functional Safety) established under Electrical and electronic equipment (TC22/SC3)

• 2009: Draft version of standard (DIS) available and voting begins

• 2011: Final draft version available (FDIS) for Parts 1 – 9

• 2011: November 15, First edition of ISO 26262 released for Parts 1 – 9

• 2012: August 1, First edition of Part 10 released (not normative)


Future Roadmap

Reference: CTI ‘15, ISO 26262 – Status and Roadmap, Carsten Gebauer

2nd Edition Draft Available 2nd Edition Release Available


Future Roadmap

� New Part 11: Semiconductors (ISO/PAS 19451)o Base failure rateso Dependent failure analysiso Multi-coreo Programmable logic devices (e.g. FPGA)o HW qualification

� New Part 12: Motorcycles (ISO/PAS 19695)o Necessary adaptations for motorcycleso Hazard Analysis and Risk Assessmento Safety Validation

� Inclusion of commercial vehicles� Safety of the intended functionality (SOTIF)� SW Safety Analysis� Security� Modification of the HW metrics

Reference: CTI ‘15, ISO 26262 –Status and Roadmap, Carsten Gebauer

Planned Changes in 2nd Edition (Draft: Dec. ’16; Release: Jan. ‘18)


State of the Art

What does it mean to be State of the Art?• The State of the Art is described in standards by commercial partners

concerning all aspects relevant to safety

• Following the “State of the art” ensures that the creator has fulfilled his obligation to take care

ISO 26262 from a legal perspective:• The international standard ISO 26262 for functional safety, describes the

state of the art in relation to functional safety during the lifecycle of safety-related systems comprised of electrical, electronic and software elements in vehicles weighing under 3,500 kg that provide safety related functions

12


State of the Art

How to adapt to the State of the Art?

� Manufacturers must implement any safety measure, that is:

� Necessary to reduce the residual risk of a product

� Available according to the current State of the Art

� Affordable considering the cost-benefit ratio

� Obligation to apply available solutions, but not to develop new solutions or to press ahead of the State of the Art

Reference: CTi ‘15, Functional safety new questions arise; Andreas Reuter


Legal Aspect: Functional Safety Standards

14

Trials deal with what you did 10 or 15 years ago…

� What can save you are:

� Well defined processes that were followed

� Good documentation

Reference: CTi ‘15, U.S. Legal Issues – Overview and Practical Considerations; Clay Guise



15

Reference: CTi ‘15, Functional safety new questions arise; Andreas Reuter

Product liability puts the burden of proof for acting with due care on the

manufacturer. Therefore manufacturers must be able to

provide evidence by appropriate documentation that they ensured the

safety of its product with due care.



16

Reference: CTi ‘15, U.S. Legal Issues – Overview and Practical Considerations; Clay Guise

How a standard can be used in U.S. Law

– Product meets the standard– Standard applies but it was not met– If standard had been met, product would be “better”– Others do it “better” or “differently”


What does NHTSA say?

Reference: CTi ‘15, NHTSA’s Electronics Reliability – Functional Safety Research; Cem Hatipojlu

Although NHTSA currently hasn’t

used this, they have the

authority to require a

functional safety process

GROW AMERICA Act, SEC. 4105


Scope of ISO 26262

• “ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3500 kg.”– Systems and their components released for production, or systems and

their components already under development prior to the publication date of ISO 26262, are exempted from the scope

– ISO 26262 does not address unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.

18


Scope of ISO 26262

• “ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3500 kg.”

– ISO 26262 addresses possible hazards caused by malfunctioning behavior of E/E safety-related systems, including interaction of these systems. It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behavior of E/E safety-related systems.

– ISO 26262 does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems • e.g.. active and passive safety systems, brake systems, Adaptive Cruise Control

19


The Need for ISO 26262

Source: Lisa Whalen, Making Products and Systems Functionally Safe, 2012 CTi Conference on ISO 26262, Troy, MI

Vehicle’s E/E systems are complex and are growing rapidly

20


The Need for ISO 26262

1 Source: Robert Charette, This Car Runs on Code, IEEE Spectrum, February 2009

F-22 Raptor1.7 Million

F-35 Joint Strike Fighter5.7 Million

Boeing 787 Dreamliner6.5 Million

2009 MB S-Class20 Million1 (radio and navigation only)

~100 Million (today)~70-100 ECUs

~200-300 Million (predicted future)

Complex Vehicle Software Size (lines of code)

21


Structure of ISO 26262Overview of ISO 26262 m

8-5 Interfaces within distributed developments

8-6 Specification and Management of safety requirements

8-7 Configuration Management

8-8 Change Management

8-9 Verification

8-10 Documentation

8-11 Confidence in the use of SW tools

8-12 Qualification of SW Components

8-13 Qualification of HW Components

8-14 Proven in use argument

9-5 Requirements Decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

9-7 Analysis of dependent failures

9-8 Safety analyses

2-5 Overall safety management 2-6 Safety management during the concept phase and the product development 2-7 Safety management after the item’s release for

production

2. Management of functional safety

1. Vocabulary

4. Product development at the system level 7. Production and operation3. Concept phase

5. Product development at the hardware level

6. Product development at the software level

8. Supporting Processes

9. ASIL-oriented and safety-oriented analyses

4-11 Release for production

4-10 Functional safety assessment

4-9 Safety validation

4-8 Item integration and testing

4-5 Initiation of product development at the system level

4-6 Specification of the technical safety requirements

4-7 System design

5-5 Initiation of product development at the hardware level

5-6 Specification of hardware safety requirements

5-7 Hardware design

5-8 Evaluation of the hardware architectural metrics

5-9 Evaluation of the safety goal violations due to random hardware failures

5-10 Hardware integration and testing

3-5 Item definition

3-6 Initiation of the safety lifecycle

3-7 Hazard analysis and risk assessment

3-8 Functional safety concept

7-5 Production

7-6Operation, service (maintenance and repair), and decommissioning

10. Guideline on ISO 26262 22

6-5 Initiation of product development at the software level

6-6 Specification of SW safety requirements

6-7 Software architectural design

6-8 Software unit design and implementation

6-9 Software unit testing

6-10 Software integration and testing

6-11 Verification of software safety requirements


Definitions

kVA = engineered safetykVA i d f t

ISO 26262 Vocabulary

risk � Combination of the probability of occurrence of harm (1.56) and the severity (1.120) of that harm.

tolerable risk � Risk (1.99) which is accepted in a given context based on the current moral concept of society.

24

unreasonable risk � Risk (1.99) judged to be unacceptable in a certain context according to valid societal moral concepts



safety � The absence of unreasonable risk (1.136).

functional safety � Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems.

25

E/E system � System (1.129) that consists of electrical and/or electronic elements (1.32), including programmable electronic elements.



ASIL (Automotive Safety-Integrity-Level) � One of four levels to specify the item's (1.69) or element's (1.32) necessary requirements of ISO26262 and safety measures (1.110) to apply for avoiding an unreasonable residual risk (1.97), with D representing the most stringent and A the least stringent level.”

SI (safety integrity) � Probability that a safety-related system fulfils the required safety functions on demand under all given conditions within a fixed time period.

26


Transitioning to a Safe State

fault tolerant time interval � Time-span in which a fault (1.42) or faults can be present in a system (1.129) before a hazardous event (1.57) occurs.

(alternate: “the time-span in which the vehicle function can be stressed with faults before a hazardous event develops”)

fault reaction time � Time-span from the detection of a fault (1.42) to reaching the safe state (1.102).

eered safety

Fault Fault DetectionPossibleHazard

Normal Operation Safe State

27


ISO 26262 Part 2Safety Management

28

ISO 26262 Part 2:Safety Management

2.5 Overall Safety Management

2.6 Safety Management during the concept phase

and the product development

2.7 Safety Management after

the item’s release for production

• Organization-wide• “Corporate”• Not program specific

• Program Specific• “Product team”• The bulk of specific

steps reside here

• Relatively less demanding


Differences between ICE and xEV


Why are e-Powertrains different?

• Internal combustion engines (ICE) provide drive torque

� Electric powertrains provide drive torque

• ICEs provide braking torque

� Electric powertrains provide braking torque

Are we not the same?


One difference is how we dress…

Safety glasses

Hearing protectionHigh Voltage

rubber gloves


Traditional Powertrain – EGAS

The EGAS monitoring concept provides a standardized approach to safe drive-by-wire control for gasoline and diesel engines

Functions defined by an internal combustion engine (ICE):

- Providing drive torque- Providing braking torque (drag torque of the ICE)

Where the following hazards are identified:

- Unintended acceleration (ASIL B)- Missing acceleration (QM)- Unintended deceleration (QM)- Missing deceleration (QM)


Traditional Powertrain – SAE J2980

SAE has recently published the J2980, Considerations for ISO 26262 ASIL Hazard Classification (May 2015)

Where the following hazards are identified within the example (ranges provided based on specific vehicle):

Providing drive torque:- Unintended acceleration (ASIL B)- Unintended acceleration with pedestrian in

area (ASIL B or ASIL C)- Unintended yaw rate change (QM to ASIL C)- Loss of acceleration (QM)

Providing braking torque:- Unintended deceleration (No ASIL agreed)- Unintended yaw rate change (ASIL B to

ASIL D)


e-Powertrain Drive Torque

Different drive torque capabilities

• Often higher torque capabilities at lower speeds than an ICE

• Can be at each wheel

• Can be belt driven or inside of a transmission

• Can be combined with other power sources

• Can be direct at the wheel

EV

ICETorq

ue

rpm


e-Powertrain Brake Torque

Different brake torque capabilities

Normally electric machines can produce braking torque equal to their drive torque, something not representative of an ICE

Drive Torque

Brake Torque


e-Powertrain Braking Torque in a PM Machine

Speed

Voltage

Torque

Speed

A back-emf voltage, proportional to speed, is generated when uncontrolled. Potential hazards:

- When HV battery contactors are closed, generated voltage can be greater than the battery voltage, thus charging the battery and creating unintentional braking torque

Uncontrolled generation can be from:- Loss of gate drivers (power supply)- Broken IGBT/Power Switch- …

Commonly a three-phase short (3PS) is used as a safe state, however, at low speed there will be a spike of higher braking torque

Different brake torque situations


High Voltage Hazards

Bodily Effect dc Current [mA]

Feeling Sensation 1.0

Pain is Felt 62

“Let-Go” Threshold 76

Severe Pain; Breathing Difficulties 90

Heart Fibrillation Occurs 500

Why is HV safety stressed so much?

A number of factors influence the human body resistance, but IEC has provided 1 kΩ as an

average value.

12 mA @ 12 V

300 mA @ 300 V

http://www.data-input.de

Note: @60 V, body currents are ~60 mA. Anything over 60 Vdc must be considered High Voltage.



Real event during F1 testing

2008: During F1 testing in Spain,

BMW Saubermechanic was electronically

shocked from the HV KERS (Kinetic Energy

Recovery System)

The energy from this vehicle can be a magnitude lower energy than a typical EV/HEV battery!



• How can we protect against HV hazards?– Ground fault isolation detection– Interlock loops– Special connectors with sensing– Active discharge circuits– Control algorithms– …

They are all controlled by electronics


Thermal Hazards


Thermal Hazards

• How can we protect against thermal hazards?– Overcurrent detection– Temperature sensors and thermal modeling – Limp home strategies– Enclosures– …

Some are controlled by electronics


HARA


Structure of ISO 26262Overview of ISO 26262 m

8-5 Interfaces within distributed developments

8-6 Specification and Management of safety requirements

8-7 Configuration Management

8-8 Change Management

8-9 Verification

8-10 Documentation

8-11 Confidence in the use of SW tools

8-12 Qualification of SW Components

8-13 Qualification of HW Components

8-14 Proven in use argument

9-5 Requirements Decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

9-7 Analysis of dependent failures

9-8 Safety analyses

2-5 Overall safety management 2-6 Safety management during the concept phase and the product development 2-7 Safety management after the item’s release for

production

2. Management of functional safety

1. Vocabulary

4. Product development at the system level 7. Production and operation3. Concept phase

5. Product development at the hardware level

6. Product development at the software level

8. Supporting Processes

9. ASIL-oriented and safety-oriented analyses

4-11 Release for production

4-10 Functional safety assessment

4-9 Safety validation

4-8 Item integration and testing

4-5 Initiation of product development at the system level

4-6 Specification of the technical safety requirements

4-7 System design

5-5 Initiation of product development at the hardware level

5-6 Specification of hardware safety requirements

5-7 Hardware design

5-8 Evaluation of the hardware architectural metrics

5-9 Evaluation of the safety goal violations due to random hardware failures

5-10 Hardware integration and testing

3-5 Item definition

3-6 Initiation of the safety lifecycle

3-7 Hazard analysis and risk assessment

3-8 Functional safety concept

7-5 Production

7-6Operation, service (maintenance and repair), and decommissioning

10. Guideline on ISO 26262 43

6-5 Initiation of product development at the software level

6-6 Specification of SW safety requirements

6-7 Software architectural design

6-8 Software unit design and implementation

6-9 Software unit testing

6-10 Software integration and testing

6-11 Verification of software safety requirements


ISO 26262 Part 3 Clause 8: Derivation of Safety Requirements

ety 44


Transitioning to a Safe State

fault tolerant time interval � Time-span in which a fault (1.42) or faults can be present in a system (1.129) before a hazardous event (1.57) occurs.

(alternate: “the time-span in which the vehicle function can be stressed with faults before a hazardous event develops”)

fault reaction time � Time-span from the detection of a fault (1.42) to reaching the safe state (1.102).

eered safety

Fault Fault DetectionPossibleHazard

Normal Operation Safe State

45

kVA = engineered safety TÜV NORD Systems GmbH & Co. KG 46

Work Products from Item Definition:1. Item definition resulting from the requirements of 5.4

Item Boundary

The EGAS monitoring concept provides a standardized approach to safe drive-by-wire control for gasoline and diesel engines

Functions defined by an internal combustion engine (ICE):

- Providing drive torque- Providing braking torque (drag torque of

the ICE)

Where the following hazards are identified within EGAS:

- Unintended acceleration (ASIL B)- Missing acceleration (QM)- Unintended deceleration (QM)- Missing deceleration (QM)

ISO 26262 Part 3 Clause 5:Item Definition


ISO 26262 Part 3 Clause 7:Hazard Analysis and Risk Assessment (HARA)

• HARA is a standardized approach to vehicle-level hazard classification

• HARA lists every combination of hazardous malfunction under every scenario (e.g.., road type, speed, driving situation, etc.)– Implication: typical HARA can easily grow to hundreds of lines

• HARA combines three concepts related to functional safety:– The SEVERITY (S) of the hazard– The EXPOSURE PROBABILITY (E) of the operational situations– The CONTROLLABILITY (C) of the hazard (e.g.., by the driver)

47


Initiation of the hazard analysis

and risk assessment

Situation analysis

Hazard identification

Classification of hazardous

events

Determination of ASIL and safety goals

Verification

ISO 26262 Part 3 Clause 7: Hazard Analysis & Risk Assessment (HARA) Lifecycle

48


7.4.1 - Initiation of the hazard analysis and risk assessment

7.4.1.1 - The hazard analysis and risk assessment shall be based on the item definition

7.4.1.2 - The item without internal safety mechanisms shall be evaluated during the hazard analysis and risk assessmenti.e. safety mechanisms intended to be implemented or that have already been implemented in predecessor items shall not be considered in the hazard analysis and risk assessment.

7.4.2.1 - Situation AnalysisThe operational situations and operating modes in which an item's malfunctioning behavior will result in a hazardous event shall be described, both for cases when the vehicle is correctly used and when it is incorrectly used in a foreseeable way.

ISO 26262 Part 3 Clause 7: HARA Initiation and Situation Analysis

Initiation of the hazard

analysis & risk assessment

Situation analysis



events


Verification

49


HARA attempts to answer the following questions:

• What can happen?

• How often can it happen?

• What are the effects, if it happens?

• Can the driver (or others) control it?

ISO 26262 Part 3 Clause 7: Hazard Identification

50


Step 1 – What are the possible hazardous accidents / events?

7.4.2.2 - Hazard Identification

• The hazards shall be determined systematically by using adequate techniques

• Hazards shall be defined in terms of the conditions or behavior that can be observed at the vehicle level

• The hazardous events shall be determined for relevant combinations of operational situations and hazards

• The consequences of hazardous events shall be identified

• If there are hazards identified in 7.4.2.2 that are outside of the scope of ISO 26262 then the need for appropriate measures to mitigate or control these hazards shall be highlighted and reported to the responsible persons



Situation analysis



events


Verification

ISO 26262 Part 3 Clause 7: Hazard Identification

51


Probability of Exposure

7.4.3.2 - The probability of exposure of each operational situation shall be estimated based on a defined rationale for each hazardous event. The probability of exposure shall be assigned to one of the probability classes, E0, E1, E2, E3 and E4, in accordance with Table 2.

Step 2 – For each hazard, what is the probabilityof bring in the situation/scenario?



Situation analysis



events


Verification

ISO 26262 Part 3 Clause 7: Classification of Hazardous Events

52

• Vehicle in incident with airplane landing on highway• Natural disasters, e.g. earthquakes, hurricane, forest fire, etc.


Severity

7.4.3.2 - The severity of potential harm shall be estimated based on a defined rationale for each hazardous event. The severity shall be assigned to one of the severity classes S0, S1, S2 or S3.

Step 3 – For each hazard occurrence, how severeis the damage?



Situation analysis



events


Verification


53


Controllability

7.4.3.2 - The controllability of each hazardous event, by the driver or other persons potentially at risk, shall be estimated based on a defined rationale for each hazardous event. The controllability shall be assigned to one of the controllability classes C0, C1, C2, and C3 in accordance with Table 3.

Step 4 – For each hazard occurrence, to what degree can the situation be controlled, e.g. by the driver?



Situation analysis



events


Verification


54


E1very low

probability

E2low

probability

E3medium

probability

E4high

probability

Value 0.001 0.01 0.1 1

Fre

quen

cy a

nd D

urat

ion

Situations that occurless often thanonce a year for thegreat majority ofdrivers

Situations that occura few times a yearfor the great majorityof drivers

Situations that occuronce a month ormore often for anaverage driver

All situations thatoccur during almostevery drive onaverage

n.a. <1% of average operating time

1% – 10% of average operating time

> 10% of average operating time

- Vehicle being towed- Vehicle during jump start

- Snow and ice on road- Trailer attached- Highway entranceramp

- Wet road- Heavy traffic (stop and go)- Vehicle beingrefueled- Overtaking

- Highway- Country road-Accelerating- Executing a turn (steering)

S1 Light and moderate Injuries

S2 Severe injuries, possibly life-threateníng, survival probable

S3 Life threatening injuries (survival uncertain) or fatal injuries.

Class C1simply

controllable

C2normally

controllable

C3difficult to control or uncontrollable

Value C 0.01 0.1 1

De-finition

More than 99%of average drivers or other traffic participants are usually able to control the damage

More than 90% of average drivers or other traffic participants are usually able to control the damage.

The average driver or other traffic participants is usually unable, or barely able, to control the damage

Brake to slow/stop when:- Fault

adjustment of seat position while driving

- Blocked steering column at start

Maintain intended driving path when: - Failure of ABS

during emergency braking,

- Motor failure at high acceleration

Maintain intended driving path when: - Faulty driver

airbag release when travelling at high speed,

- Incorrect steering angle with high angular speed

ISO 26262 Part 3 Clause 7: Exposure, Severity and Controllability

55


• Based on the Hazard Assessment and Risk Analysis (HARA), each hazard is assigned an “Automotive Safety Integrity Level” or ASIL– Range from ASIL A (least stringent) to ASIL D (most stringent) – QM (Quality Management) follows normal development process– SAE J2980 under development to harmonize levels

Severity Class Exposure Class Controllability Class

C1 C2 C3

S1

E1 QM QM QME2 QM QM QME3 QM QM AE4 QM A B

S2

E1 QM QM QME2 QM QM AE3 QM A BE4 A B C

S3

E1 QM QM AE2 QM A BE3 A B CE4 B C D

Difficulty to Control

Higher Probability

OfExposure

Greater Severity

ASIL

RAT

ING



Situation analysis



events


Verification

ISO 26262 Part 3 Clause 7: ASIL Determination

56


7.4.4.3 - A safety goal shall be determined for eachhazardous event with an ASIL evaluated in the hazard analysis. If similar safety goals are determined,these may be combined into one safety goal.

7.4.4.4 - The ASIL determined for the hazardous event shall be assigned to the corresponding safety goal. If similar safety goals are combined into a single one, in accordance with 7.4.4.3, the highest ASIL shall be assigned to the combined safety goal.

7.4.4.5 - If a safety goal can be achieved by transitioning to, or by maintaining, one or more safe states, then the corresponding safe state(s) shall be specified.

7.4.4.6 - The safety goals together with their attributes (ASIL) shall be specified in accordance with ISO 26262-8:2011, Clause 6.

Safety GoalsInitiation of the hazard


Situation analysis



events


Verification

ISO 26262 Part 3 Clause 7: ASIL Determination of Safety Goals

57


7.4.5 - Verification (7.4.5)

The hazard analysis, risk assessment, and the safety goals shall be verified to show their:

• completeness with regard to situations and hazards

• compliance with the item definition

• consistency with related hazard analyses and risk assessments

• completeness of the coverage of the hazardous events• consistency of the assigned ASILs with the corresponding hazardous

events



Situation analysis



events


Verification

ISO 26262 Part 3 Clause 7: Verification

58


Exercise: HARA


Initiation of the hazard analysis

and risk assessment

Situationanalysis

Hazardidentification


events

Determinationof ASIL and safety goals

Verification

Exercise: HARA and Safety GoalsHazards and Situations

60

• What Situations should we consider?

• What hazards are relevant for this function?


Exercise: HARA and Safety GoalsHazards and Situations

Malfunctions that cause Hazards:

Driving Situations:

• Unintended acceleration• Steering too large• Steering angle too small• No steering when intended• Etc…

• Driving Direction• forward• reverse

• Driving Speed• Very low / Parking situation• Low• High

• Road Direction• Straight• Curved

• Pedestrians• Yes• No


Exercise: HARA and Safety GoalsSafety Goals Guidelines

• A safety goal often takes the form of “avoiding” or “preventing” a hazard or malfunction from the HARA

• Safety Goals should specify an associated SAFE STATE if applicable

• Safety Goals are associated with hazards:�A Safety Goal inherits the highest ASIL of the hazard to which it is

associated.�Example: if a hazard is rated ASIL D, then the safety goal associated

with that hazard must be rated ASIL D.


Exercise: HARA and Safety GoalsRate S, E, C and ASIL for these Hazards/Situations:

DRIVING SCENARIO

Hazard: Driv

ing

Dire

ctio

n

Driv

ing

Spee

d

Road

Con

ditio

n

Road

Dire

ctio

n

S S

comment EE

comment CC

comment ASILUnintended deceleration Forward High

(70mph) High mu Highway

Unintended deceleration Forward Medium (45

mph) Lo muCountry

Road

Unintended deceleration Forward Low

(30 mph) High mu City roads



DRIVING SCENARIO

Hazard: Driv

ing

Dire

ctio

n

Driv

ing

Spee

d

Road

Con

ditio

n

Road

Dire

ctio

nS S comment E E comment C C comment ASIL

Unintended deceleration Forward Medium

(45 mph) Lo muCountry

Road S3

Life-threatening injuries (survival uncertain), fatal injuries

E2

Less than 1% of average operating time for majority ofdrivers

C3

Less than 90 % of alldrivers or other traffic participants are usually able to avoid harm by applying brakes quickly

B



DRIVING SCENARIO

Hazard: Driv

ing

Dire

ctio

n

Driv

ing

Spee

d

Road

Co

nditi

on

Road

D

irect

ion

S S comment E E comment C C comment ASIL

Unintended deceleration Forward Lo

(30 mph) High mu City roads S1 Light and moderateinjuries

E3

Betweeen 1% and 10% of average operating time for majority of drivers

C3

Less than 90 % of alldrivers or other traffic participants are usually able to avoid harm by applying brakes quickly

A



DRIVING SCENARIO

Hazard:

Driv

ing

Dire

ctio

n

Driv

ing

Spee

d

Road

Con

ditio

n

Road

Dire

ctio

n

S S comment E E comment C C comment ASIL

Unintended deceleration Forward High (70mph) High mu Highway S3


E4Greater than 10% of average operating time

C3

Less than 90 % of all drivers or other traffic participants are usuallyable to avoid harm by applying brakes quickly

D

Unintended deceleration Forward Medium (45

mph) Lo muCountry

Road S3


E2

Less than 1% of average operating time for majority of drivers

C3

Less than 90 % of all drivers or other traffic participants are usually able to avoid harm by applying brakes quickly

B

Unintended deceleration Forward Lo

(30 mph) High mu City roads S1 Light and moderate injuries

E3

Betweeen 1% and 10% of average operating time for majority of drivers

C3

Less than 90 % of all drivers or other traffic participants are usually able to avoid harm by applying brakes quickly

A


Exercise: HARA and Safety GoalsSafety goal, Safe state and ASIL

What is the safety goal:

What is the safe state:

What is the ASIL assigned to this safety goal:


HAZARD: Unintended decelerationSAFETY GOAL:

SAFE STATE:

Q: What is the ASIL assigned to this safety goal?

Exercise: HARA and Safety GoalsDefine Safety Goals for Each of these Hazards:

Unintended deceleration shall be avoided

Limited or No brake torque

ASIL D


Advanced Hazards of Electrified Powertrains


What are Advanced Hazards?

• Advanced hazards are hazards we are not familiar with– Different technology– Different configuration– Different behaviors– Different environment

• Systemic hazards are inherently hard to associate with an “Item”– May overlap or fall between multiple Items: assign ownership?– Controls architecture often ties the system together – many stakeholders


How ISO 26262 Addresses Systemic Hazards

• Systemic Solutions• ISO 26262-2:2011, Management of Functional Safety• ISO 26262-1:2011, Vocabulary

1.130 systematic failure – failure (1.39), related in a deterministic way to a certain cause, that can only be

eliminated by a change of the design or of the manufacturing process, operational procedures, documentation or other relevant factors


How Non-FuSa Engineers Develop FuSa

How (non-FuSa) Development Engineers develop functional safety concepts1. Keep the same functional safety concept from a simpler system2. Adapt that concept however they need for their advanced system3. Hope they pass validation!

CASE STUDY #1: EV DRIVE INSTABILITY

“Divide responsibility and nobody is responsible.”W. Edwards Deming


Case Study #1: EV Drive Instability

• This case had a proven controls architecture already in production

• Safety is highest priority, then component protection, then drive quality, etc.

• Battery power mapped to an equivalent torque limit

Source: teslamotorsclub.com, for illustration onlyThis was NOT a Tesla case study

REQUESTSHAPING

BATTERYMOTORS

UNIN. ACCELFinal OutputTorque Cmd

Priority

Control Architecture Priorities



• Unique conditions arose:– Low SOC, reduced power– Driver warning indicated– Vehicle speed below 5 MPH

• Battery power limit approaches 0 kW

• HV DC loads still present until car shuts off

Source: teslamotorsclub.com, for illustration onlyThis was NOT a Tesla case study

0

imaginary

Torque ≈ -k*Speed

Motor Speed

Motor Torque



Questions to consider:• How does torque safety monitoring define a violation?

– Torque magnitude? Magnitude and duration?– Torque RMS, energy balance check?– Wrong direction?

• How does torque command limiting prevent torque commands from becoming too high?– Static offset from request?– Estimate actual axle torque?

• Are EV shutdown responsibilities assigned thoughtfully and given dedicated functionality within the controls architecture?– When is it OK to violate a battery power limit?– Is code centralized, or distributed? Documentation?

Actual Axle

Command Motor

CASE STUDY #2: DUAL AXLE RISKS

“Best efforts will not substitute for knowledge.”W. Edwards Deming

kVA = engineered safetySuppliers

Performance Mngr

Case Study #2: Dual Axle Risks

• Dual Axle = P4 or P4Px– Peugeot 3008 Hybrid 4, Porsche

918, BMW i8, Tesla Model X– Many rumored: Toyota, Honda,

Nissan, VW, BMW, etc.• Challenge: Blank Paper vs.

Legacy Architecture– Evolution of torque domain:

MAP, crankshaft, trans in, trans out, axle, wheels

– Cross Functions: engine controls, transmission controls, hybrid controls, brake controls, chassis controls, suppliers, performance managers, functional safety, etc.

Source: www.seriouswheels.com, for illustration onlyThis was NOT a Porsche case study

Engine Team

TransTeam

HybridTeam

BrakeTeam

ChassisTeam



• Re-allocation of torque safety interventions– Net torque: driver request,

vehicle over-speed, cruise, preemptive collision, etc.

– Axle-specific torque: ABS, traction lock-up, traction slip, advanced stability, etc.

• Creation of new safety limits– “Thru-the-Road” component– Potentially greater severity– Functional safety response time

requirements– Functional safety intermediate

torque limits

Axle 2 Specific Axle 1 Specific

Net Torque

Net Torqueet Torqueet Torque

Axle 1

Axle 2

ice

ice



Questions to consider:• Does each development team have a common safety rep?

– Internal safety members?– Do engineers know safety philosophy,

or safety implementation?

• Are development engineers eager to raise potential safety concerns before tackling it themselves?– Are they aware of safety “success stories”?– Do they see functional safety as a checkbox or a guide?

• Are safety related interventions assigned thoughtfully and given dedicated functionality within the controls architecture?– Is code centralized, or distributed? Documentation?– Does project management assign authority to functional safety?

CASE STUDY #3: HAPTIC BRAKE PROPERTIES

“Meeting specifications is not enough.”and“Quality is pride of workmanship.”W. Edwards Deming


Case Study #3: Haptic Brake Properties

• Blended (xEV) brakes vs hydrostatic brakes– Hydrostatic: instant, 1-to-1, linear

relationship between pedal and deceleration

– Blended brakes: different actuator response times, efficiency gains

• Notoriously critiqued– Accord “…a little alien” (2007)– Prius “…inconsistent” (2010)– Volt “…feel disconnected” (2011)– Leaf “…change at random” (2012)– S550 “…braking feel suffers” (2015)

• NOT the fault of brake developers– Systemic limits on response time are

inherent

Blended brakes

Hydrostatic



• Controllability: Brake release– Hydrostatic: instant, 1-to-1,

modulation of decel and slight accel– Blended brakes: creep torque likely

canceled, lash closure before any slight accel is felt by driver

• Position control mode to stop– Card swipe, drive-thru window– Parking spots, garage, driveway– Intersection, cross-walks– Common pedestrian areas

• Risk: Confused state, startle– Delays in brake response– Driver overcompensates, lifts foot– Driver resorts to accel pedal– “Unintended” accel in close quarters

LashSpring

Torq

ue

Creep/Idle

Brake

Brake Release

Blended brake releaseHydrostatic release

Actuator

Lash Spring

Actuator



Questions to consider:• Does functional safety account for confusion or startle?

– Delays or partial -> Confusion– Sudden or excessive -> Startle

• Are development engineers eager to raise potential safety concerns before tackling it themselves?– Are they aware of safety “success stories”?– Do they see functional safety as a checkbox or a guide?

• Is functional safety given system level authority?– Are system level requirements accessible to development teams?– Does system validation provide “flags” to alert functional safety in areas

traditionally left to quality, performance, etc.?

REVIEW OF CASE STUDIES

“We should work on our process, not the outcome of our processes.”and“The aim should be to work on the method of management.”W. Edwards Deming


Review of Case Studies

• Case Study #1 – EV Drive Instability: drivability, durability, quality, efficiency, and functional safety

• Case Study #2 – Dual Axle Risks: drivability, efficiency, and functional safety

• Case Study #3 – Haptic Brake Properties: drivability, quality, efficiency, and functional safety

• Functional safety is inseparable from both performance objectives and product development


Recent Interview on ISO 26262

Mr. Rivett, what is a critical factor for success when working in functional safety with the ISO Standard?

“It’s about pinning down the feature or system on the vehicle in terms of what the standard calls the “item definition”. A lot of the systems that we’re doing now build on software legacy systems, and they are also distributed systems where functions run on different nodes and communicate across busses. That can be quite complex, so the critical factor of success is getting that defined well at the start before you start trying to apply the functional safety processes. It’s hard to do because you have to interface with legacy, and it’s distributed across different nodes, so responsibility for different bits of the system might be in different bits of the organisation. Getting cross-department cooperation is critical. If you can get that sorted out, it makes life a lot easier. If you don’t, you will miss things that come up later on, making the process much more difficult than it would otherwise be.”

Roger Rivett works as Functional Safety Technical Specialist at Jaguar Land Rover, UK and is a long-time member of the International ISO 26262 Committee. (Automotive IQ, June 2015)


Parting Thoughts: Systemic Solutions

• Encourage open forums– Monthly event (donuts)– Newsletters– Roundtables– Highlight successes

• Teach functional safety philosophy– Proactive– Not checklist, not legacy– Fundamentals of Hazard

Analysis and Risk Assesment– Fundamentals of validation

testing

“People need to know how their job contributes.”W. Edwards Deming

“Break down barriers between departments”

W. Edwards Deming


Summary


Contact

Jody J. NelsonManaging Partner, [email protected]

www.kvausa.com

Documents

An Introduction to Functional Safety for Electrified ......kVA = engineered safety History of ISO 26262 • IEC 61508 is the basis for ISO 26262, but not specific to Automotive •