ISO/PAS 21448:2019

PUBLICLY ISO/PAS
AVAILABLE 21448
SPECIFICATION
First edition
2019-01
Road vehicles — Safety of the intended
functionality
Véhicules routiers - Sécurité de la fonction attendue
Reference number
©
ISO 2019
© ISO 2019
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 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Overview of this document’s activities in the development process .6
5 Functional and system specification (intended functionality content) .11
5.1 Objectives.11
5.2 Functional description .11
5.3 Consideration on system design and architecture .12
6 Identification and Evaluation of hazards caused by the intended functionality .13
6.1 Objectives.13
6.2 Hazard identification .14
6.3 Hazard analysis .15
6.4 Risk evaluation of the intended function .16
6.5 Specification of a validation target .16
7 Identification and Evaluation of triggering events .17
7.1 Objectives.17
7.2 Analysis of triggering events .17
7.2.1 Triggering events related to algorithms .17
7.2.2 Triggering events related to sensors and actuators .18
7.3 Acceptability of the triggering events .19
8 Functional modifications to reduce SOTIF related risks .19
8.1 Objectives.19
8.2 General .19
8.3 Measures to improve the SOTIF .20
8.4 Updating the system specification .22
9 Definition of the verification and validation strategy .22
9.1 Objectives.22
9.2 Planning and specification of integration and testing .23
10 Verification of the SOTIF (Area 2) .23
10.1 Objectives.23
10.2 Sensor verification .24
10.3 Decision algorithm verification .24
10.4 Actuation verification .25
10.5 Integrated system verification .25
11 Validation of the SOTIF (Area 3) .26
11.1 Objectives.26
11.2 Evaluation of residual risk .26
11.3 Validation test parameters.26
12 Methodology and criteria for SOTIF release .27
12.1 Objectives.27
12.2 Methodology for evaluating SOTIF for release .27
12.3 Criteria for SOTIF release .28
Annex A (informative) Examples of the application of SOTIF activities .30
Annex B (informative) Example for definition and validation of an acceptable false alarm
rate in AEB systems .33
Annex C (informative) Validation of SOTIF applicable systems .41
Annex D (informative) Automotive perception systems verification and validation.43
Annex E (informative) Method for deriving SOTIF misuse scenarios.46
Annex F (informative) Example construction of scenario for SOTIF safety analysis method .49
Annex G (informative) Implications for off-line training .52
Bibliography .54
iv © ISO 2019 – 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 of 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 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.
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.
Introduction
The safety of road vehicles during their operation phase is of paramount concern for the road vehicles
industry. Recent years have seen a large increase in the number of advanced functionalities included
in vehicles. These rely on sensing, processing of complex algorithms and actuation implemented by
electrical and/or electronic (E/E) systems.
An acceptable level of safety for road vehicles requires the avoidance of unreasonable risk caused by
every hazard associated with the intended functionality and its implementation, especially those not
due to failures, e.g. due to performance limitations. ISO 26262-1 defines the vehicle safety as the absence
of unreasonable risks that arise from malfunctions of the E/E system. ISO 26262-3 specifies a Hazard
Analysis and Risk Assessment to determine vehicle level hazards. This evaluates the potential risks due
to malfunctioning behaviour of the item and enables the definition of top-level safety requirements,
i.e. the safety goals, necessary to mitigate the risks. The other parts of the ISO 26262 series provide
requirements and recommendations to avoid and control random hardware failures and systematic
failures that could violate safety goals.
For some systems, which rely on sensing the external or internal environment, there can be potentially
hazardous behaviour caused by the intended functionality or performance limitation of a system that is
free from the faults addressed in the ISO 26262 series. Examples of such limitations include:
— The inability of the function to correctly comprehend the situation and operate safely; this also
includes functions that use machine learning algorithms;
— Insufficient robustness of the function with respect to sensor input variations or diverse
environmental conditions.
The absence of unreasonable risk due to these potentially hazardous behaviours related to such
limitations is defined as the safety of the intended functionality (SOTIF). Functional safety (addressed
by the ISO 26262 series) and SOTIF are distinct and complementary aspects of safety.
To address the SOTIF, activities are implemented during the following phases:
— Measures in the design phase;
EXAMPLE Requirement on sensor performance.
— Measures in the verification phase;
EXAMPLE Technical Reviews, test cases with a high coverage of relevant scenarios, injection of
potential triggering events, in the loop testing (e.g. SIL/HIL/MIL) of selected SOTIF are relevant use cases.
— Measures in the Validation phase.
EXAMPLE Long term vehicle test, simulations.
A proper understanding of the function by the user, its behaviour and its limitations (including the
human/machine interface) is the key to ensuring safety.
In many instances, a triggering event is necessary to cause a potentially hazardous behaviour; hence
the importance of analysing hazards in the context of particular use cases.
In this document the hazards caused by a potentially hazardous system behaviour, due to a triggering
event, are considered both for use cases when the vehicle is correctly used and for use cases when it
is incorrectly used in a reasonably foreseeable way (this excludes intentional alterations made to the
system’s operation).
EXAMPLE Lack of driver attention while using a level 2 driving automation.
In addition, reasonably foreseeable misuse, which could lead directly to potentially hazardous system
behaviour, is also considered as a possible triggering event.
vi © ISO 2019 – All rights reserved

