ISO 26262 Functional Safety Vector

The model-based approach to
ISO 26262 compliant

development in PREEvision 7.0
Dr. Eduard Metzker

May 2014
© 2014. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V 1.0 2014-05-02
Agenda
> Introduction to PREEvision

Introduction to ISO 26262
ISO 26262 Compliant Development in PREEvision
1. Item Definition
2. Hazard and Risk Analysis
3. Functional Safety Concept
4. Technical Safety Concept
5. HW / SW Interface (HSI)
6. Safety Analysis: FMEA
7. Safety Analysis: FTA
8. Safety Analysis: HW Architectural Metrics
9. Safety Case Report
Summary
Slide: 2
Introduction to PREEvision
Model-Based E/E-System Engineering (1/2)
Components Single Source

Principle
Software Harness
Requirements Networks PowerSupply

Multi-User
Functions Topology Collaboration
Platform Platform Script Based
Signals Mappings
Model Calculations
Variants Routings
Electric Configuration
Logic Management
Lowered
System Level Smarter E/E Better Market
System
Optimization Architecture Expandability Success
Costs
Slide: 3
Model-Based E/E-System Engineering (2/2)
Requirements
 Domain specific language and data

model.
 Single source model across all
PowerMirrorCtrl
development levels and disciplines.
SwitchMatrix PowerMirrorPass
Architecture
Support for reuse and product line

y:PM_y y:PM_y x+:pm_pass_x+ Assembly Net x+:pm_pass_x+
Logical/SW
x:PM_x
sel:PM_selection
x:PM_x
sel:PM_selection
y+:pm_pass_y+
y-:pm_pass_y-
y+:pm_pass_y+
y-:pm_pass_y-

engineering.
x-:pm_pass_x- x-:pm_pass_x-
Type: PowerMirr...
Type: SwitchMatrix
PowerMirrorDriver
x-:pm_driv_x-
y+:pm_driv_y+
x-:pm_driv_x-
y+:pm_driv_y+
 Automated report generation and
consistency checks.
PowerManagement y-:pm_driv_y- y-:pm_driv_y-
KeyIn:KeyIn def12:KeyIn x+:pm_driv_x+ Assembly Net x+:pm_driv_x+
Type: PowerMirr...
Type: PowerMan... Type: PowerMirrorCtrl
 Scripts for Benchmarking

- -
Network/HW
Architecture
PassengerMirror
- cv2:4w
Pass Door Ctrl
- Door Ctrl _0
KA_Pass
Driver Door Ctrl
-
DriverMirror
-
 Automated algorithms for scheduling,
signal routing, etc.
Import and export of industry
- - - DoorLIN:LIN SwtichMatrix
BatMng
-
CANPT:CANC Gateway
-
Body Ctrl
-
PowerSupply -

exchange formats (e.g. AUTOSAR, LDF,
Ground
DBC, FIBEX, RIF/ReqIF…)

Geometry
Wiring/
Slide: 4
Agenda
> Introduction to ISO 26262
1. Item Definition
Summary
Slide: 5
Achieving functional safety effectively means applying best practice to

systems engineering, project management and quality assurance
 …plus additional safety specific analyses (HARA, FMEA, FTA, FMEDA)
 …and being able to demonstrate that you have done exactly this! (safety
case)
The development tool chain should actively support this by:

 …managing the complexity in the E/E system concept design
 …supporting bidirectional traceability between each step of
development
 …ensuring safety analysis and development activities are performed on a
single source model of the system
 …ensuring consistency between all work products referenced by the
safety case (configuration management)
Slide: 6
1 2 3 4
Hazard and Risk Functional Safety Technical Safety

Item Definition Analysis Concept Concept
Definition of features and Identification and Design of a system concept Design of technical system
their interactions, operating classification of hazardous for implementing the safety and component concepts
modes, vehicle states, etc. scenarios and derivation of goals, for example on the including the derivation and
appropriate system safety basis of diagnostic or implementation of technical
goals. redundancy measures. safety requirements
accordingly.
5 6 7 8
Qualitative Quantitative Verification and

