Functional Safety Management · Development of Global Chassis Control 1978 2001 electronics...

Functional Safety Management

Hans-Leo Ross

System- and Software Safety

Quality Automotive


Topics Contents

Risk, Systems and Safety Mechanism

Hazard & Risk determination in relation to ISO 26262

Transparence and Traceability basis for System Engineering

Software-Safety Mechanism

2 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG

Quality Automotive


Challenges with ISO 26262 Stakeholder of Automotive Products

Standards

Our enemy is complexity, and it’s our goal to kill it. Jan Baan

Performance

Maintenance

Capacity

Availability

Safety

Fault tolerance

Functionality Cost Compatibility

Legislations

The challenge over the next 20 years will not be speed or cost or performance; it will be a question of complexity. Bill Raduchel, Chief Strategy Officer, Sun Microsystems

Platforms

Reuse Resilience Production

Ethic Resources

Quality

Schedule

Qualification

Security

Markets

Behavior of User


http://images.google.de/imgres?imgurl=http://www.pharaonenpage.de/Pyramiden/neue-pyramide.jpg&imgrefurl=http://www.pharaonenpage.de/Pyramiden/pyramide.html&h=293&w=471&sz=23&hl=de&start=20&tbnid=5uqjOAE-SgIP7M:&tbnh=80&tbnw=129&prev=/images?q=Pyramide&gbv=2&svnum=10&hl=de

Quality Automotive


Challenges with ISO 26262 for Automotive Industry

Motivation for “SAFE”

Due to product liability we need safety arguments for our products.

Not only the complexity of our products increases significantly,

-> also the complexity of organizations involved in vehicle development explodes.

Depth of supply chain, e.g. OS

supplier are at least TIER 4.

Width of supplier up-to 20

companies provide software for a

single control unit.

Automotive-wide generic or

standardized interfaces are not

available.

Dependability of product

characteristics, properties, features

etc. are not sufficiently traceable.


Quality Automotive


Interfaces, Dependability and Complexity to be Managed


SE

E2

E1

E3

E4

R1 Rn

Technical Component 1

Technical Component 2

Technical Interfaces

- Environment and technical element

- between elements

Functional Interfaces

- Environment and logical element

- between logical elements

- between technical elements

- between logical and technical interfaces

Additional organisational Interfaces

- Project interfaces -> process interfaces

- Customer / supplier interfaces

- Product boundary / interfaces

Intended Function 1

Intended Function 2

En Logical element

Quality Automotive


Challenges with ISO 26262 Automotive SPICE Traceability Model

Vehicle-Level

U M

U d Battery ECU U M U d

U d

System-Level 1

System-Level 2

Component-Level 2

System-Level 3

Component-Level 1

Part / Unit-Level 3

Vehicle

Validation

SUP 3 BP3

Plan

Validation

SUP 3 BP1

Acceptance

Validation

SUP 3 BP2

Vehicle Requirements

REU 3 / SUP 6 / ENG 1

Domain Architecture

REU 3 BP3

System Requirements

ENG 2

Verification Criteria

System Architectural Design

ENG 3


Software Requirements

ENG 4


Software Unit Construction

ENG 6


Software Architectural Design

ENG 5


Software Detailed Design


EN

G 5

BP

10

Test Spec. SW Unit

ENG 6

Test Cases Acceptance Criteria

ENG 6 BP 7

Test Spec. SW Integration Test

ENG 7


ENG 8 BP 5 Test Spec. SW Test

ENG 8


ENG 7 BP 7

Test Spec. System Integration

ENG 9


Test Spec. System Test

ENG 10


ENG 9 BP 7

ENG 10 BP 5


Quality Automotive


Challenges with ISO 26262 Development of Global Chassis Control

2001 1978

electronics

networking

Perf

orm

an

ce

Electronic Brake System ABS, EBD, TCS, BA, ESP Electro Hydraulic Brake

Electro Mechanical Brake

Hydraulic Brake System drum brake disc brake brake booster

Networked Brake System " 30-m car" (brake+chassis+tires) ESP II (brake+steering)

Development of

- no. of functions

- memory for controller (1980 10kbyte up to 1Gbyte 2007)

- network knots, no. of development partners, interfaces

- degree of integration, interdependences, demand on dynamic

Cost reduction?

Weight reduction?

No. of variants?


Quality Automotive


AFS, EPS Options for Steering Systems


Quality Automotive


Active Front Steering

Absolute 360° input

shaft sensor (via CAN) 1)

Flow control signal

const. pressure

regulated pump

Flow control valve

AFS column actuator

Hydraulic servo

rack drive steering

Steering valve

Pinion

1) steering wheel angle sensor 2) absolute ±180° after initialization, absolute ±740° together with software functionality

Intermediate

shaft

ECU12V

Mmot

U

U

dD

dout

U

AFS

G

R

AF

S S

ys

tem

sin-cos-track

position sensor180° output

shaft sensor 2)


Quality Automotive


ESP II – Braking on µ-split


Quality Automotive


ESP with Driver Steering Recommendation Braking on -split


Quality Automotive


ESP II – ESP with Rear Wheel Steering Intervention Slalom Manoeuvre


Quality Automotive


