Safety of the intended functionality (SOTIF) is the implementation of safety measures to prevent or mitigate hazardous events at the vehicle level caused by functional insufficiencies, foreseeable feature misuses by a driver and unexpected conditions within the operational design domain (ODD).
SOTIF differs from functional safety (FuSa), which focuses on mitigating risks from systematic software faults and systematic and random hardware faults in electrical/electronic systems.
To understand the difference between FuSa and SOTIF, consider the hazardous event of unintended deceleration, which can have numerous causes. If a malfunctioning behavior in the underlying hardware or software of the vehicle’s propulsion system causes the unintended deceleration, then FuSa processes are responsible for mitigating the risks involved. However, if the unintended deceleration is caused by a weakness of a sensor, that falls under the purview of SOTIF.
Given their roles in the safe operation of automated features, incorporating SOTIF and FuSa helps make a vehicle more appealing to consumers.
The ISO 21448 standard provides automotive manufacturers and their suppliers with best practices to help ensure that SOTIF is achieved at every stage of a system’s lifecycle.
Hazard analysis and risk assessment
Many of the practices used for achieving SOTIF come from FuSa, such as the hazard analysis and risk assessment (HARA) done at the beginning of a system’s development. During HARA activity, engineers are challenged to think about how the combination of hazards and operational scenarios may collectively lead to hazardous events at the vehicle level.
After the potential hazardous events have been identified, they are evaluated based on three factors:
- The severity (S) factor takes into account the potential harm to all endangered people within the scenario, including the driver and passengers in the vehicles involved, cyclists, pedestrians, and first responders. An abbreviated injury scale is often used to define the severity, ranging from “no injuries” to “extremely critical or fatal injuries.”
- The exposure (E) factor takes into account how often the scenario for a given hazardous event could occur, which is rated from “incredible” (rare) to “high probability.”
- The controllability (C) factor takes into account how easy it would be for a driver and/or the other people within the scenario to avoid the hazardous event and is rated from “controllable in general” to “difficult to control.”
Based on the S, E and C ratings for a given hazardous event, a criticality level is calculated using the Automotive Safety Integrity Level (ASIL) risk classification scheme, which ranges from A to D; ASIL-A is the least stringent, and ASIL-D is the most stringent. A corresponding safety goal is created to address the hazardous event and may include metrics — known as SOTIF KPIs — that must be met to achieve SOTIF.
Deriving safety requirements
The safety goals and SOTIF KPIs drive the creation of the SOTIF concept, which comprises requirements that define the safety measures needed to prevent or mitigate hazardous events.
Like FuSa, SOTIF has an iterative workflow, and utilizes the V-model throughout development. As a result, revisions are made to the concept, requirements and/or design where appropriate, and tests are run repeatedly until all of the safety goals, including the SOTIF KPIs, are achieved.
Many of the analysis techniques applied in FuSa can be used to arrive at these safety measures. However, because of SOTIF’s focus on specification insufficiencies and driver misuse, additional techniques are also required, including searching for and identifying specific conditions that could trigger potentially hazardous events.
For example, forward-facing camera systems must be able to distinguish lane markings from other marks on the road, such as tire skids. The appearance of skid marks would be considered a triggering condition, and the limit of the system’s ability to recognize lane markings would be considered a functional insufficiency.
Vehicles must distinguish lane markings from other marks on the road.
Testing on the road and with simulations
Real-world tests and simulations can be performed to characterize components that the system will be using. Even if a system as a whole has not yet been fully developed, the sensors and actuators within it might be ready, and those components can be run through different facets of the ODD to try to expose triggering conditions that have not yet been documented.
Simulations and real-world tests can also be used to understand drivers’ interactions with vehicles in different scenarios, leading to the definition of additional safety measures. For systems that fall into the range of Levels 0 to 3 on the Society of Automotive Engineers’ six levels of driving automation, the driver is expected to be in control or to be able to take control of the vehicle (albeit to varying degrees, depending on the level). Therefore, it is critical to determine how to keep the driver properly engaged, how to return their full attention to the task of driving in a safe amount of time and what types of cues are needed to facilitate that return.
Continuous testing, integration and deployment
Even after the vehicle is in operation, maintaining SOTIF through software updates is essential to keeping up with the changing world. Advancements in over-the-air updates open the door to continuous improvements but require software development environments that can enable the seamless verification, validation and deployment of those updates to vehicles in the field.
Overall, SOTIF must be practiced hand-in-hand with FuSa to provide a holistically safe system, which is why these activities are usually carried out by members of the same team. Aptiv’s experience with practicing both of these disciplines in varying project scopes helps us to develop systems that meet the safety objectives of our customers over the life of a vehicle.