A successful attack exploiting vehicle security vulnerabilities can also have very serious consequences
(i.e. data or identity theft, privacy violation, etc.). Although security risks can also lead to potentially
hazardous behaviour that needs to be addressed, security is not addressed by this document.
It is assumed that the E/E random hardware faults and systematic faults of the E/E system are
addressed using the ISO 26262 series. The activities mentioned in this document are complementary to
those given in the ISO 26262 series.
Table 1 illustrates how the possible causes of hazardous event map to existing standards.
Table 1 — Overview of safety relevant topics addressed by different ISO standards
Source Cause of hazardous event Within scope of
E/E System failures ISO 26262 series
Performance limitations or insufficient situa-
tional awareness, with or without reasonably ISO/PAS 21448
foreseeable misuse
ISO/PAS 21448
System
ISO 26262 series
Reasonably foreseeable misuse, incorrect HMI
(e.g. user confusion, user overload) European statement of principal
on the design of human-ma-
chine-interface
Hazards caused by the system technology Specific standards
successful attack exploiting vehicle security
a
ISO 21434 or SAE J3061
vulnerabilities
Impact from active Infrastructure and/or vehi-
External cle to vehicle communication, external devices ISO 20077 series; ISO 26262 series
factor and cloud services.
Impact from car surroundings (other users,
ISO/PAS 21448
“passive” infrastructure, environmental condi-
ISO 26262 series
tions: weather, Electro-Magnetic Interference…)
a
Under preparation. Stage at the time of publication: ISO/SAE CD 21434.
NOTE Options for automated driving level definitions (from NHTSA, SAE and OICA, etc.) are discussed in the
ITS-Informal Group ECE/TRANS/WP29.
PUBLICLY AVAILABLE SPECIFICATION ISO/PAS 21448:2019(E)
Road vehicles — Safety of the intended functionality
1 Scope
The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the
intended functionality or by reasonably foreseeable misuse by persons is referred to as the Safety
Of The Intended Functionality (SOTIF). This document provides guidance on the applicable design,
verification and validation measures needed to achieve the SOTIF. This document does not apply to
faults covered by the ISO 26262 series or to hazards directly caused by the system technology (e.g. eye
damage from a laser sensor).
This document is intended to be applied to intended functionality where proper situational awareness
is critical to safety, and where that situational awareness is derived from complex sensors and
processing algorithms; especially emergency intervention systems (e.g. emergency braking systems)
and Advanced Driver Assistance Systems (ADAS) with levels 1 and 2 on the OICA/SAE standard J3016
automation scales. This edition of the document can be considered for higher levels of automation,
however additional measures might be necessary. This document is not intended for functions of
existing systems for which well-established and well-trusted design, verification and validation (V&V)
measures exist at the time of publication (e.g. Dynamic Stability Control (DSC) systems, airbag, etc.).
Some measures described in this document are applicable to innovative functions of such systems,
if situational awareness derived from complex sensors and processing algorithms is part of the
innovation.
Intended use and reasonably foreseeable misuse are considered in combination with potentially
hazardous system behaviour when identifying hazardous events.
Reasonably foreseeable misuse, which could lead directly to potentially hazardous system behaviour, is
also considered as a possible event that could directly trigger a SOTIF-related hazardous event.
Intentional alteration to the system operation is considered feature abuse. Feature abuse is not in scope
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
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 26262-1:2018 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
action
atomic behaviour that is executed by any actor in a scene
Note 1 to entry: The temporal sequence of actions/events and scenes specify a scenario.
EXAMPLE Ego vehicle activates the hazard warning lights.
3.2
erroneous pattern
input that can trigger unintended behaviour
3.3
event
occurrence at a certain place and at a particular point in time
Note 1 to entry: The temporal sequence of actions/events and scenes specify a scenario.
Note 2 to entry: In particular this document addresses triggering events (3.15) and hazardous events. A hazardous
event is the combination of a hazard (caused by malfunctioning behaviour) and a specific operational situation.
Refer to Figure 12 for details.
EXAMPLE 1 Tree falling on a street 50 m ahead of a vehicle XY.
EXAMPLE 2 Traffic light turning green at time XX:XX.
3.4
functional improvement
modification to a function, system or element specification to reduce risk
3.5
intended behaviour
specified behaviour of the intended functionality including interaction with items
Note 1 to entry: See Clause 5 for additional information about the specification of intended behaviour.
Note 2 to entry: The specified behaviour is the behaviour that the developer of the item considers to be the
nominal (i.e. fault-free) functionality, with its capability limitations due to inherent characteristics of the
components and technology used.
3.6
intended functionality
behaviour specified for a system
3.7
misuse
usage of the system by a human in a way not intended by the manufacturer of the system
Note 1 to entry: Misuse can result from overconfidence in the performance of the system.
Note 2 to entry: Misuse includes human behaviour that is not specified but does not include deliberate system
alterations.
3.8
misuse scenario
scenario in which misuse occurs
3.9
performance limitation
insufficiencies in the implementation of the intended functionality
EXAMPLE Incomplete perception of the scene, insufficiency of the decision algorithm, insufficient
performance of actuation.
2 © ISO 2019 – All rights reserved

