A framework for definition of logical scenarios for safety assurance of automated driving

Abstract

Objective: In order to introduce automated vehicles on public roads, it is necessary to ensure that these vehicles are safe to operate in traffic. One challenge is to prove that all physically possible variations of situations can be handled safely within the operational design domain of the vehicle. A promising approach to handling the set of possible situations is to identify a manageable number of logical scenarios, which provide an abstraction for object properties and behavior within the situations. These can then be transferred into concrete scenarios defining all parameters necessary to reproduce the situation in different test environments.

Methods: This article proposes a framework for defining safety-relevant scenarios based on the potential collision between the subject vehicle and a challenging object, which forces the subject vehicle to depart from its planned course of action to avoid a collision. This allows defining only safety-relevant scenarios, which can directly be related to accident classification. The first criterion for defining a scenario is the area of the subject vehicle with which the object would collide. As a second criterion, 8 different positions around the subject vehicle are considered. To account for other relevant objects in the scenario, factors that influence the challenge for the subject vehicle can be added to the scenario. These are grouped as action constraints, dynamic occlusions, and causal chains.

Results: By applying the proposed systematics, a catalog of base scenarios for a vehicle traveling on controlled-access highways has been generated, which can directly be linked to parameters in accident classification. The catalog serves as a basis for scenario classification within the PEGASUS project.

Conclusions: Defining a limited number of safety-relevant scenarios helps to realize a systematic safety assurance process for automated vehicles. Scenarios are defined based on the point of the potential collision of a challenging object with the subject vehicle and its initial position. This approach allows defining scenarios for different environments and different driving states of the subject vehicle using the same mechanisms. A next step is the generation of logical scenarios for other driving states of the subject vehicle and for other traffic environments.

Keywords:

• Automated driving
• safety assurance
• safety evaluation
• automated driving systems
• scenarios

Introduction

In recent years, automated driving has become a prevalent research area within the automotive industry. Demonstrator vehicles have already shown different use cases of automated driving systems (ADS) operating at SAE Level 3 (SAE International 2018) or higher. However, the systems have not proven ready for market introduction yet. A necessary condition for the introduction of ADS to public roads is to assure that these systems are safe (Winner 2015).

In order to generate a basis for safety assurance of automated vehicles, this article presents a framework for the definition of safety-relevant scenarios, which uses systematics that generate a comprehensive scenario catalog based on the layer model presented in PEGASUS (2018) and that also allows a direct link to accident classification. Focus is put on layer 4 because this layer covers object constellations and their dynamics leading to safety-relevant events. Furthermore, detailed focus will be put on the relevance of additional objects within the scenario.

Safety assurance of automated vehicles

A traditional approach for assuring the safety of a driving automation system is validation test drives in real traffic showing that the usage of the system does not cause a crash over a large enough distance driven. Statistical considerations have shown that due to the large mean distance between 2 crashes, for an ADS, this would require a test distance that is not economically feasible (Wachenfeld and Winner 2015).

Scenario-based validation

An alternative to safety assurance of ADS by means of field tests is the generation of dedicated test cases. These test cases should represent safety-relevant situations that an automated vehicle may encounter within its operational design domain. Whereas for ADAS this domain is strictly limited, for continuously operating ADS the number of possible relevant situations is unforeseeably large.

A promising approach to handling the vast number of potential safety-relevant situations is clustering the relevant situations into scenarios. Within different research projects and publications, different definitions of the term scenario are used due to different scopes of research. Fahrenkrog et al. (2016) described a driving situation as a specific driving maneuver with detailed parameters that can be analyzed and simulated and a driving scenario as the general abstract description of a driving situation without any specification of the related parameters. A similar understanding has been established in Elrofai et al. (2018), although using the terms scenario and scenario class.

Geyer et al. (2014) depicted a model for defining the terms scenario and situation, according to which a situation consists of a scene and an ego vehicle. The scene herein consists of the dynamic elements, the scenery including all static elements of the scene and additional instructions. Compared to other dynamic elements of the scene, the action of the ego vehicle may not be entirely predefined. Especially in safety-relevant situations, the action of the ego vehicle may not be foreseen.

Within the German research project PEGASUS, a logical scenario is defined as a model for the time sequence of scenes, which begins with an initial scene and creates a parameter space. Herein, scenarios are defined according to a 6-layer model displayed in Figure 1, based on the layer model in Schuldt (2017). The layer model in PEGASUS (2018) consists of layer 1 describing the road geometry and topology, which includes the number of lanes, lane markings and the curvature of the road. Layer 2 describes all traffic infrastructure; for example, barriers, signs, or traffic lights. Temporal modifications of layer 1 and layer 2 are represented in layer 3, which allows the representation of scenarios with temporary construction sites or additional static objects such as bollards or traffic cones.

Figure 1. Six-layer model for scenarios (Bock et al. 2018) (reprinted with permission).

Movable objects and their relations are defined in layer 4. This especially includes all traffic participants such as motor vehicles and vulnerable road users. Layer 5 describes environmental variables that have an influence on the other layers; for example, rain lowering the friction coefficient in layer 1. The model initially consisting of 5 layers (Bagschik et al. 2018b) was extended by a sixth layer, which covers digital information such as the availability of high-definition map data or vehicle-to-everything communication (Bock et al. 2018).

Scenarios from field data

One central research aspect within PEGASUS is the development of a database of relevant driving scenarios that can be utilized for safety assurance of highly automated vehicles (Puetz et al. 2017). The use case within the project is an SAE Level 3 ADS operating on controlled-access highways (PEGASUS 2018). Within the project, data are collected from various vehicles equipped with environment sensors recording real-world driving data. These data are then processed by a database framework identifying safety-relevant situations. From single situations, information about the underlying safety-relevant scenarios is gathered, which can then be utilized for safety assurance of automated vehicles combining simulations and tests on dedicated proving grounds. This process is shown in Figure 2.

Figure 2. Database process within PEGASUS based on Zlocki et al. (2018).

Using field data for safety evaluation of driving automation systems has already been the subject in various research projects such as euroFOT. Scenario catalogs for evaluation of field data have been defined in different projects (e.g., Roesener et al. 2017; Elrofai et al. 2018). However, most scenarios within the projects are being defined based on experience. As, for instance, in Fahrenkrog et al. (2016), scenarios are defined by factors that may be represented in any layer of the 6-layer model. Therefore, scenarios may not be disjunct or certain situations cannot be assigned to scenarios without ambiguity.

Definition of scenarios

Two different approaches for defining logical scenarios for automated driving can be identified, other than defining scenarios from experience. The first relies on a formal representation of knowledge using a model or other forms of knowledge representation. Examples of defining scenarios with a focus on the behavior of the participants based on a formal representation of knowledge can be found in Neumann and Novak (1986), Bagschik et al. (2018a, 2018b), and Kemper and Etzien (2014); a model-based approach is applied in Bach et al. (2016). To generate scenarios, these approaches typically utilize scenes with discrete positions on the road or a discrete set of maneuvers for each participant.

A second option is the identification of scenarios from data without utilization of a priori knowledge by using unsupervised learning approaches. Fahrenkrog (2016) applied clustering to evaluate the relevance of safety-relevant situations. Wang and Zhao (2018) presented an approach that clusters driving data into driving primitives, which may be elements of scenarios. A concern when developing a scenario framework based on data without incorporating knowledge is that only scenarios can be detected that are existent in the data. Data sets representing all safety-relevant situations would thus have to be extraordinarily large. Unsupervised learning approaches are a powerful tool for clustering the data set, but it is difficult to prove that all relevant scenarios are represented by a dedicated cluster.

An alternative to relying on driving data for generating scenarios is using accident data, because all accidents occur as the consequence of safety-relevant situations. Roesener et al. (2018) present an approach for estimating the prospective safety of ADS by linking scenarios to the 3-digit accident types in German databases. Yet, crash types in a crash report database may not be directly translated into relevant scenarios, because they represent only one possible outcome of a safety-relevant situation and only represent a limited number of objects. This article presents a systematic approach for defining safety-relevant scenarios based on a model that allows recreating a relation between crash types and the actual scenario.

Methods

Framework for defining base scenarios

An important aspect of finding safety-relevant scenarios within field data is the identification of the relevant elements in a scenario. If all objects in the environment of a subject vehicle (SV) in a scenario were interpreted as equally relevant elements, this would lead to a great variation of possible scenarios. For instance, if a vehicle from a neighboring lane cuts into the lane of the SV leading to a critically small headway, a vehicle traveling further in front of the 2 vehicles will only be considered as element of the scenario if it is of relevance.

The concept was initially developed for controlled-access highways (comparable to the Autobahn) which is the focus of PEGASUS. In general, the covered scenarios can be transferred to objects on the same traffic way traveling in the same direction, comparable to accident types 6xx for the German 3-digit accident type. Transferring the concept to other driving environments as intersections will be done within follow-up research projects.

In order to represent only the relevant elements of a safety-relevant scenario, this article presents an approach that considers the potential collision between 2 objects. This potential collision will at a certain point in time manifest in layer 4 of the 6-layer model. Hence, an object requires the SV to depart from its intended course of action in order to avoid a collision. (Crashes that involve only one object—e.g., loss of traction or roadside departures—are not considered by this approach.)

This object is referred to as the challenging object or challenger, which for the use case motorway is typically another vehicle. This challenging object is not necessarily the accident perpetrator. However, from the SV’s point of view it is the object with which a collision is imminent if no collision avoidance action is executed. The term challenger was chosen because it does not specify what type of object forces the SV to depart from its planned course of action. A heavy piece of cargo may pose a threat to the SV similar to a decelerating vehicle. Furthermore, the underlying cause of the safety-relevant situation may not be situated in layer 4; for example, a slippery surface (layer 5). If such factors are identified in a measured safety-relevant situation, these can be added to the scenario in the other description layers.

To derive a set of base scenarios, the SV is considered to be traveling in a straight line with a constant speed. Analogous to accident classification, potential collisions are divided into front, rear, and side impacts. These types of potential collisions serve as one of 2 factors defining the base scenarios. The second factor is the position of the challenging object at the beginning of the scenario: For each collision type, initial positions of the challenging object can be identified that overlap with the outline of the SV in the lateral or longitudinal direction or do not overlap at all (Figure 3).

Figure 3. Relative collision paths defining the base scenarios (Bock et al. 2018) (reprinted with permission).

The framework is illustrated by taking the example of a front impact: One position the paths lead to is located in front of the subject vehicle that overlaps in the lateral direction (position 1). Secondly, a position can be identified in front of the SV that does not overlap (position 2). A front impact from the remaining positions is only possible if the challenger moves past the SV. Therefore, all paths are assumed to go through position 4, which thus defines the third initial position. Hence, for a front impact resulting from a lateral relative movement only whether the challenger was initially in front of the SV or not is relevant. The complete necessary decisions for defining the base scenarios are shown in Figure 4.

Figure 4. High-level decision process for deriving the base scenarios.

Figure 5. Configurations of dynamic occlusions.

For the assignment of the scenarios to crash types, it is necessary to describe not only the crash type but also the pre-event movement in order to represent the scenarios adequately. The lateral overlap criteria for the rear-end scenarios can be interpreted with regard to whether the challenging vehicle was located in the SV’s lane prior to the crash.

Additional objects in a scenario

In addition to the challenger, other objects within a scenario may be of relevance. These objects may not require a collision avoidance maneuver by the SV but may increase the challenge for the SV to handle the scenario safely. From the authors’ view, such vehicles need not be described in as much detail as the challenging object in order to keep the dimensionality in the scenario description low. Several types of additional objects in layer 4 of the layer model described above have been grouped.

Action constraints

Action constraints describe objects that may affect the possible actions the SV may choose to avoid a collision. In contrast to a challenging vehicle, which requires an avoidance maneuver by the SV, an action constraint does not require any collision avoidance action. However, a certain reaction to the challenger would result in a collision between the SV and the action constraint. Therefore, an action constraint restricts possible avoidance maneuvers that can be safely executed by the SV.

The classification of possible action constraints allows defining the necessary objects by a smaller number of parameters than defining the exact behavior of each object present in the scenario. To define the possible action constraints, objects in front, behind, and to the side of the SV can be considered. By combining positions in traffic flow direction, 2 additional types of action constraints can be listed:

1. Object in front of the SV.

2. Object behind the SV.

3. Object to the side of the SV.

4. A complete blockage to the side of the SV.

5. A blockage to the side of the SV that contains a gap sufficient in size for a lateral evasive maneuver by the SV.

A visualization of the action constraints is given in Appendix B (see online supplement).

When the scenarios are simulated, the first 3 action constraints can be achieved by a single vehicle, which can be described in less detail compared to the challenger. The remaining action constraints may require multiple vehicles in a simulation but do not require dedicated parameters for each vehicle. For a blockage with a gap, it is possible to describe the dimensions and positions of the gap rather than describing the behavior of the vehicles creating the gap. Combinations of constraints are also possible to account for a larger number of relevant vehicles in a scenario.

Dynamic occlusions

Similar to action constraints, dynamic occlusions do not require a collision avoidance maneuver by the SV but can contribute to a more challenging scenario for the SV to handle. The occlusion by another object may have the consequence that the challenging vehicle is detected at a later point in time in the scenario. An object in a scenario is evaluated as a dynamic occlusion if it obstructs the view on the challenging object.

Occlusion is interpreted to be independent from the sensor setup of the SV but as planar geometry: By means of connecting a theoretical point of view of the SV with the bounding box of the challenging vehicle, whether an object partly or completely obstructs the vision on the challenging vehicle can be determined. Depending on the sensors of the SV, the challenger may still be perceived, although from the planar representation it is completely obstructed, as, for example, a radar sensor may detect the challenger via reflections. Such circumstances are not treated explicitly by the proposed scenario description: Because for testing a scenario on a proving ground or in a simulation, obstructing objects may be represented by vehicles, suitable target objects or a reasonable level of detail of the simulation will reproduce the possible advantages of the sensor setup.

The definition of dynamic occlusion serves as a description of the dynamic behavior of relevant objects in the scenario as shown in Figure 5. From the SV’s point of view, occlusion needs to be a dynamic process; otherwise, the additional object would block the path of the challenger. Depending on whether the movement of the occluding object out of the view cone of the SV reveals the challenger or whether this is due to the SV passing the occluding object, different models need to be applied for parameterization of the dynamic occlusion.

Multiple challenging objects

In addition to the 2 types of configurations of additional objects in a scenario, it is plausible that multiple objects require the SV to perform collision avoidance action. Hence, the same systematics as stated for the single challenger must be applied. However, it is necessary to define the temporal context of these challengers. This aspect needs to be subject to further research with regard to naturalistic driving data in order to identify all possible mechanisms or combinations of multiple challenging objects.

Causal challenger chains

In contrast to objects whose behaviors in the scenario increase the challenge for the SV, there are objects that potentially reduce the challenge for the SV: Just as human drivers do, an automated driving system could act tactically by anticipating relevant scenarios and avoiding them at an early stage. One reason for the emergence of a challenging behavior may be that the challenger itself was previously forced to a collision avoidance action by another object. Therefore, an object within the perception range of the SV that causes a reaction by another object and makes this other object a challenger to the SV is considered relevant and thus is described in the scenario.

Results

Relation to accident types

As described above, crash types as in (NHTSA 2016) may not be directly treated as a scenario for safety assurance, especially if more than 2 objects are relevant. Yet, it is beneficial if the scenarios can be linked to traffic accident research in order to evaluate the relevance of scenarios in terms of frequency and severity. Possible configurations of the NASS definitions that represent the hypothetical crash defining the base scenarios are shown in Appendix A (see online supplement).

Therefore, the base scenarios represent a different scope of information than just the crash type because movements before the collision are described as well. Scenarios involving more than 2 vehicles will lead to even more possible crash types: A crash with an action restriction due to an inappropriate collision avoidance maneuver by the SV may generate crash types such as Forward Impact: Avoid Collision With Vehicle (NHTSA 2016).

A proposed nomenclature of the base scenarios as listed in Table 1 has been adapted from the crash types in the NASS definitions (NHTSA 2016).

Table 1. Proposed nomenclature for base scenarios.

Impact location	Initial position	Path	Term
Front	1	A	Slower lead vehicle (challenger)
	2	B	Slower turn into path (challenger)
	4	C	Overtaking turn into path (challenger)
Side	2	D	Slower sideswipe (challenger)
	3	E	Sideswipe (challenger)
	4	F	Overtaking sideswipe (challenger)
Rear	2	G	Slower rear end (challenger)
	4	H	Rear end turning into path (challenger)
	5	I	Rear end (challenger)

Discussion

The approach in this article allows defining scenarios in a way that ensures that the scenarios are relevant for safety assurance, because the central element is the hypothetical collision with another object. Furthermore, a link to accident classification can be made that allows evaluating the relevance of the scenarios using accident statistics. Additionally, multiple objects can be considered within a scenario, by giving those objects a dedicated role contributing to the challenge for the SV to handle the scenario safely. Certain base scenarios such as scenario G may not be likely as a scenario in normal traffic but become more relevant for maneuvers (e.g., deceleration or lane changes) of the SV. The resulting scenarios for other driving states of the SV are subject to further research.

When identifying the scenarios described in this article, a vital element is the evaluation of whether a driving situation would lead to a collision without accident avoidance. Indicators for criticality like the worst time-to-collision as discussed in Wachenfeld et al. (2016) may be suitable to a large extent. Furthermore, probabilistic methods may consider uncertainty of potential collision states.

To make use of the extracted data on safety-relevant scenarios it is necessary to develop description models for the behavior of the participants in the scenario. These allow reproducing scenarios with sufficient accuracy in simulations or on proving grounds. Because each object within a scenario needs to be described with a certain number of parameters, the overall number of parameters in the scenario grows exponentially with the number of objects within the scenario. The underlying idea of the concept presented is to focus on the challenging object, which is described in detail. The generalization of the other vehicles in the scenario allows keeping the number of the parameters for each scenario as low as possible. However, it is necessary to develop tools as part of the overall tool chain that can process the abstractly defined elements of a scenario like action constraints to behavior of traffic participants in a simulation. The necessary tools are developed as part of PEGASUS and related projects.

Additional information

Funding

This article describes results of work carried out by fka in the context of PEGASUS, a project funded by the German Federal Ministry for Economic Affairs and Energy.