ISO 26262-4:2018

INTERNATIONAL ISO
STANDARD 26262-4
Second edition
2018-12
Road vehicles — Functional safety —
Part 4:
Product development at the system
level
Véhicules routiers — Sécurité fonctionnelle —
Partie 4: Développement du produit au niveau du système
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Requirements for compliance . 2
4.1 Purpose . 2
4.2 General requirements . 2
4.3 Interpretations of tables . 3
4.4 ASIL-dependent requirements and recommendations . 3
4.5 Adaptation for motorcycles . 4
4.6 Adaptation for trucks, buses, trailers and semi-trailers. 4
5 General topics for the product development at the system level . 4
5.1 Objectives. 4
5.2 General . 4
6 Technical safety concept . 5
6.1 Objectives. 5
6.2 General . 6
6.3 Inputs to this clause . 6
6.3.1 Prerequisites . 6
6.3.2 Further supporting information . 6
6.4 Requirements and recommendations . 6
6.4.1 Specification of the technical safety requirements . 6
6.4.2 Safety mechanisms . . 7
6.4.3 System architectural design specification and technical safety concept . 9
6.4.4 Safety Analyses and avoidance of systematic failures . 9
6.4.5 Measures for control of random hardware failures during operation .11
6.4.6 Allocation to hardware and software .11
6.4.7 Hardware-software interface (HSI) specification .12
6.4.8 Production, operation, service and decommissioning .12
6.4.9 Verification .13
6.5 Work products .14
7 System and item integration and testing .14
7.1 Objectives.14
7.2 General .15
7.3 Inputs to this clause .15
7.3.1 Prerequisites .15
7.3.2 Further supporting information .15
7.4 Requirements and recommendations .15
7.4.1 Specification of integration and test strategy .15
7.4.2 Hardware-software integration and testing .17
7.4.3 System integration and testing .19
7.4.4 Vehicle integration and testing .21
7.5 Work products .24
8 Safety validation .24
8.1 Objectives.24
8.2 General .24
8.3 Inputs to this clause .25
8.3.1 Prerequisites .25
8.3.2 Further supporting information .25
8.4 Requirements and recommendations .25
8.4.1 Safety validation environment .25
8.4.2 Specification of safety validation .25
8.4.3 Execution of safety validation . .26
8.4.4 Evaluation .26
8.5 Work products .27
Annex A (informative) Overview of and workflow of product development at the system level .28
Annex B (informative) Example contents of hardware-software interface (HSI) .30
Bibliography .34
iv © ISO 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles Subcommittee, SC 32,
Electrical and electronic components and general system aspects.
This edition of ISO 26262 series of standards cancels and replaces the edition ISO 26262:2011 series of
standards, which has been technically revised and includes the following main changes:
— requirements for trucks, buses, trailers and semi-trailers;
— extension of the vocabulary;
— more detailed objectives;
— objective oriented confirmation measures;
— management of safety anomalies;
— references to cyber security;
— updated target values for hardware architecture metrics;
— guidance on model based development and software safety analysis;
— evaluation of hardware elements;
— additional guidance on dependent failure analysis;
— guidance on fault tolerance, safety related special characteristics and software tools;
— guidance for semiconductors;
— requirements for motorcycles; and
— general restructuring of all parts for improved clarity.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
A list of all parts in the ISO 26262 series can be found on the ISO website.
vi © ISO 2018 – All rights reserved