Safety Analyses Safety Analyses Validation Safety Case
Application of deductive and Calculation of the probability Confirmation through review, Construction of a structured,
inductive safety analysis of the system failing to meet analysis and test that all coherent, complete and
techniques (e.g. FTA, FMEA) the safety goals and safety requirements are convincing argument that the
to validate the ability of the confirmation that the failure correctly implemented in the system meets all its safety
design to meet the system rate and diagnostic coverage delivered system and that all goals and appropriate
safety goals. targets are met. assumptions made in the regulations.
safety concept are valid.
Slide:
1 2 3 4

 PREEvision Modeling  Hazard and Risk  Logical Architecture  Hardware Architecture
Capabilities Analysis Editor  Activity Chains  Software Architecture
 System Diagrams  Hazard and Risk Analysis  Safety Goal, FSR  TSR
Report  FSC Report  Safety Mechanisms
 HSI Specification Report
 TSC Report
5 6 7 8

 FMEA  Quantitative FTA  Integration with  Comprehensive Safety
 FTA  HW Architectural vTestCenter Case Report Generator
 Automatic FT Synthesis Metrics
 HW/SW Fault
Propagation Analysis
New or improved Features in PREEvision 7.0
Slide:
 Item Definition defining the scope of the item under consideration

 Hazard and Risk Assessment performed according to method outlined
in ISO 26262 – 3
 System Safety Goals incl. definition of ASIL and safe state
 Functional Safety Concept including allocation of safety goals and
functional safety requirements to the system architecture
 Technical Safety Concept including refinement of the functional safety
concept and allocation of technical safety requirements to hardware and
software components
 Analysis (e.g. FMEA) to identify failures that can contribute to a
violation of the safety goals
These work products must be internally consistent, traceable to one

another, well documented and placed under rigorous quality and
configuration management control
Slide: 9
Agenda
> ISO 26262 Compliant Development in PREEvision
1. Item Definition
Summary
Slide: 10
 The lane keeping assistant (LKA) system serves as an example for the
reader to better follow and comprehend the presented concepts.
 The basic goal of the LKA system is to serve „as a mechanism designed to
warn a driver when the vehicle begins to move out of its lane (unless a turn
signal is on in that direction) and to perform correcting measures if
necessary. These systems are designed to minimize accidents by
addressing the main causes of collisions: driver error, distractions and
drowsiness”
 The LKA example does not claim to be complete in any sense.
 Its main purpose is to illustrate the model based system engineering
approach for functional safety which is provided in PREEvision
Slide: 11
1. Item Definition
Artefacts modeled in PREEvision:

 Feature specifications
 Product-line variant model
 Functional and non-functional
requirements
 Operating scenarios and
operating modes
 Logical and topological system
architecture including allocation of
functions
 Dependencies with other systems
Typical migration scenario:

Model those aspects relevant to safety by using imported
requirements, SW-Architectures, communication schedules, etc.
Slide: 12
Agenda
1. Item Definition
> 2. Hazard and Risk Analysis
Summary
Slide: 13
 Drag and drop allocation of item definition artifacts

 Version control and reuse at hazard description level
Slide: 14
Efficiency & Usability Improvements

 Assign functions / features and malfunctions to hazardous events
 Drag & Drop operations for all columns
 Pick operating scenarios and operating modes from catalogues
 Automatic calculation of ASIL
 Auto create hazardous events by D&D of features with malfunctions (library
product line / reuse approach)
 Create and link safety goals directly in table
Slide: 15
Report generation:
 Export direct to MS Excel
 Configurable report generator (Open
Office, Word, PDF)
Example consistency checks to ensure

quality of the assessment:
 At least one safety goal per hazard
 Compatibility of safety goal ASILs to
hazards
 Compatibility of exposure values to
operating scenarios
Slide: 16
Agenda
1. Item Definition
> 3. Functional Safety Concept
Summary
Slide: 17
Slide: 18
 Support detailing safety goals via

 Refinement
 Decomposition
 Prevent errors and inconsistencies

 Trace tables with automatic validation of ASIL decomposition
 Increase efficiency and reduce manual efforts
 Automatically create valid decompositions of Safety Goals, Functional Safety
Requirements and Technical Safety Requirements via metrics
 Propagate ASILs down along trace links
