SOTiF & Functional Safety : Introduction
ISO 21448 defines SOTIF as “the absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality (insufficiencies of specification of the intended functionality at the vehicle level or insufficiencies of specification or performance insufficiencies in the implementation of electric and/or electronic (E/E) elements in the system) or by reasonably foreseeable misuse.”
The standard also accounts for the operation or assistance of a vehicle that relies on remote drivers/users or communication schemes. These schemes may affect vehicle decision-making and lead to safety hazards. SOTIF only addresses unintended system behavior in the absence of faults. It addresses hazards that can arise from driving conditions that exceed the technology’s limitations or from human factors.
These hazards can be triggered by specific conditions of a scenario, defined as triggering conditions. These conditions can include reasonably foreseeable misuse of the intended functionality. Additionally, the interaction with other functions at the vehicle level can lead to hazards. For example, activating the parking brake while the automated driving function is active within highway driving conditions.
SOTIF vs ISO 26262 Functional Safety
SOTIF does not address faults and failures (covered by the ISO 26262 series), cybersecurity threats (covered under ISO 21434), hazards directly caused by the system technology (such as health damage due to the nature of the technology; laser light emitted from Lidar and possible damage to the human eye, which can be addressed through IEC 60825), or hazards related to electrical shock, fire, smoke, etc., unless these are caused by the intended functionality. It also does not cover deliberate actions that violate the system’s intended use (feature abuse).
Requirement-based approaches to ISO 26262 functional safety (FuSa) have long been approved and accepted. One of their main benefits is that they enable analysis of test coverage of the verification and validation (V&V) activities as planned in the validation strategy. In evaluating coverage of SOTIF-related performance requirements (concerned with perception and decisions), which is the case for ADAS and AD systems, the full control loop, including feedback from the environment of the item under test, is relevant. In other words, the test methodology needs to include input information from the environment state to produce a valid pass/fail result.
SOTiF process and clauses
The SOTIF process starts with the definition of the functional and system specification (Clause 5). The possible hazardous behaviors of the intended function are subjected to a Hazard Identification and Risk Evaluation (addressed in 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. The intended functionality can be considered free from unreasonable risk (the unreasonable risk classification needs to be supported by argumentation).
- 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. This analysis is tackled by Clause 7.
Clause 6 focuses only on the evaluation of hazardous events that could result from hazardous intended behavior, and on defining the verification and validation targets to be met.
Clause 7 addresses the analysis of the causes of potentially hazardous behavior and evaluates if the risk resulting from the identified potential functional insufficiencies and triggering conditions is reasonable.
The identified functional insufficiencies are mitigated in Clause 8 through functional improvements, which may include restrictions to the use cases to avoid or reduce the risk. These are then verified and validated in Clauses 9, 10, and 11.
The residual risk is evaluated (Clause 12) considering the results from verification and validation.
Finally, the process to evaluate and resolve possible emerging field operation SOTIF issues is defined in the operation phase (Clause 13).
The three pillars of SOTIF:
SOTIF is based on three main principles.
- SOTIF related hazardous event modelling,
- The four scenarios’ areas categories, and
- The sense – plan – act model.
SOTIF defines 4 areas based on two metrics; safety and knowledge of the scenarios leading to harm as illustrated in the figure hereafter.
- Area 1 (known-safe),
- Area 2 (known-unsafe)
- Area 3 (unknown-unsafe) are the most relevant since these can be considered as the trigger for SOTIF enhancement either system based, or human based.
- Area 4 (unknown-safe) is referenced only for completeness.
When considering those 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.
The goal of the SOTIF activities is to evaluate the SOTIF in these scenarios and to provide a proof that the risk is acceptable by increasing the size of known-safe scenarios proportion while reducing the proportion of unsafe scenarios whether these are known or unknown.
- The sensing capabilities that depict a sufficiently accurate image of the environment in which the automated system is evolving (sensing, perception, ego vehicle localization).
- The reasoning and processing leveraged to take the appropriate decisions (objects recognition, planning safe paths, etc.).
- The ability to derive accurate actions and execute them in a timely manner on the actuation side while ensuring stability.
