ISO PAS 21448:2019 download.Road vehicles – Safety of the intended functionality.
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, Ic. 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 viobte 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 indudes 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:
EXAM PIE Requl rement on sensor performance.
— Measures In the verification phase;
EXAMPLE Technical Reviews, test cases with a high coverage of relevant scenarios, Injection of potential tnggerlng 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.
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.
I Scope
The absence of unreasonable risk due to hazards resulting from functonal insulliciencies of the Intended functrnnality 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).
ISO PAS 21448 is Intended to be applied to Intended tunctionality 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 I and 2 on the OIA/SAE standard 13016 automation scales. This edition of the document can be considered for higher levels of automation. however additional measures might be necessary. ISO PAS 21448 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 tRme of pubhcation (e.g. flynamic Stability Control (DSC) systems. airbag, etc.). Some measures described in tins 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 potenually hazardous system behaviour when ldentIfing 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 ahuse 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 vehides — Functional Safety Patti: 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:
action
atomic behaviour that is executed by any actor in a scene
Note Ito entry: The temporal sequence of actions/events and scenes specify a scenario. EXAMPLF. Ego vehicle activates the hazard warning lights,
erroneous pattern
input that can trigger unintended behaviour
event
occurrence at a certain place and at a particular point In Lime
Note I to entry: The temporal sequence of actions/events and scenes specify a scenario,
Note 2 to entry: In particular this document addresses triggering events (115) 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 tar details.
EXAMPLE I Tree tailing on a street SO m ahead cia 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 Ito entry: See ClauseS for additional information about the specification of Intended behaviour.
Note 2 to entry The specified behaviour is the behaviour that the developer of thr item consIders 10 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 I to entry: Misuse can result from overconfidence in the perfonnance of the system.
Note 2 to entry: Misuse includes human behaviour that Is not specified but does not include deliberate system alterations.
misuse scenario
scenario in which misuse occurs
3.9
performance limitation
insulficiencies in the implementation of the intended functionality
EXAMPLE Incomplete perception o the scene, insullkiency ol the decision algorithm, insufficient performance of actuation.
3.10
Safety Of The Intended Functionality
SOTIF
absence of unreasonable risk due to hazards resulting from functional Insufficlencles of the Intended functionality or from reasonably foreseeable misuse by persons
Note 1 to entiy Nominal perlorniance includes intended functionality and the implementation of intended functionality that can be affected by performance llmittions or by foreablc misuse by persons,
3.11
scenario
description of the temporal development between several scenes in a sequence of scenes
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 enLry See Figure 4.
Note 2 to entry: Only a sceiic 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 (Le. a sublective scene).
Note 3 to entry Refer to Rrlrrrnce Lii.
3.16
use case
specification of a generalized held 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 Ito entry: The use case description typically does not include a detailed list otall 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 Ito entry: The unintended behsvmur might be discovered during validation.
3.18
validation
set of activities gaining contldence that an item is able to accomplish its expected functionalities and missions
Notc I to entry: Verification activities address mainly Area 2 of hgures I, 8 and 9 including the verification o known use cases, whereas Validation activities address mainly Area 3 of t,gures 7, 8 and 9, including the validation nISOTIF in unknown use cases.
4 Overview of this document’s activities in the development process
The oblective subclauses of this document (&i. (i1.. 2.1. 11,1,, 9.1, 1ILL 11.1 and ILL) 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 .ill development parties when applicable for a distributed product developmenL 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 sate 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).
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 Iclause 7)
— Improve the system design as necessary through functional modifications or use case restriction to reduce SOTIF risk (Oause 8): and
— Verily 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 aISOTIF related potentially hazardous behaviour and the system failures covered by the ISO 26262 series can be identicaL
Annex A presents an example of apphcatlon of the SOTIF activities.
ISO PAS 21448 provides a non-exhaustive collection of methods and measures, from which the development team can select he appropriate combination. Other equivalent methods can also be applied.
S 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 Ls 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 relate&
— 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;201U tern 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 indudes 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 SOT1F 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, Tier!, 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 rntended 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 bases! 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 I 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 I’erformance limitations can be addressed by redundancy, diversity, functional restrictions or other measures.
EXAMPLE I A highway lane boundary detection algorithm, for functions such as lame 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 functionaUty 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 ii this imphes leaving the perceived lane. etc.
EXAMPLE 2 An object detection algorithm detects a person on a skateboard as a pedestrian hut rejects the object as due to it speed being iniplausihir. A collision with the skateboarder Is mitigated by a collision mitigation lraking system which uses sensing and processing that is independent from that of the nblect detection algorithm
EXAMPLF. 3 An optical illusion drawing of a child running into th 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 arc alternative countenneasurrs for such cases, as well as other common detection cases such as ghosts that result [mm classification errors.
Figure 11 — Example ol optical illusion drawing that could tool 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 dosed.
6 IdentificatIon and vaIuaton of hazards caused by the Intended functionality
6.1 Objectives
The potential hazards related to the SOTIF shall be systematically identified and evaluated such that:
— The possible hazardous events. caused by functionality that results in potentially hazardous behaviour and their potential consequences, are identified and evaluated.
— The acceptance criteria (e.g. a validation target) to evaluate the design in the validation phase are specified.
NOTE Such acceptance criteria could be the minimum length of the required endurance run combined
with a maximum number of observed failures for each type (e.g. false positives, false negatives),
‘V
— The possible hazardous events caused by reasonably foreseeable misuse ofthe function, by the user,
are identified and evaluated.
6.2 Hazard Identification
The hazards, caused by the unintended behaviour of the function, are determined systematically. This systematic Identification is primarily based on knowledge about the function and Its possible deviations. This can be achieved by applying the methods proposed in ISO 26262-3:20tH while considering performance hmitations of the intended functionality. An Illustration of the common elements of the hazard analyse process required by both the ISO 26262 series and by this sub.dause can be found In Fiiure 12. Fioure 13 uses an automated emergency braking (AEB) system as an example to show how the terms from Figure 12 are used.
IXAMPLE I For an AEH system, an incorrect detection can cause unintended lull braking. However, the system can be designed to limit the allowable braking commanded by AEB. An Incorrect detection of a lead vehicle can therefore only trigger braking up to this intended limit. Nevertheless, unwanted braking (due to incorrect detection) limited to the specilled authority can have salety consequences. Such unwanted braking events are considered in the SOTIF related risk evaluation,
tXAMPLE Z A system specilied to Implement an adaptive cruise control (ACC) function might exhibit undesirable behaviour if several vehicles are using ACC to drive one after another in a line. In such cases, high control loop tatencies can lead to an “accordion effect” bullding.up, until th system Is unable to brake hard enough and the driver has to intervene, Although this operational situation might be considered controllable by the driver, the need to avoid such build-up effects might still be analysed as part of the SO11F.
NOTE Unlike in ISO 26262-3:2018. when analysing a SOTIF related hazard, no ASIL is determined for a hazardous event However, the S. E and C parameters can be used to adjust the validation effort
6.3 Hazard analysis
The harm and controllability of hazardous events can be estimated using the method described In ISO 26262.3:2018, Clause 6 but their evaluation for an individual hazardous event can be specific to a given SOTIF related hazard.
F.XAMPLE I The seventy of a rear collision, caused by emergency braking, can be reduced by limiting the brake intervention magnitude. The nugnirude limit can he seen as a safety mechanism to Increase controllability, or as a modificatIon to the intended behaviour. When analysing the hazard, the limit Is considered part of the Intended behaviour; whereas functional failures relating to the amplementahon of the limit would be the subject of other safety standards, such as the ISO 26262 serIes.
The severity and controllability of the potentially hazardous behaviour, in a given scenario, are considered to determine whether a credible harm can result. For hazardous event classification a delayed or no reaction to control the hazard, from the Involved persons, can be considered.
EXAMPLE 2 An environmental condition that Is not supported by an ADAS that requires the driver to resume control
Delays due to the reaction time of the driver can impact the controllability evaluation and can be a topic of the SOTIF related analysis.
EXAMPLE 3 IabIt2 gives an example of the evaluation of a potential consequence for an AEK system and a SOTIF related hazardous event.
6.4 Risk evaluation of the intended function
The risk evaluation considers the performance limitations or the intended functionality to judge whether controllabihty or severity is acceptable; that Is controllability Is controllable In general” or severity is “no resulting harm”. The severity and controllability evaluation can take into account the expected system limitations and the measures that have been implemented to mitigate their effects (according to the functional and system specill cation described in Clause 5).
6.5 Specification of a validation target
Validation targets take into account any applicable governmental and industry regulations as well as the current level of functional performance needed to ensure safety. the specified validation targets will depend on the methods chosen in the validation strategy.
EXAMPLE I l)eductive analysis requires a list of all known and relevant triggering events to be considered. For such analysis, a relevant validation target would ensure the coverage ci all events on this list. In contrast, an inductive analysis of SOTIF related hazards would involve a search for previously unknown triggering events that are relevant to the application. In this case, validation targets would he defined with a statistical confidence that the empirical data supports the hypothesis that tilggering events do not impose unreasonable risk.
Approaches that can be considered when specilying these targets include:
— the available traffic data for the target market (e-g accident statistIcs, traffic analyses) (see D.3); and
— pre’cxisting targets from similar functions operating in the field.
EXAMPLE 2 The pass/fail criteria fur simulation testing, in a given situation, could be defined as: The allowable false positIve and false negative rates for a Function executing when not required, and, the allowable false positive and false negative rates for a function not executing when required.
If only a subset of scenarios is relevant to a specific hazard, then the exposure to the relevant scenarios (similar to the exposure in ISO 26262-3:2018, Clause 6) can be considered when determining the target value for this hazard and the associated validation duration.
When evaluating the likelihood that. in a given scenario, a triggering event will violate the quantitative target, the exposure, controllability and severity of the resulting behaviour are factors that can be taken into account. This can result in a reduction in the effort required to demonstrate the occurrence rate of the triggering event in Area 3, see Annex B of this document.
EXAMPLE 3 ConsIder the example from ,3 where unintended braking only results in a rear crash ii a trailing vehicle is present. The exposure rate to a trailing vehicle can be considered when specilying a validation target.
If applicable traffic statistics or field data are unavailable, then an appropriate target can be chosen provided a valid rationale is given.
NOTE 1 A rationale could be based on a risk tolerability principle, such as the French GAMAH or GAME: both have the meaning “globally at least as good”. Follawing this principle, the residual risk (with respect to safety) of any new system is not significantly higher than those of existing systems having comparable functionality and hazards. The application of such a risk tolerability principle to the overall residual risk, that considers all hazards of the new system, allows relevant risk trade-oils to be made. For example, a system ran be released even though the residual risk for a given hazard has increased, provided that this is compensated by counter balancing reductions in one or more other residual risks.
NOTE 2 A rationale could also be based on the ALARP (as low as reasonably practicable) principle. The ALARP Risk Management framework can provide a useful risk reducflon principle. particularly with regard to the development and Introduction of novel lechnologies where “good practice” does not currently exist. Ky acknowledging that a state of zero/no risk is not possible, the ALARP principle alms to reduce risk to a Level considered reasonab)y practicable” by weighing the risk against the sacrifice needed to further reduce it.
7 Identification and Evaluation of triggering events
7.1 Objectives
The triggering events:
— that can trigger potentially hazardous behaviour shall be identified:
— shall be evaluated for their acceptability with respect to the SOTIF.
NOTE Triggering event identification can be supported by a detailed environmental model
7.2 Analysis of triggering events
A systematic method can be established to perform the analysis of triggering events. This method can consider knowledge gained from similar projects and field experience. The analysis alms to identify the system weaknesses (including those of its sensors, algorithms, actuators) and the related scenarios that could lead to an identifIed hazard.
This analysis can be conducted in parallel, starting from both:
— the known limitations of the system components to determine scenarios that could result in hazardous behaviour due to these limitations; and from
— the identified environment conditions and foreseeable misuses to determine the system limitations that could trigger potentially hazardous behaviour of the system. Further detail is given in Annex E and Annex F.
These analyses will increase the understanding of the limitations of the systems and will improve the identification of unknown triggering events,
NOTE The analysis can be supported by inductive and/or deductive methods.
7.2.1 Triggering events related to algorithms
An analysis of triggering events related to algorithms is used to determine:
— SOTIF risk mitigation methods and measures according to U3.
— decision algorithm verification according to It; and
— validation of functionality according to Clause. 11.
The analysis considers categories such as:
— environment and location;
— road infrastructure:
— urban infrastructure;
— highway infrastructure;
— driver behaviour (Including reasonably foreseeable driver misuse);
— expected behaviour of other drivers/road users:
— driving scenario (e.g a construction site, an accident, a traffic jam with emergency corridor, driving the wrong.way); and
— algorithm limitation. (e.g. capability to handle possible scenarios, or non.deterministic behaviour.). NOTE The denttfied functional limitations are Included In the list mentioned In Clause S.
7.2.2 Triggetlng events related to sensors and actuators
An analysis of triggering events related to sensor disturbances and actuator limitations is used to determine:
— SOTIF risk improvement methods and measures according to &i
— sensor verification strategy according to W2
— actuator verification strategy according to )&4 and
— validation of functionality according to (Iaiisfl.
The analysis considers categories that can cause triggering events such as:
— weather conditions;
— mechanical disturbance (Including Installation, design location, transmission of signals):
— EMI interference:
— Interference from other vehicles or other sources (e.g. radar or lidar):
— acoustic disturbance;
— glare
— poor-quality reflection;
— accuracy;
— range:
— response time:
— durability;and
— authority capability (applicable to actuators).
EXAMPLE 1 Rain and snow can affect radar performance,
EXAMPLE 2 RIsing sun In the front of the velicle can iftct the performance of a video camera.
EXAMPLE 3 A heavy woollen coal can stied the performance of ultrasonic sensors.
EXAMPLE 4 An Improper alignment can affect many sensor types.
NOTE I The consklesed sensors ca.i include Inertial sensors, cameras, radar, etc.
NOTE 2 A potential scenario can be a scenario resulting from a theoretical combination of already observed scenarios.
NOTE 3 For specifIc analysis categories see Annexes I). Land k For each category, a list of detailed disturbances is determined based on knowledge and experience (including knowledge gained on similar projects and in field experience)
In addition, a systematic analysis of each environmental Input. In the range olpossible values (including potential and observed scenarios), can be conducted.
7.3 Acceptability of the triggering events
The identified tnggerlng events are evaluated considering the acceptance criteria that are specified during the SOTIF risk identification and evaluation (as described in Claiiseh).
The response of the system to these triggering events can be considered as acceptable with respect to the SOTIF without need of further functional Improvement (as described In Clause 8)11:
— The probability of the system causing a hazardous event Is lower than the validation target value specified in k and
— There Is no systematically unacceptable scenario in relation to a specific vehicle that has the potential to lead to a hazardous event.
NOTE Even if a fleet has a very low probability of a triggering event, it can be unacceptable if for a specific systenlatw vehicle behaviour, the probability is high.
EXAMPLE A particular structure that always causes the AEB system to brake excessively
8 Functional modifications to reduce SOTIF related risks
8.1 Objectives
The development activities of the functional modifications to reduce the SOTIF related risks shall achieve the following objectives:
— identification and allocation of measures to avoid, reduce, or mitigate the SOTIF related risks;
— estimation of the effect of the SOTIF related measures on the intended function; and improvement of the information required by ClauseS (Functional and system specification).
8.2 General
This sub-clause deals with identification cii measures to avoid, reduce, or mitigate the SOTIF related risks. The function and system descriptions are developed through several iterations and each time the Functional and System specification (required by Clause 5) is updated with information about the identified measures.
A functional modification to reduce SOTIF related risks may be needed when the Identified triggering events:
a) have the possibility to trigger a potentially hazardous behaviour leading to a hazardous event with credible harm (according to Clause f) and
b) cannot be evaluated as acceptable with respect to the safety ofthe intended functionality (according to Clausei).
To support achieving the objectives of this clause, the followmg information can be considered:
a) information on the system architectural design;
b) the functionality which is defined and described in accordance with Clause 5
c) the evaluation of the potential outcome of possible hazardous events in accordance with Clause 6:
d) the possible scenarios that can trigger an unintended system behaviour leading to a hazardous event in accordance with Clause 7:
e) knowledge derived from previous verification results, where the system and components did not behave as expected for specific use cases durtng verification In accordance with Clause 10 (if any); and
f) knowledge derived from previous validation results including real-life use cases, where the function did not behave as expected and the system and component limitations cause an unreasonable level of risk in accordance with Clause 11 (it any).
8.3 Measures to Improve the SOTIF
Measures to Improve the SOTIF address the identified system limitations (in accordance with 22) that lead to a safety violation, Depending on the evaluated SOTIF related rIsks the measures to Improve the SOTIF can be aimed at avoidance, reduction, or mitigation.
The Improvement measures can Include:
a) System improvement to avoid or reduce the SOTIF related risks, including but not limited to:
1) Increased sensor performance and/or accuracy by:
— sensor algorithm improvement;
— adequate sensor technology;
— sensor location modification;
— sensor disturbance detection that triggers an appropriate warning and degradation strategy;
— recognition of exiting the operational design domainj3j. i.e. recognition of a known unsupported environmental condition that requires a transItion to an appropriate sensor usage strategy;
— diverse sensor technology;
2) Increased actuator performance and/or accuracy by;
– adequate actuator technology (e.g. Increase accuracy. extend range of output, shorter response times, improve durability, arbitrate authority capability);
3) increased performance of the recognition and decision algorithms by;
— algorithmic improvements;
— recognition of exiting the operational design domainlJ. I.e. recognition of a known unsupported environmental condition that requires a transition toan appropriate warning and degradation strategy;
— design strategy that incorporates the triggering of an appropriate warning and degradation strategy bra known unsupported SOTIF use case;
EXAMPLE Lane keeping,
— strategy for mitigation and resolution of Functional interference/conflict (.woidance oF unintended behaviour due to inter-system dead lock/live lock);
EXAMPLI Conflict bttwrrn lane keeping and automatic lane change.
4) Improved testability by:
-— allowing verification olsystem and component behaviour.
8.4 UpdatIng the system specification
The following information is identified in order to update the functional and system specification:
— measures of system Improvements to avoid, reduce, or mitigate the SOTIF related risks;
— measures of functional restrictions to reduce or mitigate critical operational situation effects;
— measures of improvement of the Human-Machine Interface and warning and degradation strategy; and
— measures resulting from the handling of reasonably foreseeable misuses.
9 Definition of the verification and validation strategy
9.1 Objectives
A venilcation and validation strategy shall be defined such that:
— It supports the rationale for the SOTIF;
— The necessary evidence (e.g. analysis results, test reports, dedicated Investigations) Is generated: and
— The procedures to generate the evidence are developed.
The system verification and validation activities with regard to the risk of potentially hazardous behaviour (excluding the faults addressed by the ISO 2626Z series) include integration testing activities to address the following scope:
— The ability of sensors and the sensor processing algorithms to model the environment;
— The ability of the decision algorithms to handle both known and unknown situations and to make the appropriate decisions according to the environment model and the system architecture;
— The robustness of the system or function;
— The ability of the HMI to prevent reasonably foreseeable misuse; and
— The manageability of the handover scenario by the driver.
To support the achievement of the objectives of this sub-clause, the following information can be considered:
— Functional concept, including sensors, actuators and algorithm specifications;
— System design specification;
— Verification and validation targets;
— Vehicle architecture;
— Analysisoftriggeringevents results as described in Z2
— System design;
— System Integration & testing plan;
— Lessons learned,
9.2 Planning and specification of integration and testing
A verification and validation strategy is defined to provide evidence that the objectives are achieved and to state how the targets are to be met. The verification and validation strategy can cover both E/E elements and elements of other technologies considered relevant to the achievement of the SOTIF.
Verification and validation activities consider calibration and configuration data to achieve the SOTIF.
NOTE I Variability of the triggering event parameters is considered by evaluating the verification and validation strategy. See Annex D for further practices for the verification and validation of automotive perception systems.
NOTE 2 As functional improvements are made, the system is analysed to determine it, additional functions are retested during verification and validation, These dependent functions are verified with regression tests. This ensures that known or new triggering events do not cause potentially hazardous behaviour in unchanged functions. Triggering events found during verification and validation activities, where potentially hazardous behaviour is present, are retested on every release. With a proper rationale, the testing scope can be reduced. To ensure that correct functional behaviour is maintained, complete testing is documented for any release intended for production. This includes documentation of parts that have not been affected and retesting of parts that have been affected by changes.
Methods to specify the verification and validation activities (e.g. integration test cases, analysis) can be derived using an appropriate combination of methods, and by considering the integration level, as illustrated by Table 4.
11 Validation of the SOTIF (Area 3)
11.1 Objectives
The functions of the system and the components (sensors, decision-algorithms and actuators) shall be validated to show that they do not cause an unreasonable level of risk in real-life use cases (see Area 3 of Figure 9). This requires evidence that the validation targets are met.
To support the achievement of this objective the following information can be considered:
— Validation strategy, as defined in Clause 9:
— Verification results in defined use cases, as defined in Clause 10:
— Functional concept, including sensors, actuators and decision-algorithm specification;
— System design specification;
— Validation targets, as defined in Clause 6:
— Vehicle design (e.g. sensor mounting position); and
— Analysis of triggering events results as described in Z2.
11.2 Evaluation of residual risk
Methods to evaluate the residual risk arising from real-life situations, that could trigger a hazardous behaviour of the system when integrated in the vehicle, can be applied as illustrated by Table 9.