functional safety management · development of global chassis control 1978 2001 electronics...
TRANSCRIPT
Functional Safety Management
Hans-Leo Ross
System- and Software Safety
Quality Automotive
Functional Safety Management
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
Functional Safety Management
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
3 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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.
4 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Interfaces, Dependability and Complexity to be Managed
5 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
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
Functional Safety Management
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
Verification Criteria
Software Requirements
ENG 4
Verification Criteria
Software Unit Construction
ENG 6
Verification Criteria
Software Architectural Design
ENG 5
Verification Criteria
Software Detailed Design
Verification Criteria
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
Test Cases Acceptance Criteria
ENG 8 BP 5 Test Spec. SW Test
ENG 8
Test Cases Acceptance Criteria
ENG 7 BP 7
Test Spec. System Integration
ENG 9
Test Cases Acceptance Criteria
Test Spec. System Test
ENG 10
Test Cases Acceptance Criteria
ENG 9 BP 7
ENG 10 BP 5
6 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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?
7 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
AFS, EPS Options for Steering Systems
8 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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)
9 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
ESP II – Braking on µ-split
10 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
ESP with Driver Steering Recommendation Braking on -split
11 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
ESP II – ESP with Rear Wheel Steering Intervention Slalom Manoeuvre
12 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
ESP II – ESP with Rear Wheel Steering Intervention Double Lane Change Manoeuvre
13 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
General Hazards addressing Functional Safety
Crash barrier in
- electronic and
- software
14 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
15 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
16 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
17 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
18 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
19 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
20 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Multiple System Levels
See ISO 26262 Part 4 Figure 3
21 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
22 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
See ISO 26262 Part 10 Figure 4
23 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
See ISO 26262 Part 10 Figure 5
24 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
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
Functional Safety Management
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
26 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
27 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Design PhasesDesign PhasesRequirements PhasesRequirements Phases
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
Test PhasesTest Phases
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
28 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Information Flow in Layers
Design PhasesDesign PhasesRequirements PhasesRequirements Phases
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
Test PhasesTest Phases
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
See ISO 26262 Part 10 Figure 8
29 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
30 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Influences to HW/SW Interface
From ISO 26262 Part 4, Annex B
31 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
32 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
33 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Aspects of an architecture including Safety View
34 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
35 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
36 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
37 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
38 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
39 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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>
40 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Technical Element
needs:
- room (resources, memory..)
- energy
- time
produces, effects or reacts on:
- heat
- aging
- noises (stress, vibration, dirt, humidity …)
- chemical
Quality Automotive
Functional Safety Management
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
41 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
42 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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.
43 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
44 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
45 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
46 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Horizontal Layer of Abstraction Comparison between Airborne and Automotive Industry
Komponentenebene
Funktionsgruppenebene
Bauelementeebene C61 C61
R63
47 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Komponentenebene
Architekturebene
Software-Design-Ebene
Horizontal Layer of Abstraction Comparison between Airborne and Automotive Industry
48 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
49 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
50 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deriving of Safety Requirements (e.g. HIS), Consequences for Requirement Analysis
SW
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
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
51 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deriving of Safety Goals, Consequences for Requirement Analysis
SW C
U2
U1
U3
U4
SR1 SR2
E/E C
P2
P1
P3
P4
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.
52 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
53 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
54 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Signal Flow
From ISO 26262 Part 4, Annex B
55 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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%
Timing or Performance
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
56 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deductive Analysis Failure Analysis of Functions
100%
0
120%
80%
Timing or Performance
Ideal Function 100%
0
120%
80%
Timing or Performance
Ideal Function
No Function Partially or Un-intendent function
100%
0
120%
80%
Timing or Performance
Ideal Function
Interrupted or oscillated Function
100%
0
120%
80%
Timing or Performance
Ideal Function
Drift or Off-Set Function
57 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
58 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
&
59 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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.
60 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
61 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deriving of Safety Goals, Consequences for Requirement Analysis
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.
62 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deriving of Safety Goals, Consequences for Requirement Analysis
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
63 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deriving of Safety Goals, Consequences for Requirement Analysis
SW C
U2
U1
U3
U4
SR1 SR2
E/E C
P2
P1
P3
P4
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.
64 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
65 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Deriving of Safety Requirements (e.g. HIS), Consequences for Requirement Analysis
SW
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
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
66 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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.
67 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
68 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
69 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
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
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
70 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
Architecture Integration of Safety Mechanism on Architectural Level
E1
Intended Function
SM1.1 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
E2
E3
SM1.2
E2E
Protected data
Protected data
Un-protected data
Un-protected data
&
&
71 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG
Quality Automotive
Functional Safety Management
End
Thank you for your attention!
Hans-Leo Ross
Contact:
72 / Hans-Leo Ross, Functional Safety / 17.10.2012 © Continental AG