Introduction
The ISO 26262 series of standards is the adaptation of IEC 61508 series of standards to address the
sector specific needs of electrical and/or electronic (E/E) systems within road vehicles.
This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised
of electrical, electronic and software components.
Safety is one of the key issues in the development of road vehicles. Development and integration of
automotive functionalities strengthen the need for functional safety and the need to provide evidence
that functional safety objectives are satisfied.
With the trend of increasing technological complexity, software content and mechatronic
implementation, there are increasing risks from systematic failures and random hardware failures,
these being considered within the scope of functional safety. ISO 26262 series of standards includes
guidance to mitigate these risks by providing appropriate requirements and processes.
To achieve functional safety, the ISO 26262 series of standards:
a) provides a reference for the automotive safety lifecycle and supports the tailoring of the activities
to be performed during the lifecycle phases, i.e., development, production, operation, service and
decommissioning;
b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive
Safety Integrity Levels (ASILs)];
c) uses ASILs to specify which of the requirements of ISO 26262 are applicable to avoid unreasonable
residual risk;
d) provides requirements for functional safety management, design, implementation, verification,
validation and confirmation measures; and
e) provides requirements for relations between customers and suppliers.
The ISO 26262 series of standards is concerned with functional safety of E/E systems that is achieved
through safety measures including safety mechanisms. It also provides a framework within which
safety-related systems based on other technologies (e.g. mechanical, hydraulic and pneumatic) can be
considered.
The achievement of functional safety is influenced by the development process (including such
activities as requirements specification, design, implementation, integration, verification, validation
and configuration), the production and service processes and the management processes.
Safety is intertwined with common function-oriented and quality-oriented activities and work
products. The ISO 26262 series of standards addresses the safety-related aspects of these activities and
work products.
Figure 1 shows the overall structure of the ISO 26262 series of standards. The ISO 26262 series of
standards is based upon a V-model as a reference process model for the different phases of product
development. Within the figure:
— the shaded “V”s represent the interconnection among ISO 26262-3, ISO 26262-4, ISO 26262-5,
ISO 26262-6 and ISO 26262-7;
— for motorcycles:
— ISO 26262-12:2018, Clause 8 supports ISO 26262-3;
— ISO 26262-12:2018, Clauses 9 and 10 support ISO 26262-4;
— the specific clauses are indicated in the following manner: “m-n”, where “m” represents the number
of the particular part and “n” indicates the number of the clause within that part.
EXAMPLE “2-6” represents ISO 26262-2:2018, Clause 6.
Figure 1 — Overview of the ISO 26262 series of standards
viii © ISO 2018 – All rights reserved

INTERNATIONAL STANDARD ISO 26262-4:2018(E)
Road vehicles — Functional safety —
Part 4:
Product development at the system level
1 Scope
This document is intended to be applied to safety-related systems that include one or more electrical
and/or electronic (E/E) systems and that are installed in series production road vehicles, excluding
mopeds. This document does not address unique E/E systems in special vehicles such as E/E systems
designed for drivers with disabilities.
NOTE Other dedicated application-specific safety standards exist and can complement the ISO 26262 series
of standards or vice versa.
Systems and their components released for production, or systems and their components already under
development prior to the publication date of this document, are exempted from the scope of this edition.
This document addresses alterations to existing systems and their components released for production
prior to the publication of this document by tailoring the safety lifecycle depending on the alteration.
This document addresses integration of existing systems not developed according to this document and
systems developed according to this document by tailoring the safety lifecycle.
This document addresses possible hazards caused by malfunctioning behaviour of safety-related E/E
systems, including interaction of these systems. It does not address hazards related to electric shock,
fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar
hazards, unless directly caused by malfunctioning behaviour of safety-related E/E systems.
This document describes a framework for functional safety to assist the development of safety-
related E/E systems. This framework is intended to be used to integrate functional safety activities
into a company-specific development framework. Some requirements have a clear technical focus to
implement functional safety into a product; others address the development process and can therefore
be seen as process requirements in order to demonstrate the capability of an organization with respect
to functional safety.
This document does not address the nominal performance of E/E systems.
This document specifies the requirements for product development at the system level for automotive
applications, including the following:
— general topics for the initiation of product development at the system level;
— specification of the technical safety requirements;
— the technical safety concept;
— system architectural design;
— item integration and testing; and
— safety validation.
Annex A provides an overview on objectives, prerequisites and work products of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 26262-1:2018, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and
decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-
oriented and safety-oriented analyses
3 Terms and definitions
For the purposes of this document, the terms, definitions and abbreviated terms given in
ISO 26262-1:2018 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at https: //www .iso .org/obp
4 Requirements for compliance
4.1 Purpose
This clause describes how:
a) to achieve compliance with the ISO 26262 series of standards;
b) to interpret the tables used in the ISO 26262 series of standards; and
c) to interpret the applicability of each clause, depending on the relevant ASIL(s).
4.2 General requirements
When claiming compliance with the ISO 26262 series of standards, each requirement shall be met,
unless one of the following applies:
a) tailoring of the safety activities in accordance with ISO 26262-2 has been performed that shows
that the requirement does not apply; or
b) a rationale is available that the non-compliance is acceptable and the rationale has been evaluated
in accordance with ISO 26262-2.
2 © ISO 2018 – All rights reserved