3.10
Safety Of The Intended Functionality
SOTIF
absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended
functionality or from reasonably foreseeable misuse by persons
Note 1 to entry: Nominal performance includes intended functionality and the implementation of intended
functionality that can be affected by performance limitations or by foreseeable misuse by persons.
3.11
scenario
description of the temporal development between several scenes in a sequence of scenes
Figure 1 — Scenario (dashed) as a temporal sequence of actions/events (edges) and scenes
(nodes)
Note 1 to entry: Every scenario starts with an initial scene. Actions and events, as well as goals and values, may
be specified to characterise this temporal development within a scenario. In contrast to a scene, a scenario spans
a certain amount of time.
[1]
Note 2 to entry: See Figures 1, 2 and 3 .
Figure 2 — Taxonomy of use case, scene and scenario
Figure 3 — Temporal view of scenes, events, actions and situations in a scenario
3.12
scene
snapshot of the environment including the scenery, dynamic elements, and all actor and observer self-
representations, and the relationships between those entities
Note 1 to entry: See Figure 4.
Note 2 to entry: Only a scene representation in a simulated world can be all-encompassing (i.e. an objective
scene, or ground truth). In the real world the scene is incomplete, incorrect, uncertain, and from one or several
observers’ points of view (i.e. a subjective scene).
[1]
Note 3 to entry: Refer to Reference .
Figure 4 — Characteristics of a scene
4 © ISO 2019 – All rights reserved

