ISO 26262 the

Emerging Automotive
Safety Standard
Agenda
• Introduction of ISO/DIS 26262 (ISO 26262)
• Parts of ISO 26262
• ASIL Levels
• Part 4 : Product Development – System Level
• Part 6 : Product Development – Software Level
• Fitting software tools into ISO 26262 process

2
Introduction of ISO/DIS 26262
(ISO 26262)

3
Introduction
ISO 26262 is an adaptation of IEC 61508
for the automotive industry.
IEC 61508 (Industrial)
Functional Safety for E/E/PE
Safety related systems

ISO 26262
Functional Safety in EN 50128/EN50129 IEC 62304 IEC 670880
Automotive Rail Transport Medical Devices Nuclear Power
Electronics

4
Introduction
• It applies to safety-related road vehicle E/E
systems, and addresses hazards due to
malfunctions, excluding nominal performances of
active and passive safety systems.
• Risk is determined based on customer risk by
identifying the so-called Automotive Safety
Integrity Level (ASIL) associated with each
undesired effects.
• It provides ASIL-dependent requirements for the
whole lifecycle of the E/E system (including
Hardware and Software components)

5
Parts of ISO 26262

6
ISO 26262 Parts
• Part 1 : Vocabulary
• Part 2 : Management of Functional Safety
• Part 3 : Concept phase
• Part 4 : Product Development: System Level
• Part 5 : Product Development: Hardware Level
• Part 6 : Product Development: Software Level
• Part 7 : Production and Operation
• Part 8 : Supporting Processes
• Part 9 : ASIL-oriented and Safety-oriented Analyses
• Part 10 : Guidelines on ISO 26262

7
IEC 61508 versus ISO 26262
IEC 61508 ISO/DIS 26262
Part 1: General requirements Part 1: Vocabulary
Part 2: Requirements for Part 2: Management of functional safety
electrical/electronic/programmable electronic
safety-related systems
Part 3: Software requirements Part 3: Concept phase
Part 4: Definitions and abbreviations Part 4: Product Development: System Level

Part 5: Examples of methods for the Part 5: Product Development: Hardware

determination of safety integrity levels Level
Part 6: Guidelines on the application of parts Part 6: Product Development: Software Level
2 and 3
Part 7: Overview of techniques and Part 7: Production and Operation
measures
Part 8: Supporting Processes
Part 9: ASIL-orientated and safety-oriented
analysis
Part 10: Guideline
8
ISO 26262 Process

9
ASIL Levels

10
ASIL
• ISO/DIS 26262 replaces SILs with ASILs (Automotive
Safety Integrity Levels)

• ASILs designed to specify the measures required to avoid

unreasonable residual risk

• ASIL levels A-D, with D being the most demanding

• Risk of each hazardous event is evaluated on the basis

of:
– Frequency of the situation (or “exposure”)
– Impact of possible damage (or “severity”)
– Controllability

11
Part 4 : Product Development –
System Level

12
Part 4 : Product Development – System
Level After the initiation of the
product development and
specification of the
technical safety
requirements, the system
design is performed.

Depending on the
complexity of the
architecture, the
requirements can be
derived iteratively, and
integrated after the
Hardware &Software
implementation.

Integrate software &

hardware, validation is
performed to comply with
each safety requirement in
accordance
with its specification and
ASIL classification.

13
4.6 - Specification of the Technical
Safety Requirements
• Objective is to develop the technical safety requirements,
which refine the functional safety concept considering the
preliminary architectural design.

• To verify through analysis that technical safety

requirements comply to the functional safety
requirements.

• To bring item-level functional safety requirements into

system-level technical safety requirements, down to the
allocation to hardware and software elements

14
4.6 - Specification of the Technical
Safety Requirements
Requirements Engineering of this nature requires
additional initial effort but benefits will be obtained
whenever changes are required.

Cost of a project
WITHOUT Requirements
Engineering

Cost of a project WITH Deliver

Requirements
Engineering

Project Start Deliver

(less delay)
15
4.7 - System Design
• To develop the system design and the technical safety
concept that comply with the functional requirements and
the technical safety requirements specification.

• Verify the System design and technical safety concept

comply with Technical safety requirements specification.

• Need to have bidirectional traceability between System

design and Technical safety requirements specification.

16
4.8 - Item integration and testing
• To integrate the different parts that compose the system,
included other technologies and/or external entities, and
to test the obtained product to comply with each safety
requirement and to verify that the design has been
correctly implemented.

• The integration and testing is carried out from

software-hardware integration, and going through
integration of systems up to vehicle integration, with
specific tests performed at each integration phase.

17
4.8 - Item integration and testing
• Each functional and technical safety requirements shall
be tested at least once in the complete integration phase.

