Iso 26262 Dis Tutorial 2010 Final - 1 PDF

ISO 26262
Functional Safety Draft International Standard for Road Vehicles:

Background, Status, and Overview
Barbara J. Czerny, Joseph D’Ambrosio, Rami Debouk,

General Motors Research and Development
Kelly Stashko, General Motors Powertrain
ISO 26262 Road Vehicles - Functional Safety

Draft International Standard Tutorial
ISSC 2010 Minneapolis, Minnesota
 This tutorial presents an overview of the Draft International Standard (DIS) version of
the proposed ISO 26262 Functional Safety standard for road vehicles
 It conveys the content of the standard as it is currently drafted
 Since the release of the DIS, additional technical and editorial changes to the text have been made, but
these will not be covered in the tutorial slides
 Permission was received from ISO to use content taken directly from the ISO/DIS and
contained in this presentation
 The process presented in this tutorial, represents the ISO/DIS 26262 process and is not
intended to reflect or discuss the processes of any specific individual manufacturer

Roadmap
 Background
 Status
 Part 1: Vocabulary and Part 10: Guideline
O
 Part 2: Management of Functional Safety

v
Part 3: Concept Phase
 Part 4: Product Development: System Level
e
 Part 5: Product Development: Hardware Level
Break
r
 Part 6: Product Development: Software Level
v
 Part 7: Production and Operation

i
Part 8: Supporting Processes
 Part 9: ASIL-oriented and Safety-oriented Analyses
e
 Key aspects that have evolved over time
w
 Summary
 Q&A
Draft International Standard Tutorial 3
Background
Barbara J. Czerny

What is ISO 26262?
 Adaptation of IEC 61508 to comply with

the specific needs of E/E systems
within road vehicles
 Specifies a functional safety life-cycle for
automotive products
 Applies to all activities during the safety lifecycle of
safety-related systems comprised of electrical,
electronic, and software components
 Scope
 Series production passenger cars
 Maximum gross weight up to 3500 kg
 Does not apply to E/E systems in special purpose vehicles
 e.g., vehicles designed for drivers with disabilities

Origins of ISO 26262 (Automotive IEC 61508)
MISRA
BNA
FAKRA
OEMs
Suppliers
Technical Services
Initiatives First drafts ISO

IEC Initial work within of TC22
61508 of individual national requirement SC3
companies standardization specifications WG16 11.2005
bodies First WG16 Meeting
2002 2003 1.2004 9.2005
ISO
TC22 (Automotive)
other
Safety Standards RESPONSE
Autom otive SPICE
Quality Standards
Engineering Standards HIS
SC3 (E/E)
WG16 (Functional Safety)

ISO 26262 Working Group 16
Convenor Ch. Jung, Independent Consultant
Secretary E. Fritzsche, VDA
Germany BMW, Daimler , VW, Bosch, Continental
France PSA, Renault, Continental, Valeo
UK Landrover, MIRA, Renesas
Sweden Delphi, Volvo Cars, AB Volvo, Mecel
Italy Centro Ricerche Fiat, Fiat Auto, TRW
Japan Denso, Hitachi, Honda, Nissan, Toyota
USA GM, IBM, TRW,

Belgium Nissan, Toyota Motor Europe
Active membership as of 10/2007

What’s the Difference Between IEC 61508 and ISO 26262?
 IEC 61508:  ISO 26262:
1. Framework standard 1. IEC 61508 Automotive Sector adaptation
2. Implied context of Process/Automation 2. Applies to vehicles with ≥ 4 wheels (carrying
industries (where validation is done after install) passengers, goods)
3. Safety Integrity Levels, “SIL” 3. Automotive SIL, “ASIL”
 SIL 1 – SIL 4  ASIL A-D
 Measure of the reliability of safety functions  Based on the violation of a safety goal
 Includes a quantitative target for the probability of a  Provides requirements to achieve acceptable level of risk
dangerous failure  No exact mapping between SIL’s and ASIL’s
 No exact mapping between SIL’s and ASIL’s  Loose mapping
 Loose mapping  ASIL’s A, B, and D
 SIL’s 1, 2, 3  ASIL C
 Between SIL 2 and SIL 3 4. Focus on safety goals
4. Focus on safety functions 5. Adds required work products

Prescriptive (IEC 61508) vs. Goal-Oriented (ISO 26262)
 Tables
 Example of Part 4 Table 2 “System design verification”
 Goal requirement: System design shall be verified for compliance and completeness with regard to the
technical safety concept. In this aim, the methods and measures in Table 2 shall be considered.
ASIL
Methods
A B C D
1a System design inspectiona + ++ ++ ++
1b System design walkthrougha ++ + o o
2a Simulationb + + ++ ++
2b System prototyping and vehicle tests b + + ++ ++
3 Safety analysesc see Table 1
a Methods 1a and 1b serve as check of complete and correct detailing and implementation of the technical safety requirements
into system design.
b Methods 2a and 2b can be used advantageously as a fault injection technique.
c For conducting safety analyses, see ISO 26262-9: —, Clause 8.
Source: ISO/DIS 26262

More Facts About ISO/DIS 26262
 Focus is on possible hazards caused by malfunctioning behavior of E/E safety-related systems
 failures or unintended behaviours of an item with respect to its design intent
 Includes interactions between E/E safety-related systems
 Process Framework includes the following process steps/deliverables:
 Safety plan & safety goals
 Safety case & documentation
 Bidirectional traceability
 Safety lifecycle
 Validation, verification and independent assessment
 Corresponds to automotive product lifecycle
 Development, validation, release for production vs. development, installation and commissioning, validation in IEC 61508
 Supports distributed development
 e.g., division of work between OEMs/suppliers
 Hazard analysis corresponds to automotive use cases
 Includes “Controllability” in Risk Assessment

Overview of ISO/DIS 26262
Source ISO/DIS 26262 ISO 26262 Road Vehicles - Functional Safety

Flow and Organization of ISO 26262
ASIL-O riented and Safety-Oriented Analysis

Status of Development
 ISO Draft International Standard made available for review by all SC 3 countries July
2009
 First time a version of the standard was made publically available
 DIS ballot held in November 2009 and ballot passed
 Preparing Final Draft International Standard (FDIS)
 Working on resolving comments received with DIS Ballot
 FDIS version will be handed over to ISO for publication in late 2010
 Review of FDIS will only be for editorial changes
 Part 10 will have a second DIS ballot
 Expect publication as a full International Standard in mid-2011

Checkpoint Questions – Background and Status
1. On what standard is ISO 26262 based?
A. ISO/IEC 12207 – Systems Software engineering – Software life cycle processes
B. ISO/IEC 15504 – AutoSpice
C. IEC 61508 -- Functional safety of electrical/electronic/programmable electronic safety-related systems
D. None – ISO 26262 is completely new and developed for Automotive Safety
2. Is there a top Level probability associated with an ASIL
A. Yes
B. No
3. Name the fundamental steps/deliverables of the ISO26262 Process Framework.
A. Safety plan & safety goals, Safety case & documentation, Bidirectional traceability, Safety lifecycle, Validation, verification and
independent assessment
B. Safety plan & potential hazards, Safety cases & documentation, Bidirectional traceability, Safety lifecycle, Validation, verification
and independent assessment
C. Safety plan & safety goals, Safety case & documentation, Bidirectional traceability, Safety lifecycle, Validation, verification and
external assessment
4. Is Controllability included in the Risk Assessment
A. Yes
B. No

