SOTIF (Safety Of The Intended Functionality) is a subfield of technical product safety that deals with the hazards of technical systems. The standard “ISO 21448 – Road vehicles – Safety of The Intended Functionality” is currently being developed specifically for the automotive sector in order to raise the requirements for a product and the product development process to a uniform standard. Thus, SOTIF is part of product safety, which is legally anchored in many countries, such as Germany and China.
The scope of the standard is identified for new, innovative and complex functions and defines procedures for errors resulting from the limitation of a functionality.
SOTIF is intended to close a gap in the existing safety and security standards. A well-known representative of safety standards is ISO 26262, which deals with concepts, procedures and measures for errors resulting from random hardware faults or systematic errors. As an addition, SOTIF thus outlines the goal of avoiding any unreasonable risk due to hazards resulting from the insufficiency of the intended functionality, its implementation, and the reasonably foreseeable misuse of individuals.
At the core of the standard is also a risk assessment of scenarios in two dimensions of safety and awareness, let’s call this a scenario matrix. The standard therefore divides these four areas:
The standard thus aims to identify unknown and hazardous situations in particular and to prevent them from occurring. In our view, the identification and elimination of so-called edge cases is important for the success of highly automated driving functions.
The norm essentially uses the term scenarios.
A scenario is a situation with its possible combinations of variations. An example of a situation is a “child at the roadside”. Variations of this situation would be:
- the child stops at the roadside
- the child crosses the road
In any situation, the system should not create a hazardous situation for the driver and his environment.
The problem is that you do not know every possible situation from the beginning. The normal case for new developments is to gain information and data step by step. This iterative approach leads to the continuous expansion of scenarios. A technical solution is needed to handle the expansions.
Possible extensions of our case study could be the following:
- with/without oncoming traffic
- weather (rain, snow, sun, overcast)
- other persons at the roadside
- sensor dirty/clean
- a rubbish bag floating through the air
Each scenario can have any additional numbers of safety relevant aspects. It is important to know that the extensions of a situation can be interdependent, but do not have to be. This sometimes makes a description very complicated and difficult. In our experience, knowing the dependencies and independence makes it easier to create test cases.
Unfortunately, you will also not know all these dependencies from the beginning. You will have to be prepared to add and change aspects.
Test case definition is further complicated by the fact that they will confirm a large number of test cases for modeling test scenarios.
Therefore, we recommend an early start verification and validation with a systematic structured approach where frequent changes are expected.
From our point of view, you can already start your verification and validation at the software level with virtual tests and thus gain knowledge at an early stage.
A final validation must be carried out at the vehicle the basis of all tests can be scenarios reused at all test levels.
We asked ourselves how TPT – our test automation – already supports this standard today.
In short, TPT offers the following possibilities:
- own test modelling language for the creation of scenarios of any complexity and a structured approach for all variant handling
- back-to-back testing with reusable tests between models, software, hardware and networks from unit level to full Integration / product level
- fast test execution in CI/CT/CD environments and in the cloud (Windows/Linux)
- reusable definition of expected results, which are independent of test cases
- integrations to simulation environments such as CarMaker and VTD – and options to setup own plain models
In TPT, a test modelling language is available for scenario description. The advantages of model-based development, such as context separation, hierarchization and clarity, are thus also available for testing. The implementation of the test cases is derived directly from the test model.
From our point of view and that of numerous customers, there is hardly an easier way to develop scenario-based tests. At any time, the tester has a good overview of all created scenarios. A user can easily expand them and add variants. The single-source-of-truth approach also makes them very easy to maintain. With unprecedented clarity through structure and systematics, all test case creation and maintenance activities as well as all reviews of tests are accelerated.
In the following video you can see a very simple example of testing scenarios in TPT using CarMaker by IPG Automotive for visualization:
Related topics