18
4.9 - Safety Validation
• To provide evidence of due compliance with the functional
safety goals and that the safety concepts are appropriate
for the functional safety of the item.

• To provide evidence that the safety goals are correct,

complete and fully achieved at vehicle level.

• The validation plan shall include:

– 1. The configuration of the item
– 2. The specification of test cases and acceptance criteria
– 3. The required environmental conditions

19
4.10 - Functional safety assessment
• To assess the functional safety that is achieved by the
item.

20
4.11 – Release for Production
• To specify the criteria for the release for production at the
completion of the item development.

• The release for production confirms that the item complies

with the requirements for functional safety at vehicle level.

• The documentation shall include

– a) the name and signature of the person in charge of release
– b) the version/s of the released item
– c) the configuration of the released item
– d) references to associated documents
– e) the release date

21
Part 6 : Product Development –
Software Level

22
Part 6 : Product Development –
Software Level
• ISO 26262 (Part 6) refers more specifically to the
development of software, particularly:

– Initiation of product development at the software level

– Derivation of software safety requirements from the system level
(following from part 4) and their subsequent verification
– Software architectural design
– Software unit design and implementation
– Software unit testing, and
– Software integration and testing

23
6.5 Initiation of Product Development
at Software Level
• To plan and initiate the functional safety activities for the
sub phases of the software development

24
6.5 Modelling and Coding Guidelines
• To support the correctness of the design and
implementation, the design and coding guidelines for the
modelling, or programming languages, shall address
following topics:

25
6.6 Specification of Software Safety
Requirements
• To specify the software safety requirements which are
derived from technical safety concept and system design
to detail hardware-software requirements and verify that
the software safety requirements are consistent with the
technical safety concept and the system design
specification

• The technical safety requirements are divided into

hardware and software safety requirements. The
specification of the software safety requirements
considers constraints of the hardware and the impact of
these constraints on the software.

26
6.6 Verification of Software Safety
Requirements
• A verification activity shall be performed to demonstrate
that the software safety requirements are traceable with
the technical safety requirements, the system design and
consistent with the relevant parts of the hardware safety
requirements achieving complete traceability.

27
6.7 Software Design
• To develop a software architectural design that realizes
the software safety requirements and verify the software
architectural design achieving bi-directional traceability

• The software architectural design represents all software

components and their interactions with one another in a
hierarchical structure.

28
6.7 Software Design
• The software architectural design shall exhibit
– Modularity
– Encapsulation
– Minimum complexity

29
6.7 Verification of Architectural Design
• The software architectural design shall be verified by
using the following software architectural design
verification methods:

30
6.8 Software Unit design &
implementation
• To specify the software units in accordance with the SW
architectural design and the associated SW safety
requirements, to implement the software units as
specified and to verify the design of the SW units and
implementation.

• The specification of the software units shall describe the

functional behavior and the internal design.

• The design and implementation of software unit shall

achieve
– Avoidance of unnecessary complexity
– Testability
– Maintainability

31
6.8 Software Unit Design
• The design principles for software unit design and
implementation shall be applied to follow below properties

• Correct execution order

• Interface consistency
• Correct data/control flow
• Simplicity
• Readability and
comprehensibility
• Robustness
• Change suitability
• Testability

32
6.8 Verification of software unit design
and implementation
• The software unit design and implementation shall be
verified to demonstrate
• Compliance with the hardware-
software interface
• Completeness regarding the
software safety requirements
and the software architecture
through traceability
• Compliance of the source code
with its specification
• Compliance of the source code
with the coding guidelines
• Compatibility of the software unit
implementations with target
hardware.
33
6.9 Software Unit Testing
• Software units fulfill the software unit specifications and
do not contain undesired functionality.

• The following testing methods can be used for proving

compliance with specification and Hardware Software
interface, correct implementation, absence of unintended
functionality, robustness, and sufficiency of the resources.

34
6.9 Test case specification and
structural coverage metrics
• To evaluate the
completeness of test cases
and to demonstrate that
there is no unintended
functionality, the coverage
of requirements at the
software unit level shall be
determined and the
structural coverage shall be
measured in accordance
with the metrics listed.

35
6.10 SW integration & Testing
• To integrate the software components and demonstrate
that the software architectural design is correctly realised
by the embedded software.
• Integrated software tested against architectural design
and interfaces between the software units and the
software component.
• Software integration test shall demonstrate
– Compliance with the software architectural design
– Compliance with the specification of the hardware-software
interface
– Correct implementation of the functionality
– Robustness
– Sufficiency of the resources to support the functionality.