ESP II – ESP with Rear Wheel Steering Intervention Double Lane Change Manoeuvre


Quality Automotive


General Hazards addressing Functional Safety

Crash barrier in

- electronic and

- software


Quality Automotive


Hazard

& & Safety Goals

≥1 m

alfu

nctio

n

malfu

nctio

n

malfu

nctio

n

malfu

nctio

n

malfu

nctio

n

malfu

nctio

n

functio

n

functio

n

functio

n

functional effects ≥1

functio

n

functio

n

functio

n

driving situation driving situation driving situation

& & & &

Hazards and Potential Sources of Risk Functional and Safety of Use

technical effects: heat, fire, smoke, EMC, voltage, radiation, chemical, toxicities etc.

environment: vibration, temperature, humidity, etc.

Scope of ISO 26262


Quality Automotive


Top Failure / Safety Goal of an Item

Item 1

Motor

Manage

ment

Independent Items influencing longitudinal axle of a vehicle

e.g. ASIL D -> 10 Fit for any independent safety goal

of an independent item

PMHF1 =

10 e-9 / h

Item 2

Trans-

mission

Item 3

Brake

PMHF2 =

10 e-9 / h

PMHF2 =

10 e-9 / h

Grey Zone for Item and Safety Goal

Not definitely specified in ISO 26262

Speed

over ground


Quality Automotive


Corridor Control Development Target to identify the Safe Corridor!

V

unintended

positive effect

-V

corridor for

straight forward

drive

unintended

negative effect

torque, impulse, ….

design limits, limits of controllability.

Derived from safety goal 1

Derived from Safety Goal 2

Safety

Corridor


Quality Automotive


Hazard & Risk Analysis Safety Goal Variants

E = const

other factors > e.g. demand rate of function

S = linear e.g. speed

Design limitations, road and vehicle design

0 100% Performance

or possible malfunction

Energy or Impulse

130 km/h

C=3 C=2

C=1 QM

ASIL D

ASIL C

SG= prevent unintended steering intervention

SG= prevent unintended brake force

SG= prevent unintended lateral torque

Basis is the intended specified functionality

ASIL B

ASIL A


Quality Automotive


Relation between Item, Systems and Functions

One instance consists of one or more other instances(e.g. a system may consist of one or more subsystems)

One instance is realized by another instance (e.g. a function is realized by one or more systems)

Composition: one instance depends on another instance (e.g. a system consists of a set of components)

Note 1 Depending on the context, the term “element”can apply to the entities system”, “component”, “hardware part” and “software unit” in this chart according to ISO°26262-1, Clause°1.32.

Note 2 The system as it is defined in ISO°26262-1 is at least a sensor, controller and an actuator, e.g. at least 3 related elements.

Note 3 * means N elements are possible.

Item Function

HW-Part/ SW-Unit

1..*

1..*

1..*

*

Component

System

0..*(sub-) component:e.g. microcontroller,application software,

3..*

0..*(sub-) system :e.g. sensor, controller, actuator

e.g. CPU,SW-RAM Test Module

One instance consists of one or more other instances(e.g. a system may consist of one or more subsystems)

One instance is realized by another instance (e.g. a function is realized by one or more systems)

Composition: one instance depends on another instance (e.g. a system consists of a set of components)

Note 1 Depending on the context, the term “element”can apply to the entities system”, “component”, “hardware part” and “software unit” in this chart according to ISO°26262-1, Clause°1.32.

Note 2 The system as it is defined in ISO°26262-1 is at least a sensor, controller and an actuator, e.g. at least 3 related elements.

Note 3 * means N elements are possible.

Item Function

HW-Part/ SW-Unit

1..*

1..*

1..*

*

Component

SystemSystem

0..*(sub-) component:e.g. microcontroller,application software,

3..*

0..*(sub-) system :e.g. sensor, controller, actuator

e.g. CPU,SW-RAM Test Module

See ISO 26262 Part 10 Figure 3


Quality Automotive


Requirement Flow

Functional safety requirements

Result of allocation

Functional safety concept

Other technology

External measures

Technical safety concept

System design

Result of allocation to hardware and

software

E/E

HSI

Other functional/non-

functional requirements

(Functional req.

Quality req.

Environmental req.

etc.)

Preliminary architectural assumption

Safety goals

External source

Technical safety requirements

Non-E/E

External source

Warning/

degradation

concept

etc.

3- 8.4.3.2

3 - 8.4.3.3

3 - 8

3- 8

4 - 6

4- 7.4.6

5- 6.4.10

6- 6.4.44- 7.4.5

4 - 7

4- 7

3 - 7

Internal/ External interface

Hardware safety requirement

Hardware safety requirement

Software safety requirement

Software safety requirement

4- 7.4.2.4

3 – 8.4.3

5- 6 6- 6

3 - 8

From ISO DIS 26262 Part 10, Figure 8


Quality Automotive


Multiple System Levels



Quality Automotive


Horizontal Layer of Abstraction Comparison between Airborne and Automotive Industry

Component level

Vehicle Level

system level 1 vehicle interface

system level 2 component interface

system Level 3 hardware / software interface

Flight level

separation on

control units (TMR)

level

separation on

microcontroller level

separation on core level

and in

software functions


Quality Automotive


Different Layer

