>>
<<
ISO 21448:2022(en)
ISO - Cover page
Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Overview and organization of SOTIF activities
 4.1 General
 4.2 SOTIF principles
  4.2.1 SOTIF-related hazardous event model
  4.2.2 The four scenario areas
  4.2.3 Sense-Plan-Act model
 4.3 Use of this document
  4.3.1 Flow chart and structure of this document
  4.3.2 Normative clauses
  4.3.3 Interpretation of tables
 4.4 Management of SOTIF activities and supporting processes
  4.4.1 Quality management, systems engineering and functional safety
  4.4.2 Distributed SOTIF development activities
  4.4.3 SOTIF-related element out of context
5 Specification and design
 5.1 Objectives
 5.2 Specification of the functionality and considerations for the design
 5.3 System design and architecture considerations
 5.4 Performance insufficiencies and countermeasures considerations
 5.5 Work products
6 Identification and evaluation of hazards
 6.1 Objectives
 6.2 General
 6.3 Hazard identification
 6.4 Risk evaluation
 6.5 Specification of acceptance criteria for the residual risk
 6.6 Work products
7 Identification and evaluation of potential functional insufficiencies and potential triggering conditions
 7.1 Objectives
 7.2 General
 7.3 Analysis of potential functional insufficiencies and triggering conditions
  7.3.1 General
  7.3.2 Potential functional insufficiencies and triggering conditions related to planning algorithms
  7.3.3 Potential functional insufficiencies and triggering conditions related to sensors and actuators
  7.3.4 Analysis of reasonably foreseeable direct or indirect misuse
 7.4 Estimation of the acceptability of the system's response to the triggering conditions
 7.5 Work products
8 Functional modifications addressing SOTIF-related risks
 8.1 Objectives
 8.2 General
 8.3 Measures to improve the SOTIF
  8.3.1 Introduction
  8.3.2 System modification
  8.3.3 Functional restrictions
  8.3.4 Handing over authority
  8.3.5 Addressing reasonably foreseeable misuse
  8.3.6 Considerations to support the implementation of SOTIF measures
 8.4 Updating the input information for “Specification and design”
 8.5 Work products
9 Definition of the verification and validation strategy
 9.1 Objectives
 9.2 General
 9.3 Specification of integration and testing
 9.4 Work products
10 Evaluation of known scenarios
 10.1 Objectives
 10.2 General
 10.3 Sensing verification
 10.4 Planning algorithm verification
 10.5 Actuation verification
 10.6 Integrated system verification
 10.7 Evaluation of the residual risk due to known hazardous scenarios
 10.8 Work products
11 Evaluation of unknown scenarios
 11.1 Objectives
 11.2 General
 11.3 Evaluation of residual risk due to unknown hazardous scenarios
 11.4 Work products
  11.4.1 Validation results for unknown hazardous scenarios fulfilling objective 11.1
  11.4.2 Evaluation of the residual risk fulfilling objective 11.1
12 Evaluation of the achievement of the SOTIF
 12.1 Objectives
 12.2 General
 12.3 Methods and criteria for evaluating the SOTIF
 12.4 Recommendation for SOTIF release
 12.5 Work products
13 Operation phase activities
 13.1 Objectives
 13.2 General
 13.3 Topics for observation
 13.4 SOTIF issue evaluation and resolution process
 13.5 Work products
Annex A (informative) General guidance on SOTIF
Annex B (informative) Guidance on scenario and system analyses
Annex C (informative) Guidance on SOTIF verification and validation
Annex D (informative) Guidance on specific aspects of SOTIF
Bibliography
30mm
20mm
15mm
15mm
10mm
17mm

International

Standard

ISO 21448
Road vehicles — Safety of the intended functionality
Véhicules routiers — Sécurité de la fonction attendue
Reference number
ISO 21448:2022(en)
First edition
2022-06
30mm
20mm
15mm
15mm
10mm
17mm
30mm
20mm
15mm
15mm
10mm
17mm