3.13
situation
selection of an appropriate behaviour pattern at a particular point of time
Note 1 to entry: A situation entails all relevant conditions, options and determinants for the behaviour. A situation
is derived from the scene, by an information selection and augmentation process that is based on transient (e.g.
mission-specific) as well as permanent goals and values. Hence, a situation is always subjective as it represents
an element’s point of view.
[1]
Note 2 to entry: See Figure 5 and Reference .
Figure 5 — Characteristics of a situation
3.14
test case
set of conditions to determine if a system is working according to its intended functionality
Note 1 to entry: A test case entails a (logical) scenario with a specific set of parametric values for each aspect of
the scenario, together with the pass-fail criteria on which to evaluate it.
[2]
Note 2 to entry: Refer to Reference .
3.15
triggering event
specific conditions of a driving scenario that serve as an initiator for a subsequent system reaction
possibly leading to a hazardous event
EXAMPLE While operating on a highway, a vehicle’s automated emergency braking (AEB) system
misidentifies a road sign as a lead vehicle resulting in braking at X g for Y seconds.
3.16
use case
specification of a generalized field of application, possibly entailing the following information about
the system:
— one or several scenarios;
— the functional range;
— the desired behaviour; and
— the system boundaries
Note 1 to entry: The use case description typically does not include a detailed list of all relevant scenarios for this
use case. Instead a more abstract description of these scenarios is used.
3.17
unexpected item behaviour
unintended behaviour not specified
Note 1 to entry: The unintended behaviour might be discovered during validation.
3.18
validation
set of activities gaining confidence that an item is able to accomplish its expected functionalities and
missions
Note 1 to entry: Verification activities address mainly Area 2 of Figures 7, 8 and 9 including the verification
of known use cases, whereas Validation activities address mainly Area 3 of Figures 7, 8 and 9, including the
validation of SOTIF in unknown use cases.
4 Overview of this document’s activities in the development process
The objective sub-clauses of this document (5.1, 6.1, 7.1, 8.1, 9.1, 10.1, 11.1 and 12.1) are normative. All
other content is informative. Compliance to this document can be claimed by listing the objectives and
providing an argument that the objectives have been achieved.
A development interface agreement can be defined between all development parties when applicable
for a distributed product development. The goal of an agreement is to confirm in the early stages of a
project all responsibilities of the SOTIF activities.
Achieving SOTIF requires some activities which are complementary to the ISO 26262:2018 series. One
of the main objectives of this document is to outline the process and rationale used to ensure that the
likelihood of a hazardous event is sufficiently low. Furthermore, this document also seeks to assess that
the remaining residual risk from:
i) a system not able to process a given scenario in a safe manner, and
ii) the involved persons (driver, other vehicle occupants, or bystanders) are not capable of mitigating
the hazardous event, is acceptable (see Figure 6).
The functional and system specification includes relevant use cases and those use cases are comprised
of several relevant scenarios. These scenarios could contain triggering events (see Clause 3 definitions)
that lead to harm (see Figure 6).
6 © ISO 2019 – All rights reserved

a
These scenarios can also be caused by reasonably foreseeable misuse, e.g. activating a functionality intended for
the highway in an urban setting causes the vehicle to be in a scenario in which it does not detect a red traffic light.
b
Reasonably foreseeable misuse can lead directly to a hazard, e.g. in case of mode confusion where the driver
assumes that the system is active even though it is deactivated.
c
The inability to control the hazardous event can also be the result of a reasonably foreseeable misuse, e.g. the
driver does not supervise the system as he is supposed to do.
Figure 6 — Visualisation of a Potential SOTIF-related Hazardous Event Model
Within this document, the scenarios which are part of the relevant use cases are therefore classified
into four areas (see Figure 7).
Key
1 known safe scenarios (Area 1)
2 known unsafe scenarios (Area 2)
3 unknown unsafe scenarios (Area 3)
4 unknown safe scenarios (Area 4)
Figure 7 — Visualisation of the Known/Unknown and Safe/Unsafe Scenario categories
Areas 1, 2 and 3 are used as a mental model to structure this document. Area 4 is referenced for
completeness but is not needed for the purposes of this document and therefore not used further. When
considering the areas in the model, it can be useful to imagine their size as representing the proportion
of each type of scenario that falls within each respective area.
A given use case can include known as well as unknown scenarios.
At the beginning of the development Areas 2 and Area 3 might be too large, resulting in unacceptable
residual risk. The ultimate goal of the SOTIF activities to evaluate the SOTIF in Area 2 and Area 3 and to
provide an argument that these areas are sufficiently small and therefore that the resulting residual risk
is acceptable. While the known scenarios and the corresponding use cases of Area 2 can be explicitly
evaluated, the scenarios and corresponding use cases of Area 3 are evaluated by industry best practice
or by other approaches such as design measures, systematic analyses, or dedicated experiments. The
results of these evaluations provide an argument that Area 3 is sufficiently small and Area 2 is managed
through SOTIF improvements and therefore the probability of encountering these kinds of scenarios is
sufficiently low.
It is expected that Areas 2 and Area 3 will be reduced and Area 1 will grow during development
(see Figure 8).
Key
1 known safe scenarios (Area 1)
2 known unsafe scenarios (Area 2)
3 unknown unsafe scenarios (Area 3)
4 unknown safe scenarios (Area 4)
Figure 8 — Evolution of the scenario categories resulting from the ISO/PAS 21448 activities
The goals of the SOTIF process with respect to Area 1, Area 2, and Area 3 and relevant scenarios are:
— Area 1: Maximize or maintain area, while minimizing Areas 2 & 3. This retains or improves safe
functionality.
— Area 2: Minimize area with technical measures to an acceptably small level, with statistical
significance of that level appropriate to the relative impact of the technical measure; evaluate the
potential risk and, if necessary, move hazardous scenarios into Area 1 by improving the function or
by restricting the use/performance of the function.
— Area 3: Minimize area (the risk of the unknown) as much as possible with an acceptable level of
effort (every detected hazardous scenario is moved into Area 2).
8 © ISO 2019 – All rights reserved