Slide: 19
Agenda
1. Item Definition
> 4. Technical Safety Concept
Summary
Slide: 20
HW Safety Concept
1)
 HW elements can be modeled and associated with technical safety

requirements, faults and safety mechanisms
 Powerful library concept for faults and safety mechanisms
1) Example Based on ISO 26262 – 5, Annex D.1
Slide: 21
Detailed HW Safety Concept
1)
 HW safety design can be detailed down to the device level

 HW elements can be modeled and associated with technical safety
requirements, faults and safety mechanisms
 Powerful library concept for faults and safety mechanisms
1) Example Based on ISO 26262 – 5, Annex E.1
Slide: 22
Detailed SW Safety Concept
 SW safety design, technical safety requirements (TSR) and safety

mechanisms (SM) can be detailed down to ports, interfaces and data
elements
Slide: 23
Agenda
1. Item Definition
> 5. HW / SW Interface (HSI)
Summary
Slide: 24
 Efficiently specify HSI via HSI Editor

 Create HSI-Requirements directly in Editor
 Pick HW/SW Elements in Editor from existing Architecture
 Efficiently generate HSI

Specification (Work Product
required by ISO 26262-4/5/6)
Slide: 25
Agenda
1. Item Definition
> 6. Safety Analysis: FMEA
Summary
Slide: 26
 FMEA refers directly to requirements, architecture and test artifacts enabling

a round-trip approach to architecture design and safety analysis.
visemr7
Slide:
Folie 27
visemr7 Anpassen auf LKA

Metzker, Eduard; 30.04.2014
Use technical architecture Analysis leads to FMEA issues which can

to derive FMEA Parts lead to new requirements or solutions
Slide:
 FMEA actions are directly modeled as change tickets and can be allocated
to human resources, work packages etc.
 Different tables can be configured to provide use case specific views on
the data (e.g. FMEA entries sorted according to RPN).
Slide:
 Consistency checks validate the traceability of prevention and

detection measures.
 FMEAs can be exported according to user configurable
document templates or as an excel file.
Slide:
Agenda
1. Item Definition
> 7. Safety Analysis: FTA
Summary
Slide: 31
 Modeling auf fault trees

 Calculation of minimal cut sets (Qualitative Analysis)
 Calculation of quantitative importance of minimal cut sets (Quantitative
Analysis)
32
Slide:
Local Fault Trees Synthesized Fault Tree
 Local fault trees of HW/SW components can be automatically synthesized

to fault trees of the overall system
33
Slide:
Agenda
1. Item Definition
> 8. Safety Analysis: HW Architectural Metrics
Summary
Slide: 34
Build / Edit
Failure Mode
Library
Design Hardware
Architecture
Perform Analysis
with HW
Architectural
Metrics
Slide: 35
 Build failure mode library by convenient

annotation of all HW library elements (e.g.
Devices Types, Module Types, CPU types etc.) Build / Edit
Failure Mode
Library
 Dedicated Failure Mode Library Editor for
high usability and efficiency
Design Hardware
Architecture
Perform Analysis
with HW
Architectural
Metrics
Slide:
 Use library elements during HW design as usual

 Increased efficiency by reusing failure mode
definitions for design from library Build / Edit Failure
Mode Library
Design Hardware
Architecture
Perform Analysis
with HW
Architectural
Metrics
Slide:
 Allocate target values via D&D

 Assign safety mechanisms and detection
mechanisms via D&D Build / Edit Failure
Mode Library
 Convenient HW architectural metrics calculator
 Instant highlighting of fullfillments and violations
 Covers all metrics defined ISO 26262 - 5
Design Hardware
Architecture
Perform Analysis
with HW
Architectural
Metrics
Slide:
 Integrated iterative Design and Analysis / Optimization
Build / Edit Failure

Mode Library
Design Hardware
Architecture
Perform Analysis
with HW
Architectural
Metrics
Slide:
 Conveniently create HW Architetural Metrics Report
Build / Edit Failure

Mode Library
Design Hardware
Architecture
Perform Analysis
with HW
Architectural
Metrics
Slide:
Agenda
1. Item Definition
> 9. Safety Case Report
Summary
Slide: 41
Check
Consistency
of Work
Products
Generate
Safety
Case
Report
Perform Safety
Engineering Tasks
Slide: 42
Safety Case  Safety Case artifact