ContentsPage

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.
This first edition cancels and replaces the first edition of ISO/PAS 21448:2019, which has been technically revised.
The main changes are as follows:
the scope has been extended to include all levels of driving automation;
the clauses and annexes have been reworked and expanded for clarification and additional guidance;
the definitions (Clause 3) have been reworked, in particular to clarify the hazard model; and
Clause 13 has been added to address the operation phase after the function has been activated for end users.
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 is a concern of paramount importance for the road vehicle industry. The number of automated driving functionalities included in vehicles is increasing. 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 absence of unreasonable risk caused by every hazard associated with the intended functionality and its implementation, including both hazards due to failures and due to insufficiencies of specification or performance insufficiencies.
For the achievement of functional safety, ISO 26262-1 defines functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of the E/E system. ISO 26262-3 describes how to conduct a hazard analysis and risk assessment (HARA) to determine vehicle-level hazards and associated safety goals. 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 E/E systems, e.g. systems which rely on sensing the external or internal vehicle environment to build situational awareness, the intended functionality and its implementation can cause hazardous behaviour, despite these systems being free from the faults addressed in the ISO 26262 series. Example causes of such potentially hazardous behaviour include:
the inability of the function to correctly perceive the environment;
the lack of robustness of the function, system, or algorithm with respect to sensor input variations, heuristics used for fusion, or diverse environmental conditions;
the unexpected behaviour due to decision making algorithm and/or divergent human expectations.
In particular, these factors are relevant to functions, systems or algorithms that use machine learning.
The absence of unreasonable risk resulting from hazardous behaviours related to functional insufficiencies is defined as the safety of the intended functionality (SOTIF). Functional safety (addressed by the ISO 26262 series) and the SOTIF are complementary aspects of safety (see A.2 for a better understanding of the respective scopes of the ISO 26262 series and this document).
To address the SOTIF, measures to eliminate hazards or reduce risks are implemented during the following phases:
the specification and design phase;
EXAMPLE 1Modification of vehicle functionality or of sensor performance requirements, driven by identified system insufficiencies or by hazardous scenarios identified during the SOTIF activities.
the verification and validation phase; and
EXAMPLE 2Technical reviews, test cases with a high coverage of relevant scenarios, injection of potential triggering conditions, in the loop testing (e.g. SIL: software in the loop / HIL: hardware in the loop / MIL: model in the loop) of selected SOTIF-relevant scenarios.
EXAMPLE 3Long-term vehicle testing, test-track vehicle testing, simulation testing.
the operation phase.
EXAMPLE 4Field monitoring of SOTIF incidents.
These hazards can be triggered by specific conditions of a scenario, defined as triggering conditions, which can include reasonably foreseeable misuse of the intended functionality. Additionally, the interaction with other functions at the vehicle level can lead to hazards (e.g. activation of the parking brake while the automated driving function is active).
Therefore, a proper understanding by the user of the functionality, its behaviour and its limitations (including the human/machine interface) is essential to ensure safety.
EXAMPLE 5Lack of driver attention while using a Level 2 automated driving system.
EXAMPLE 6Mode confusion (e.g. the driver thinks the function is activated when it is deactivated) can directly lead to a hazard.
NOTE 1Reasonably foreseeable misuse excludes intentional alterations made to the system’s operation.
Information provided by the infrastructure (e.g. V2X – Vehicle2Everything communication, maps) is also part of the evaluation of functional insufficiencies if it can have an impact on the SOTIF. See D.4 for guidance on V2X features.
EXAMPLE 7For automated valet parking systems, the functionalities of route planning and object detection could be achieved jointly by the infrastructure and the vehicle.
NOTE 2Depending on the application, elements of other technologies can be relevant when evaluating the SOTIF.
EXAMPLE 8The location and mounting of a sensor on the vehicle can be relevant to avoid noisy sensor output resulting from vibration.
EXAMPLE 9The windshield optical properties can be relevant when evaluating the SOTIF of a camera sensor.
It is assumed that the random hardware faults and systematic faults (including hardware and software faults) of the E/E system are addressed using the ISO 26262 series.
One could interpret the functional insufficiencies addressed in this document as systematic faults. However, the measures to address these functional insufficiencies are specific to this document and complementary to the ones described in the ISO 26262 series. Specifically, the ISO 26262 series assumes that the intended functionality is safe, and addresses E/E system faults that can cause hazards due to a deviation from the intended functionality. The requirement-elicitation process for the system and its elements can include aspects of both standards.
Table 1 illustrates how the possible causes of hazardous events map to existing standards.
Table 1 — Overview of safety relevant topics addressed by different standards
Source of hazard Cause of hazardous events Within scope of
System E/E system faults ISO 26262 series
Functional insufficiencies This document
Incorrect and inadequate Human-Machine Interface (HMI) design (inappropriate user situational awareness, e.g. user confusion, user overload, user inattentiveness) This document
European Statement of Principles on human-machine interface[1]
Functional insufficiencies of artificial intelligence-based algorithms This document
System technologies
EXAMPLE    Eye damage from the beam of a lidar.
Specific standards
EXAMPLE     IEC 60825
External factor Reasonably foreseeable misuse by the user or by other road participants This document
The ISO 26262 series
Attack exploiting vehicle security vulnerabilities ISO/SAE 21434
Impact from active infrastructure and/or vehicle to vehicle communication, and external systems This document
ISO 20077; ISO 26262 series, IEC 61508 series
Impact from vehicle surroundings (e.g. other users, passive infrastructure, weather, electromagnetic interference) This document
The ISO 26262 series
ISO 7637-2, ISO 7537-3
ISO 11452-2, ISO 11452-4, ISO 10605 and other relevant standards
30mm
20mm
15mm
15mm
10mm
17mm

International StandardISO 21448:2022(en)
Road vehicles — Safety of the intended functionality

1Scope