System

array

System …

E/E

Components

Sensor

Hardware

Hardware

Components

Hardware

Parts

Software

Software

Components

Software

Units

Controller

Hardware

Hardware

Components

Software

Software

Components

Software

Units

Actuator

Hardware

Hardware

Components

Hardware

Parts

Software

Software

Components

Software

Units

Communication Other technology

Components

Item

Element

Hardware

Parts



Quality Automotive


Layered Failure Propagation

Fault Error Failure

Fault Error Failure

Item

Component

Loss of electrical

connection

Engine control unit stops

operation by intermittence

Ignition coil is not supplied

by intermittence

Engine control unit interrupts

operation when wiper is

switched on

Vehicle bucks

Ignition

interrupted by

intermittence

Systematic SW

Random HW

Systematic HW

Systematic SW

Random HW

Systematic HW

Programming Error at

loop termination

condition.

Oxidation

Insufficient EMC

immunity of engine

control unit with respect

to the wiper cable EMC

susceptibility.

Unwanted endless

loop (leads to

Watchdog-Reset)

Program sequence

in engine control

unit is disturbed.

Vehicle

Engine control unit

Engine control unit

interrupts operation when

wiper is switched on

Engine control unit stops

operation by intermittence

Ignition coil is not supplied

by intermittence



3. Concept phase

2. Management of functional safety

2-5 Overall safety management 2-6 Safety management during item development

7. Production and operation

6-5 Initiation of product development at the software level 6-6 Specification of software 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 Software verification

5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety requirements

5-7 Hardware design

5-8 Hardware architectural metrics

5-10 Hardware integration and testing

Co

re p

roc

es

se

s

2-7 Safety management after release for production

3-6 Initiation of the safety lifecycle

1. Vocabulary

3-5 Item definition

3-7 Hazard analysis and risk

assessment

3-8 Functional safety

concept

7-6 Operation, service and

decommissioning

7-5 Production

8. Supporting processes

8-5 Interfaces within distributed developments

8-6 Overall management of safety requirements

8-8 Change management

8-9 Verification

8-7 Configuration management

4. Product development: system level

4-5 Initiation of product development at the system level

4-7 System design 4-8 Item integration and testing

4-9 Safety validation

4-10 Functional safety assessment

4-11 Release for production

6. Product development:

software level

5. Product development:

hardware level

5-9 Evaluation of violation of the safety goal due to random HW failures

4-6 Specification of the technical safety requirements

9. ASIL-oriented and safety-oriented analyses

9-5 Requirements decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of

8-10 Documentation

8-11 Qualification of software tools

8-13 Qualification of hardware components

8-14 Proven in use argument

8-12 Qualification of software components

9-7 Analysis of dependent failures

9-8 Safety analyses

10. (Informative) Guidelines on ISO 26262

Mapping to SPICE

high coverage

medium coverage

low coverage

no coverage

Quality Automotive


Variability of Functions e.g. Adaptive Cruise Control

Fixed-speed

cruising

Deceleration

control

Following

control

Acceleration

control

No other

vehicle in front Slow vehicle

in front Following in

constant distance

Acceleration

To set speed

130 km/h

Set speed

130 > 100

km/h appr. 100

km/h

100 > 130 km/h

Set speed

Variants on ASIL ALLOCATION

Motor

Controller

Brake

Controller QM ASIL B ASIL D

Sensor

Safety Mechanism in Controller

Sensor

Distributed Safety Mechanism

Sensor

Safety Mechanism in Sensor


Quality Automotive


Design PhasesDesign PhasesRequirements PhasesRequirements Phases

3-8

Functional

safety requirements

4-6

Technical

safety

requirements

3-7

Safety

goals

3-8Functional

safety

concept

4-6/7

Technical

safety

concept

Requirements, design and test flowRequirements / design interaction

5-6

HW safety

requirements

3-8, 4-6

System

safety requirements

Test PhasesTest Phases

5-10

Hardware

integration

test

4-8

System

integration

test

4-9System

safety

validation

System design V 0.1

System design V 0.2

System design V 1.0

3-8

Preliminary

architectural assumptions

4-7System

design

5-7

Hardware

design

3-5

Item

definition

Parallel Requirement and Design Phase


Quality Automotive



3-8

Functional

safety requirements

4-6

Technical

safety

requirements

3-7

Safety

goals

3-7Functional

safety

concept

4-6/7

Technical

safety

concept

Requirements, design and test flowRequirements / design interaction

6-6

Software

safety

requirements

6-6 SW safety requirements

at architectural

level

6-6

SW safety

requirements

at unit level

3-8, 4-6

System

safety requirements


6-9

Software unit

test

6-10

Software

integration

test

4-8

System

integration

test

4-9System

safety

validation

System design V 0.1

System design V 0.2

System design V 1.0

3-8

Preliminary

architectural assumptions

4-7System

design

6-8

Software unit design

6-7Software

architectural

design

3-5

Item

definition

Parallel Requirement and Design Phase


Quality Automotive


Information Flow in Layers


3-8

Functional safety

requirements

4-6

Technical

safety

requirements

3-7

Safety

goals

3-8

Functional

safety

concept

4-6/7

Technical

safety concept