A. Yes
B. No
external assessment
A. Yes
B. No

A. Yes
B. No
external assessment
A. Yes
B. No

A. Yes
B. No
external assessment
A. Yes
B. No

A. Yes
B. No
external assessment
A. Yes
B. No

Part 1: Vocabulary
&
Part 10: Guideline on ISO 26262 (Informative)
Rami Debouk

Source ISO/DIS 26262
ISO/DIS 26262 Terms
Safety
Absence of unreasonable risk
Risk
Combination of the probability of occurrence of
harm and the severity of that harm
Exposure
Severity State of being in an operational
measure of the extent of harm situation that can be hazardous
to an individual if coincident with the failure mode
in a specific situation under analysis
Harm Controllability
Physical injury or damage avoidance of the specified harm or damage
to the health of people through the timely reactions of the persons
involved

ISO/DIS 26262 Terms
Item, system, element, & component
System Array
Item
System …
Other technology
E/E Components Communication
Components
Sensor Controller Actuator
Hardware Software Hardware Software Hardware Software Element
Hardware Software Hardware Hardware Software

Software Components
Components Components Components Components Components
Component
Hardware Parts Software Units Hardware Parts Software Units Hardware Parts Software Units
A software component consists of one or more software components, or software units, or both

ISO/DIS 26262 Terms
Failure Types
 Random Hardware Failures

 failure that may occur unpredictably during the lifetime of a hardware element and
that follows a probability distribution
 Systematic Failures
 failure of an element or item that is caused in a deterministic way during
development, manufacturing, or maintenance
 all software faults and a subset of hardware faults are systematic

ISO 26262 Terms
Safety Mechanism
Safety Mechanism
 Activity or technical solution to detect / avoid / control failures or mitigate
their harmful effects
 Implemented by an E/E function or element or in other technologies
 The safety mechanism is either
 able to switch to or maintain the item in a safe state or
 able to alert the driver such that the driver is expected to control the effect of the
failure

ISO 26262 Terms
Work Products
Work product
Information or data
The result of one or more system safety process activities
Format appropriate to the work product’s content
Data files, models, source code, etc.
May include currently existing documents
Several work products may be in one document

ISO 26262 Terms
Confirmation Measures
Confirmation measures
Ensure the sufficient completion of work products and proper execution of
the safety lifecycle.
Provide for the evaluation of the system safety activities and work products
as a whole
Used to determine the adequacy of achievement of the functional safety
goals

ISO 26262 Terms
Safety Case
Safety case
 Communicates a clear, comprehensive and defensible argument (supported by
evidence) that a system is acceptably safe to operate in a particular context.
 Includes references to safety requirements and supporting evidence
 AND a “safety argument” that describes how the safety requirements have been
interpreted, allocated, decomposed, etc., and fulfilled as shown by the supporting
evidence.

Part 2: Management of Functional Safety
Rami Debouk

2.4 – 2.6 Management of Functional Safety
Mgmt & Quality

3.4 Item Definition
Initiation of the Advanced Eng’g

3.5
Safety Lifecycle
Product Eng’g
concept phase
Hazard Analysis and

3.7
Risk Assessment Production
3.8
Functional Safety Service
Concept
4 Product Development
System level
product dev elopment
Production H/W S/W Other External

7.5 5 6 Controllability
Planning Level Level Technologies Measures
Operation
7.6
Planning 4.11 Release for production
7.5 Production
Back to appropriate
lif ecycle phase
after SOP
Operation, Service &

7.6
Decommissioning
8.4 – 8.13 Supporting Processes

Overview
Functional Safety Management requires:

 Planning, coordinating, and documenting activities related to functional safety
 Implementing management plan for all phases of the safety lifecycle, including:
 Overall project-independent functional safety management activities
 Safety management during development
 Safety management after Start of Production (SOP)

Overall Project Independent Safety Management
Objectives
 Define responsibilities of persons, departments and organisations in charge of each phase during the overall safety
lifecycle
 Define management activities during the complete safety lifecycle
Management plan to incorporate:

 Safety culture
 Quality management
 Continuous improvement
 Training and qualification
 Application of the lifecycle

Safety Management during Development
Objectives
 To define responsibilities of the persons, departments and organisations in charge of functional safety for each
phase during development
 Includes activities to ensure functional safety of the item
 Includes activities for confirmation of functional safety measures
 Define management activities during the development phases
Management plan to incorporate:

 Allocation of safety responsibilities and duties
 All safety management activities during development
 Safety case
 Confirmation measures for assessment of functional safety

Safety Management during Development
Confirmation Measures
Confirmation review
 Purpose: Evaluate the safety activity work products for compliance with the requirements of ISO 26262
 How: Work products are evaluated for compliance after completion of select safety activities, and a subsequent review of this
compliance evidence is conducted, resulting in confirmation review reports
Functional safety audit
 Purpose: Evaluate the development process applied (as defined by the product’s safety plan)
 How: Phased reviews during the development process, resulting in audit reports
Functional safety assessment
 Purpose: Evaluate the achieved functional safety of the item
 How: Progressive review of processes and safety measures applied during development to achieve functional safety of the item

Confirmation Measures Requirements
 Depending on the work product and the ASIL assigned to safety goals, confirmation
measures are either recommended or required
 In the case of required confirmation measures:

 There are no requirements on the person performing the confirmation measure
 The confirmation measure shall be performed by a person from a different team, not reporting to
the same direct superior
 The confirmation measure shall be performed, by a person from a different department or
organization, i.e., independent from the relevant department, regarding management, resources, and
responsibility for release for production

Safety Management after Start of Production (SOP)
Objectives
 To define responsibilities of persons, departments and organisations in charge of functional safety after SOP
 Relates to general activities necessary to ensure the required functional safety of the item
Requirements
 Organizational measures to achieve functional safety
 Management of functional safety after SOP
 Field monitoring and collection of data
 Malfunction survey
 Malfunction analysis
 Malfunction solution

Part 2 Work Products
 Company-specific standard for functional safety

 Training and qualification program
 Quality management system
 Safety plan
 Overall project plan
 Safety case
 Results of the Confirmation measures
 Confirmation plan
 Functional safety assessment plan
 Evidence of a field monitoring process

Checkpoint Questions –
1. What are the requirements for Project Independent Safety Management?
A. Safety culture and Quality management
B. Continuous improvement, Training, and qualification
C. Application of the lifecycle
D. All of the above
2. Are a Safety Plan, Confirmation Plan, and a Safety Case required Work products
A. Yes
B. No

D. All of the above
A. Yes
B. No

D. All of the above
A. Yes
B. No

Part 3: Concept Phase
Rami Debouk

Functional Safety during Concept Phase
For a given Product “Item”: 2) Perform a Hazard Analysis ASIL

A, B, C, D
Determine ASIL
3) Identify Safety Goals SAFETY

GOALS
1) Identify relevant safety 4) Identify Functional

lifecycle steps Safety Concept
System
Requirements
Functional Safety
Concept
System
Requirement Functional
Safety
Requirement