This document provides a general argument framework and guidance on measures to ensure the safety of the intended functionality (SOTIF), which is the absence of unreasonable risk due to a hazard caused by functional insufficiencies, i.e.:
a)
the insufficiencies of specification of the intended functionality at the vehicle level; or
b)
the insufficiencies of specification or performance insufficiencies in the implementation of electric and/or electronic (E/E) elements in the system.
This document provides guidance on the applicable design, verification and validation measures, as well as activities during the operation phase, that are needed to achieve and maintain the SOTIF.
This document is applicable to intended functionalities where proper situational awareness is essential to safety and where such situational awareness is derived from complex sensors and processing algorithms, especially functionalities of emergency intervention systems and systems having levels of driving automation from 1 to 5[2].
This document is applicable to intended functionalities that include one or more E/E systems installed in series production road vehicles, excluding mopeds.
Reasonably foreseeable misuse is in the scope of this document. In addition, operation or assistance of a vehicle by a remote user or communication with a back office that can affect vehicle decision making is in scope of this document when it can lead to safety hazards.
This document does not apply to:
faults covered by the ISO 26262 series;
cybersecurity threats;
hazards directly caused by the system technology (e.g. eye damage from the beam of a lidar);
hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, release of energy and similar hazards, unless directly caused by the intended functionality of E/E systems; and
deliberate actions that clearly violate the system’s intended use, (which are considered feature abuse).
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 (e.g. dynamic stability control systems, airbags).

2Normative 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, Road vehicles — Functional safety — Part 1: Vocabulary

3Terms and definitions