Requirements and design flowRequirements, design and test interaction

6-6

Softwaresafety

requirements

6-6 SW safety

requirements

at architectural

level

6-6

SW safety

requirements

at unit level

3-8, 4-6System

safety

requirements


6-8Software unit

design

4-7System

design

6-7

Software

architectural

design

6-11Software

safety

verification

6-10

Software

integration testing

3-8

External

measures

and other technologies

3-8

Preliminary architectural

assumptions

3-5

Item

definition

6-9

Software unit

testing

4-8

System

integration

testing

4-9System

safety

validation

4-8

Vehicle integration

testing



Quality Automotive


Spiral Model: Samples needed by OEM

A-Sample

B-Sample

C-Sample

D-Sample

Prototype specification

Prototype production

Experiment, Test

change and / or enhance

Prototype accepted? yes

no

Analyze requirements Develop Concept

Sample

Design Verification

Sample Process /Product

Verification / Validation


Quality Automotive


Influences to HW/SW Interface

From ISO 26262 Part 4, Annex B


Quality Automotive


Hierarchical Product Structure

Vehicle-Level

U M

U d Battery ECU

U M U d

U d

System-Level 1

System-Level 2, Product-Level

Component-Level

E-HW

Physical

- touching, geometry

Communication

- CAN, FlexRay, Ethernet

Interface Characteristics

- timing, performance

- torque, energy, force

- angle

- rotation speed

sensor caliper ASIC

Physical

- screwed, press fitting

- housing

- analogue, digital

Communication

- plugs, interfaces, protocol

Physical

- pins, cable, sockets

- vibration, temperature, etc.

Communication

- protocol frames, CRC, Bytes

SW


Quality Automotive



Component level

Vehicle Level

system level 1 vehicle interface

system level 2 component interface

system Level 3 hardware / software interface

Flight level

separation on

control units (TMR)

level

separation on

microcontroller level

separation on core level

and in

software functions


Quality Automotive


Aspects of an architecture including Safety View


Quality Automotive


logical elements logical elements

Independence, the price for high integration density

intended Function

- requirements (+Parameter)

- intended behavior

- architectural assumptions

- design limitations

- boundary (Interfaces)

- environment

H&

RA

logical elements

logical elements logical elements technical elements

logical elements logical elements safety goals (ASIL)

logical elements logical elements intended function

logical elements logical elements requirements (QM)

logical elements logical elements logical elements

logical elements logical elements technical elements

logical elements logical elements safety mechanism

logical elements logical elements requirements (ASIL)

sufficient

independence /

freeness of

interference

functional

safety

concept

technical

safety

concept


Quality Automotive


Information Flow in System- and SW-Development

Requirement Integration Design

3-7

Safety Goals

3-5

Vehicle

System

Definition

Analyse

Boundary

Analysis/

G&RA

Design

Assumptions,

Limitations

4-9

System-

Safety

Validation

Functional

targets

Requirements

3-8

Functional

safety

requirements

4-6

Technical

safety

requirements

4-8

Integration

Tests

Architecture

Architectural

assumptions

Verification

3-8.4.5

Verification

4-8

Verification

3-8.4.4

Validation

Criterion

3-8.4.3

Allocation

3-8

Functional

Safety Concept

4-6

Technical

Safety Concept

4-7.1/2

System-

architecture

4-7.3/4

System safety

analyse

4-7.6/7

System

Design

6-6

Software safety

requirements

6-8

Verification

6

Software

Safety Concept

6-7

Software-

architecture

6-8

Software

Design

6-9/10

Software

Integration +

Tests

6-8.4.2/3/4

Software- Unit

requirements 6-9

Software

Unit-Tests

6-7

Software

Architectural

Analysis

Concept

FMEA


Quality Automotive


Architecture Abstraction

System Function

Block

Software architecture blocks

Requirement

Support

Architecture and Design Support

Hardware architecture blocks

SysC. architecture blocks

Operational

Perspective

Functional

Perspective Logical

Perspective

Technical

Perspective

Geometrical

Perspective

Allocation

E/E wiring & In

ECU

Variability

Perspective

Hydraulic,

others

Functional Safety

Concept

Technical

Safety Concept

ISO26262

view

Syst .Feature

SW Feature

HW Feature

SysC. Feature

Syste

m

Safety

Support

Software

component

architecture

Software component

design allocation (RTE

configuration)

Hardware

component

architecture

Hardware component

design allocation

(package)

Com

pone

nt

Systems

component

architecture

Systems component

design allocation (Meca.

package)

Core

Allocation

PCB

Allocation

Physical

Flow (as

Hydraulic,

others)

Environment

Perspective

Sys Design

Limit

Design Limit


Quality Automotive


Architecture view from Abstraction layer

Functional Safety

Concept

Technical

Safety Concept

ISO26262

view

Syste

m

Safety Support

Com

pone

nt

Architectural

View Failure View Timing View

Only relevant

elements

Only relevant

elements Blocks failure

Software

component

architecture

Hardware

component

architecture

Systems

component

architecture

Component

failure

Component

failure

Component

failure

Only relevant

elements

Only relevant

elements

Only relevant

elements

Functional

Behavior View

Dysfunctional

Behavior view

Signal chain

Signal chain