Figure 9 describes a flowchart for the improvement of the intended functionality to ensure its safety.
The circled numbers denote the corresponding clauses within this document.
Figure 9 — Flowchart of this document’s activities
In Figure 9, the process starts with a definition of the functional and system specification (see Clause 5).
The possible hazardous behaviours of the intended function are subjected to a Hazard Identification
and Risk Evaluation (see Clause 6) that identifies potential hazardous events. If it is shown that these
potentially hazardous events do not lead to harm, then no improvement is necessary and the intended
functionality can be considered free from unreasonable risk.
If it is shown that harm is possible, then an analysis of the possible hazardous triggering events (e.g.
misdetection of certain objects under certain environmental conditions or driver misuse) is conducted
(see Clause 7).
Clause 6 and Clause 7 address different aspects of the SOTIF. Clause 6 does not consider the causes of
possible hazardous intended behaviour of the function, but only their consequences for safety. Clause 6
is, therefore, focused on evaluating hazardous events that could result from hazardous intended
behaviour, and on defining the verification and validation targets to be met. Clause 7 addresses the
analysis of the causes of potentially hazardous behaviour. These are mitigated in Clause 8 and verified
and validated in Clause 9, Clause 10 and Clause 11.
Functional improvement or restrictions of the use cases are applied to avoid these hazards or to further
reduce the resulting risk (see Clause 8).
A verification and validation strategy is developed to provide an argument that the residual risk is below
an acceptable level (see Clause 9). This includes enforcement of the resulting strategy. Corresponding
verification and validation test cases can be derived from this analysis (see Clauses 10 & 11).
Finally, the residual risk is evaluated (Clause 12) considering the results from verification and validation.
If the risk is determined to be unacceptable, further functional improvement or restrictions of the use
cases can be necessary (Clause 8). This verification and validation strategy can include model-in-the-
loop (MIL), software-in-the-loop (SIL), hardware-in-the-loop (HIL), test track experiments, dedicated
analyses, long-term endurance tests, or other approaches.
Possible causes of unintended behaviour considered in this document are closely related to the
performance of sensing, processing of algorithms, actuation, and their implementation for the
functionality under development. Therefore, this document’s activities are applicable to the vehicle,
system, and component levels.
Similarly, the selection of a capable, overall system architecture becomes a primary concern to ensure
the SOTIF, and, to ensure that overall capability, corresponding activities take place both at early stages
and throughout the overall functional development lifecycle.
It can be necessary to include specific mechanisms to ensure the SOTIF. For instance, a dedicated
Human-Machine Interface (HMI) can be defined to prevent/mitigate some reasonably foreseeable
misuses by the driver (see Annex E). During the product development, both this document’s activities
and activities specified in the ISO 26262:2018 series activities are carried out and the measures for
SOTIF are evaluated.
Figure 10 — Possible interactions of product development activities between this document
and the ISO 26262 series processes
Figure 10 describes possible interactions between this document and the ISO 26262:2018 series
activities. The product development phases will typically require several iterations to produce a final
functional and system specification. These iterations are not represented in the figure.
10 © ISO 2019 – All rights reserved