For the purposes of this document, the terms and definitions given in ISO 26262-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
ISO Online browsing platform: available at https://www.iso.org/obp
IEC Electropedia: available at https://www.electropedia.org/
3.1
acceptance criterion
criterion representing the absence of an unreasonable level of risk (3.23)
Note 1 to entry: The acceptance criterion can be of qualitative as well as quantitative nature, e.g. physical parameters that define when a specific behaviour is considered as hazardous behaviour, maximum number of incidents per hour, as low as reasonably practicable (ALARP).
EXAMPLE 1        From traffic statistics, a reasonable level of risk of one accident per X km is derived.
EXAMPLE 2        The comparison with an equivalent vehicle-level effect that is proven in use to be controllable by the driver can support the definition of an acceptance criterion. For instance, the trajectory perturbation due to an unwanted lane keeping assist function intervention might be compared to a lateral wind gust to define an acceptable level of authority for the function.
3.2
action
single act or behaviour that is executed by any actor in a scene (3.27)
Note 1 to entry: The temporal sequence of actions/events (3.7) and scenes ‎are parts of the definition of a scenario (3.26).
EXAMPLE        Ego vehicle (3.6) activates the hazard warning lights.
Note 2 to entry: In the context of this definition, an actor can be a person, another object, another system or any element in interaction with the considered function.
3.3
driving policy
strategy and rules defining acceptable actions (3.2) at the vehicle level
3.4
dynamic driving task
DDT
real-time operational and tactical functions required to operate a vehicle in traffic
Note 1 to entry: The following functions are part of the DDT:
lateral vehicle motion control (operational);
longitudinal vehicle motion control (operational);
monitoring the driving environment (operational and tactical) and object and event (3.7) response execution (operational and tactical), see object and event detection and response (OEDR) (3.20);
manoeuvre planning (tactical); and
enhancing conspicuity via lighting, signalling or gesturing, etc. (tactical).
Note 2 to entry: The concept was originally defined in SAE J3016[2].
3.5
DDT fallback
response by the driver or automation system to either perform the dynamic driving task (DDT) (3.4) or transition to a minimal risk condition (MRC) (3.16) after the occurrence of a failure(s) or detection of a functional insufficiency (3.8) or upon detection of a potentially hazardous behaviour
EXAMPLE        An operational design domain (ODD) (3.21) exit or a sensor blocked by ice can lead to hazardous behaviour which requires a response by the driver.
Note 1 to entry: The concept was originally defined in SAE J3016[2].
3.6
ego vehicle
vehicle fitted with functionality that is being analysed for the SOTIF (3.25)
3.7
event
occurrence at a point in time
Note 1 to entry: The temporal sequence of actions (3.2)/events and scenes ‎(3.27) are parts of the definition of a scenario (3.26).
Note 2 to entry: While every action is also an event, not every event is an action, i.e. the set of all actions is a subset of all events.
EXAMPLE 1        Tree falling on a street 50 m ahead of a vehicle.
EXAMPLE 2        Traffic light turning green at a given time.
3.8
functional insufficiency
insufficiency of specification (3.12) or performance insufficiency (3.22)
Note 1 to entry: Functional insufficiencies include the insufficiencies of specification or performance insufficiencies at the vehicle level or the E/E elements of the system.
Note 2 to entry: The SOTIF (3.25) activities include the identification of functional insufficiencies and the evaluation of their effects. Functional insufficiencies lead to hazardous behaviour or inability to prevent or detect and mitigate a reasonably foreseeable misuse (3.17) by definition (see 3.12 and 3.22). The term “potential functional insufficiency” can be used when the ability to contribute to hazardous behaviour or inability to prevent or detect and mitigate a reasonably foreseeable misuse is not yet established.
Note 3 to entry: Figures 1 to 3 describe the SOTIF cause and effect model, in which the relation of triggering conditions (3.30), functional insufficiencies, output insufficiencies, hazardous behaviour, inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse, hazard (3.11), hazardous event (3.7) and harm is described.
Note 4 to entry: In the case of indirect misuse contributing to the occurrence of harm, two functional insufficiencies are typically involved. One is the functional insufficiency leading to the hazardous behaviour of the system in combination with triggering conditions, the other is the functional insufficiency leading to the inability to prevent or detect and mitigate the reasonably foreseeable indirect misuse. See Figures 1, 2 and 3.
EXAMPLE        A vehicle is equipped with a Level 2 highway driving assist functionality. A driver monitoring camera to detect the inattentiveness of the driver is part of the system. For sake of simplicity let us assume that the following statements are true:
the sense element has a functional insufficiency that, if activated by the triggering condition 1, leads to the hazardous behaviour – execution of an incorrect vehicle trajectory; and
the driving monitoring camera has a functional insufficiency that, if activated by the triggering condition 2, leads to the inability of the system to detect and mitigate a reasonably foreseeable indirect misuse.
For the harm to occur the scenario (3.26) needs to contain the following:
presence of an indirect misuse by the driver: driver is inattentive and does not detect the hazardous behaviour of the system in time to be able to control it;
presence of triggering condition 2 leading to the inability of the system to detect and mitigate the present reasonably foreseeable indirect misuse in time; and
presence of triggering condition 1 leading to the hazardous behaviour of the system.
Note 5 to entry: If a functional insufficiency at the vehicle level is activated by a triggering condition, it results in either a hazardous behaviour or an inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse. See Figure 3 (A).
Note 6 to entry: If a functional insufficiency on element level is activated by a triggering condition, it results in what is referred to as an output insufficiency. See Figure 3 (B). An output insufficiency, either by itself or in combination with one or more output insufficiencies of other elements, contributes to either a hazardous behaviour at the vehicle level or an inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse. See Figure 3 (B).
Figure 1 — Correlation between hazard and occurrence of harm
fig_1
Key
a The hazard is the potential source of the harm, caused by a hazardous behaviour at the vehicle level.
b The scenario containing conditions in which the hazard can lead to harm is a contributing factor to the occurrence of harm, but not its source.
c The inability to gain sufficient control of the hazardous event is a contributing factor to the occurrence of harm, but not its source.
Figure 2 — Reasons for the hazardous event not being controlled
fig_2
Figure 3 — The SOTIF cause and effect model
fig_3
Key
a Depending on the architecture of the system this functional insufficiency on an element level can be recognized either as a single-point functional insufficiency (3.28) or a multiple point functional insufficiency (3.19).
b An output insufficiency, either by itself or in combination with one or more output insufficiencies of other elements, contributes to either a hazardous behaviour at the vehicle level or an inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse.
3.9
functional modification
alteration of a functional specification
Note 1 to entry: Functional modification is not the same as the term “modification” defined in ISO 26262-1:2018. The "functional modification" of this document would be referred to as "change" in ISO 26262 terms.
3.10
fallback-ready user
user who is able to operate the vehicle and is capable of intervening to perform the DDT fallback (3.5) as required and within a time span appropriate for the defined non-driving occupation
Note 1 to entry: The concept was originally defined in SAE J3016[2].
3.11
hazard
potential source of harm caused by the hazardous behaviour at the vehicle level
[SOURCE: ISO 26262-1:2018, 3.75, modified — The word "malfunctioning" has been replaced by "hazardous", the phrase "of the item" has been replaced by "at the vehicle level" and the Note 1 to entry has been removed.]
3.12
insufficiency of specification
specification, possibly incomplete, contributing to either a hazardous behaviour or an inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse (3.17) when activated by one or more triggering conditions (3.30)
EXAMPLE 1        An incomplete specification of the adaptive cruise control headway distance results in the ego vehicle (3.6) not keeping a safe distance to the vehicle in front.
EXAMPLE 2        System inability to handle uncommon road signs due to specification gaps, i.e. the uncommon road sign is not part of the specification and thus the system cannot process it appropriately.
Note 1 to entry: Insufficiency of specification can be either known or unknown at a given point in the system lifecycle.
Note 2 to entry: The SOTIF (3.25) activities include the identification of insufficiencies of specification and the evaluation of their effects. The term “potential insufficiency of specification” can be used when the ability to contribute to hazardous behaviour or inability to prevent or detect and mitigate a reasonably foreseeable misuse is not yet established.
Note 3 to entry: Requirements derived from the specification, from the assumptions of other systems or elements, or from systematic analyses (such as those included in Clause 6 or other analyses that elicit design and implementation requirements for the SOTIF) can be included in formal databases to support assurance of verification. These requirements might not be designated as the “specification” in many organizations but are necessary to ensure the SOTIF. The usage of the term “insufficiency (insufficiencies) of specification” in this document includes insufficiencies in such derived requirements.
3.13
intended behaviour
behaviour of the intended functionality (3.14)
Note 1 to entry: The intended behaviour is that which the developer considers to be the nominal functionality considering capability limitations due to inherent characteristics of the components and technology used.
Note 2 to entry: The intended behaviour specified by the developer, while not representing unreasonable risk (3.31), might not match the driver’s expectation of the system behaviour.
3.14
intended functionality
specified functionality
Note 1 to entry: Intended functionality is defined at the vehicle level.
3.15
levels of driving automation
mutually exclusive set of driving automation levels, ranging from Level 0
(no automation) to Level 5 (full automation), defining the roles of the driver or user and automation system in relation to each other
Note 1 to entry: See Table 2.
Note 2 to entry: The concept was originally defined in SAE J3016[2].
Table 2 — Levels of driving automation
    DDT (3.4)    