Signal chain

Signal chain

Signal chain Functional

Behavioral

Function

Behavioral

models (HW,

SW, SystC)

Dysfunctional

Behavioral

models (HW,

SW, SystC)

Dysfunctional

Behavioral

Functional

Behavioral

Functional

Behavioral

Functional

Behavioral

Dysfunctional

Behavioral

Dysfunctional

Behavioral

Dysfunctional

Behavioral


Quality Automotive


Architecture view from Abstraction layer

Functional Safety

Concept

Technical

Safety Concept

ISO26262

view

Syste

m

Safety Support

Com

pone

nt

Architectural

View Failure View

Only relevant

elements

Only relevant

elements Blocks failure

Software

component

architecture

Hardware

component

architecture

Systems

component

architecture

Component

failure

Component

failure

Component

failure

Only relevant

elements

Only relevant

elements

Only relevant

elements

Functional

Behavior View

Dysfunctional

Behavior view

Functional

Behavioral

Function

Behavioral

models (HW,

SW, SystC)

Dysfunctional

Behavioral

models (HW,

SW, SystC)

Dysfunctional

Behavioral

Functional

Behavioral

Functional

Behavioral

Functional

Behavioral

Dysfunctional

Behavioral

Dysfunctional

Behavioral

Dysfunctional

Behavioral

Timing View

Signal chain

Signal chain

Signal chain

Signal chain

Signal chain


Quality Automotive


Meta Model for System Engineering Functional Element and Requirements

Element Inputs

Valid operation modes,

configurations, ….

Environment

Outputs

Inner relation

[<When?><Condition?>] shall

must

can

Element

<element name>

<whom?>

offer the ability

to be able

-

[<Object &

Supplement to Objects>] <action>


Technical Element

needs:

- room (resources, memory..)

- energy

- time

produces, effects or reacts on:

- heat

- aging

- noises (stress, vibration, dirt, humidity …)

- chemical

Quality Automotive


Boundary Diagram inclusive Interface Matrix (Function in Vehicle)

Vehicle

External

Functional Unit

Boundary Ideal Functions

External

Functional Unit

Internal

Functional Unit

External

Functional Unit

External

Functional Unit

Internal

Functional Unit

Internal

Functional Sub-unit Internal

Functional Sub-unit

Internal

Functional Unit

Internal

Functional Sub-unit Internal

Functional Sub-unit

P E

I M

P E

I M

P E

I M

P E

I M

P E

I M

P E I M

P E I M P E

I M


Quality Automotive


Failure Error Fault

Item

Vehicle Level

Hazard Situation

Failure Error Fault

Components

System Level

Demand

Failure Error Fault

Part / Unit

Component Level

Demand

Hierarchical Level and Failure Behavior


Quality Automotive


Failure Error Fault

Item

Vehicle Level

Hazard Situation

Failure Error Fault

Components

System Level

Demand

Failure Error Fault

Part / Unit

Component Level

Demand

Hierarchical Level and Failure Behavior

Vehicle speed < 15 km/h

Faulty brake at 1 wheel

Faulty pressure to 1 wheel Un-intended open valve

Un-intended open valve

Does the un-intended opening of valve have an impact

in case of non active control, such as ESC?

Electric pulses to coil Faulty oscillations from ECU

Faulty oscillations from ECU

Are the pulses able to switch a valve?

Driver floating to Hi-signal

Resistor, Capacitor,

Transistor, mass connection

etc.


Quality Automotive


System

Zuverlässigkeitsblockdiagramme

Komponentenebene

Fahrzeugebene

Systemebene

I

Realisierungsebene

S II III VI

V A

Fahrzeugsystem

A B C

Komponente

F1 F2 F3 F4

Funktionsgruppe

B1 B2 B3 B4 B5 B6

R2

I1

R1

T2

R3

T1

B2

B1

B3

B4

B5 B6

B1

B3

B2

B4

B5

B6


Quality Automotive


FMEA – That‘s how it works -> CAP0500032

A FMEA is generally developed in 5 steps (reference VDA 4.x):

• Reduce risk with

further measures

• Quantify modified

stage

Architecture Analysis

1. Step

Structure Analysis

• Work-out and

structure the relevant

elements

• Define hierarchy

(level of abstraction)

• Define interfaces

2. Step

Function Analysis

• Analyze and

decompose function

• Allocate function to

structure elements

• Analyze functional

dependability

3. Step

Fault Analysis

• Analyze fault mode per

function (FTA inside of

system element)

• Analyze cause and

effect based on

functional and technical

dependability

• Connect single failure

effects to the failure net

4. Step

Measure Analysis

• Identify necessary

avoidance or detection

measures

• Agree measures to

assure correct design

• Define measure with

effectiveness in field.

• Quantify measures

5. Step

Optimization

Risk Analysis and Measures

Deductive Analyse Inductive Analyse


Quality Automotive


Informationsfluss in System- und SW-Entwicklung

Anforderungsphasen Integrationsphasen Designphasen Analysephasen

4-6

Technische

Sicherheits-

anforderungen

4-8

Integration-

tests

Architekturphasen Verifikation

4-8

Verifikation

4-6

Technisches

Sicherheits-

konzept

4-7.1/2

System-

architektur

