The ISO 21448 Safety of the Intended Functionality defines methods for failure resulting from the limitation of a functionality. ISO 26262 deals with concepts, procedures and measures for failures resulting from random hardware failures or systematic HW/SW failures.
Many experts see the SOTIF standard as a normative support for the realization of autonomous driving. This view is supported by statements in chapter 1 of the standard. There it is explicitly mentioned that ISO 21448 should not be applied to well-proven systems such as the airbag etc., but rather to innovative, new and complex functions such as ADAS.
The following article gives an overview of the contents of the standard and discusses the point whether ISO 21448 and ISO 26262 really help to enable autonomous driving.
Safety of the Intended Functionality (SOTIF) and appropriate Use Cases
ISO 21448 defines SOTIF as follows:
The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons is referred to as the Safety Of The Intended Functionality (SOTIF).
Below are a few examples of failure scenarios which may result in unacceptable functional limitations and for which ISO 21448 is applied:
- Failures resulting from technological limitations of a sensor or actuator used
- Failures that result from the limited performance of a system
- Failures resulting from foreseeable misuse, e.g. activation of a functionality for the motorway which is activated in an urban environment and causes the vehicle to be in a scenario where it does not detect red traffic lights
Content of ISO 21448 (SOTIF)
The following diagram gives an overview of the structure of the standard. The numbers given indicate the corresponding chapter in the standard.
Compared to ISO 26262, no fundamentally new methods are used. The main difference is that the intended functionality is the focus of the considerations. ISO 26262 focuses on the possible random and systematic failures of the system.
What contribution does SOTIF make to the realization of autonomous driving?
ISO 21448 (SOTIF) rightly draws attention to the comprehensive validation of a safety-relevant system. In recent years, it has been recognized that a system which only reacts correctly to random errors and which contains a minimum of systematic errors may still not provide sufficient safety for the intended functionality.
This will certainly close a certain gap in the security process. At the same time, the step towards autonomous vehicles is still a big one.
In order to really be able to guarantee the safety of autonomous vehicles with a sufficient probability, I see two major challenges that SOTIF does not solve either. One is the system and software architecture at vehicle level and the other is the verification and validation of the systems.
At least the classic car manufacturers will have to design completely new architectures. The current architectures have become much too heterogeneous, complex and complicated. A meaningful further development for autonomous driving is no longer possible.
Regardless of this, we are heading towards a complexity and scope that can no longer be managed when verifying and validating the systems. Essentially, this means that we must say goodbye to the paradigm of 100% verification/validation. So far, however, there are no alternative methods suitable for industrial use with which the necessary proof that the systems are sufficiently defect-free can be provided.
Systematic, risk-based testing taking into account selected software parameters and other data about the system could be an approach in my view. It is time that we deal with these topics intensively, otherwise there will probably be no autonomous driving.
ISO 21448 (SOTIF) is a useful supplement to ISO 26262. However, it remains quite non-binding with regard to the concrete implementation of the proposed measures.
The standard closes a previously existing gap in the safety process. With SOTIF, however, we are only a very small step closer to autonomous driving.
Related HEICON Blog posts
- Good safety development process – What is it?
- Functional Safety – What is it?
- ISO26262 Safety Case – Success factors: management and traceability!
I’ll be glad to help you also with any specific questions about your project. Send an email to: info [at] heicon-ulm.de
An overview of the HEICON services can also be found on the HEICON Homepage.