Identify relevant safety lifecycle steps
Safety Lifecycle for given item is adapted based on:
 “New development”
 Consider all safety lifecycle steps relevant
 “Modification” of an existing component/system

 Tailor safety lifecycle following an impact analysis of the modifications
 Impact analysis considers the “proven in use argument” if original component/system was not
developed based on ISO 26262

Perform a Hazard Analysis
Determine ASIL
 Situation Analysis & Hazard Identification

“Identify potential unintended behaviors of the item that could lead to a
hazardous event.”
 Vehicle Usage
 Environmental Conditions
 Foreseeable driver use and misuse
 Interaction between vehicle systems

Determine ASIL
RISK ASSESSMENT
Risk = Severity x Frequency x Controllability
S E C
ASIL
ASIL: Automotive Safety Integrity Level

Determine ASIL
 For each identified hazardous scenario, evaluate …
S0 S1 S2 S3
No injuries Light and moderate injuries Severe and life-threatening injuries Life-threatening injuries (survival
(survival probable) uncertain), fatal injuries
E0 E1 E2 E3 E4
Incredible Very low probability Low probability Medium probability High probability
C0 C1 C2 C3
Controllable in Simply controllable Normally controllable Difficult to control or uncontrollable
general

Perform a Hazard Analysis,
Determine ASIL
 Use Severity, Exposure, Controllability to set ASIL
C1 C2 C3
E1 QM QM QM
E2 QM QM QM
S1
E3 QM QM ASIL A
E4 QM ASIL A ASIL B
E1 QM QM QM
E2 QM QM ASIL A
S2
E3 QM ASIL A ASIL B
E4 ASIL A ASIL B ASIL C
E1 QM QM ASIL A
E2 QM ASIL A ASIL B
S3
E3 ASIL A ASIL B ASIL C
E4 ASIL B ASIL C ASIL D
Identify Safety Goals
 Safety Goals are top-level safety requirement as a result of the hazard analysis and risk assessment
 A safety goal is to be determined for each hazardous event evaluated in the hazard analysis
 ASIL determined for the hazardous event is to be assigned to the corresponding safety goal.
 Potential hazard may have more than one safety goal
 If similar safety goals are determined, they can be combined into one safety goal that will be
assigned the highest ASIL of the similar goals

Identify Safety Goals - Combination
Hazard A Safety Goal M

ASIL B
Fault X
Fault Y
Hazard B Safety Goal N
ASIL C
Fault Y
Per analysis results, Fault Y is implicated for both
Goals M and N but since Goal N is associated with a
Fault Z
higher ASIL (C), safety mechanisms to cover for Fault
Y must satisfy ASIL C requirements.

Identify Functional Safety Concept
Functional Safety Concept

is composed of the
Functional Safety Requirements.

 Item definition
 Impact Analysis
 Hazard analysis and risk assessment
 Safety goals
 Review of hazard analysis, risk assessment and the safety goals
 Functional safety concept
 Review of the functional safety requirements

Checkpoint Questions - Part 3: Concept Phase
1. What determines the activities needed for a modification of a previous product?
A. ASIL
B. Item Definition
C. Impact Analysis
D. Hazard and Risk Analysis
2. What 3 factors determine an ASIL?
A. Severity, Occurrence, and Detection.
B. Risk, Controllability and Severity.
C. Severity, Controllability, and Exposure
3. What are the 4 ASILs
A. A, B, C, D
B. 1,2,3,4
C. Critical, Severe, serious, and moderate

A. ASIL
B. Item Definition
C. Impact Analysis
A. A, B, C, D
B. 1,2,3,4

A. ASIL
B. Item Definition
C. Impact Analysis
A. A, B, C, D
B. 1,2,3,4

A. ASIL
B. Item Definition
C. Impact Analysis
A. A, B, C, D
B. 1,2,3,4

Part 4: Product Development: System Level
Barbara J. Czerny

Overview Part 4: Product development: system level
 Identify and plan the functional safety activities

Initiation of Product development at the system
4-5
for each sub-phase of system development level
 Includes supporting processes activities

Specification of the technical safety requirements
4-6
 Includes methods to be used
Safety Plan
 Tailoring of the lifecycle
4-7 System Design
Part 5: Product development: hardware Part 6: Product development: software

level level
 Applies to both systems and subsystems
Item Integration and testing
4-8
Safety Validation
4-9
4-10 Functional safety assessment
4-11 Release for production

Example Product Development at the System Level
Initiation of Product development at the system
System 4-5
level

4-6
4-7 System Design
Sub-system A Sub-system B
Specification of the technical safety requirements Specification of the technical safety requirements
4-6 4-6
4-7 System Design 4-7 System Design
Part 5: Product Part 6: Product Part 5: Product Part 6: Product

development: hardware development: software development: hardware development: software
level level level level
Hardware-software integration and testing Hardware-software integration and testing

4-8.4.2 4-8.4.2
4-8.4.3 System integration and testing
Source ISO/DIS 26262 4-8.4.4 Vehicle integration and testing

Specification of the Technical Safety Requirements
 Objectives
 Develop the technical safety requirements
 Refinement of the functional safety requirements considering the preliminary architectural
assumptions
SAFETY
GOALS
 Verify the technical safety

Functional Safety Concept
requirements comply with
the functional safety
Functional
requirements Safety
Requirement Prelim. Arch.
Assumptions
Verify Refine
Describe how to implement the
Functional Safety Concept Technical
Safety
Requirement

Specification of the Technical Safety Requirements Cont’d.
 Specification includes
 Safety-related functional and safety-related non-functional dependencies
 Between systems or elements of the item and between the item and other systems
 System/element response to stimuli
 Safety mechanisms
 Related to detection, indication and control of faults, that enable the system to achieve and
maintain a safe state, …
 Safety-related requirements for production, operation, maintenance and decommissioning
 Define system properties

 External interfaces, constraints, system configuration requirements
 Specify other functional and non-functional requirements

System Design and Technical Safety Concept
 Objectives
 Develop the system design and the technical safety concept
 Verify that the system design and technical safety concept comply with the technical safety
requirements specification
SAFETY
GOALS
 Specify the system design based on
 Functional safety concept Functional Safety Concept
 Preliminary architectural
Functional
assumptions Safety
Requirement Prelim. Arch.
 Technical safety requirements Assumptions
specification
Technical Safety Concept
Implementation of
Technical Safety
Requirements Verify System
Technical Design
Safety
Requirement Verify

System Design and Technical Safety Concept Cont’d
 Requirements for avoiding systematic failures
 e.g., deductive and inductive analysis to identify causes and effects of systematic failures, use well-trusted
design principles, apply properties to modular design, etc.
 Overall requirements for the control of random hardware failures during operation
 e.g., specify measures for detection and control, set target values for metrics in part 5 for final evaluation
at the item level, etc.
 Allocate each technical safety requirement to hardware, software, or both
Allocate Hardware
Refine
Technical
Refine
Safety
Requirement Allocate Software

System Design and Technical Safety Concept Cont’d.
 Specify the hardware –software interface (HSI)
 Specify requirements for production, operation, service, and decommissioning

 e.g., measures to support field monitoring, specification of diagnostic features to allow fault identification