4-7.3/4

System

Sicherheits-

analyse

4-7.6/7

System-

design

6-6

Software

Sicherheits-

anforderungen

6-8

Verifikation

6

Software

Sicherheits-

konzept

6-7

Software-

architektur

6-8

Software-

design

6-9/10

Software

Integration +

Tests

6-8.4.2/3/4

Software- Unit

Anforderungen

6-9

Software

Unit-Tests

6-7

Software

Architektur-

analyse


Quality Automotive



Komponentenebene

Funktionsgruppenebene

Bauelementeebene C61 C61

R63


Quality Automotive


Komponentenebene

Architekturebene

Software-Design-Ebene



Quality Automotive


Deriving of Safety Goals, Consequences for Requirement Analysis

ITEM

E2

E1

E3

E4

SG1 SG2

(1) Requirement for the entire Item (e.g. environment)

(2) Requirement of an element (e.g. characteristics of the element)

(3) Requirement of functions (e.g. behaviour, interface consistency)

(1), (2) relevant for element tests

(1), (3) relevant for integration tests


Quality Automotive


SW

Deriving of Safety Requirements (e.g. HIS), Consequences for Requirement Analysis

Sub.-S

E2

E1

E3

E4

SR1 SR2

Integration testing (sometimes called Integration and Testing, abbreviated "I&T") is the phase in software testing in which individual software

modules are combined and tested as a group. It occurs after unit testing and before validation testing. Integration testing takes as its input

modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates,

and delivers as its output the integrated system ready for system testing.

Sub.-S

E2

E1 E3

E4

SR1 SR2

F1 F2

P2 P3 P1 EE

M2 M3 M1

Deductive Systematic

Failure Analysis Inductive Random HW

Failure Analysis

Failure <= Systematic Failure

Random HW Failure


http://en.wikipedia.org/wiki/Software_testing

http://en.wikipedia.org/wiki/Unit_testing

http://en.wikipedia.org/wiki/Verification_and_Validation_(software)

http://en.wikipedia.org/wiki/Module_(programming)


http://en.wikipedia.org/wiki/Test_plan

http://en.wikipedia.org/wiki/System_testing

Quality Automotive



SW

Sub.-S

E2

E1

E3

E4

SR1 SR2

F1 F2

P2 P3 P1

EE

M2 M3 M1



Failure Analysis


Random HW Failure

Functional/ Logical View

Technical /

Component View

Component

-FMEA

FMEA on

System-Level

Fault: abnormal condition that can

cause an element (1.32) or an item

(1.69) to fail

Error: discrepancy between a computed,

observed or measured value or

condition, and the true, specified or

theoretically correct value or condition

Failure: termination of the ability of an element

(1.32), to perform a function as

required

&

Function 1

Fu

nctio

n 1

.1

Functio

n 1

.2

Functio

n 1

.3

Function 1.1 Function 1.2 Function 1.3

Function 1


Quality Automotive



SW C

U2

U1

U3

U4

SR1 SR2

E/E C

P2

P1

P3

P4

SR1 SR2

From Wikipedia













Quality Automotive


Measures to Control Systems or Hardware Software Failure Safety Mechanism

I1 I2 I3

O1 O2

Software

unit I2 I3

I1

O2 O1

=

= =

Measures to control failure

ASIL C and D / SIL 3

Systematic redundancy architecture Dependability Analysis

=

=

= =

=

=

Critical Unit, failure could not be controlled from system

Redundancy is measure to avoid random and systematic failure.

As a consequence we need SW Safety Mechanism such as redundant SW function.

ISO 26262 describes it as a decomposition and

requires a sufficient level of independence of the redundant paths.

Measures to control System or Hardware Failure (Safety Mechanism)

(Software Safety Integrity Requirements in IEC 61508)

allocated to Software need also a sufficient degree of independence.

Safety-related SW Functions and Safety Mechanism

shall never implemented in the same SW Unit. C1=Signal to activate control measure

F1= Failure Signal

V1=Value to be controlled

D1= Expected value / redundant result

Diagnostic

Control

Unit C1

F1 D1 V1 &

WD

WD

Manager

&

C2

Diagnostic

Manager

&

F2


Quality Automotive


NC

Anforderungen an die Elektronik heruntergebrochen

P

W

V

D

Ü

Steuerung SA

SA

SA

SA

SA

Mikrocontroller

DkA

DA

P dP

Fs

Dk SA

U

I

n

Korridorüberwachung

ASIL C

Beabsichtigte

Funktion

externe Peripherie

Interne

Peripherie

SA

P

Steuerung

SA

SA

SA

SA

SA

Mikrocontroller

DkA

DA

SA Korridorüberwachung ASIL C

Beabsichtigte

Funktion

Stecker, Gehäuse, Sicherungen, Platine

Interne

Spannungs-

versorgung

SA

C61

R62

R63 I61

R64

C61

R61

R62

R63

T61

I61

R64

C62

R66

E/E total 100 Fit

lRF <= 10E-09 /h

lMPF <= x 10E-7 /h

lLat <= x 10E-7 /h

lSafe <= x 10E-7 /h


Quality Automotive


Signal Flow

From ISO 26262 Part 4, Annex B


Quality Automotive


