Read next
Safetronic 2024 Review
Extending existing processes of Functional Safety
Complex behavior presented by modern vehicles relies on complex sensors recognizing the environment of the vehicle. Unfortunately, this functionality does not operate in a black-white scheme.
© Fraunhofer IKS
Sensors can recognize some elements in the environment, others cannot, they may work in one situation, but not in another. This led to the introduction of the standard ISO 21448 (1).
That new standard introduces new terms and raises new questions to follow during the safety life cycle. To integrate activities in an established process according to ISO 26262 (2) seems to be challenging. Why? Well, safety experts are used to look inside the system. The main question is: what could go wrong so that the state of the system or the failure of a required function puts the person out of control? They are forced to look outside, in the environment of the system, where everything may happen.
The basic idea
What are the important aspects in an environment, what knowledge does the system need to operate there? How could the problem be described?
The Operational Design Domain (ODD) describes the modeled environment in which the Ego (i.e. the autonomous driving system in perspective) must operate and so helps answering questions like the one mentioned above. The ODD describes actors, signals, objects, roads and environmental conditions as well.
Interactions of actors and other elements in the ODD can be collected, described, and sorted via scenarios. This is one of the big contributions of the PEGASUS project (3) and the subsequent VVM project (2).
Now we can take the next step: what shall Ego do? In other words, which behavior shall be observed if the Ego acts in the selected and described scenarios?
Safetronic 2025
The next Safetronic, the international conference on holistic safety for road vehicles, will take place on
November 12 and 13, 2025
at Filderhalle in Stuttgart/Leinfelden-Echterdingen.
The basic idea of the presented method for describing behavior is the safety behavior cycle. The first step is to model the things to be recognized. We call these things “facts”. For the sake of simplicity, let us agree that a fact is a statement related to actors, signals etc. including their relation. Which facts are important results from the Ego and its mission (or dynamic driving task). The sum of all facts is called “Traffic Situation Picture” (TSP).
Example: we can measure the relative position of a pedestrian, of traffic lights or a crosswalk. But the important fact is: there is a pedestrian walking on a crossing lane at a green traffic light.
The next step is to decide, which actions the Ego shall take depending on the facts detected from its TSP – we call this “Action Set”. That is one possible way to describe behavior: Read the TSP, select an appropriate action. Performing this action will change the environment, so the Ego must read the TSP again and the cycle is closed and starts again.
Everything must be argued
What is the advantage of such an abstraction? It supports argumentation!
- Describe the ODD – the concepts of actors, signals and objects help to argue feasibility and completeness.
- Describe Scenarios – today this is a state-of-the-art technique for designing the foundation of the definition of target behaviors. The modelling and designing process supports argumentation.
- Safe Behavior Cycle – it is a highly structured and goal-oriented approach. With these characteristics, it contributes to an argumentation of appropriateness and completeness.
To investigate the so-called triggering events is one core requirement of the ISO 21448 (3). This investigation is guided by the definition of the TSP, because for every fact you now could ask, which event in the environment would harm the reading of an TSP.
Re-use Functional Safety processes
The Safe Behavior Cycle is also intended to fit into Functional Safety (FuSa) processes. The standard ISO 21448 (3) requires accumulating knowledge to make the set of unknown unsafe scenarios (and situations) as small as possible. Accumulating knowledge is also the intention of any FuSa lifecycle. And it is easy to see, that all the ODD aspects have the nature of requirements. It defines the ground and reference of requirements. Further, TSP and Action Set seem appropriate as part of an item definition, because TSP and Action Set could be seen as generalization of system properties and system functions which are the topic of any item definition.
Furthermore, the search for Triggering Events may be an extension of a traditional Hazard and Risk Analysis (HARA) step. First, Hazards shall be identified in the well-known way of FuSa processes. It is also possible to use TSP and Action Set during the HARA. In any case, to extend the HARA with the TSP/Action Set supported search for Triggering Events seems like a natural extension of this important step of the FuSa Life Cycle.
Thus, proven-in-use functional safety processes do not need to be rejected because of new technical challenges, but could instead be extended by using goal- and intention-oriented ways to reasoning about the problem.
References
(1) ISO. ISO 21448 Safety of the intended functionality. 2022.
(2) EICT GmbH. Verification and Validation Methods for Urban Crossing L4/L5. [Online] 11 2023. https://www.vvm-projekt.de/
(3) DLR, Deutsches Zentrum für Luft- und Raumfahrt e.V. PEGAUS Project. [Online] 2019. https://www.pegasusprojekt.de/....