by service personnel, etc.
 Continue development at the hardware and software levels

4-6
4-7 System Design
Part 5: Product Part 6: Product

development: hardware development: software
level level

Item Integration and Testing Part 5: Product Part 6: Product
development: hardware development: software
 Objectives level level
 Integrate the elements of an item 4-8 Item Integration and testing
 If applicable, systems or elements of other

technologies and external measures or systems
 Test the integrated item for compliance with
each safety requirement
 Verify that the system design is correctly implemented by the entire item
 Process
Hardware-software integration and testing
4-8.4.2
4-8 Item Integration and testing

4-8.4.3 System integration and testing
4-8.4.4 Vehicle integration and testing

Part 5: Product Part 6: Product
Safety Validation development: hardware
level
development: software
level
 Objectives
 Evidence of compliance with the 4-8
functional safety goals

 Evidence that the safety concepts are 4-9
Safety Validation
appropriate for the functional safety of the item

 Evidence that the safety goals are correct, complete, and fully achieved at the vehicle level
 Validation of safety goals is applied to the item integrated at the vehicle level
 Includes: E/E system, software (if applicable), hardware, elements of other technologies, external measures
 Validation plan includes
 Validation test procedures for each safety goal with pass/fail criteria
 Scope of the application
 e.g., configuration, environmental conditions, driving situations, etc.

Functional Safety Assessment Part 5: Product
development: hardware
Part 6: Product
level level
 Objective 4-8
 Assess the functional safety achieved Safety Validation

4-9
by the item
Functional safety
4-10
assessment
 Initiated by the entity with responsibility for functional safety

 e.g., the vehicle manufacturer

Functional Safety Assessment Cont’d.
Identify topics to be addressed by the
FSA for each step of the safety Confirmation Plan
lifecycle (Part 2)
Recommendations from
Conduct Assessment
previous Functional Safety
according to Part 2 Considering Assessments
By
Results from functional safety
Review processes & safety measures applied audits and confirmation
during development to achieve functional reviews
safety of the item
Conditional
Acceptance Rejection
Acceptance Perform corrective actions and
Functional Safety Considered Evident
reassess
Release for Production Part 5: Product
development: hardware
Part 6: Product
level level
 Objective
4-8
 Specify the criteria for the release for
production at the completion of item development
Safety Validation
4-9
 Confirmation that the item complies with
the requirements for functional safety 4-10
Functional safety
assessment
at the vehicle level
 Ready for series-production and operation 4-11
Release for
production
 Only approved if the required work products are available and provide confidence of
functional safety
 Functional safety assessment report, safety case
 Requires appropriate documentation of functional safety for release for production
 Name and signature of person in charge of release, Version of released item, etc.

 Overall project plan (refined)  Requirements for production, operation,
 Safety plan (refined) service, and decommissioning
 Validation plan  HW/SW interface specification (HSI)
 Functional safety assessment plan  Integration testing specification
 Technical safety requirements specification  Integration testing report
 System level verification report  Validation report
 Technical safety concept  Functional safety assessment report
 System design specification  Release for production report
 Item integration and testing plan

Checkpoint Questions - Part 4: Product Development System Level
1. Where are the safety mechanisms specified and where are they allocated to hardware and
software?
A. Item Definition and Hazard Analysis and Risk Assessment
B. Hazard Analysis and Risk Assessment
C. Functional Safety Concept and Functional Safety Requirements
D. Technical Safety Requirements and System Design
2. Which of the following is true concerning Safety Validation?
A. Item tested as integrated at vehicle level
B. Test procedures for each safety goal (pass/fail)
C. Within scope of driving situations, environmental conditions, configuration, etc.
D. All of the above

software?
D. All of the above

software?
D. All of the above

Part 5: Product Development: Hardware Level
Rami Debouk

Overview
 Identify relevant safety lifecycle steps for item Technical Safety

hardware engineering Concept (Part 4)
 Identify Hardware safety requirements Hardware Safety

 Design hardware, protecting for safety concerns Requirements
 Assess architectural constraints

Hardware Design
 Evaluate probability of violation of a safety goal & Verification
Architectural
 Hardware safety integration and test Constraints
Probability
of Safety Goal
Violation
Hardware Integration
& Testing

Establish Target Safety Goal Metrics
Single Point Undetected
& Residual Dual Point
Single Point = Faults Latent Multiple = Faults
Fault metric Point Fault metric

All Single Point
Faults & Residual
Faults
 Single Point Fault: fault leads directly to the violation of the safety goal
 Residual Fault: portion of a fault, not covered by a safety mechanism, that by itself leads to
the violation of a safety goal Latent
Single Point
ASIL Multiple Point
 Dual/Multiple Point Fault: combination of two/multiple independent faults that leads Fault Metric
Fault Metric
directly to the violation of a safety goal
 Latent Fault: multiple point fault whose presence is not detected by a safety mechanism nor B > 90% > 60%
perceived by the driver
 Safe Faults: fault whose occurrence will not significantly increase the probability of violation C >97% >80%
of a safety goal
D >99% >90%

Evaluating violation of Safety Goal target metrics due to random
hardware failures
“…to provide criteria to demonstrate that the risk of safety goal violation
due to random hardware failures of the item is sufficiently low.”
Method 1: Probabilistic Method for Random Hardware Method 2: Residual Risk

Failure Assessment Method
Quantitative analysis to evaluate Evaluation of residual risks due to
probability of violation of safety goal. random hardware failures of the item,
 Latent fault metric targets to show that the residual risk is
 Metrics are compared to target goals to demonstrate sufficiently low.
achievement of safety goal

Method 1:
Probabilistic Method for Random Hardware Failure
Compute probability of violation of each safety goal due to random hardware failures and then
compare it to a target value
Quantitative target values for maximum probability of violation of each safety goal due to random
hardware failures are defined from sources such as:
1. Quantitative analysis on similar well-trusted designs, using well known failure rate databases.
2. Derived from field data of similar well-trusted designs
3. Derived from Table G-1
Random hardware failure target

ASIL Level values
D < 10-8 per hour
C < 10-7 per hour
B < 10-7 per hour
A < 10-6 per hour

Method 1:
Probabilistic Method for Random Hardware Failure
Quantitative Analysis considers:

a) Single point faults, residual faults, dual point faults
b) Item architecture
c) Estimated hardware part failure rates (all modes) for single point faults
d) Estimated hardware part failure rates for dual point faults
e) Diagnostic coverage (Tables B.1-B.12 may be used)
f) Exposure duration (in case of multiple point faults)
g) Remaining dependent faults due to random hardware faults

Method 2 – Residual Risk Evaluation Method
Individually evaluate each single point fault, residual fault and dual point failure
of the hardware parts which violate the considered safety goal.
Defines Failure Rate Classes based on random hardware failure targets :

Failure Rate Class 1 < 10-10

Method 2 – Evaluation Method – Single Point Faults
A single point fault occurring in a hardware part shall be considered as acceptable, if the
corresponding hardware part failure rate is:
ASIL of
Failure Rate Class
Safety Goal
Class 1 (10-10) +
D dedicated measures to ensure Class 1
Class 2 (10-9) +
C dedicated measures to ensure Class 2
OR Class 1 (10-10)
Class 2 (10-9)
B OR Class 1 (10-10)

