What is Safety Of The Intended Functionality (SOTIF)?
When working with embedded software or hardware, you might have come in contact with functional safety. Functional safety deals with getting the risk of malfunctioning behaviour of your systems to a level that you can accept. In essence, malfunctioning behaviour means that your system does not work as intended, and when this happens in a safety-critical system like a car, it can threaten lifes. Unfortunately, getting the risk of malfunctioning behaviour to acceptable levels is tough. This is why international standards govern how safety-critical systems are developed. Instead of vibe coding driver assistance systems, the ISO 26262 standard series “Road vehicles – Functional safety” describes how road vehicles (say car, bus, truck, …) and their subsystems are expected to be built. On over 800 pages in 12 parts, ISO 26262 details expected processes that car manufacturers and suppliers are required to have in place like risk assessments, traceability in their requirements or verification and validation activities.
Despite all this effort on safety, your system can still put people in danger, even if we assume it is working as intended 100% of the time. This fact is hinted by ISO 26262 itself which contains the following seemingly minor note (in Section 6.4.2.1 of Part 3):
Hazards resulting only from the item behaviour, in the absence of any item failure, are outside the scope of this document.
ISO 26262 is only concerned with safety risks from failures (caused by systematic faults like incomplete requirements, poor fault tolerance, software bugs, etc., or random hardware faults, but let’s not dive too much into the terminology of ISO 26262 for the sake of brevity). When the implementation of our functionality is working as intended (it is free from faults) but we still see safety risks, the intended functionality itself might be the problem.
Examples of Safety Risks not Covered by ISO 26262
To make this more tangible, we will need a few examples. The intended functionality could be automated emergency braking (AEB) that is supposed to hit the brakes when your vehicle is about to hit another object. This function could rely on data from a radar which unfortunately can see “ghost objects” under certain circumstances causing radar signals to get reflected. From an ISO 26262 perspective, everything is working as intended when your vehicle hits the brakes despite a clear road in front of you. But instead of increasing safety, it leads to you being rear-ended by a following vehicle.
Another functionality could be a lane keeping assist system (LKAS) which is supposed to keep your vehicle in the middle of its driving lane. The system could use camera data to detect the lane markings and estimate the vehicle’s position in the lane. Unfortunately, snow can be misinterpreted as lane markings by the system, and again, ISO 26262 would not complain about the assist system driving you off the road instead of keeping you on it.
Both of the examples have in common that they involve systems that try to make sense of the vehicle’s environment to maintain some form of situational awareness. On the way to driving automation, vehicles are increasingly equipped with these kind of systems that rely on complex sensor data and processing. Due to this, there was an urgent need for a new standard to fill this safety gap left by functional safety standards like ISO 26262.
Safety Of The Intended Functionality
Safety Of The Intended Functionality, in short SOTIF, was first introduced as a publicly available specification (PAS) with ISO/PAS 21448 in 2019 to address the urgent need to fill the safety gap described above. At the time of this writing, the latest version of the standard is ISO 21448 from 2022.
SOTIF introduces a new iterative process that extends several activities of ISO 26262 but does not really fit cleanly into ISO 26262’s somewhat strict V-model. Both SOTIF and ISO 26262 perform a hazard analysis early in the process to find safety risks that should be accounted for in the later stages of the process. However, the verification and validation performed by SOTIF focuses on scenarios which describe how the vehicle and other entities behave under defined events and environmental conditions including for example weather (the terms scenario and operational design domain are additional cans of worms that I am trying to open only as much as needed for the high-level explanation of SOTIF). This could be something like a pedestrian stepping onto the road in front of the vehicle under heavy rain at dawn while the vehicle is going 30 km/h etc. (ASAM OpenSCENARIO is a widely used standard for defining scenarios).
In simplified terms, you maintain a growing list of scenarios which you use to verify and validate that your system behaves safely. If it does not, you analyze what went wrong and modify the specification (like only allowing use in summer) or design of your function or its implementation (like adding compute power or a more powerful sensor). Then, you perform another iteration of identifying hazards and evaluating scenarios, where you might have added scenarios since the previous iteration.
From my point of view, the SOTIF process is notable for several reasons. While ISO 21448 is an addon to ISO 26262, its iterative process significantly deviates from “classical” functional safety where you almost linearly work your way through the different phases of the V-model. Furthermore, the shift from focusing on avoiding failures (ISO 26262) to focusing on scenarios (ISO 21448) requires a different kind of thinking. While failures and the world of functional safety are more or less deterministic, scenario-based verification and validation are probabilistic and incomplete: it is theoretically possible to enumerate all faults but impossible to enumerate all scenarios your vehicle can encounter. Instead of designing an almost provably safe system, the introduction of situational awareness forces us to formulate statistical arguments that our system is good enough. SOTIF further accepts the fact that we might have missed SOTIF-related issues when putting the vehicle on the market, puts weight on field monitoring and requires us to go back to evaluating our system when a potential issue is observed. Therefore, the SOTIF process is continuous and extends into operation of the vehicle.
This is Just the Beginning
SOTIF is so far a concept of the automotive domain, but other domains too are becoming more automated and rely increasingly on situational awareness. In fact, one of the last things I was involved in before leaving RISE was to investigate whether SOTIF can suit automated mobile machinery like the ones used in forestry. While the full results are not yet publicly available, there is this presentation from SCSSS held at SafeComp and I would say it worked out pretty well. I would not be surprised to see a similar concept or an adaptation of SOTIF to sooner or later appear within the world of mobile machinery.
SOTIF does not really focus on AI but looks more generally at risks with functionality that relies on complex sensors and situational awareness. It is easy to think of AI, however, and wonder how to make sure that it behaves safely. This is the focus of another ISO effort which was recently published as ISO/PAS 8800 “Road vehicles — Safety and artificial intelligence”. From a first quick readthrough, I would say that it goes even further than SOTIF in embracing non-determinism as well as the marriage of safety and iterative development.