collects work products
which are the input for the
safety case report(e.g.
Safety Hazard Analysis,
Item Requirement Packages,
Definition
Hazard FMEA, Safety Plan etc.)
Analysis
 Report distills the content
which is required for
Safety safety case report
Plan
 Always consistent
report based on current
status of work products
 Dramatic reduction of
costs for consistent
documentation
Safety Case Report
Slide: 43
Agenda
1. Item Definition
> Summary
Slide: 44
Summary
1 2 3 4

Available Available Available Available
5 6 7 8

Available Available Available Available
Slide: 45
Summary
Advantages for Functional Safety
 Safety concepts can be systematically derived and evaluated according

to a wide range of criteria:
 Automated consistency checking of safety concepts
 System level optimization, taking into account all architecture levels
(Software, Network, Component, Wiring, Geometry).
 Safety analyses (e.g. FMEA) are based on a single source model

ensuring consistency between the analyses and the development stream.
 Safety Round-Trip Engineering: The results of safety analyses are
directly visible in the model. The impact of changes in the architecture
are directly visible in the relevant parts of the safety analysis.
 See Vector website for technical papers and trainings on functional safety
 http://vector.com/portal/medien/cmc/factsheets/Safety_Solution_FactSheet_EN.pdf
 http://vector.com/portal/medien/distributed_systems/preevision/ATZe_201305_EN.pdf
 https://vector.com/vi_news_en.html#!vi_news_detail_iframe_en,,,1220395,detail.html
Slide: 46
Thank you for your attention.
For detailed information about Vector

and our products please have a look at:
www.vector.com
Author:
Dr. Eduard Metzker
Product Line Process Tools,
Vector Informatik GmbH Stuttgart
Slide: 47

ISO 26262 Functional Safety Vector

Uploaded by

Copyright:

Available Formats

You might also like

ISO 26262 Functional Safety Vector

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISO 26262 Functional Safety Vector

Uploaded by

Copyright:

Available Formats

The model-based approach to

ISO 26262 compliant

Dr. Eduard Metzker

> Introduction to PREEvision

Components Single Source

Requirements Networks PowerSupply

 Domain specific language and data

Support for reuse and product line

 Scripts for Benchmarking

DBC, FIBEX, RIF/ReqIF…)

Achieving functional safety effectively means applying best practice to

The development tool chain should actively support this by:

Hazard and Risk Functional Safety Technical Safety

Qualitative Quantitative Verification and

Hazard and Risk Functional Safety Technical Safety

Qualitative Quantitative Verification and

 Item Definition defining the scope of the item under consideration

These work products must be internally consistent, traceable to one

Artefacts modeled in PREEvision:

Typical migration scenario:

 Drag and drop allocation of item definition artifacts

Efficiency & Usability Improvements

Example consistency checks to ensure

 Support detailing safety goals via

 Prevent errors and inconsistencies

 HW elements can be modeled and associated with technical safety

Detailed HW Safety Concept

 HW safety design can be detailed down to the device level

Detailed SW Safety Concept

 SW safety design, technical safety requirements (TSR) and safety

 Efficiently specify HSI via HSI Editor

 Efficiently generate HSI

 FMEA refers directly to requirements, architecture and test artifacts enabling

visemr7 Anpassen auf LKA

Use technical architecture Analysis leads to FMEA issues which can

 Consistency checks validate the traceability of prevention and

 Modeling auf fault trees

Local Fault Trees Synthesized Fault Tree

 Local fault trees of HW/SW components can be automatically synthesized

 Build failure mode library by convenient

 Use library elements during HW design as usual

 Allocate target values via D&D

 Integrated iterative Design and Analysis / Optimization

Build / Edit Failure

 Conveniently create HW Architetural Metrics Report

Build / Edit Failure

Safety Case  Safety Case artifact

Hazard and Risk Functional Safety Technical Safety

Qualitative Quantitative Verification and

Advantages for Functional Safety

 Safety concepts can be systematically derived and evaluated according

 Safety analyses (e.g. FMEA) are based on a single source model

For detailed information about Vector

You might also like