Hardware Integration & Testing
 To ensure, by testing, the compliance of the integrated hardware elements with the hardware safety
requirements

 Overall project plan (refined)  Requirements for production and operation
 Safety plan (refined)  Assessment of the effectiveness of the system architecture to
cope with the hardware random failures
 Hardware safety requirements specification
(including test and qualification criteria)  Review report of assessment of the effectiveness of the
system architecture to cope with the hardware random
 Hardware architectural metrics requirements failures
 Random hardware failure requirements  Evaluation of random hardware failures
 Hardware-software interface specification (refined)  Specification of dedicated measures
 Hardware safety requirements verification report  Review report of evaluation of violation of the safety goal
 Hardware design specification due to random HW failures
 Hardware safety analysis report  Hardware integration and verification report
 Hardware design verification report

Checkpoint Questions - Part 5: Product Development Hardware Level
1. What is the Single Point Fault Metric requirement for ASIL D?

A. >99%
B. >97%
C. >90%
D. None of the above
2. What is the Latent Fault Metric requirement for ASIL C?
A. >90%
B. >80%
C. >60%


A. >99%
B. >97%
C. >90%
2. What is the Latent Fault Metric requirement for ASIL D?
A. >90%
B. >80%
C. >60%


A. >99%
B. >97%
C. >90%
2. What is the Latent Fault Metric requirement for ASIL D?
A. >90%
B. >80%
C. >60%

Break

Part 6: Product Development: Software Level
Barbara J. Czerny

Part 6 Overview Part 6: Product development: Software level
 Planning 6-5
Initiation of Product development at the software
level
 Software development activities wrt functional safety

Specification of software safety requirements
6-6
 Supporting processes
 Methods to achieve requirements of assigned ASIL
6-7 System Architectural Design
 Guidelines and tools
 Coordination with product development at hardware level 6-8
Software unit design and implementation
 Lists requirements to be satisfied for each phase of 6-9

Software unit testing
the software development lifecycle

 Dependent on ASIL 6-10 Software integration and testing
6-11 Verification of software safety requirements

Part 6 Overview Cont’d. Source ISO/DIS 26262
 ASIL of software safety requirements flows down

Requirements Flow Down
 Requires qualification of software tools used for
software development (Part 8 Clause 11) ASIL
 Identifies criteria to be addressed in design and

coding guidelines
 e.g., use of language subsets, support for abstraction and
modularity,
strong typing, …
Allocation to HW/SW

Tailoring of the lifecycle at the software level based on:
Evaluate work products to ensure they Ensure that the item developed, or
meet previously established requirements parts of it, comply with the
Reference Phase Model for the Software Development requirements

Specification of Software Safety Requirements
 Objectives 6-6 Spec. of SW
Safety Reqs.
6-11 Verif. of
SW Safety Reqs
 Specify the SW safety requirements 6-7 SW Arch. 6-10 SW

from the technical safety requirements Design Integration Tstg.
(including their ASIL) and the system design specification 6-8 SW Unit 6-9 SW Unit
Des. & Imp. Testing
 Detail the hardware-software interface requirements SAFETY

GOALS
Functional Safety
 Verify that the SW safety requirements are consistent with the Concept
technical safety requirements and the system design Functional
specification Safety
Requirement
Technical Safety
Concept
System
Technical Design
Compliant with technical safety requirements and Safety
System Design Requirement
system design, and consistent with relevant Refine /
hardware safety requirements Verify Allocate Verify
6-5 Spec. of SW Software Safety
Safety Reqs. Requirements

Software Architectural Design 6-6 Spec. of SW 6-11 Verif. of
Safety Reqs. SW Safety Reqs
 Objectives
6-7 SW Arch. 6-10 SW
 Develop a SW architectural design that Design Integration Tstg.
 Realizes the software safety requirements

6-8 SW Unit 6-9 SW Unit
 Verify the SW architectural design Des. & Imp. Testing
 Gives requirements for notations for SW architectural design

 Goal – appropriate levels of abstraction
 Includes design principles to apply to achieve modularity, encapsulation, minimum complexity

 e.g., hierarchical structure, restricted size of SW components/interfaces …
 Allocates SW safety requirements to the SW components

 SW components of different ASILs SW Safety Reqs
 Treat as belonging to the highest ASIL ASIL A
 Exception: adequate freedom from SW

Comp1 SW
SW
Comp 3
interference between SW components Comp1 SW
Comp 1 SW
ASILs A,C,D Comp 2
ASIL D ASIL B

Software Architectural Design Cont’d.
 Safety analysis (Part 9-8) applied to the software architecture to
 Help identify and confirm safety-related characteristics
 Support specification of the safety mechanisms
 Requirements for addressing error detection

 e.g., plausibility checks, detection of data errors, control flow monitoring, …
 Requirements for addressing error handling

 e.g., static recovery mechanisms, graceful degradation, correcting codes for data, …
 Specifies verification requirements

 Includes control flow analysis, data flow analysis, inspections, etc.
6-6 Spec. of SW
Safety Reqs. Target
Design Hardware
Guidelines Compliant
Adherent 6-7 SW Arch. Compatible
Design

Software Unit Design and Implementation
6-6 Spec. of SW 6-11 Verif. of
 Objectives Safety Reqs. SW Safety Reqs
 Specify the software units in accordance 6-7 SW Arch. 6-10 SW

Design Integration Tstg.
with the software architectural design
and the associated software safety 6-8 SW Unit 6-9 SW Unit
Des. & Imp. Testing
requirements
 Implement the software units as specified
 Verify the design of the software units and their implementation
 Notation requirements based on ASIL

 To allow subsequent development activities to be performed correctly and effectively
 Specifies design principles to apply to achieve robustness, testability, simplicity, …
 e.g., one entry and one exit point in subprograms and functions, limited use of pointers, …

Software Unit Design and Implementation Cont’d.
 Specifies verification requirements
 Control flow analysis, data flow analysis, static code analysis, walkthrough’s,
inspections, …
6-6 Spec. of SW
Safety Reqs.
Completeness
Hardware-
Coding 6-7 SW Arch. Software
Guidelines Design Interface
Compliant Completeness Compliant

Target
Source 6-8 SW Unit
Hardware
Code Spec. Des. & Imp.
Compliant Compatible

Software Unit Testing 6-6 Spec. of SW 6-11 Verif. of
 Objective
 Demonstrate that the software units satisfy their Design Integration Tstg.
specification and do not contain undesired functionality
 Addresses 6-8 SW Unit
Des. & Imp.
6-9 SW Unit
Testing
 SW unit test planning

 Selection of test methods
 Interface test, resource usage test, …
 Methods for deriving test cases to demonstrate appropriate specification of test cases
 Analysis of requirements, boundary value analysis, …
 Test environment requirements
 As close as possible to the target environment
 Evaluation criteria
 Compliance with expected results, & pass or fail criteria
 Demonstrates
 Compliance with the SW unit design specification and the HW/SW interface
 Correct implementation of the functionality
 Absence of unintended functionality
 robustness

Software Integration and Testing 6-5 Spec. of SW 6-10 Verif. of
 Objectives
 Integrate the software components 6-6 SW Arch.