Informative content, including notes and examples, is only for guidance in understanding, or for
clarification of the associated requirement, and shall not be interpreted as a requirement itself or as
complete or exhaustive.
The results of safety activities are given as work products. “Prerequisites” are information which shall
be available as work products of a previous phase. Given that certain requirements of a clause are
ASIL-dependent or may be tailored, certain work products may not be needed as prerequisites.
“Further supporting information” is information that can be considered, but which in some cases is not
required by the ISO 26262 series of standards as a work product of a previous phase and which may be
made available by external sources that are different from the persons or organizations responsible for
the functional safety activities.
4.3 Interpretations of tables
Tables are normative or informative depending on their context. The different methods listed in a table
contribute to the level of confidence in achieving compliance with the corresponding requirement. Each
method in a table is either:
a) a consecutive entry (marked by a sequence number in the leftmost column, e.g. 1, 2, 3), or
b) an alternative entry (marked by a number followed by a letter in the leftmost column, e.g. 2a, 2b, 2c).
For consecutive entries, all listed highly recommended and recommended methods in accordance with
the ASIL apply. It is allowed to substitute a highly recommended or recommended method by others
not listed in the table, in this case, a rationale shall be given describing why these comply with the
corresponding requirement. If a rationale can be given to comply with the corresponding requirement
without choosing all entries, a further rationale for omitted methods is not necessary.
For alternative entries, an appropriate combination of methods shall be applied in accordance with the
ASIL indicated, independent of whether they are listed in the table or not. If methods are listed with
different degrees of recommendation for an ASIL, the methods with the higher recommendation should
be preferred. A rationale shall be given that the selected combination of methods or even a selected
single method complies with the corresponding requirement.
NOTE A rationale based on the methods listed in the table is sufficient. However, this does not imply a bias
for or against methods not listed in the table.
For each method, the degree of recommendation to use the corresponding method depends on the ASIL
and is categorized as follows:
— “++” indicates that the method is highly recommended for the identified ASIL;
— “+” indicates that the method is recommended for the identified ASIL; and
— “o” indicates that the method has no recommendation for or against its usage for the identified ASIL.
4.4 ASIL-dependent requirements and recommendations
The requirements or recommendations of each sub-clause shall be met for ASIL A, B, C and D, if not
stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal.
If ASIL decomposition has been performed at an earlier stage of development, in accordance with
ISO 26262-9:2018, Clause 5, the ASIL resulting from the decomposition shall be met.
If an ASIL is given in parentheses in the ISO 26262 series of standards, the corresponding sub-clause
shall be considered as a recommendation rather than a requirement for this ASIL. This has no link with
the parenthesis notation related to ASIL decomposition.
4.5 Adaptation for motorcycles
For items or elements of motorcycles for which requirements of ISO 26262-12 are applicable,
the requirements of ISO 26262-12 supersede the corresponding requirements in this document.
Requirements of ISO 26262-2 that are superseded by ISO 26262-12 are defined in Part 12.
4.6 Adaptation for trucks, buses, trailers and semi-trailers
Content that is intended to be unique for trucks, buses, trailers and semi-trailers (T&B) is indicated
as such.
5 General topics for the product development at the system level
5.1 Objectives
The objective of this clause is to provide an overview of product development at the system level.
5.2 General
The necessary activities during the development of a system are given in Figure 2. In an iterative process,
the technical safety concept is developed, incorporating technical safety requirements and the system
architectural design. The system architecture is established, the technical safety requirements are
allocated to elements of the system, and, if applicable, on other technologies. In addition, the technical
safety requirements are refined and requirements arising from the system architecture are added,
including the hardware-software interface (HSI). Depending on the complexity of the architecture, the
requirements for subsystems can be derived iteratively.
After their development, the hardware and software elements are integrated and tested to form an item
that is then integrated into a vehicle. Once integrated at the vehicle level, safety validation is performed
to provide evidence of functional safety with respect to the safety goals.
This document applies to the development of systems. ISO 26262-5 and ISO 26262-6 describe the
development requirements for hardware and software, respectively. Figure 3 is an example of a system
with multiple levels of integration, illustrating the application of this document, ISO 26262-5 and
ISO 26262-6.
NOTE 1 Table A.1 provides an overview of objectives, prerequisites and work products of the particular sub-
phases of product development at the system level.
Figure 2 — Reference phase model for the development of a safety-related item
4 © ISO 2018 – All rights reserved

