Safety cases are usually based on functional safety arguments to demonstrate that failures will not result in hazardous situations. But accidents may have causes related to the system behaviour different than failures. This is where SOTIF comes in. This stands for Safety of the Intended Functionality. What does it mean? It covers mitigation of hazard factors related to unexpected situations or system limitations. One example of an unexpected situation is bright sunlight making it difficult for an autonomous vehicle to identify lanes. Another example is a system misuse, such as a system operator giving commands that is not foreseen for the current operation mode. SOTIF helps us assure safe system behaviour in unexpected situations.
SOTIF extends functional safety
Functional safety focuses on the risk arising from system faults or failures, i.e. hardware or software malfunctions. In the automotive sector, this is described in the ISO 26262 standard. Safety assurance for other causes related to system limitations and unexpected situations are regulated in the SOTIF standard ISO 21448.
The SOTIF safety assurance process involves a few steps:
- The boundaries and scope of the intended functionality must be defined within the Operational Design Domain (ODD).
- System behaviour is analysed for potential unsafe scenarios.
- Mitigation measures are identified, which can be related to functional modifications to achieve SOTIF goals.
- The planned mitigation measures are implemented and verified.
- Validation is performed under diverse and representative conditions.
- Field monitoring for SOTIF evaluation and maintenance is defined for implementation during system operation.
SOTIF arguments
SOTIF implementation needs to be demonstrated in the system safety case. Guidance how to do this and examples of GSN arguments are provided in ISO 21448. A sample top-level argument for the pre-release SOTIF process of safety assurance is presented below. A separate claim is specified for each main phase of the SOTIF process.
This argument should be extended to include a second branch of the argument for the operational phase of the system life cycle. This argument is focuses on demonstrating the capabilities of the SOTIF safety maintenance process, since the argument is to be developed and approved before the system operation starts. During the system operation this can be supplemented with evidence that these actions are actually performed.
As SOTIF extends functional safety, there is a question how these two arguments relate to each other. There are a few common actions or work products shared between functional safety and SOTIF, such as:
- identified hazards,
- limitations and assumptions of functional safety,
- safety goals and safety requirements,
- safety requirements verification and validation.
You can develop separate assurance case modules for functional safety and for SOTIF, they can refer to shared artifacts where necessary. Probably, you will need a claim to demonstrate that functional Safety and SOTIF measures are consistent and jointly sufficient to achieve the acceptable system risk level.
You can browse the sample SOTIF assurance case online in PREMIS using this link.
Summarizing, joint SOTIF and functional safety assurance case covers hazards related to both failures and system limitations including unexpected situations. ISO 21448 is dedicated for automotive sector but this approach is also useful in other industries.