Commit 0bf21d3a authored by Benjamin Engel's avatar Benjamin Engel
Browse files

Add images to use cases chapter

parent 8730cd35
......@@ -63,7 +63,7 @@ Additional information::
The specification of an initial design for 'Lane Keep Assistance' is provided below. The table represents the flow of events required in the scenario and the corresponding flow of events in the evaluator.
image::usecase_1_lk.svg[align=center]
image::usecases/usecase_1_lk.svg[align=center]
[%header, cols="1,3"]
|===
......@@ -237,7 +237,7 @@ Scenario description: Cut-In on highway. Only option for VUT is to emergency br
** TSV#2 has to follow the position of VUT on the right lane with an offset of 4m from front bumper to front bumper
image::usecase_4.png[align=center]
image::usecases/usecase_4.png[align=center]
*Additional Information*
......@@ -435,7 +435,7 @@ Description::
A motorcycle is driving on the left lane next to a car. The motorcycle cuts in. The car brakes suddenly and crashes.
image::usecase_9.png[]
image::usecases/usecase_9.png[]
ifndef::backend-pdf[]
[cols="a,a"]
......@@ -551,7 +551,7 @@ Simulation can help to find this out but given the number of relevant details an
+
The safety analyst will need to get informed about any safety goal violations that occurred during simulation runs, together with the determining parameters. He will then consider these as descriptors for the Triggering Conditions according to ISO 21448 and suggest improvement measures for the AV system under test. For efficiency reasons, the safety analyst does not want to receive all simulation records, but just the results for safety-critical situations. Therefore, he will formalize monitoring conditions (e.g. two vehicles getting close to each other omre than a minimum longitudinal safe distance), also in OpenSCENARIO2.0 language. These will be translated into monitors (or observers) that remain active throughout all simulation runs. They trigger reporting of a particular scenario whenever a monitor condition is violated. The relevant scenarios with their determining parameters are then reported back to the safety / SOTIF analysis tool and evaluated by the safety analyst.
image::usecase_10a.png[align=center]
image::usecases/usecase_10a.png[align=center]
Example scenario::
......@@ -564,7 +564,7 @@ The safety analyst finds out that a vehicle that suddenly appears in close dista
+
The safety analyst may want to specify graphically or textually an abstract or logical scenario in his SOTIF analysis tool and export it to the simulation tool chain. The scenario stub contains only the necessary elements (e.g. no other vehicles that may be around, not details regarding the type of target vehicle) and leaves ranges from which to choose the concrete parameters (e.g. initial speed >= 120 km/h, merging in occurs in a distance between 50 m and 100 m, target vehicle continues driving at constant speed for 1 to 2 s before deceleration begins, etc.). However, the abstract or logical scenario must at least specify the characteristic details about the road type and layout, weather, and sight conditions (if relevant), and sequence of scenes and actions, which may be a serial sequence in the simplest case. All of this must be included in the OpenSCENARIO2.0 export. Furthermore, the monitoring condition must be derived from the hazard under investigation. If this hazard is a rear-end crash, a monitoring condition could be that at any time the longitudinal distance gets lower than 10 m. If this monitor is triggered during execution of any of the derived concrete scenarios, the scenario is labeled as failed, and a report is generated, which can be imported back into the safety analysis tool.
image::usecase_10b.png[align=center]
image::usecases/usecase_10b.png[align=center]
Additional information::
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment