What is SOTIF?

Safety of the Intended Functionality (SOTIF) is a safety approach developed for advanced driver assistance systems (ADAS) and automated driving systems (ADS) applications, addressing the safety of sensors and algorithms in the absence of a system failure. 

With the rise of advanced driver assist systems and automated driving systems of all levels, ISO 21448 was developed in 2022 to provide guidance to automotive manufacturers and suppliers on how to ensure the "absence of unreasonable risk” due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons. Together, these safety standards provide a holistic approach for autonomous driving systems and ADAS in all automotive platforms. Cybersecurity issues are addressed in ISO 21434, as the standards organizations agreed it was best to provide a single framework for managing cybersecurity risks across the entire vehicle life cycle.

Although the idea of SOTIF as laid out in ISO 21448 was developed for the automotive domain, it can be carried over to any autonomous system. Companies are finding it useful in aerospace, heavy machinery, construction, and manufacturing automation applications where it is often coupled with existing functional safety strategies. SOTIF is an evolving methodology, and standards groups worldwide are actively refining it to address emerging technologies and applications. 

The guidance found in ISO 21448 was developed to complement the guidance around functional safety in ISO 26262. Where functional safety (FuSa) deals with system failures, SOTIF addresses a system's safety in the absence of failure.

The following table addresses some of the differences between the two automotive safety standards:

In short, FuSa helps engineering teams avoid safety problems associated with software and hardware failures in any electrical/electronic (E/E) system, while SOTIF addresses automotive safety issues that arise when autonomous and driver assistance systems receive inaccurate data, interpret it incorrectly, or are misused or misunderstood by the human operator. 

After developing standards for road vehicles around equipment failures, the automotive engineering community recognized the need for safety requirements to address other potential hazards that arise when autonomous systems are not compromised and do not fail. ADAS and autonomous driving systems use sensors to obtain situational awareness, machine learning to process sensor data, and complex algorithms to inform, assist, or take over from the driver.

To help engineers develop a process for identifying and addressing risks, the standard defines three types of hazardous events:

Functional Insufficiencies

A functional insufficiency is the inability of a covered system to accurately interpret a real-world occurrence within its operational design domain (ODD), leading to a hazardous event. Functional insufficiencies in a system include gaps in the system's specifications. An example would be a collision with an overtaking motorcycle because the automated vehicle was not aware that the motorcycle would approach so fast and be identified so late.

Performance Limitations

Performance limitations occur when a system behaves unsafely due to the deficiencies of a sensor or algorithm. If one or more inherent limitations are caused by a sensor, algorithm, or component, that could result in hazardous behavior. A representative example of this is an emergency braking system not engaging because its camera's sensor cannot detect an object due to heavy rain or fog.

Foreseeable Misuse

Foreseeable misuse events are situations where a user interacts in an unintended way. For example, a user suddenly turns the steering wheel while in an automated driving mode or driving while distracted and not seeing or hearing a warning message about a potential collision. 

Once a team identifies a safety concern, they develop scenarios, or stories, capturing situations the vehicle might encounter on the road. The ISO 21448 standard defines four scenario areas that represent the safety and knowledge levels of the situation. The safety level can be safe or unsafe, and the knowledge about the situation can be known or unknown.

SOTIF focuses on reducing the number of unknown and unsafe situations, with a priority on discovering potentially hazardous scenarios, especially converting them from unknown to known. The next step is to turn hazardous scenarios into non-hazardous ones. This is done by improving the system’s performance or by avoiding exposure to such scenarios through ODD restriction. Arranging these labels into a quadrant chart based on the categories noted below helps safety teams determine which scenarios are hazardous and also how to set priorities. 

As the number of use cases where SOTIF is applicable grows, companies are working hard to integrate the ever-evolving standard into the safety regime across their products' entire life cycle. Although the industry's experience with SOTIF is still new, some best practices have emerged to accelerate integration, increase the efficiency of SOTIF implementations, and ultimately improve the safety of vehicles with driver assistance systems, self-driving features, and other machines that utilize sensors and AI for automation and autonomy. These best practices are noted below.