NOTE 2 Within the figures 2 and 3, the specific clauses of each part of ISO 26262 are indicated in the following
manner: “m-n”, where “m” represents the number of the part and “n” indicates the number of the clause, e.g. “4-6”
represents ISO 26262-4:2018, Clause 6.
Figure 3 — Example of a product development at the system level
NOTE 3 Further information regarding product development at the system level can be found in References
[1] and [2].
6 Technical safety concept
6.1 Objectives
The objectives of this clause are:
a) to specify technical safety requirements regarding the functionality, dependencies, constraints
and properties of the system elements and interfaces needed for their implementation;
b) to specify technical safety requirements regarding the safety mechanisms to be implemented in
the system elements and interfaces;
c) to specify requirements regarding the functional safety of the system and its elements during
production, operation, service and decommissioning;
d) to verify that the technical safety requirements are suitable to achieve functional safety at the
system level and are consistent with the functional safety requirements;
e) to develop a system architectural design and a technical safety concept that satisfy the safety
requirements and that are not in conflict with the non-safety-related requirements;
f) to analyse the system architectural design in order to prevent faults and to derive the necessary
safety-related special characteristics for production and service; and
g) to verify that the system architectural design and the technical safety concept are suitable to
satisfy the safety requirements according to their respective ASIL.
6.2 General
The technical safety concept is an aggregation of the technical safety requirements and the
corresponding system architectural design that provides rationale as to why the system architectural
design is suitable to fulfil safety requirements resulting from activities described in ISO 26262-3 (with
consideration of non-safety requirements) and design constraints.
The technical safety requirements specify the technical implementation of the functional safety
requirements at their respective hierarchical level; considering both the item definition and the system
architectural design, and addressing the detection of latent failures, fault avoidance, safety integrity
and operation and service aspects.
The system architectural design is the selected system-level solution that is implemented by a
technical system. The system architectural design aims to fulfil both, the allocated technical safety
requirements and the non-safety requirements.
System development can be performed iteratively.
6.3 Inputs to this clause
6.3.1 Prerequisites
The following information shall be available:
— functional safety concept in accordance with ISO 26262-3:2018, 7.5.1;
— system architectural design (from an external source, see ISO 26262-3:2018, 7.3.1); and
— requirements to the item from other safety relevant items if applicable.
EXAMPLE Requirements from a park assist system to a brake system.
NOTE In a distributed development, a technical safety concept can be based on another technical safety
concept realized by subsystems.
6.3.2 Further supporting information
The following information can be considered:
— hazard analysis and risk assessment report (see ISO 26262-3:2018, 6.5.1); and
— item definition (see ISO 26262-3:2018, 5.5.1).
6.4 Requirements and recommendations
6.4.1 Specification of the technical safety requirements
6.4.1.1 The technical safety requirements shall be specified in accordance with the functional safety
concept and the system architectural design of the item considering the following:
a) the safety-related dependencies and constraints of items, systems and their elements;
b) the external interfaces of the system, if applicable; and
c) the configurability of the system.
NOTE 1 Design constraints can result from: environmental conditions, the installation space, the
implementation itself (e.g. available performance, thermal capacity, thermal dissipation), and other functional or
non-functional requirements (e.g. security, physical limits of used technology).
6 © ISO 2018 – All rights reserved

