With the increasing level of complexity, it is a growing challenge to define SOTIF functions. Some functions are distributed across multiple devices, multiple development teams and organisations. How do we approach this challenge?
Before we dive deep into the topic: The SOTIF standard defines very explicitly where the ISO DIS 21448 is applicable and – even more importantly – what is out of scope. So, safety and security issues are excluded and therefore all the bad and dangerous aspects are not touched upon here.
Far more interesting is the upcoming driving automation.
In general, there are two extreme approaches:
- The vehicle scans its environment and decides on its own how to react to each situation
Hereby it is autonomous and does not need any information from any other external source.
- There is a central intelligence unit that gathers information from each vehicle on the road and tells every vehicle how to act.
Pros & Cons
Each of those two approaches has its pros and cons. The autonomous vehicle would need extensive training to cope with all possible scenarios and still there is no guarantee that every situation can be handled optimally (see also SOTIF & AI – Rise of a little Brother). The centralized control unit would make the perfect target for hacker attacks (see also Handling cybersecurity with SOTIF – a question of luck?). A mixture would help to minimize those disadvantages.
Car2Car and Car2X
One promising approach is the communication between vehicles and traffic signs or signals. This is known as Car2Car or Car2X in general. In principle the vehicle still makes its own decisions. But in that scenario, it gains much more information about the environment without the blurs of its own sensors. Thanks to the vehicle communication, the car itself is notified immediately of the braking process of the previous car, and how strong the deceleration will be.
Another example can be placed at a crossing. With communicating signals, the car is instantly notified of the actual state of the traffic light or who has priority at the intersection. The system of the vehicle does not have to interpret impressions from sensors and possible errors are eliminated.
And here the question arises: Who is responsible for the function itself?
The function is, for example: stop at the red light when coming to a regulated crossing.
- There is a transmitter sending the signals about the states of the traffic light for each way.
- The vehicle knows which street it is driving on – maybe by GPS or also transmitters beside the road.
- In case of a red light, the vehicle shall stop at the line or behind the previous car.
In that case the function is split onto three devices:
- The traffic light / transmitter – delivering the information Stop or Go
- The road / transmitters – where are you?
- The vehicle – evaluate the information and stop if necessary.
Designing the vehicle according to ISO DIS 21448 entails the phrase “ODD” – operational design domain – describing the specific conditions under which a given driving automation system is designed to function.
Thus, this communication would be such a specific condition. But the design and development of the “other side” is completely off the records. Also, the section about distributed development is not applicable in that case. It is more like a distributed functionality.
For safety or security there are clear definitions as to how different systems shall communicate or fulfil specific parameters. In SOTIF there is no concrete suggestion.
It is understandable that at present only experimental set-ups exist with which the feasibility is to be demonstrated. Still, if there are several set-ups, each with a single partner in the automotive industry, the chances are rather high that multiple systems are designed and developed which are incompatible to each other.
Therefore, a superior level needs to be introduced. A standard for communication to standardize it for all types of vehicles and transmitting systems within the traffic. Or an adaption of the ISO DIS 21448.
By Gerrit Steinöcker, Functional Safety Consultant