Level Name Lateral and longitudinal vehicle motion control OEDR (3.20) DDT fallback (3.5) ODD (3.21)
0 No driving automation Driver Driver Driver Not applicable
1 Driver assistance Driver and system Driver Driver Limited
2 Partial driving automation System Driver Driver Limited
3 Conditional driving automation System System Fallback-ready user (3.10) Limited
4 High driving automation System System System Limited
5 Full driving automation System System System Unlimited
3.16
minimal risk condition
MRC
vehicle state in order to reduce the risk (3.23), when a given trip cannot be completed
Note 1 to entry: This is one expected outcome of a DDT fallback (3.5).
Note 2 to entry: The functional safety analogue of the ISO 26262 series would be the safe state.
Note 3 to entry: The concept was originally defined in SAE J3016[2].
3.17
misuse
usage in a way not intended by the manufacturer or the service provider
Note 1 to entry: Misuse includes human behaviour that is not intended but does not include deliberate system alterations or use of the system with the intention to cause harm.
Note 2 to entry: Misuse can result from overconfidence in the performance of the system.
Note 3 to entry: Depending on the causal relationship to the hazardous behaviour, there are two kinds of misuse, direct and indirect.
Note 4 to entry: Direct misuse, which could be a cause for the occurrence of a hazardous behaviour of the system, is considered to be a potential triggering condition (3.30). If its ability to contribute to the occurrence of a hazardous behaviour is established, then it is considered to be a triggering condition. It is also possible that the direct misuse is part of a triggering condition, i.e. next to the direct misuse additional specific conditions of a scenario need to be present for the hazardous behaviour of the system to occur.
EXAMPLE 1        Direct misuse: activating a functionality intended for the highway in an urban setting results a scenario (3.26) in which the vehicle does not detect and react to a STOP sign.
EXAMPLE 2        Direct misuse: driver activates automated system when outside the operational design domain (ODD) (3.21) specified in the user manual. This is considered direct misuse independent of whether the system includes an ego vehicle (3.6) localization component that prevents activation outside the specified ODD.
Note 5 to entry: Indirect misuse leads to a reduced controllability of the hazardous behaviour, to a potentially increased severity of an occurring accident, or a combination of both. It is not considered to be a potential triggering condition since it cannot contribute to the hazardous behaviour of the system itself.
EXAMPLE 3        Indirect misuse: a hands-free Level 2 highway assistant with known perception issues, requires the driver to continuously monitor the correct execution of the dynamic driving task (DDT) (3.4) by the system and intervene if necessary. Indirect misuse is the driver falling asleep and not monitoring. This is considered indirect misuse independent of whether or not the situation is detected and mitigated by a driver monitoring system.
EXAMPLE 4        Indirect misuse: passenger unbuckling the seat belt while ego vehicle is in motion and driving autonomously. This is indirect misuse due to the potential to increase the severity of an accident while not being a triggering condition.
Note 6 to entry: Refer to Figures 1 to 3.
3.18
misuse scenario
scenario (3.26) in which misuse (3.17) occurs
3.19
multiple-point functional insufficiency
functional insufficiency (3.8) of an element leading to hazardous behaviour or inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse (3.17) only in conjunction with functional insufficiencies of other elements when activated by one or more triggering conditions (3.30)
3.20
object and event detection and response
OEDR
tasks of the dynamic driving task (DDT) (3.4) that include monitoring the driving environment and executing an appropriate response to objects and events (3.7) to complete the DDT and/or the DDT fallback (3.5)
[SOURCE: SAE J3016:2021, 3.19[2], modified — The phrase "(detecting, recognizing, and classifying objects and events and preparing to respond as needed)" located after "environment" was removed.]
3.21
operational design domain
ODD
specific conditions under which a given driving automation system is designed to function
Note 1 to entry: Conditions can be spatial, temporal, intrinsic or environmental.
Note 2 to entry: The term “designed” is taken from the definition in SAE J3016[2]. In this document it means “specified”.
Note 3 to entry: The conditions of automated driving system itself (e.g. the vehicle speed, computing capabilities, and perception sensing capabilities) are also in the scope of ODD.
Note 4 to entry: The concept was originally defined in SAE J3016[2].
3.22
performance insufficiency
limitation of the technical capability contributing to a hazardous behaviour or inability to prevent or detect and mitigate reasonably foreseeable indirect misuse (3.17) when activated by one or more triggering conditions (3.30)
Note 1 to entry: Performance insufficiencies can be either known or unknown at a given point in the system lifecycle.
Note 2 to entry: Performance insufficiencies are considered for E/E elements of the system and elements of other technologies considered relevant to the achievement of the SOTIF (3.25) (see Note 1 to entry of 3.8).
Note 3 to entry: The SOTIF activities include the identification of performance insufficiencies and the evaluation of their effects. The term “potential performance insufficiency” can be used when the ability to contribute to hazardous behaviour or inability to prevent or detect and mitigate a reasonably foreseeable misuse is not yet established.
EXAMPLE        Limitation of technical capabilities are limited calculation performance, limited perception range of a sensor, limited actuation, etc.
3.23
risk
combination of the probability of occurrence of harm and the severity of that harm
[SOURCE: ISO 26262-1:2018, 3.128]
3.24
reaction
response to an action (3.2) by any actor in a scene (3.27)
3.25
safety of the intended functionality
SOTIF
absence of unreasonable risk (3.31) due to hazards (3.11) resulting from functional insufficiencies (3.8) of the intended functionality (3.14) or its implementation
Note 1 to entry: A hazardous behaviour of the system that could lead to a hazard (see Figure 1) is initiated by a triggering condition (3.30) of a scenario (3.26). Reasonably foreseeable direct misuse (3.17) is considered as a potential triggering condition.
Note 2 to entry: When identifying the hazardous events (3.7), intended use and reasonably foreseeable indirect misuse are also considered in combination with hazardous behaviour resulting from insufficiencies of specification (3.12) or performance insufficiencies (3.22).
3.26
scenario
description of the temporal relationship between several scenes (3.27) in a sequence of scenes, with goals and values within a specified situation, influenced by actions (3.2) and events (3.7)
Note 1 to entry: Every scenario starts with an initial scene. Actions and events, as well as goals and values, can be specified to characterise this temporal relationship within a scenario. In contrast to a scene, a scenario spans a certain amount of time.
Note 2 to entry: This definition is adapted from Reference [3].
Note 3 to entry: The referenced “goals and values” are conditional parameters of the intended functionality (3.14). A goal could be “staying between the lane markings”. A value could be to “prioritize safety of pedestrians over avoiding monetary damage”.
3.27
scene
snapshot of the environment including the scenery, dynamic elements, and all actors’ and observers’ self-representations, and the relationships among those entities
Note 1 to entry: A scene can include environmental elements (state, time, weather, lighting and other surrounding conditions), road infrastructure or internal elements (road or interior geometry, topology, quality, traffic signs, barriers, etc.) and objects/actors (static, dynamic, movable, interactions, manoeuvres if applicable).
Note 2 to entry: An all-encompassing scene (i.e. an objective scene or ground truth) incorporating all entities (e.g. scenery, dynamic elements, actors) can only be modelled in simulation. In the real-world, scenes are perceived by sensors. The scene perceived by the ego vehicle (3.6) or human driver is an incomplete, inaccurate, uncertain and potentially erroneous projection of ground truth.
Note 3 to entry: The scene can also include aspects of the ego vehicle and the system implementing the intended functionality (3.14), like tyre pressure, user occupation and the presence of failures of parts of the system.
Note 4 to entry: This definition is adapted from Reference [3].
3.28
single-point functional insufficiency
functional insufficiency (3.8) of an element leading directly to hazardous behaviour or the inability to prevent or detect and mitigate a reasonably foreseeable misuse (3.17) when activated by one or more triggering conditions (3.30)
3.29
situational awareness
understanding of the situation
3.30
triggering condition
specific condition of a scenario (3.26) that serves as an initiator for a subsequent system reaction contributing to either a hazardous behaviour or an inability to prevent or detect and mitigate a reasonably foreseeable indirect misuse (3.17)
Note 1 to entry: The concept of “triggering” includes the possibility that there can be multiple conditions that can gradually happen, leading to hazardous behaviour or the inability to prevent or detect and mitigate a reasonably foreseeable misuse.
Note 2 to entry: A triggering condition of a scenario (3.26) activates a functional insufficiency (3.8), resulting in the subsequent system reaction. See Figures 1 to 3.
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. In this example, the triggering condition is the circumstance which leads to the misidentification of the road sign while operating on a highway, whereas AEB has the relevant performance insufficiency (3.22) (e.g. low accuracy of perception or misclassification by algorithm).
Note 3 to entry: The SOTIF (3.25) activities include the identification of triggering conditions and the evaluation of the response of the system. The term “potential triggering condition” can be used when the ability to initiate a corresponding reaction is not yet established.
Note 4 to entry: Reasonably foreseeable direct misuse, which could directly initiate a hazardous behaviour of the system, is considered as a potential triggering condition.
Note 5 to entry: Refer to Figures 1 to 3.
3.31
unreasonable risk
risk (3.23) judged to be unacceptable in a certain context according to valid societal moral concepts
[SOURCE: ISO 26262-1:2018, 3.176]
3.32
use case
description of a suite of related scenarios (3.26)
Note 1 to entry: A use case can include the following information about the system:
one or several scenarios;
the functional range (e.g. maximum allowed speed, maximum allowed deceleration);
the desired behaviour;
the system boundaries; and
assumptions on the environment and human operation.
Note 2 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.
Note 3 to entry: This definition is adapted from Reference [3].
3.33
validation target
value to argue that the acceptance criterion (3.1) is met
Note 1 to entry: The definition of a validation target depends on target markets and operational scenarios.
Note 2 to entry: In the context of the SOTIF (3.25), validation is the assurance, based on examination and tests, that the acceptance criteria (of the identified hazards) will be achieved with a sufficient level of confidence.
EXAMPLE        No hazardous behaviour of the functionality during a Y hour endurance run, or one hazardous behaviour with a certain severity during X times parking
Note 3 to entry: For the complete fulfilment of a given acceptance criterion, the fulfilment of more than one validation target can be necessary.
3.34
vehicle-level SOTIF strategy
VLSS
set of vehicle-level requirements for the intended functionality (3.14) used to support design, verification and validation activities to achieve the SOTIF (3.25)
Note 1 to entry: A VLSS can be defined for each SOTIF-related system.
30mm
20mm
15mm
15mm
10mm
17mm