NOTE 2 The configurability of systems is determined by variants in the system elements, by configuration
data or by calibration data and is often used as part of the strategy to reuse existing systems for different
applications.
6.4.1.2 The technical safety requirements shall specify the stimulus response of the system that affects
the achievement of safety requirements. This includes the combinations of relevant stimuli and failures
with each relevant operating mode and defined system state.
EXAMPLE The Brake System Electronic Control Unit (ECU) disables Adaptive Cruise Control (ACC) braking
if a received ACC command message fails error detection code checks.
6.4.1.3 If other functions or requirements are implemented by the system or its elements, in addition
to those functions for which technical safety requirements are specified, then these functions or
requirements shall be specified or their specification referenced.
EXAMPLE Other requirements can come from Economic Commission for Europe (ECE) rules, Federal Motor
Vehicle Safety Standard (FMVSS), company platform strategies, functional concepts or other concepts such as
cybersecurity concept.
6.4.1.4 Technical safety and non-safety requirements shall not contradict.
6.4.2 Safety mechanisms
6.4.2.1 The technical safety requirements shall specify the safety mechanisms that detect faults
and prevent or mitigate failures present at the output of the system that violate the functional safety
requirements (see ISO 26262-3:2018, Clause 7) including:
a) the safety mechanisms related to the detection, indication and control of faults in the system itself;
NOTE 1 This includes the system self-monitoring to detect random hardware faults and, if appropriate, to
detect systematic faults.
NOTE 2 This includes safety mechanisms for the detection and control of communication channel failures
(e.g. data interfaces, communication buses, wireless radio link).
NOTE 3 Safety mechanisms can be specified with respect to the appropriate level within the system
architecture.
b) the safety mechanisms related to the detection, indication and control of faults in other external
elements that interact with the system;
EXAMPLE External devices include other electronic control units, power supplies or communication
devices.
c) the safety mechanisms that contribute to the system achieving or maintaining the safe state of
the item;
NOTE 4 This includes arbitration in the case of multiple control requests from safety mechanisms.
d) the safety mechanisms to define and implement the warning and degradation strategy; and
e) the safety mechanisms that prevent faults from being latent.
NOTE 5 These safety mechanisms are usually related to self-tests that take place during power up (pre-
drive checks), as in the case of measures a) to d), during operation, during power-down (post-drive checks),
and as part of maintenance.
6.4.2.2 For each safety mechanism that enables an item to achieve or maintain a safe state, the
following shall be specified:
a) the transition between states;
NOTE 1 This includes the requirements to control the actuators.
b) the fault handling time interval with respect to the timing requirements apportioned from the
appropriate architectural level; and
NOTE 2 This sub-requirement aims to achieve a consistent timing within the boundary of the fault
handling time interval) FTTI which is specified for each Safety Goal.
c) the emergency operation tolerance time interval, see ISO 26262-1:2018, 3.45, if the safe state of the
item cannot be reached within the FTTI.
NOTE 3 In-vehicle testing and experimentation can be used to determine the emergency operation
tolerance time interval.
EXAMPLE 1 Duration of the degraded operation prior to the safe state.
EXAMPLE 2 A safety mechanism for a brake-by-wire application, which depends on the power supply,
can include the specification of a secondary power supply or storage device (capacity, time to activate and
operate, etc.).
6.4.2.3 This requirement applies to ASILs (A), (B), C, and D. If applicable, safety mechanisms shall be
specified to prevent faults from being latent.
NOTE 1 Only random hardware faults which are multiple-point faults have the potential to be latent.
EXAMPLE Self-tests are safety mechanisms which verify the status of components during the different
operation modes (e.g. power-up, power-down, during operation or in an additional self-test mode) to detect
multiple-point faults. Valve, relay or lamp function tests that take place during power up routines are examples of
self-tests.
NOTE 2 Evaluation criteria identifying the need for safety mechanisms preventing faults from being latent
are derived in accordance with good engineering practice. The latent fault metric, given in ISO 26262-5:2018,
Clause 8, provides evaluation criteria.
6.4.2.4 This requirement applies to ASILs (A), (B), C, and D. To avoid multiple-point failures, the
diagnostic test strategy shall be specified for each safety mechanism implemented to detect multiple-
point faults, considering:
a) the reliability requirements of the hardware components with consideration given to their role in
the architecture and their contribution to a multiple-point failure;
b) the specified quantitative target values for the maximum probability of violation of each safety
goal due to random hardware failures (see ISO 26262-5:2018, Clause 9);
c) the assigned ASIL derived from the related safety goal, the related functional safety requirement or
technical safety requirement at a higher hierarchical level; and
d) the multiple-point fault detection time interval.
NOTE 1 The diagnostic test strategy can be time driven (e.g. using the diagnostic test time interval) or event
driven (e.g. a start-up test).
NOTE 2 A second-order multiple-point failure comprises two faults, separated by the multiple-point fault
detection time interval.
NOTE 3 The use of the following measures depends on the time constraints:
—  periodic testing of the system or elements during operation;
—  self-tests of elements during power-up or power-down; and
—  testing the system or elements during maintenance.
8 © ISO 2018 – All rights reserved