Design
6-9 SW
Integration Tstg.
 Demonstrate that the software architectural

6-7 SW Unit 6-8 SW Unit
design is correctly realized by the embedded Des. & Imp. Testing
software
 Addresses
 Planning
 Selection of test methods to demonstrate that the SW components and embedded SW achieve
 Compliance with the architectural design and the HW/SW interface
 Correct implementation of the functionality
 Robustness
 Sufficiency of the resources to support the functionality
 Example test methods - Fault injection, resource usage tests, …
 Methods for deriving test cases
 Analysis of requirements, boundary value analysis, …
 Requirements on the test environment

Verification of Software Safety 6-6 Spec. of SW 6-11 Verif. of
Requirements Safety Reqs. SW Safety Reqs
 Objective
Design Integration Tstg.
 Demonstrate that the embedded 6-8 SW Unit

Des. & Imp.
6-9 SW Unit
Testing
software fulfills the software safety
requirements in the target environment
 Addresses
 Planning
 Selection of test environments
 Hardware-in-the-loop, vehicles, …
 Execution on the target hardware
 Evaluation criteria
 Compliance with expected results, coverage of the software safety requirements, pass/fail criteria

 Safety plan (refined)  Software verification report
 Software verification plan  Software architectural design specification
 Design and coding guidelines for modelling  Safety analysis report
and programming languages
 Dependent failures analysis report
 Software tool application guidelines
 Software unit design specification
 Software safety requirements specification
 Software unit implementation
 Hardware-software interface specification
(refined)  Software verification specification (refined)
 Software verification plan (refined)  Embedded software

Checkpoint Questions - Part 6: Product Development Software Level
1. Do software requirements inherit an ASIL?

A. Yes
B. No
2. Do Software components always inherit the highest ASIL?
A. Yes
B. No
3. Where is the verification of software safety requirements executed?
A. On the target system
B. In the system model
C. In the software to software integration phase


A. Yes
B. No
A. Yes
B. No


A. Yes
B. No
A. Yes
B. No


A. Yes
B. No
A. Yes
B. No

Part 7: Production and Operation
Barbara J. Czerny

Production and Operation
 Specifies requirements on production, operation, service, and decommissioning
 Production objectives
 Develop a production plan for safety-related products
 Ensure that the required functional safety is achieved during the production process
 Planning
 Includes planning for safety-related special characteristics
 e.g., temp. range for specific processes, material characteristics, configuration …
 Considers requirements for production, conditions for storage, transport, and handling of hardware elements,
approved configurations, …
 Describes, as applicable production process flow and instructions, production tools and means, …
 Requirements for production

 Implementation of the planned production process, Analysis of process failures and monitoring of corrective
measures, …

Production and Operation Cont’d.
 Operation, service (maintenance and repair), and decommissioning objectives
 Define the scope of customer information, and maintenance and repair instructions regarding the safety-related
products in order to maintain the required functional safety during operation of the vehicle
 Provide the requirements concerning activities addressing safety issues before disassembly
 Planning
 Considers requirements for operation, the warning and degradation concept, measures for field data collection and
analysis, …
 Maintenance plan describes methods required for maintenance including steps, intervals, means of maintenance,
and tools
 User manual requirements

 Relevant functions and operating modes, how to use them in the intended way, required maintenance activities,
warnings regarding known hazards resulting from interactions with third party products, …

Production and Operation Cont’d.
 Operation
 Field monitoring process for functional safety events related to the item needs to be implemented as
planned
 Requirements for decommissioning activities need to be developed

 Measures to be taken before disassembling the vehicle
 Emphasis on deactivating the systems or elements that would lead to violation of a safety goal if activated
during disassembly or decommissioning

 Production plan (refined)  Maintenance plan (refined)

 Production Control plan (refined)  Repair instructions
 Documentation of performed control  User manual
measures
 Instructions regarding field observations
 If applicable, requirements on
 Instructions for decommissioning
producibility at system, hardware or
software development level  If applicable, requirements concerning
operation, maintenance and decommissioning
 Assessment report for capability of the
at system, hardware or software development
production process
level

1. What requirements are specified in the clause on Production and Operation?
A. Production
B. Operation
C. Service and decommissioning
D. All of the above

1. What requirements are specified in the clause on Production and Operation?
A. Production
B. Operation
C. Service and decommissioning
D. All of the above

Part 8: Supporting Processes
Barbara J. Czerny

Requirements for Supporting Processes
 Objective
 Consolidate common requirements to maintain consistency
 Supporting Processes
 Interfaces within distributed developments
 Specification and management of safety requirements
 Configuration management
 Change management
 Verification
 Documentation
 Qualification of software tools
 Qualification of software components
 Qualification of hardware components
 Proven in use argument

Clause 5: Interfaces Within Distributed Developments
 Objective
 Describe procedures and allocate responsibilities within distributed developments ( e.g.,
vehicle manufacturer and supplier) for items and elements
 Supplier selection criteria

 Evaluate the supplier’s capability to develop and produce items of comparable
complexity and ASIL according to ISO 26262
 Supplier’s quality management system, experience, capability in developing products of
comparable complexity and ASIL, …

Clause 5: Interfaces Within Distributed Developments Cont’d.
 Development Interface Agreement (DIA) specifying:
 Safety managers at the customer's and supplier's
 Joint tailoring of the safety lifecycle, with identification of activities and processes to be performed by the customer and by the
supplier;
 The information required; work products to be exchanged; persons responsible
 Communication of target values (derived from system level targets) specified to fulfil the targets for single point faults metric
and latent faults metric, and evaluation of violation of the safety goal due to random hardware failures
 Coordination of supporting processes and tools
 Including interfaces assuring compatibility between the customer and the supplier
 Adequate customer access to supplier work products to allow completion of safety case
 Information related to execution of DIA, including Safety Assessment at the supplier’s facility, and post-
production support

Clause 5: Interfaces within distributed environments
Work Products
 Supplier selection report

 Development Interface Agreement
 Supplier’s project plan
 Supplier’s safety plan
 Safety Assessment Report
 Supply agreement

Clauses 6 through 10: Existing engineering processes
 Include requirements for existing engineering processes

 Accommodate the functional system safety activities defined in other parts of the standard
 Engineering process capabilities addressed include:

 Clause 6: Specification and Management of safety requirements
 Clause 7: Configuration Management
 Clause 8: Change management
 Clause 9: Verification
 Clause 10: Documentation

Clause 6 – Specification and Management of Safety Requirements
 Objectives
 Ensure correct specification of safety requirements with respect to attributes and
characteristics
 Support consistent management of safety requirements throughout the safety lifecycle
 Clause includes requirements for
 Notations for the specification of safety requirements
 Attributes and characteristics of safety requirements
 Unambiguous and comprehensible, atomic, internally consistent …
 Properties for the collection of safety requirements
 Hierarchical, complete, externally consistent, maintainable, …
Management of safety requirements
 Traceability, configuration management, verification
Work Product – Safety Plan (refined)

Clause 7 – Configuration Management
 Objective
 Ensure unique identification and reproducibility of work products at any time
 Ensure traceability of relationships and differences between earlier and current versions
 Compliance with the requirements of ISO TS 16949, 4.2.3 and ISO 12207, 6.2
 Work products listed in ISO 26262 are subject to configuration management
 Tools subject to configuration management
 Software tools and software development environments
 Test tools and test environments
 Work product – configuration management plan