A set of methods and measures are selected in order to:
— Identify and evaluate the SOTIF related hazards associated with the intended functionality
(Clause 6);
— Identify and evaluate hazardous triggering events (Clause 7);
— Improve the system design as necessary through functional modifications or use case restriction to
reduce SOTIF risk (Clause 8); and
— Verify and validate the appropriateness of the design with respect to the SOTIF (Clause 9–11).
NOTE The hazard identification process is similar to the process described in ISO 26262-3:2018, because
the vehicle-level effects of SOTIF related potentially hazardous behaviour and the system failures covered by the
ISO 26262 series can be identical.
Annex A presents an example of application of the SOTIF activities.
This document provides a non-exhaustive collection of methods and measures, from which the
development team can select the appropriate combination. Other equivalent methods can also be
applied.
5 Functional and system specification (intended functionality content)
5.1 Objectives
The functional and system specification activity shall:
— Compile and create evidence containing the information sufficient to initiate the SOTIF related
activities;
— Update the evidence as necessary after each iteration of the SOTIF related activities (see Figure 9).
5.2 Functional description
The functional and system specification includes (where applicable):
Function related:
— The goals of the intended functionality;
— The use cases in which the intended functionality is activated, deactivated and active;
— The description of the intended functionality;
— The level of automation/authority over the vehicle dynamics; and
— The dependencies on, and interaction with:
— the car driver, passengers, pedestrians and other road users;
— relevant environmental conditions; and
— the interfaces with the road infrastructure.
System related:
— The description of the system and elements implementing the intended functionality.
— The description and behaviour of the installed sensors, controllers and actuators used by the
intended functionality.
— The assumptions about how the intended functionality makes use of inputs from other elements.
— The assumptions about how other elements make use of outputs from the intended functionality.
— The concepts and technologies for the system and sub systems.
— The limitations and their countermeasures.
— The system architecture supporting the countermeasures.
— The degradation concept.
— The warning strategies.
— The dependencies on, and interaction with other functions and systems of the vehicle.
NOTE This document and the ISO 26262-3:2018 item definition can contain common information.
5.3 Consideration on system design and architecture
The functional and system specification provides an adequate understanding of the system and its
functionality so that the activities in subsequent phases can be performed. This includes a list of all
performance limitations and their countermeasures. Some limitations and countermeasures are
known and documented before the SOTIF related process begins while others are revealed as a result
of the SOTIF activities.
Each iteration of the SOTIF related activity (Figure 9) can result in engineering activity and an update
to this specification. Each iteration relies on this specification being up to date, such that it reflects all
information discovered in previous iterations. Cooperation between all development parties (OEM, Tier1,
TierN) is used to discover limitations and develop countermeasures during all development phases.
The functional and system specification lists performance limitations of every individual mechanisms,
algorithms, or elements related to the safety of the intended functionality. The system is thus designed
considering such limitations and ensuring that countermeasures are taken to mitigate their effect on
the overall system if needed.
As the SOTIF activities identify new limitations and consequences (Clause 7), and define new mitigation
measures (Clause 8), the functional and system specification is updated. This will ensure that all the
required work is done both for closure of previous iterations, and at the beginning of the next iteration.
Specifically, the design includes considerations of system limitations that can result in erroneous
subsystem output values being reported with high confidence (low confidence values might be ignored
by design) and which can lead to potentially hazardous behaviour. Examples of limitations include
incorrect classification, incorrect measurements, incorrect tracking, misdetection, ghosts, incorrect
target selection, incorrect kinematic estimation, etc.
The final system architecture achieves robustness by considering every component, technology and
system limitation. The system development is based on the assumption made about the limitations in
design. Implementing measures to ensure SOTIF and integrating them into the functional and system
specification, decreases the sizes of Area 2 and Area 3, and increases overall robustness by increasing
the size of Area 1. Area 3 testing is used to uncover new issues only when the countermeasures, with
respect to the original system design, are incomplete or not applicable to newly introduced use cases.
NOTE 1 Methods such as qualitative fault tree, HAZOP, FMEA, STPA and event tree analysis can be used to
increase the confidence for the SOTIF.
NOTE 2 Performance limitations can be addressed by redundancy, diversity, functional restrictions or other
measures.
12 © ISO 2019 – All rights reserved

EXAMPLE 1 A highway lane boundary detection algorithm, for functions such as lane keeping, might
incorrectly determine the lane due to debris on the roadway. However, lane excursions that result in a collision can
be mitigated by other autonomous driving functionality such as: using a high definition map and localization to
confirm the lane, rationalizing the vehicle trajectory with the trajectory of preceding vehicles, collision avoidance
algorithms maintaining separation with other vehicles even if this implies leaving the perceived lane, etc.
EXAMPLE 2 An object detection algorithm detects a person on a skateboard as a pedestrian but rejects
the object as due to its speed being implausible. A collision with the skateboarder is mitigated by a collision
mitigation braking system which uses sensing and processing that is independent from that of the object
detection algorithm.
EXAMPLE 3 An optical illusion drawing of a child running into the road is used to alert drivers in some areas.
The image is drawn specifically to fool the human perception and can also fool a vision system into detecting a
non-existent object. In this case, an optical flow-based analysis mechanism can prevent false braking. Optical
flow analyses as well as radar-based environment recognition are alternative countermeasures for such cases, as
well as other common detection cases such as ghosts that result from classification errors.
Figure 11 — Example of optical illusion drawing that could fool a vision system
EXAMPLE 4 Using an automated parking system with a big item protruding from the open trunk can lead to
a hazardous event. A countermeasure in the system design can be to only permit automatic parking when the
trunk is closed.
6 Identification and Evaluation of hazards caused by the inte
...