36
6.11 Verification of SW safety
requirements
• To demonstrate that the embedded software fulfils the
software safety requirements and embedded software
satisfies its requirements in the target environment.
• The results of the verification of the software safety
requirements shall be evaluated in accordance with:
– Compliance with the expected results
– Coverage of the software safety requirements
– A pass or fail criteria

37
Fitting software tools into ISO
26262 process

38
LDRA Compliance with ISO 26262
• ISO/DIS 26262 is a new standard for the Automotive
sector
– But it is based on principles which have been long established
elsewhere

• The concept of adopting Aerospace development

principles sounds expensive
– But tools to handle these issues are
• Sophisticated and proven, and
• Designed to apply these principles cost effectively

• Similarly, the LDRA tool suite have long been established

to provide the support for IEC 61508 based principles

39
V Model Process
IBM® Rational®
DOORS® & Text Processing
RequisitePro®… & Office files

4.7 System 4.8 Item integration

Design & testing
LDRA
TBreq® Testbed®
Requirements Test
Traceability 6.6 Specification of 6.11 Verification of Verification
software safety software safety
requirements requirements

6.7 Software 6.10 Software

Architectural integration and
Design testing
LDRA Testbed® TBrun®
& TBvision® Automated
Programming Unit
standards 6.8 Software unit 6.9 Software unit Testing
checking and design and testing
metrication implementation

LDRA Testbed®
Test and Metrics
Reporting

40
Static Analysis

41
Coding Standard Enforcement
• JPL
• MISRA
• MISRA-C:2004
• NETRINO
• RUNTIME
• CERT
• CMSE
• CONFORM
• CWE
• DERA
• EADS
• JSF++ AV
• MISRA C++:2008

42
Cyclomatic Complexity

43
Software Architectural Design

44
Data Flow and Control Flow

45
Software Unit Testing
ASIL
Topics
A B C D
1a Requirement-based test ++✔ ++✔ ++✔ ++✔
1b Interface test ++✔ ++✔ ++✔ ++✔
1c Fault injection test +✔ +✔ +✔ ++✔
1d Resource usage test + + + ++
1e Back-to-back test between model and code, if + + ++ ++
applicable

ASIL
Topics
A B C D
1a Analysis of requirements ++✔ ++✔ ++✔ ++✔
1b Generation and analysis of equivalence +✔ ++✔ ++✔ ++✔
classes
1c Analysis of boundary values +✔ ++✔ ++✔ ++✔
1d Error guessing +✔ +✔ +✔ +✔

”++” The method is highly recommended for this ASIL.

“+“ The method is recommended for this ASIL.
“o“ The method has no recommendation for or against its usage for this ASIL.
✔Satisfied by the LDRA tool suite
46
Unit Test Case Execution

47
Coverage Analysis
ASIL
Topics
A B C D
1a Statement coverage ++✔ ++✔ +✔ +✔
1b Branch coverage +✔ ++✔ ++✔ ++✔
1c MC/DC (Modified Condition/Decision +✔ +✔ +✔ ++✔
Coverage)
”++” The method is highly recommended for this ASIL.
“+“ The method is recommended for this ASIL.
“o“ The method has no recommendation for or against its usage for this ASIL.
✔Satisfied by the LDRA tool suite

ASIL
Topics
A B C D
1a Function coverage +✔ +✔ ++✔ ++✔
1b Call coverage +✔ +✔ ++✔ ++✔

”++” The method is highly recommended for this ASIL.

“+“ The method is recommended for this ASIL.
“o“ The method has no recommendation for or against its usage for this ASIL.
✔Satisfied by the LDRA tool suite

48
Coverage Analysis

49
Traceability Matrix
• Forward and Backward
Traceability

50
Software Lifecycle Traceability
Telelogic DOORS®,
IBM® Rational®
RequisitePro®…
Tier 1
High-Level
TBreq® Requirements
Requirements
Traceability Requirements Traceability Matrix LDRA Testbed®
Design Review
Tier 2 Legacy Code/ Defects
Architectural Software Specs
Modelling Tool Hand Code
Concepts
TBmanager® Requirements Traceability Matrix TBvision®
System Test
Code Review
Management Defects
Tier 3 Implementation
(Source Code / Assembly)

Requirements Traceability Matrix TBrun®

TBmanager® Host
Unit Test Tier 4 Testing
Management Host Tier
(Node 1 – n)

Requirements Traceability Matrix TBrun®

Target
Tier 5 Target Tier Testing

(Node 1 – n)

51
Conclusion
• IEC 26262 ensures the safety of the electrical / electronic
/ programmable electronic devices in Road vehicles.

• Using tools with a proven track record and pedigree to

automate the software development process:
– Will help in producing safe product
– Provides confidence to the manufacturers
– Save time and money

52
For further information visit:

www.ldra.com
[email protected]

53