Clause 8 – Change Management
 Objective
 The analysis and management of changes to safety-related work products occurring throughout the safety
lifecycle
 Involves
 Systematically planning, controlling, monitoring, implementing, and documenting changes, while maintaining
consistency of all work products

 Planning and initiating change management
 Change requests
 Unambiguously identified, author, reason for change, exact description, …
 Impact analysis of the change requests
 Type of change, affected work products, impact on functional safety ...
 Deciding on a change request
 Carrying out and documenting the change

Clause 8 – Change Management – Work Products
 Change management plan

 Change request
 Impact analysis
 Change request plan
 Change report

Clause 9– Verification
 Objective
 Ensure that all work products
 are correct, complete, and consistent
 meet the requirements of ISO 26262

 Planning of verification
 Specification of verification
 Selection and specification of verification methods, specification of test cases, …
 Execution of verification
 Verification shall be executed as planned and specified
 Evaluation of verification
 Requirements on the evaluation of the verification results
 Work products – verification plan, specification of verification, verification report

Clause 10 – Documentation
 Objectives
 Develop a documentation management strategy so that every phase of the entire safety lifecycle
can be executed effectively and can be reproduced

 Availability of documentation
 Content of documentation
 e.g., precise and concise, structured in a straightforward manner, easy to understand, maintainable, etc.
 Work Products – document management plan, documentation requirements

Clause 11 – Qualification of Software Tools
 Objective
 Provide evidence of SW tool suitability for use in developing a safety-related item or element
 Confidence in correct execution of activities and tasks required by ISO 26262
 Clause includes
 Planning of qualification of a software tool
 Classification of a software tool
 Tool impact
 Possible violation of safety requirement if tool is malfunctioning or producing erroneous output (TI0 – no
possibility, TI1 – possibility)
 Tool detection
 Possibility of preventing or detecting that the software tool is malfunctioning or producing erroneous output
(TD1 – TD4)
 Tool confidence level
 Based on tool impact and tool detection determinations (TCL1 – TCL4)

Clause 11 – Qualification of software tools
 Methods for qualifying software tools
 For TCL2, TCL3, and TCL4
 Increased confidence from use Dependent on Tool
 Evaluation of the development process Confidence Level
and ASIL
 Validation of the software tool
 Development in compliance with a safety standard
 Description of each method for qualification

 Verification requirements of the qualification of software tools
 Work Products – software tool classification analysis, software tool qualification
plan, software tool documentation, software tool qualification report

Clause 12 – Qualification of Software Components
 Objectives
 To enable the re-use of existing software components as part of items, systems, or elements developed in
compliance with ISO 26262 without completely re-engineering the software components
 To show their suitability for re-use
 Required information to treat a software component as qualified

 Specification of the software component
 Evidence that the software component complies with its requirements
 Evidence that the software component is suitable for its intended use
 Requirements on the verification of the qualification of a software component
 Work Products – software component documentation, software component qualification

report

Clause 13 – Qualification of Hardware Components
 Objectives
 To show the suitability of intermediate level hardware components and parts for their use as part
of items, systems, or elements, developed in compliance with ISO 26262
 Concerning their functional behavior and their operational limitations
 Provide relevant information regarding
 Failure modes and their distribution
 Diagnostic capability with regard to the safety concept for the item

Clause 13 – Qualification of Hardware Components Cont’d.
 Qualification using analysis and/or testing
 Ensure that the functional performance of components is adequate for the purposes of the safety concept
 Identify failure modes and models by using appropriate tests or analyses
 Ensure sufficient robustness and evaluate limitations of component use
 Requirements on qualification by analysis and testing
 Requirements on qualification report
 Pass/fail with respect to the operating envelope
 Verification of the qualification report
 Work Products
 Qualification plan
 Hardware component testing plan, if applicable
 Qualification report

Clause 14 – Proven in use
 Objective
 Provide guidance for proven in use argument
 Alternate means of compliance with ISO 26262 requirements
 May be used in case of reuse of existing items or elements
when field data is available
 Proven in use credit does not eliminate need for
integration safety lifecycle activities
 Considers:
 Service period for the item/element
 Changes to the candidate for a future
application

Clause 14 – Proven in use
Requirements on analysis of field data
 Configuration management and change control applied to candidate
Target values for proven in use
 Observable incident rate must not exceed targets for the ASIL of the
candidate
 Observable incident is a failure that is reported to the
manufacturer and caused by the candidate with the Table 7 – Targets for minimum
service period for candidate
potential to lead to the violation of a safety goal Mi nimum service
 Field problems need to be recorded and retrievable ASIL
period without
observable incident
(hours)
D 1.2 · 109
 Work Products C 1.2 · 108
 Proven in use credit B 1.2 · 108
 Definition of candidate for proven in use argument A 1.2 · 107
 Proven in use analysis reports Source ISO/DIS 26262

Checkpoint Questions - Part 8: Supporting Processes
1. What specifies the interfaces between a manufacturer and supplier in a distributed development?
A. The system specification
B. The purchase order
C. The Development Interface Agreement (DIA)
2. What tools are subject to configuration management?
A. Software tools and software development environments
B. Test tools and test environments
C. All of the above
3. What is the objective of verification?
A. Ensure that all work products are correct, complete, and consistent
B. Ensure that all work products meet ISO 26262 requirements
C. All of the above
4. What is required for a Proven in Use Argument?
A. Definition of the candidate for proven in use argument
B. Analysis of changes to the candidate
C. Analysis of field data
D. All of the above

C. All of the above
C. All of the above
D. All of the above

C. All of the above
C. All of the above
D. All of the above

C. All of the above
C. All of the above
D. All of the above

C. All of the above
C. All of the above
D. All of the above

Part 9: ASIL-oriented and Safety-oriented Analyses
Rami Debouk

ASIL-oriented and safety-oriented analyses
 Requirements decomposition with respect to ASIL tailoring

 Criteria for coexistence of elements
 Analysis of Dependent Failures
 Safety Analyses

Requirements decomposition with respect to ASIL tailoring
Objectives
 Decomposing safety requirements into redundant safety requirements (not necessarily identical) to allow
ASIL tailoring at the next level of detail
 In this decomposition, the relevant safety goal is only violated if both elements fail simultaneously
Some Requirements
 ASIL decomposition is performed considering each allocated safety requirement of the element
 Initial safety requirements are implemented by sufficiently independent elements and redundant safety
requirements are derived for each of these elements

Requirements decomposition with respect to ASIL tailoring

ASIL D Safety Req’t (e.g., no RAM
 Updated architectural errors for safety-critical variables)
information
 Update of ASIL as attribute of
safety requirements and elements ASIL C (D) Element
ASIL A (D) Element
(e.g., Dual store of safety-
(e.g., Main µC)
critical variables)
ASIL A (D) Element ASIL A (D) Element

ASIL B (D) Element (e.g., Software (e.g., Verify safety-
(e.g. ECC) critical variable against
RAM tests) copy before use)

Criteria for coexistence of elements
Objectives
Provide criteria for coexistence within the same element of
 safety-related sub-elements with non-safety-related ones

 safety-related sub-elements assigned different ASILs
