ISO 26262 2nd Edition

NORME ISO 26262 Sécurité fonctionnelle électronique automobile
ISO 26262 2nd Edition
SIA Journée d'étude : NORME ISO 26262 Sécurité fonctionnelle électronique automobile , 04-03-2018
Cédric Heller, DQI/DSEE, French Delegate of TC22/SC32/WG8

NORME ISO 26262 Sécurité fonctionnelle électronique automobile 2

Time schedule of ISO 26262 (2nd ED)

Parts Leaders
USA (Joe Miller)
Japan (S. Kawana + B (G. Jacobs)
Germany
(Andreas Knapp)
Germany (Adam Moik)
FR (P. Chaussis)
GB (David Ward)
FR (N. Becker)
Italy (Marco Bellotti)
Japan (Yasuoku Ohno)
Sweden
(P. Johannessen)
Italy (R. Mariani)
JP (Takeshi Nakazawa)
Convenor : Dr. Jürgen Schwartz, Daimler :

Overview Update
Major restructuring
Part 2:
Confirmations reviews
Initiation of product dvpt
Management of safety anomalies
Part 4:
Reshuffle 4.6 /4.7
News Topics
Trucks and Buses
Motorcycles
Semiconductors
Fail-Operational
Clarifications/
Improvements
Part 1:
Timing concept
Part 5:
PMHF for “monster” items
Part 6:
Guidance on model based design
Software Safety Analysis
Part 8:
Evaluation of hardware elements
Part 9:
Analysis of dependent failure

Trucks and Buses Changes in ISO 26262
ISO PAS 19284:
Integrated in the document:
Example:

Trucks and Buses Changes in ISO 26262
ISO PAS 19284:
6.4.5
Same
definition for
E / C / S

Part 1: Vocabulary
Fault causing malfunctioning
behavior of the item
Malfunctioning behavior
resulting in hazardous event
Without Safety Mechanism
Malfunctioning Behavior
Fault Tolerant Time Interval
Safety Mechanism Implemented
Diagnostic Test Time Intervals
Time to Detect Fault
Fault Detection Time Interval
Time to Transition to Safe State
Fault Reaction Time Interval
Safe State
Safety Mechanism Implemented with Emergency Operation
Emergency Operation
Emergency Operation Time Interval
Safe State
time
time
time
Time to Detect Fault
Fault Detection Time Interval
Time to Transition to Emergency Operation
Fault Reaction Time Interval
Diagnostic Test Time Intervals
Part
1

Part 2: Confirmations Reviews
 Confirmations reviews and Safety Assessment objectives:
6.4.7.3 The functional safety of the item and its elements shall be confirmed, […] based on:
a) confirmation reviews to judge whether the key work products, i.e. those included in Table 1, provide sufficient and convincing evidence
of their contribution to the achievement of functional safety, considering the corresponding objectives and requirements of ISO 26262,
in accordance with Table 1 and Table 2;
b) one or more functional safety audits to judge the implementation of the processes […]
c) a functional safety assessment to judge the achieved functional safety of the item, […]
 Functional and Technical Safety Concept included in the confirmations reviews:
 (Extract of Part 2 Clause 6.4.9.1 Table 1)
Confirmation review of the Functional Safety
Concept […]
— I1 I1 I2 I3 […]
Confirmation review of the Technical Safety
Concept […]
— I1 I1 I2 I3 […]
Part
2

Part 2: Safety Anomalies
 Reinforcement of the Safety anomalies management in Part 5 § 5.4.3
 Safety anomalies considered in the scope of the Safety Assessment:
• 6.4.12.7 The scope of a functional safety assessment shall include:
• […]
• f) the rationales for the safety anomalies managed to closure in accordance with 5.4.3.
Part
2

Part 2: Link with cyber security
5.4.2.3 The organization shall institute and maintain effective communication channels between functional safety, cybersecurity,
and other disciplines that are related to the achievement of functional safety.
EXAMPLE 1 Communication channels between functional safety and cybersecurity in order to exchange relevant information
(e.g. in the case it is identified that a cybersecurity issue might violate a safety goal or a safety requirement, or in the case a
cybersecurity requirement might compete with a safety requirement)
EXAMPLE 2 Communication channels between functional safety and non-E/E related safety such asmechanical safety
EXAMPLE 3 Communication channels between functional safety and quality
(Extract of Part 2Clause 5.4.2.3)
+
Annex E (informative) Guidance on potential interaction of functional safety with cybersecurity
Part
2

Part 4 :« optimisation »
 Complete restructuring of Clause 4.6 and 4.7
 In Edition 1 It was confusing to specify TSR and TSC in two differents sub-phases
• 6.5.1 Technical safety requirements specification
• 7.5.1. Technical safety concept
• Feedback from automotive industry, :
- Technical safety requirements specification and Technical Safety Concept are usually performed in the same sub-phase.
Solution in Edition 2:
TSR and TSC are merged in 4.6
System design and safety analysis are in 4.7
Part
4

Part 5: PMHF
 PMHF allocation clarification for « Monsters Items »:
• For items consisting of several systems (Ex: for complexes ADAS function), the safety goal target
can be directly allocated to each system, if the number of system is lower than 10
When an item consists of several systems (as defined in ISO 26262-1:2018, 3.163), the target value of requirement 9.4.2.2,
derived from the safety goal, may be directly allocated to each system composing the item, when these systems have the
capability to violate the safety goal, as long as the corresponding item target value is not increased by more than one
order of magnitude.
NOTE 1 The possibility described in requirement 9.4.2.3 can, for example, be used for legacy systems, that are involved in a new higher
level functionality (e.g. new ADAS using Engine Management System, Electronic Stability Control System, Electric Power Assisted
Steering System or Airbag Restraint System), and that had achieved the same safety goal in previous developments.
EXAMPLE For an item with an ASIL D safety goal achieved using several systems, having each the potential to violate the Safety
Goal, then each system could be allocated the target value of 10-8/h. (Extract of Part 5 Clause 9.4.2.3)
Part
5

Part 5 / Part 10: Fail Operational
 Introduction of a new concept : safety-related availability requirements:
NOTE 2 Items with safety-related availability requirements (i.e. the loss of a certain functionality can lead
to a hazardous event) are subject to the same requirements and targets for hardware architectural metrics
as items without safety related availability requirements. (Extract of Part 5 Clause 8)
 Guidance in Part 10:
For many E/E systems, the loss of functionality cannot lead to a hazard. Therefore, the safe state can be
achieved by switching off the functionality in case of a malfunction within the system. However, in some cases
the HARA can show that the loss of a certain functionality can lead to a hazardous event. This can lead to a
safety goal specifying a safety‐related availability requirement. (Extract of Part 10 Clause 12)
 Part 5 Annex D update with safety mechanisms
Part
5+10

Part 6: Software Safety Analysis
 Software Safety Analysis:
• Clarification of the goal of the Software Analysis:
- To identify “possible single events, faults or failures that may cause a malfunctioning behaviour of more than one of the software
elements which require independence from each other”
- To identify “possible single events, faults or failures that may propagate from one software element to another inducing causal
chains leading to the violation of safety requirements“
• Scope of the safety Analysis
The scope of the analyses can be influenced by:
- […]
- properties required from the architectural design resulting from higher level safety
concepts in respect of the achievement of freedom from interference or sufficient independence.
EXAMPLE 1 Appropriate end-to-end data protection mechanisms can be used as an argument that the basic
software can be treated as a “black box” when considering the exchange of safety-related data with external
senders or receivers during a safety analyses.
Link with Safety
Concept
Part
6

Part 6: Model Based Design
 Reworked annex B on model-based development:
 This annex explains possible usage benefits and potential issues of model-based development approaches (MBDV) during the development
at the software level.
 NOTE This annex does not imply that the model-based development approaches mentioned are restricted to software development only.
Part
6

Part 9
 Safety analysis from Parts 4,5,6 moved to Part 9 Annex C
 New guidance on dependant failure analysis

Part 7 - 10
14 Guidance on Safety‐related Special Characteristics
14.1 General
This section gives guidance on safety‐related special characteristics from their identification during the product
development phase to the monitoring during the production phase.
[…]
The management of the safety‐related special characteristics consists of:
— Their identification during development;
— The specification of control measures used to control them during production planning;
— The monitoring of their fulfillment during production.
[…]
14.2 Identification of safety‐related special characteristics
[…]
EXAMPLE 1 Calibration of an e‐Motor Resolver offset is identified as a safety requirement for manufacturing during a
system FMEA and an action is assigned to specify a safety‐related special characteristic to be met during production for end of
line testing, including storing calibration data and test results. The Process Control Plan specifies that e‐Motor calibration is a
safety‐related special characteristic.
[…]
14.3 Specification of the control measures of safety‐related special characteristics
[…]
EXAMPLE Automatic Optical Inspection, End‐Of‐Line test, and In‐Circuit Test.
Part
7-10

Part 11: Guideline on application of ISO 26262 to semiconductors Part
11
4.1 How to consider semiconductor components
4.1.1 Semiconductor component development
If a semiconductor component is developed as a part of an item development compliant with ISO 26262
series of standards, it is developed based on hardware safety requirements derived from the top-level
safety goals of the item, through the technical safety concept. Targets for diagnostic coverages for
relevant failure modes to meet hardware architectural metrics and Probabilistic Metric for random
Hardware Failures (PMHF) or Evaluation of Each Cause of safety goal violation (EEC) are allocated to
the item: in this case, the semiconductor component is just one of the elements. […]

Part 11: Guideline on application of ISO 26262 to semiconductors Part
11

Part 12 : Adaptation of ISO 26262 for motorcycles Part
1212-8: HARA,
Motorcycle Safety Integrity Level (MSIL)
Tailoring to best suit motorcycle specific
hazardous events.

Next Steps
 FDIS available since 2018-03
 Publication expected for 2nd Quarter of 2018
 Date and Place of next Meetings
• No WG8 Meeting in 2018
• 1 WG8 Meeting in 2019 (June) – (Linked with SC32, host USA)
• Continue with one meeting per year linked to SC32 until 2023 (SR)

Questions

Bibliography
 ISO-26262 for FDIS parts 1 to 12
 Latest News to ISO 26262, 2nd Edition Dr. Jürgen Schwartz, Daimler
27

ISO 26262 2nd Edition

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ISO 26262 2nd Edition

Similar to ISO 26262 2nd Edition (20)

Recently uploaded

Recently uploaded (20)

ISO 26262 2nd Edition