Deductive Analysis Positive versus negative Analysis

&

Function 1 (C1, C2, …)

Fu

nctio

n 1

.1

Functio

n 1

.2

Functio

n 1

.3

Function 1.1

(C11, C12, ..)

Function 1.2

(C21, C22, ..)

Function 1.3

(C31, C32..)

Function 1 (C1, C2, ..)

>1

Failure 1

Erro

r 1.1

Error C1.1

Failure Function 1

Erro

r 1.2

E

rror 1

.3

Error C1.2

Error C1.3

>1

>1

&

Cutset Analysis

De Morgan's laws

Error C2.1

Error C2.2

Error C1.3

&

&

>1

100%

0

120%

80%

Timing or Performance

Ideal Function

Drift or Off-Set Function

100%

0

120%

80%


Ideal Function

No Function

P(A ∩ B) = P(A) · P(B)

Axiom from Kolmogorov

Stochastic Independence

Cx = Characteristics of Functions

C(F1) = C(F1.1) v C(F2.2) v C (F3.1)

Failure C2

>1

Failure C1

Petri-Net

Kolmogorow-Smirnow-Test


Quality Automotive


Deductive Analysis Failure Analysis of Functions

100%

0

120%

80%


Ideal Function 100%

0

120%

80%


Ideal Function

No Function Partially or Un-intendent function

100%

0

120%

80%


Ideal Function

Interrupted or oscillated Function

100%

0

120%

80%


Ideal Function

Drift or Off-Set Function


Quality Automotive


Deductive Analysis Positive versus negative Analysis

Function 1 SPF

MPF

Safe

not relevant

Safety

Reliability

Basic Function Safety-related Function Detection Function Reaction Function

Safety Mechanism

&

> Failure 1

Erro

r C1.1

E

rror C

1.2

E

rror C

1.3

Cutset Analysis

Control yawing effects in relation to the intended steering direction

Generate brake torque to limit yawing effects

Avoid over-compensation of yawing effects.

Control corridor between steering angle and yaw rate of the vehicle.

Monitor steering angle of the vehicle.

Monitor yaw rate of the vehicle.

?

Monitor steering

angle of the vehicle.

Monitor yaw rate of

the vehicle.

Control corridor

between steering

angle and yaw rate

of vehicle

Monitoring of

actuator

Avoid over-

compensation of

yawing effects

Enable safety function

Monitoring of actuator Failure of those function are MPF,

since CCA (or realisation leads to an other result)

A failure below the AND-Gate and in the function

only violates safety goals.

That does not mean the function is a lower ASIL.

Enabling of safety

Function


Quality Automotive


Signalflüsse

G

S

R

Ü

?

Dk

P

M

R &

G S R Ü

&

G S R Ü

M

&

Dk P

&

G S R Ü

&

G S R Ü

R

&

Dk P

Fahrzeugbeschleunigung

(Motor abwürgen)

(Lenkbeeinflussung)

Motordrehzahl

(generieren)

Motormoment

(generieren)

Drosselklappen-

stellung

Einspritzdruck

Gaspedalstellung (IST)

Geschwindigkeit (IST)

Motordrehzahl (IST)

Übersetzung (IST)

Korridorüberwachung ASIL B

Korridorüberwachung ASIL C

≥1

&


Quality Automotive


Architecture Including Safety Measures

E1

Intended Function

SM1

C1 C2

U1

U1

U1

U1

SM1.2

SM1.1 C1

C2

7.4.13 Safety analysis shall be carried out at the software architectural level

in accordance with ISO 26262-9:2011, Clause 8, in order to:

⎯ identify or confirm the safety-related parts of the software; and

⎯ support the specification and verify the efficiency of the safety mechanisms.

7.4.14 To specify the necessary software safety mechanisms at the software

architectural level, based on the results of the safety analysis in accordance

with 7.4.13, mechanisms for error detection as listed in Table 4 shall be applied.

7.4.15 This subclause applies to ASIL (A), (B), C and D, in accordance with

4.3: to specify the necessary

software safety mechanisms at the software architectural level, based on the

results of the safety analysis in

accordance with 7.4.13, mechanisms for error handling as listed in Table 5 shall

be applied.


Quality Automotive



ITEM

E2

E1

E3

E4

SG1 SG2

(1) Requirement for the entire Item (e.g. environment)

(2) Requirement of an element (e.g. characteristics of the element)

(3) Requirement of functions (e.g. behaviour, interface consistency)

(1), (2) relevant for element tests

(1), (3) relevant for integration tests


Quality Automotive



ITEM

S2

S1

S3

S4

SG1 SG2

S1

C2

C1

C3

C4

Integration see Part 4, 8.4.3 System integration and testing

Integration see Part 4, 8.4.4 Vehicle integration and testing

Validation of Safety Goal fulfilment see Part 4, 9 Safety validation

SR1 SR2

From Wikipedia:

Integration testing (sometimes called Integration and Testing, abbreviated "I&T") is the phase in software testing

in which individual software modules are combined and tested as a group. It occurs after unit testing and before

validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger

aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the

integrated system ready for system testing.









Quality Automotive



S1

EE1

SW1

SW2

EE2

SR1 SR2

(1) Requirement for the entire System (e.g. operating environment)