Can be beneficial to avoid raising the ASIL of sub-elements

Criteria for coexistence of elements
Requirements
 A non-safety-related sub-element coexisting in the same element with safety-related sub-element(s) shall only
be treated as a QM sub-element, if it has no functional dependency with any of the safety requirements allocated
to the element and it does not interfere with any other safety-related sub-elements of the element
 In the case of coexistence in the same element of safety-related sub-elements with different ASILs, a sub-
element shall only be treated as a lower ASIL sub-element if it is shown that it does not interfere with any other
sub-element assigned a higher ASIL, for each of the safety requirements allocated to the element

Analysis of Dependent Failures
Objective
 Identify any single event or single cause that could bypass or invalidate the independence or freedom
from interference between elements of an item required to comply with its safety goals
Requirements
 Identification of potential for dependent failures from safety analyses
 Evaluation for dependent failures in order to determine if a reasonably foreseeable cause exists which
will cause the dependent failures to occur and violate a safety goal
 Resolution of dependent failures in change requests to mitigate the root cause in the sub-phases of the
safety lifecycle for which analysis of dependent failure is applied

Analysis of Dependent Failures
 Results of analyses of dependent failures

 Change requests for confirmed dependent failures

Safety Analyses
Objectives
 To examine the influence of faults and failures on items or elements regarding their
architecture, functions and behaviour
 Provide information on conditions and causes that could lead to violation of a safety
goal or safety requirement
 Contribute to the identification of new functional or non-functional hazards not
previously considered during hazard analysis and risk assessment

Safety Analyses
Requirements
 Carried out according to the ASIL assigned to the item or element

 Performed according to national, international or other appropriate standards or guidelines
 Provide measures and apply them to faults or failures that could potentially violate the safety goals
or safety requirements
 Implement the above measures as part of the product development
 The results of the safety analyses is used to determine the need for additional safety-related test
cases
 The results of the safety analyses are documented and reviewed

Checkpoint Questions - Part 9: ASIL-oriented and
Safety-oriented Analyses
1. ASIL Decomposition is about decomposing safety requirements into identical redundant requirements
A. True
B. False
2. Why perform dependent failure analysis?
A. To reduce the ASIL requirement of a component
B. To identify any single event or single cause that could bypass or invalidate the independence required to satisfy the safety goals
of a system.
C. To analyze field data
D. All of the above

A. True
B. False
of a system.
D. All of the above

A. True
B. False
of a system.
D. All of the above

Key Aspects that Have Evolved Over Time During ISO/DIS 26262
Development
 What is meant by malfunctioning behavior?
 Includes more than just failures of an item
 Also includes unintended behaviours of an item with respect to its design intent and interactions between
E/E safety-related systems
 Requirement for manufacturers to ensure proper decommissioning of systems

 Changed to a “should”
 Not possible in all cases for manufacturers to ensure this
 From prescriptive to goal-based

 Methods listed in tables are now related to satisfying a specific goal
 Change required a restructuring and reinterpretation of tables and introduction of a goals clause related
to methods in the tables

Summary
 Background of ISO 26262
 What is it?
 What are the origins of ISO 26262?
 Differences between IEC 61508 and ISO 26262
 Status of ISO 26262
 Overview of each part of the standard
 Objectives, requirements, and work products
 Overview of key aspects that have evolved over time

Q&A

BACKGROUND

ISO 26262 Terms
Safety Element out of Context (SEooC)
Item Development
3 - 7 Hazard analysis and risk
Hazard analysis and risk
assessment assessment
Hazard
Hazard analysis
analysis and and risk
risk assessment assessment
SEooC Development
3 - 7 Hazard analysis and risk
ASIL
ASIL Capability
Capability Hazard analysis and risk assessment
assessment
Concept phase
Assumptions on safetyon
Assumptions goals
safety goals ( ASIL
Safety Element out of Context Specification
Specification of safety
of safety goals goals
(ASIL of per
Capability Safety
systemElement
failure out of Context)
)
Subsystem,
8- 6 Over all manage ment of saf et y r equi r e ment s
Assumptions on functional safety

Assum ptions onconcept
functional safety concept Functional
3 - 8 Functional safety
safety concept concept
Hardware or
Over all manage ment of saf et y r equi r e ment s
Assumptions on functional safety Specification of functional safety

Software developed Assumptions on functional safety requirements
requirements Specification ofrequirements
functional safety requirements
with assumed
4 - 6 Specification of technical safety
requirements (e.g., Specification ofconcept technical safety concept
ASIL), confirmed Specification ofof
Specification technical safety safety requirements
technical
requirements
when used in an
Item
Pr oduct devel op ment
4 - 7 System
System design
design
System
Systemdesigndesign
specification
specification
5 -6 Specification of HW safety 6 - 6 Specification of SW safety

Specificationrequirements
of HW safety requirements Specification of SW safety requirements
requirements
Hardw
Hardware arerequirements
safety safety requirements Softw
Software arerequirements
safety safety requirements



Iso 26262 Dis Tutorial 2010 Final - 1 PDF

Uploaded by

Copyright:

Available Formats

Iso 26262 Dis Tutorial 2010 Final - 1 PDF

Uploaded by

Document Information

Original Title

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 Dis Tutorial 2010 Final - 1 PDF

Uploaded by

Copyright:

Available Formats

ISO 26262

Functional Safety Draft International Standard for Road Vehicles:

Barbara J. Czerny, Joseph D’Ambrosio, Rami Debouk,

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

 Adaptation of IEC 61508 to comply with

ISO 26262 Road Vehicles - Functional Safety

Initiatives First drafts ISO

WG16 (Functional Safety)

ISO 26262 Road Vehicles - Functional Safety

Convenor Ch. Jung, Independent Consultant

Secretary E. Fritzsche, VDA

Germany BMW, Daimler , VW, Bosch, Continental

France PSA, Renault, Continental, Valeo

UK Landrover, MIRA, Renesas

Sweden Delphi, Volvo Cars, AB Volvo, Mecel

Italy Centro Ricerche Fiat, Fiat Auto, TRW

Japan Denso, Hitachi, Honda, Nissan, Toyota

USA GM, IBM, TRW,

Active membership as of 10/2007

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

Source: ISO/DIS 26262

ISO 26262 Road Vehicles - Functional Safety

Source ISO/DIS 26262 ISO 26262 Road Vehicles - Functional Safety

ASIL-O riented and Safety-Oriented Analysis

Source ISO/DIS 26262 ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

Sensor Controller Actuator

Hardware Software Hardware Software Hardware Software Element

Hardware Software Hardware Hardware Software

ISO 26262 Road Vehicles - Functional Safety

 Random Hardware Failures

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

ISO 26262 Road Vehicles - Functional Safety

2.4 – 2.6 Management of Functional Safety

Mgmt & Quality

Initiation of the Advanced Eng’g

Hazard Analysis and

Production H/W S/W Other External

Operation, Service &

8.4 – 8.13 Supporting Processes

ISO 26262 Road Vehicles - Functional Safety

Functional Safety Management requires:

ISO 26262 Road Vehicles - Functional Safety

Management plan to incorporate:

ISO 26262 Road Vehicles - Functional Safety