Bibliography
[1]
COMMISSION RECOMMENDATION of 22 December 2006 on safe and efficient in-vehicle information and communication systems: update of the European Statement of Principles on human machine interface (2007/78/EC): https://data.europa.eu/eli/reco/2007/78/oj
[2]
Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles SAE Recommended Practice J3016_201806, https://www.sae.org/standards/content/j3016_201806
[3]
Ulbrich S., Menzel T., Reschka A., Schuldt F., & Mauer M. Defining and Substantiating the Terms Scene, Situation, and Scenario for Automated Driving", 2015 IEEE 18th International Conference on Intelligent Transportation Systems (ITSC), https://doi.org/10.1109/ITSC.2015.164
[4]
CENELEC EN 50126-2:2017, Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) - Part 2: Systems Approach to Safety
[5]
ISO 34502, Road vehicles - Engineering framework and process of scenario-based safety evaluation
[6]
Statistics and data about reported accidents and casualties on public roads in Great Britain (STATS19), UK Department for Transport, https://www.gov.uk/government/collections/road-accidents-and-safety-statistics
[7]
German In-Depth Accident Study (GIDAS) accident data collection project in Germany, https://www.gidas.org/start-en.html
[8]
NASS General Estimates System (GES) US Department of Transportation, https://www.nhtsa.gov/national-automotive-sampling-system/nass-general-estimates-system
[9]
CARE database (Community database on Accidents on the Roads in Europe), https://road-safety.transport.ec.europa.eu/statistics-and-analysis/methodology-and-research/care-database_en
[10]
IGLAD (Europe) http://www.iglad.net/
[11]
Code of Practice for the design and evaluation of ADAS, EU Project RESPONSE 3; https://www.acea.be/uploads/publications/20090831_Code_of_Practice_ADAS.pdf
[12]
DIN SAE SPEC 91381:2019, Terms and Definitions Related to Testing of Automated Vehicle Technologies
[13]
Kuhn D.S., Kacker R.N., & Lei Y. Combinatorial testing”, NIST report, June 25, 2012, https://www.nist.gov/publications/combinatorial-testing
[14]
Kelly T., & Rob Weaver R. “The Goal Structuring Notation – A Safety Argument Notation”, https://www-users.cs.york.ac.uk/tpk/dsn2004.pdf
[15]
Stellet J.E., Brade T., Poddey A., Jesenski S., & Branz W. Formalisation and algorithmic approach to the automated driving validation problem", 2019 IEEE Intelligent Vehicles Symposium (IV), https://doi.org/10.1109/IVS.2019.8813894
[16]
Shappell S.A., & Wiegmann D.A. The Human Factors Analysis and Classification-System – HFACS, February 2000 Final Report. This document is available to the public through the National Technical Information Service, Springfield, Virginia 22161
[17]
Hartjen L., Philipp R., Schuldt F., Howar F., & Friedrich B. Classification of Driving Maneuvers in Urban Traffic for Parametrization of Test Scenarios“ in: 9. Tagung Automatisiertes Fahren, Lehrstuhl für Fahrzeugtechnik mit TÜV SÜD Akademie: https://mediatum.ub.tum.de/1535131.
[18]
BSI PAS 1883:2020, AVSC Best Practice for Describing an Operational Design Domain
[19]
Leveson N. Engineering a Safer World – Systems Thinking Applied to Safety. MIT Press, Cambridge, Massachusetts, USA 2011
[20]
Leveson N., & Thomas J. STPA-Handbook. 2018. Available for download at psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf
[21]
Abdulkhaleq A., & et al A Systematic Approach Based on STPA for Developing a Dependable Architecture for Fully Automated Driving Vehicles, 4th European STAMP Workshop 2016, Procedia Engineering, 179, 41-51, 2017 https://www.sciencedirect.com/science/article/pii/S1877705817312109
[22]
Abdulkhaleq A.,, Wagner , S , Lammering , D , Boehmert , H , Blueher , & P Using STPA in Compliance with ISO 26262 for Developing a Safe Architecture for Fully Automated Vehicles. arXiv preprint arXiv:1703.03657, 2017.
[23]
Abdulkhaleq A., Wagner S., & Leveson N. A Comprehensive Safety Engineering approach for Software-Intensive Systems Based on STPA. Procedia Engineering, 128:211, 2015, https://www.researchgate.net/publication/265508075_Experiences_with_Applying_STPA_to_Software-Intensive_Systems_in_the_Automotive_Domain
[24]
Sabaliauskaite G., Shen Liew L., & Cui J. Integrating Autonomous Vehicle Safety and Security Analysis Using STPA Method and the Six-Step Model. International Journal on Advances in Security, 11(1&2):160169, 2018.
[25]
ISO 26262 (all parts), Road vehicles — Functional safety
[26]
Fabris S., Priddy J., & Harris F. “Method for Hazard Severity Assessment for the Case of Unintended Deceleration”, presented at 2012 VDA Auto SYS conference in Berlin.
[27]
Piao J., & McDonald M. Low speed car following behaviour from floating vehicle data’. IEEE IV2003 Intelligent Vehicles Symposium.
[28]
Allen R., Magdaleno R., Serafin C., Eckert S., , & Sieja F. Driver Car Following Behavior Under Test Track and Open Road Driving Condition," SAE Technical Paper 970170, 1997, https://doi.org/10.4271/970170
[29]
[30]
Fabris S., Priddy J., & Harris F. “Method for hazard severity assessment for the case of undemanded deceleration.”, Presented at VDA Automotive SYS Conference, Berlin, June 19/20, 2012, https://www.researchgate.net/publication/344452155_Method_for_hazard_severity_assessment_for_Method_for_hazard_severity_assessment_for_the_case_of_undemanded_deceleration_-_Simone_Fabris.
[31]
Littlewood B., & Wright D.Some Conservative Stopping Rules for the Operational Testing of Safety-Critical Software”, IEEE Trans. SW Engng., 23(11), 673-683, Nov. 1997
[32]
[33]
Hirsenkorn N., Kolsi H., Selmi M., Schaermann A., Hanke T., Rauch A., Rasshofer R., & Biebl E. Learning Sensor Models for Virtual Test and Development. 11. Workshop Fahrerassistenzsysteme und automatisiertes Fahren, UniDAS, Walting, 2017
[34]
de Gelder E., & Paardekooper J.P. “Assessment of Automated Driving Systems using real-life scenarios,” IEEE Intell. Veh. Symp. Proc., no. IV, pp. 589–594, 2017.
[35]
Functional Mockup Interface http://functional-mockup-interface.org/
[36]
[37]
[38]
[39]
Open Simulation Interface (OSI) https://github.com/OpenSimulationInterface
[40]
Navigation Data Standard https://www.nds-association.org/
[41]
[42]
Vaicenavicius J., Wiklund T., Grigaite A., Kalkauskas A., Vysniauskas I., & Keen S. D. Self-driving car safety quantification via component-level analysis’. SAE International Journal of Connected and Automated Vehicles, Volume 4, Issue 1, pp 35-45, 2021.
[43]
Shalev-Schwarz S., Shammah S., & Shashua A. On a Formal Model of Safe and Scalable Self-driving Cars https://arxiv.org/abs/1708.06374v6
[44]
[45]
FRAADE-BLANDAR L, BLUMENTHAL M. S., ANDERSON J. M. KALRA N. – RAND: Measuring Automated Vehicle Safety – https://www.rand.org/content/dam/rand/pubs/research_reports/RR2600/RR2662/RAND_RR2662.pdf
[46]
Kendall A., & Gal Y.What Uncertainties Do We Need in Bayesian Deep Learning for Computer Vision?”, NIPS 2017.
[47]
Phan B., Khan S., Salay R., & Czarnecki K.Bayesian Uncertainty Quantification with Synthetic Data”. WAISE 2019.
[48]
Koopman P., & Wagner M. Autonomous Vehicle Safety: An Interdisciplinary Challenge," IEEE Intelligent Transportation Systems Magazine, Special Issue on SSIV, 2017, in press Vol. 9 #1, Spring 2017, pp. 90-96
[49]
Molnar C. A Guide for Making Black Box Models Explainable, 2021, https://christophm.github.io/interpretable-ml-book/
[50]
Zhang Q., & Zhu S.-C. Visual Interpretability for Deep Learning: a Survey", 2018, https://arxiv.org/abs/1802.00614
[51]
Lapuschkin S., Wäldchen S., Binder A., Montavon G., Samek W., & Müller K. R. "Unmasking Clever Hans predictors and assessing what machines really learn", 2019, In: Nature Communications 1096 (2019), https://www.nature.com/articles/s41467-019-08987-4
[52]
U.S. Department of Transportation. (Jul.2017). Vehicle-to-vehicle communication technology.[Online]. Available:https://www.nhtsa.gov/sites/nhtsa.dot.gov/files/documents/v2v_fact_sheet_101414_v2a.pdf
[53]
Tsugawa S., Jeschke S., & Shladover S. E. “A Review of Truck Platooning Projects for Energy Savings”, IEEE Transactions on Intelligent Vehicles, vol. 1, no. 1, 2016
[54]
Wang J., Liu J., & Kato N.Networking and communications in autonomous driving: A survey”, IEEE Communications Surveys & Tutorials, vol.21. no.2, Q2, 2019
[55]
3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Enhancement of 3GPP support for V2X scenarios; Stage 1(Release 16) 3GPP TS 22.186 V16.2.0 (2019-06).
[56]
IATF 16949, Quality management system requirements for automotive production and relevant service parts organisations
[57]
ISO/IEC/IEEE 15288, Systems and software engineering — System life cycle processes
30mm
20mm
15mm
15mm
10mm
17mm
30mm
20mm
15mm
15mm
10mm
17mm
ICS 43.040.10
Price based on 181 pages
iso.org