(2) Requirement of EE or SW components (e.g. memory size)

(3) Requirement of functions (e.g. Safety Mechanism for HSI)

(1), (3) relevant for Part 4 / 8.4.2 Hardware-software integration and testing

(1), (2) relevant for Part 5 / 10 Hardware integration and testing

Or relevant for Part 6 / 11 Verification of software safety requirements


Quality Automotive



SW C

U2

U1

U3

U4

SR1 SR2

E/E C

P2

P1

P3

P4

SR1 SR2

From Wikipedia













Quality Automotive


SW


Sub.-S

E2

E1

E3

E4

SR1 SR2





Sub.-S

E2

E1 E3

E4

SR1 SR2

F1 F2

P2 P3 P1 EE

M2 M3 M1



Failure Analysis


Random HW Failure









Quality Automotive



SW

Sub.-S

E2

E1

E3

E4

SR1 SR2

F1 F2

P2 P3 P1

EE

M2 M3 M1



Failure Analysis


Random HW Failure

Functional/ Logical View

Technical /

Component View

Component

-FMEA

FMEA on

System-Level

Fault: abnormal condition that can

cause an element (1.32) or an item

(1.69) to fail

Error: discrepancy between a computed,

observed or measured value or

condition, and the true, specified or

theoretically correct value or condition

Failure: termination of the ability of an element

(1.32), to perform a function as

required

&

Function 1

Fu

nctio

n 1

.1

Functio

n 1

.2

Functio

n 1

.3

Function 1.1 Function 1.2 Function 1.3

Function 1


Quality Automotive


Architecture Including Safety Measures

E1

Intended Function

SM1

C1 C2

U1

U1

U1

U1

SM1.2

SM1.1 C1

C2

7.4.13 Safety analysis shall be carried out at the software architectural level

in accordance with ISO 26262-9:2011, Clause 8, in order to:

⎯ identify or confirm the safety-related parts of the software; and

⎯ support the specification and verify the efficiency of the safety mechanisms.

7.4.14 To specify the necessary software safety mechanisms at the software

architectural level, based on the results of the safety analysis in accordance

with 7.4.13, mechanisms for error detection as listed in Table 4 shall be applied.

7.4.15 This subclause applies to ASIL (A), (B), C and D, in accordance with

4.3: to specify the necessary

software safety mechanisms at the software architectural level, based on the

results of the safety analysis in

accordance with 7.4.13, mechanisms for error handling as listed in Table 5 shall

be applied.


Quality Automotive


SW-FMEA

E1

Intended Function - Req.1 -> Behaviour (e.g. UML Diagram)

- Req. 2 -> Integration Environment

- Req. 3 -> Input Out

U1

U1

U1

U1

SM1

SM1.2

SM1.1

- Req.1 (SM1.1) -> Monitor timing and set flag

- Req. 2 (SM1.2)-> Limit out to Setpoint

Architecture Analysis – Measures e.g. Part 6, Table 4

- no function

- unexpected function

- wrong information

- module not executed

- module execution interrupted

- wrong timing


Quality Automotive


Architecture Separation on Architectural Level

E1

Intended Function

U3

U1

U2

U4 SM1

SM1.2

SM1.1

C1 C2

C1

C2

Effect Level

-Intended SW-Function

- - Failure effect

- - Double Failure

- - - Measure SM1

Failure Level

- Sub-Function U1

- - Failure

- - Double Failure

- - - Measure SM1.1

Failure Level

- Sub-Function U1

- - Failure

- - Double Failure

- - - Measure SM1.2

Failure Effect Failure (Error) Read wrong data

wrong processing

wrong configuration

Generate wrong data


Quality Automotive


Architecture Separation on Architectural Level

E1

Intended Function

U3

U1

U2

U4 SM1

SM1.2

SM1.1

C1 C2

C1

C2

Effect Level


- - Failure effect

- - Double Failure

- - - Measure SM1

Failure Level

- Sub-Function U1

- - Failure

- - Double Failure

- - - Measure SM1.1

Failure Level

- Sub-Function U1

- - Failure

- - Double Failure

- - - Measure SM1.2

Failure Effect Failure (Error) Read wrong data

wrong processing

wrong configuration

Generate wrong data

Start Anzahl Adresse Typ Daten Prüfsumme

: 10 00 B0 00 52 6F 62 6F 74 65 72 6E 65 74 7A 2E 64 65 20 20 6B


Quality Automotive


Architecture Integration of Safety Mechanism on Architectural Level

E1

Intended Function

SM1.1 Effect Level


- - Failure effect

- - Double Failure

- - - Measure SM1

Failure Level

- Sub-Function U1

- - Failure

- - Double Failure

- - - Measure SM1.1

Failure Level

- Sub-Function U1

- - Failure

- - Double Failure

- - - Measure SM1.2

E2

E3

SM1.2

E2E

Protected data

Protected data

Un-protected data

Un-protected data

&

&


Quality Automotive


End

Thank you for your attention!

Hans-Leo Ross

Contact:

[email protected]


Functional Safety Management · Development of Global Chassis Control 1978 2001 electronics...

Documents

Transcript of Functional Safety Management · Development of Global Chassis Control 1978 2001 electronics...