• Bring experts to the table: This is a new domain, and experts from within or outside an organization can speed implementation, improve accuracy, and increase impact.
• Utilize field data: ADAS and autonomous driving-related sensors, along with the algorithms that use sensor data, generate a significant amount of information essential for discovering functional omissions, performance shortcomings, and misuse.
• Integrate SOTIF processes with FuSa and cybersecurity methods with a model-based systems engineering (MBSE) approach: Although FuSa, SOTIF, and cybersecurity address different aspects and causes of hazards, they often address the same hazards. Also, similar data and safety risk assessment tools, like fault trees, cause trees, and attack trees, apply to all three areas. Try to reuse information and steps where possible. When sharing is not feasible, conduct SOTIF studies in parallel with other safety tasks. Tight integration with model-based approaches speeds up the safety analysis, ensures that the actual system setup is considered for analysis, and that results from the FuSa/SOTIF/cybersecurity analysis flow back into the development, assuring full traceability.
• Combine analytical techniques with validation: Safety teams should use analytical processes like hazard analysis, a hazard and operability study (HAZOP), cause-tree analysis, and insufficiency and triggering condition analysis to find potential issues. They should then use that information to inform validation approaches, including road tests, sensor bench tests, hardware-in-the-loop, sensor simulation, and scenario simulation.
• Adapt verification and validation methods for SOTIF: SOTIF often requires novel verification approaches due to the new functionality or due to the huge number of potential scenarios and triggering conditions. Teams should evaluate the entire verification and validation (V&V) chain and modify each step as needed to incorporate the required information for SOTIF.
• Implement virtual system training and testing: The amount of test scenario variations to cover the ODD is huge, and there is an ever-increasing amount of field experience that needs to complement the existing set of test cases. It is considered impossible to verify this by test rides with real cars on real roads. Instead, there is a tremendous shift toward simulation, both closed-loop (to test the entire vehicle behavior and how it reacts to other traffic participants in realistic scenarios) and open-loop (to test with physically accurate sensor models what the car can perceive, or how it reacts to specific stimuli). Virtual testing by simulation also allows the evaluation and optimization of algorithms and sensor setups early in the design cycle, and the iterative improvement of the system in agile cycles.
• Apply SOTIF as an iterative process: The standard refers to risks remaining after an interaction as residual risks. These remaining hazards should be addressed again until issues that do not pose an unreasonable risk remain.
• Make SOTIF an integral part of your safety culture: SOTIF offers a different perspective on how hazards occur and how to prevent them. Everyone involved in the life cycle of a vehicle should have a fundamental understanding of the standard. 

SOTIF and its associated standard, ISO 21448, were developed to complement existing industry and company standards, as well as existing standards for functional safety and cybersecurity. Although quality and safety teams work hard to anticipate events, they cannot identify all of the potential issues covered under SOTIF before a vehicle enters service. Simulation tools can aid the evaluation of systems covered under SOTIF and provide actionable data on sensors and algorithms throughout the process.

Companies that want to maximize the efficiency, speed, and accuracy of their SOTIF processes should consider the following types of simulation products and analytical tools.

Safety Process Planning and Safety Case Management

The first place to deploy software is with a safety management tool, such as Ansys Digital Safety Manager, for guided safety planning, safety case management, safety plan execution and review, simulation, SOTIF analysis, and KPI monitoring and reporting. 

Model-Based System Safety Analysis Tools

Once a safety plan is developed, proper model-based system engineering (MBSE) platforms allow engineers to conduct safety analyses on their system's design. Many engineers turn to a tool like Ansys medini analyze system-oriented safety analysis software, which supports multiple ISO standards with end-to-end traceability and integrates well with leading requirements management and system design tools like Ansys System Architecture Modeler (SAM). Ansys medini analyze is a great example of a system-level platform because it enables teams to create and import system architecture models and then conduct different types of safety analysis, including:

• Hazard analysis
• HAZOP
• Fault tree / cause tree / attack tree analysis
• Reliability block diagrams
• Failure mode and effects analysis (FMEA), failure mode, effects, and criticality analysis (FMECA), failure mode, effects, and diagnostic analysis (FMEDA), and failure mode, effects, and failure mode and effects study (FMES) models.
• Weakness and insufficiency analysis
• Triggering condition analysis

Once completed, the output from the analysis can be exported to all major requirements management tools.

Scenario and Sensor Simulation Platforms

One of the significant challenges in implementing SOTIF is gathering enough data to discover hazards. Digital mission simulation platforms designed for the autonomous vehicle space are critical if teams want to identify hazards before they occur in the field. A tool like Ansys AVxcelerate Sensors autonomous vehicle sensor simulation software can be used to model a sensor's capabilities, allowing for the testing and validation of the sensor's perception without relying on recorded data from actual driving. ADAS and autonomous driving systems testing can then be virtualized using a comprehensive and MBSE-driven simulation platform like Ansys AVxcelerate Autonomy software to perform virtual testing in the form of massive scenario simulation with many parameter variants given for each basic scenario. They can use that data to quantify the residual risk for SOTIF. 

With the increased use of E/E in cars, the ISO 26262 standard for functional safety (i.e. hazards caused by failures and malfunctioning behavior in such systems) was released in 2011. When ADAS systems and autonomous vehicles (AVs) of all levels emerged, this standard alone was no longer sufficient to address all facets of their safety, so it was complemented with the ISO 21448 standard in 2022, to provide guidance to automotive manufacturers and suppliers on how to ensure the "absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons," according to ISO. This latter standard provides guidance to original equipment manufacturers (OEMs) and their suppliers in the automotive industry for the design, verification, validation, and operation of automotive E/E systems that utilize sensors to provide situational awareness information, which is then used by algorithms to assist the driver or control the vehicle. 

Related Resources