6.4.2.5 This requirement applies to ASILs (A), (B), C, and D. The development of safety mechanisms
that are implemented only to prevent dual point faults from being latent shall at least comply with:
a) ASIL B for technical safety requirements assigned ASIL D;
b) ASIL A for technical safety requirements assigned ASIL B and ASIL C; and
c) QM for technical safety requirements assigned ASIL A.
NOTE If ASIL decomposition is applied to a requirement, then this clause is applied to the decomposed
requirement.
EXAMPLE A memory has a parity as its safety mechanism, with requirements rated ASIL B. The requirement
for the self-test that tests the capability of the parity to detect and signal memory faults can be rated ASIL A.
6.4.3 System architectural design specification and technical safety concept
6.4.3.1 The system architectural design in this sub-phase and the technical safety concept shall be
based on the item definition, functional safety concept and the prior system architectural design.
6.4.3.2 The consistency of the system architectural design in ISO 26262-3:2018, 7.3.1 and the system
architectural design in this sub-phase shall be checked. If discrepancies are identified, an iteration of the
activities described in ISO 26262-3:2018 may be necessary.
6.4.3.3 The system architectural design shall implement the technical safety requirements.
6.4.3.4 With regard to the implementation of the technical safety requirements, the following shall be
considered in the system architectural design:
a) the ability to verify the system architectural design;
b) the technical capability of the intended hardware and software elements with regard to the
achievement of functional safety; and
c) the ability to execute tests during system integration.
6.4.3.5 The internal and external interfaces of safety-related elements shall be defined such that other
elements shall not have adverse safety-related effects on the safety-related elements.
6.4.3.6 If ASIL decomposition is applied to the safety requirements during system architectural design,
it shall be applied in accordance with ISO 26262-9:2018, Clause 5.
6.4.4 Safety Analyses and avoidance of systematic failures
6.4.4.1 Safety analyses on the system architectural design shall be performed in accordance with Table
1 and ISO 26262-9:2018, Clause 8 in order to:
— provide evidence for the suitability of the system design to provide the specified safety-related
functions and properties with respect to the ASIL;
— identify the causes of failures and the effects of faults;
— identify or confirm the safety-related system elements and interfaces; and
— support the design specification and verify the effectiveness of the safety mechanisms based on
identified causes of faults and the effects of failures.
Table 1 — System architectural design analysis
ASIL
Methods
A B C D
1 Deductive analysis o + ++ ++
2 Inductive analysis ++ ++ ++ ++
NOTE 1 Safety-related properties include independency and freedom from interference requirements.
NOTE 2 The purpose of these analyses is to assist in the design. Therefore at this stage, qualitative analysis is
sufficient. Quantitative analysis can be performed if necessary.
NOTE 3 The analysis is conducted at the level of detail necessary to identify causes and effects of random
hardware failures and systematic failures.
NOTE 4 The aim of using a combination of deductive and inductive methods is to provide complementary
approaches to analysis, see also ISO 26262-9:2018, 8.2.
6.4.4.2 Identified internal causes of failure shall be eliminated, or their effects mitigated where
necessary, to comply with the safety goals or requirements.
6.4.4.3 Identified external causes of failure shall be eliminated, or their effects mitigated where
necessary, to comply with the safety goals or requirements.
6.4.4.4 To reduce the likelihood of systematic failures, well-trusted systems design principles
...