Commit c0412041 authored by Benjamin Engel's avatar Benjamin Engel
Browse files

Rename subchapters. Add use cases from concept

parent 8ee1f92a
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1133 188"><defs><style>.cls-1{fill:#b3b3b3;}.cls-1,.cls-5,.cls-7{stroke:#000;}.cls-1,.cls-3,.cls-4,.cls-5,.cls-7{stroke-miterlimit:10;}.cls-2,.cls-3,.cls-4,.cls-7{fill:none;}.cls-3,.cls-4{stroke:#fff;}.cls-3,.cls-4,.cls-7{stroke-width:2px;}.cls-4{stroke-dasharray:12.04 12.04;}.cls-5{fill:#006da2;stroke-width:0.5px;}.cls-6{font-size:18.8px;fill:#fff;}.cls-6,.cls-8{font-family:Hack-Regular, Hack;}.cls-8{font-size:18px;}</style></defs><title>usecase_1_lk</title><g id="road"><rect class="cls-1" x="0.5" y="0.5" width="1132" height="187"/><path class="cls-2" d="M1133,187"/><path class="cls-2" d="M1,187"/><line class="cls-3" x1="1" y1="94" x2="7" y2="94"/><line class="cls-4" x1="19.04" y1="94" x2="1120.98" y2="94"/><line class="cls-3" x1="1127" y1="94" x2="1133" y2="94"/></g><g id="Layer_1" data-name="Layer 1"><path class="cls-2" d="M1026,352.52"/><path class="cls-2" d="M913.41,39.4"/><path id="path5362" class="cls-5" d="M955.51,71c1.31.06,2.18-1.2.55-4.11,12.87.23,25-.06,38.75.29,5.45.13,9.91-.53,16.39-.41,4.9-.25,12.94-.67,16.29-4.17,4.7-4.91,6.12-13.73,6.15-21.37h0v-.79h0c0-7.64-1.45-16.46-6.15-21.37-3.35-3.5-11.41-3.68-16.29-4.17-3.36-.34-10.94-.55-16.39-.41-13.78.35-25.88.06-38.75.29,1.63-2.92.76-4.18-.55-4.11a3.91,3.91,0,0,0-3.22,3.85c-4.4.1-7.42.26-12.73.27-9,0-12.58.93-17.25,5.24-3.79,3.5-8.11,8.5-9.3,13.59.06,3.22,0,4-.09,7.07h0a.66.66,0,0,1,0,.14.76.76,0,0,1,0,.15h0c.11,3.1.15,3.84.09,7.07,1.19,5.09,5.51,10.08,9.3,13.58,4.67,4.31,8.24,5.22,17.25,5.24,5.31,0,8.33.18,12.73.28A3.92,3.92,0,0,0,955.51,71Zm17.71-8.53-23.84-.61s4.09-1.23,6.15-1.82,4.06-1.3,6.15-1.75a23.19,23.19,0,0,1,2.5-.38c1.89-.2,3.79-.35,5.7-.38,6.61-.08,13.21.39,19.81.84,3.55.24,7.28.42,10.63,1a.82.82,0,0,1,.61.53c.2.67-.54,2-.54,2Zm-26.93-1.2a1.22,1.22,0,0,1-.8-.29,10.11,10.11,0,0,1-4.72-4,25.89,25.89,0,0,1-3.83-9.59,29.59,29.59,0,0,1-.62-6.56,29.65,29.65,0,0,1,.62-6.56,25.84,25.84,0,0,1,3.83-9.58,10.08,10.08,0,0,1,4.72-4,1.43,1.43,0,0,1,1.62-.07l13.12,4.28a25.61,25.61,0,0,0-2,6.46,47.78,47.78,0,0,0,0,19,25.61,25.61,0,0,0,2,6.46l-13.12,4.28A2,2,0,0,1,946.29,61.27Zm55.11-4.63h-.85c-6,0-3.91-.09-9.91-.19a76.92,76.92,0,0,0,1-10.39c0-1.22.08-3,.11-4.56h0c0-.17,0-.46,0-.66s0-.48,0-.66h0c0-1.53-.06-3.34-.11-4.56a77.07,77.07,0,0,0-1-10.39c6-.1,3.91-.18,9.91-.18a4.88,4.88,0,0,1,3.26.68,11.7,11.7,0,0,1,5,7.09,29.47,29.47,0,0,1,.92,8,29.47,29.47,0,0,1-.92,8,11.75,11.75,0,0,1-5,7.1,4,4,0,0,1-2.41.69Zm-29-32.5h-2.47a57,57,0,0,1-5.7-.38,23.19,23.19,0,0,1-2.5-.38c-2.09-.45-4.11-1.15-6.15-1.75s-6.15-1.82-6.15-1.82l23.84-.6,27.17.53s.74,1.37.54,2.05a.86.86,0,0,1-.61.53c-3.35.57-7.08.75-10.63,1-5.77.38-11.55.79-17.34.84Z"/><text class="cls-6" transform="translate(958.58 47.64)">ego</text><line class="cls-7" x1="746.07" y1="41" x2="913" y2="41"/><path d="M734,41c5.68,2.11,12.73,5.7,17.09,9.51L747.65,41l3.44-9.51C746.73,35.3,739.68,38.89,734,41Z"/><line class="cls-7" x1="913" y1="41" x2="913" y2="73.93"/><path d="M913,86c-2.11-5.68-5.7-12.73-9.51-17.09L913,72.35l9.51-3.44C918.7,73.27,915.11,80.32,913,86Z"/><text class="cls-8" transform="translate(813.31 81.33)">Distance</text><text class="cls-8" transform="translate(803.33 32.75)">Speed</text></g></svg>
\ No newline at end of file
......@@ -16,8 +16,8 @@ include::subchapters/1-5_relations_to_other_standards_projects_or_organizations.
include::subchapters/2_technical-content.adoc[]
== Project Resources
include::subchapters/3-1_required_resources.adoc[]
include::subchapters/3-2_committed_resources.adoc[]
include::subchapters/3-1_work_packages.adoc[]
include::subchapters/3-2_company_commitments.adoc[]
include::subchapters/3-3_resource_summary.adoc[]
== Project Plan
......
=== Use Cases
AV use cases are influenced by a variety of factors, such as ODDs, map features, traffic model, weather model, and others. The scenarios assigned to the use cases can be parametrized and typically run in multiple modes of operations. These modes include:
[[a-share]]
==== A) SHARE
* On track test
* On road tests
* In sim tests
* In replay (i.e. resimulation) tests
1. As an AV/ADAS developer company, I can share with other companies the scenarios I built to test my technology.
2. As an AV/ADAS developer company, I can search, review and reuse scenarios built by other companies.
3. As a test engineer working for an AV/ADAS development company, I can build and run tests as similarly as possible to tests other developers at other companies are running.
4. As a test engineer, I can build and run tests as similarly as possible on different execution platforms.
5. As a researcher developing new technology, I can reutilize industry and open source scenarios to advance my research.
The intent of OpenScenario 2.0 is to cover use cases at varying levels of autonomy. Hence, they should represent an adequate level of complexity including maneuvers and ODD features that are not accounted for otherwise. An example is an AV driving on a complex road with road features such as roundabouts, bus stops, highway ramps, entries and exits or in dense traffic where various maneuvers like cut-ins, lane reductions and cross traffic with other agents on the road.
[[b-certify-analyse]]
==== B) CERTIFY & ANALYSE
The following list of use cases for scenarios attempt to cover the majority of the currently considered scope of features of OpenSCENARIO. The list adheres to the following format:
1. As an auditor/regulator, I can understand how AV/ADAS developers are testing their products.
2. As an auditor/regulator, I can compare the outcome of different execution platforms when they have the same OpenSCENARIO input.
3. As a safety consultant, I can recommend specific scenarios and related conditions (parameters) to my clients to test their products.
4. As a member of the public, I can learn more details about how AV/ADAS products are tested by AV/ADAS developers.
5. As government agency, I can understand what parts of the Operational Domain are verified by an AV/ADAS developer through each scenario.
Summary:: Title
Related user story(s):: Which user stories are related (<<User stories for OpenSCENARIO 2.0>>)?
Covered abstraction levels:: Of the multiple abstraction levels, which are relevant?
Description:: Detailed break down of the example use case
Example scenario::
[[c-develop]]
==== C) DEVELOP
* Function description (not part of the scenario):
1. As a tool developer, I can reutilize constructs, artifacts and libraries to create tools compatible with other tool vendors in industry.
2. As a service provider, I can integrate tools from multiple tool vendors to provide an integrated solution to test AV/ADAS scenarios.
3. As a system engineer working for an AV/ADAS developer company, I can fully trace which hardware and software in the AV/ADAS stack is verified by which tests.
4. As a software developer, I can process scenario information from different software/hardware releases and produce comparison charts to provide trend and gap analysis.
5. As an existing tool provider or consumer, I can migrate information from previous versions of OpenSCENARIO into OpenSCENARIO 2.0.
6. As a system engineer working for an AV/ADAS developer, I can decompose high level use cases in a standardised way.
** Customer function level:
*** System behavior level:
[[d-create]]
==== D) CREATE
* Scenario description:
1. As a content developer, I can use OpenSCENARIO 2.0 to create test scenarios that I can supply to my customers who use a OpenSCENARIO 2.0 compliant toolchain.
2. As a test engineer, I can transform abstract test descriptions into OpenSCENARIO 2.0 (e.g. NCAP tests, UNECE regulations, any requirement list, …).
3. As a development project lead, I can write scenarios on an abstract level to discuss the functional behavior with the stakeholders.
4. As a development project lead, I can create scenarios on an abstract level to document the functional behavior for legal reasons.
5. As a stakeholder, I can create natural language scenarios without having any knowledge about technical details.
** Abstract/concrete description:
[[e-sotif-based-risk-consideration]]
==== E) SOTIF-BASED RISK CONSIDERATION
* Test description (not part of the scenario):
1. As a SOTIF safety engineer and/or V&V engineer, AV developer, scenario creator, I can use OpenSCENARIO 2.0 to discover scenarios that are going to uncover safety hazards. This refer to SOTIF and safety hazards that can be present even if the system is functioning as designed, without a malfunction.
2. As a SOTIF safety engineer and/or V&V engineer, AV developer, scenario creator, I can use OpenSCENARIO 2.0 to create scenarios that are going to produce emergent behavior of the DUT to discover unknown unknows. OpenSCENARIO 2.0 shall enable to demonstrate that minimum residual risk is attained by the DUT. This is because SOTIF focuses on ensuring the absence of unreasonable risk due to hazards resulting from insufficiencies in the intended functionality or from reasonably foreseeable misuse.
** Precondition:
** Test description:
[[f-driving-mission-based-scenarios]]
==== F) DRIVING MISSION-BASED SCENARIOS
Additional information:: ...
1. As an end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable specification of a driving mission through inclusion of multiple maneuvers in a sequence or in parallel for both DUT and any other traffic agents.
2. As an end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable accomplishing a select driving mission with an indication of whether the mission has been accomplished, what are the mission KPIs and how they are computed, and whether the unambiguous goals of the mission have been attained.
==== Use Case Example 1: Evaluation/validation/checks
[[g-traffic-model-inclusion]]
==== G) TRAFFIC MODEL INCLUSION
Example for demonstrating autonomous vehicle functionality. A simple example for a generic use case in Level 2 driving domain comprised of a scenario and an evaluator.
1. As a traffic model developer, an ADS developer, or end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable inclusion of multiple traffic models and AI-based traffic agents in the scenarios and evaluators. Also, OpenSCENARIO 2.0 shall enable inclusion of mechanisms to extract scenarios from the traffic models.
2. As a test engineer, I can transform from high level scenario description to low level scenario descriptions and vice versa.
Summary::
[[h-execute]]
==== H) EXECUTE
Evaluator checks/validation for scenario descriptions
1. As a test engineer, I can execute different OpenSCENARIO 2.0 files in an automated way with my OpenSCENARIO 2.0 compliant toolchain; no file modifications are needed.
2. As a test engineer, I can execute the same OpenSCENARIO 2.0 files on different OpenSCENARIO 2.0 compliant toolchains.
3. As a test engineer, I can convert abstract scenarios into tests.
Applicable user story(s)::
[[i-describe-observations]]
==== I) DESCRIBE OBSERVATIONS
D3
1. A simulation tool can describe randomly executed simulation runs. If the Simulation was run with stochastic metrics, the user wants to have the concrete description of what has happend in OSC2.0 Format.
2. A traffic observer can describe what occured in real world with OSC2.0
3. A test engineer on a test track can describe with OSC2.0 what specific scenario he has observed on a test track. In such a way tolerances and deviations between test description and test execution will become obvious.
Covered abstraction levels::
Mainly abstract, concrete details
Description::
Scenario of an ego car driving on a road between the lanes. The evaluator checks whether the ego car is able to keep driving between the lanes. Expected outcome: Car must drive segments of oval map with LK feature enabled at all times and without any failures.
Example scenario::
* Abstract/concrete description: Ego car starts driving with 40 km/hour speed at a given location in oval map.
* Test description: Enable Lane Keeping Assistance (LK) at 10 seconds. Let the car drive in oval map for another 120 seconds.
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]
[%header, cols="1,3"]
|===
| Scenario Sequence | Evaluator
| EgoStartPosition |Pre:: Detect Ego position (centered in Ego lane)
| EgoStartSpeed | Pre:: Detect Ego start speed (e.g. 40km/h)
| EgoStartLK | Pre:: Detect Ego engages LK (e.g. after 10s of driving)
| SetWatchdog | Pre:: Start timer for maneuver (e.g. 120s duration)
| EgoSensorOK | Pre:: Assert Ego sensors are functional and clean
| ActivateEgoLK | Post:: Assert Ego LK working and engaged
| AssistEgoWithLK | Post:: Assert that the distance between Ego and center of the lane is less than a threshold (e.g. 1 meter deviation indicates fail)
|===
==== Use Case Example 2: Regulations
Summary::
Regulations are one source for verification and validation of vehicles. Regulations contain requirements that shall be fulfilled by vehicles and corresponding test descriptions. The information about maneuvers, parameters, test conditions etc. is only given in plain natural language. With OpenSCENARIO 2.0 one can create corresponding scenarios. Those scenarios can be used for test execution, sharing and analyses. Details of UN R 79 as one example can be found in the following section. As example the lane change procedure suppression in a critical situation is given.
Applicable user story(s)::
A*, B*, C*, D*, E*
Covered abstraction levels::
Mainly abstract, partly concrete
Description::
Lane change procedure suppression in a critical situation; UN Regulation No. 79 for Automatically Commanded Steering Function (ACSF) of Category C [UN R79] +
+
__"ACSF of Category C" __implies a function, which is initiated/activated by the driver and which can perform a single lateral maneuver (e.g. lane change) when commanded by the driver.
+
Requirements are given as follows (as described in section 5.6.4.6.8 of the regulation):
* The lane change procedure shall be suppressed automatically by the system when the system detects a critical situation before the lane change maneuver has started (5.6.4.7)
** A situation is deemed to be critical when, at the time a lane change maneuver starts, an approaching vehicle in the target lane would have to deccelerate at a higher level than 3m/s, 0.4 seconds after the lane change maneuver has started, to ensure the distance between the two vehicles is never less than that which the lane change vehicle travels in 1 second.
Example scenario::
* Abstract/concrete description: The test vehicle shall be driven in a lane of a straight test track, which has at least two lanes in the same direction of travel, with road markings on each side of the lanes (as in section 3.5.4 of UNR79).
. The vehicle speed shall be: V~smin~ + 10km/h.
. The ACSF of Category C shall be activated (standby mode) and another vehicle shall approach from the rear in order to enable the system (5.6.4.8.3).
. The approaching vehicle shall then pass the vehicle under test entirely.
. A Lane Change Procedure shall then be initiated by the driver.
. The test shall be repeated for the following condition, which shall occur before the lane change maneuver has started:
** The lane change maneuver has not commenced within 5.0 seconds following the initiation of the lane change procedure. (e.g. another vehicle is driving in the adjacent lane in a critical situation as described in paragraph 5.6.4.7.).
. The requirements of the test are fulfilled if the lane change procedure is suppressed, for each of the test cases above (3.5.4.2)
* Test description: Enable Lane Keeping Assistance (LK) at 10 seconds. Let the car drive in oval map for another 120 seconds.
Additional information::
A _Lane Change Procedure_ in the case of ACSF of Category C starts when the direction indicator lamps are activated by a deliberate action of the driver and ends when the direction indicator lamps are deactivated. It comprises the following operations:
* Activation of the direction indicator lamps by a deliberate action of the driver
* Lateral movement of the vehicle towards the lane boundary
* Lane Change Maneuver
* Resumption of the lane keeping function
* Deactivation of direction indicator lamps.
+
A "_Lane Change Maneuver_" is part of the Lane Change Procedure and:
* Starts when the outside edge of the tire tread of the vehicle's front wheel closest to the lane markings touches the inside edge of the lane marking to which the vehicle is being maneuverd,
* Ends when the rear wheels of the vehicle have fully crossed the lane marking.
==== Use Case Example 3: Electronic stability control (ESC) testing
Summary::
Sine with dwell test sequence, including slowly increasing steer as preparation maneuver.
Applicable user story(s)::
A4, A5, B3, D2, E1, E2
Covered abstraction levels::
Concrete level (ISO specifies concrete values for the shown scenario)
Description::
As a preparation for the actual sine with dwell test series, the vehicle is subjected to two series of runs of the slowly increasing steer test, using a constant vehicle speed of 78-82 kph and a steering pattern that increases by 13.5 deg/s until a lateral acceleration of 0.5 g is obtained. Each test series includes three repetitions. One series uses counter clockwise steering, and the other series uses clockwise steering. The goal is to determine a reference steering wheel angle A, which represents the steering wheel angle leading to a steady-state lateral acceleration of 0.3 g for the test vehicle.
+
As a preparation for the actual sine with dwell test series, the vehicle is subjected to two series of runs of the slowly increasing steer test, using a constant vehicle speed of 80 km/h and a steering pattern that increases by 13.5 deg/s until a lateral acceleration of 0.5 g is obtained. Each test series includes three repetitions. One series uses counter clockwise steering, and the other series uses clockwise steering. The goal is to determine a reference steering wheel angle A, which represents the steering wheel angle leading to a steady-state lateral acceleration of 0.3 g for the test vehicle.
+
During the actual sine with dwell test, the vehicle is steered using a steering pattern of a sine wave at a frequency of 0.7 Hz with a delay of 500 ms beginning at the second peak amplitude, see Figure below. Several tests are performed in a series in which the amplitude of the steering pattern is increased with each test. The series is performed twice, where one series starts with counter clockwise steering, and the other series start with clockwise steering. The sine with dwell test series starts with a specific fraction of the reference angle A, and is increased from run to run by half the reference angle. The calculation for the maximum steering angle amplitude to be applied is also specified by the standard.
Example scenario:: N/A
Additional information::
The main purpose of ISO 19365 is to provide a repeatable and discriminatory method for comparing simulation results to measured test data from a physical vehicle for sine with dwell tests, which are typically used to evaluate the performance of an electronic stability control (ESC) system, see "Passenger cars - Validation of vehicle dynamic simulation - Sine with dwell stability control testing (ISO 19365:2016)".
+
The comparison is made for the purpose of validating the simulation tool for this type of test when applied to variants of the tested vehicle. It is applicable to passenger cars as defined in ISO 3833. The sine with dwell test method is based on the test method specified in regulations USA FMVSS 126 and UN/ECE Regulation No. 13-H.
==== Use Case Example 4: Stakeholder Discussion
Summary::
Scenario usage as a basis for stakeholder discussion.
Applicable user story(s)::
A1, A2, C6, D3, D4, D5
Covered abstraction levels::
Mainly abstract, probably concrete details
Description::
The stakeholders in the context of a driving function development project provide information about the project setup, neighbor systems, sensors, actors and software/hardware constraints. To define the driving function, the project lead needs to discuss the function goals and behavior with the stakeholders. For this, a short and easily comprehensible scenario description, which is understandable without detailed technical knowledge, should be available. A corresponding two or three dimensional visualization can help.
Example scenario::
Function description (not part of the scenario):
* Customer function level: My driving function (emergency brake assist) has to perform an emergency braking, if either an object in the trajectory appears suddenly and the driver has no chance to react, or if the driver fails to react in a normal braking situation and the distance to the object falls below a threshold
* System behavior level: If the distance to an object in the trajectory falls below threshold C1 and the speed is above V1, inform the user visually. If the user does not react within X seconds, perform an emergency brake with -15 m/s^2^.
+
Scenario description:
* Abstract description: Highway with at least one lane, a car follows one lane, an object is in front of the car. The distance is Y meters.
* Logical and concrete descriptions: extensions of the abstract description, e.g. by defining lane width, car size, etc.
+
Test description (not part of the scenario):
* Precondition: Apply the scenario described above
* System-under-test: Implementation of the developed driving function
* Test description:
** If dist_obj < C1 && v > V1, check if message is shown to the user.
*** Start timer t.
** If t > X, check if brake == true && a < -15 m/s^2^.
*** If true, test = pass, otherwise test = fail.
==== Use Case Example 5: Proving ground testing
Summary::
Scenarios for proving ground testing.
Applicable user story(s)::
A4, D1, D2, E1, E2, E3
Covered abstraction levels::
Concrete
Description::
A scenario description is required to enable the tester to test a scenario on the proving ground.
Example scenario::
Scenario description: Cut-In on highway. Only option for VUT is to emergency brake.
* Scenario takes place on a 2-lane highway. VUT is following another vehicle (TSV#3) with Highway-Pilot (L3) active. VUT and lead-vehicle are on the left lane. An additional Vehicle (TSV#2) is right next to VUT on the right lane. It stays besides the VUT with an offset of 4m from front bumper to front bumper. A slow vehicle (TSV#1) is changing lane from right to left and cuts in between TSV#3 and VUT. The VUT has only the option to emergency brake and not to change lane.
* Stationary Conditions:
** Speed of TSV#3 = 80km/h
** Speed of TSV#1 = 20km/h
** Lane Change of TSV#2: Length = 20m; Offset = 3.7m to left; shape = sinusoidal
* Triggers:
** TSV#1 which does the lane change: LC has to be completed when distance of VUT to TSV#1 is 20m
* Control:
** 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]
*Additional Information*
.Birds-eye view perspective with logged data (https://www.youtube.com/embed/UlKaZmmz0eA?fs=1[Youtube])
video::UlKaZmmz0eA[youtube,width=800,height=400,opts="modest,autoplay,loop", theme=light, poster=Screenshot_meas-data-proving-ground.png]
==== Use Case example 6: NHTSA Scenario Descriptions
Summary::
Scenarios from NHTSA test description formats should be fully coverable by an OpenSCENARIO 2.0 description
Applicable user story(s)::
A1, A4, B1, B4, D2, D3, E3
Covered abstraction levels::
Concrete
Description::
The DUT is travelling straight in the second rightmost lane at 40 mph (lane speed). DUT is approaching a signalized intersection with a red signal state while a pedestrian is crossing at a speed of 1.2 m/s.
image:usecase_6.png[align=center]
Example scenario::
* Meta-Data:
** Map/Template: PHX
** N Scottsdale Rd & E Thomas Rd
** GPS: 33.4802924, -111.9259426
** Density: Low ( 2 of each )
** Vehicle: 1 Static / 1 Dynamic
** Bicycle: 1 Static / 1 Dynamic
** Pedestrian: 1 Static / 1 Dynamic
** Lane Count: 6
** Actor: Pedestrian
** Scenario Total: 1
* Baseline Scenario:
** Expected SDV Speed: 40 mph (17.88 m/s)
** SDV Start Position:
*** Right Travel Lane (second lane from the right)
*** 60 m before the intersection on N Scottsdale Rd.
*** Heading northbound
** End Position: 50 m after the intersection
** Actor Starting Position:
*** 0 m at the crosswalk on N Scottsdale
*** Front Right Near side of the intersection
** End Position:
*** 2 m on the other side of the intersection
*** Crossing N Scottsdale
*** Moving from Front Right Near to Front Left Near, ~35 m
** Actor Speed: 1.2 m/s
** Trigger Points:
*** Pedestrian OverlapAction Trigger_BP
*** 40 m before the intersection
** Trigger Variation Extent: N/A
* Expected Termination Condition(s):
** No Progress Timeout
* Metrics:
** Simulation_standard_test
Additional information::
* Composite/OD Tags
* Infrastructure
* Composite Tags
==== Use Case Example 7: Replay Observed Traffic Situation
Summary::
A traffic camera observes certain traffic situations. This measured data will be transformed into OpenSCENARIO2.0. At the end a OpenSCENARIO2.0 file will contain the concrete scenario description. This example shall be representative for all measured data, no matter if recorded by a drone, from within a car, during test track runs or simulation runs or real world traffic.
Applicable user story(s)::
I1, I2, I3
Covered abstraction levels::
Concrete
Description::
A highway section is observed from the bird perspective. In one period of observation a cut-in maneuver is observed and this traffic situation shall be converted into a concrete scenario description.
Example scenario::
Following section of highway is observed.
image:usecase_7.png[align=center]
Data from following measurements channels is available:
[cols="2,5,1",options="header",frame=topbot,grid=rows]
|===
|*Name* |*Description* |*Unit*
|frame |The current frame. |[-]
|id |The track's id. |[-]
|x |The x position of the upper left corner of the vehicle's bounding box. |[m]
|y |The y position of the upper left corner of the vehicle's bounding box. |[m]
|width |The width of the bounding box of the vehicle. |[m]
|height |The height of the bounding box of the vehicle. |[m]
|xVelocity |The longitudinal velocity in the image coordinate system. |[m/s]
|yVelocity |The lateral velocity in the image coordinate system. |[m/s]
|xAcceleration |The longitudinal acceleration in the image coordinate system. |[m/s]
|yAcceleration |The lateral acceleration in the image coordinate system |[m/s]
|frontSightDistance |The distance to the end of the recorded highway section in driving direction from the vehicle's center. |[m]
|backSightDistance |The distance to the end of the recorded highway section in the opposite driving direction from the vehicle's center. |[m]
|dhw |The Distance Headway. This value is set to 0, if no preceding vehicle exists. |[m]
|thw |The Time Headway. This value is set to 0, if no preceding vehicle exists. |[s]
|ttc |The Time-to-Collision. This value is set to 0, if no preceding vehicle or valid TTC exists. |[s]
|precedingXVelocity |The longitudinal velocity of the preceding in the image coordinate system. This value is set to 0, if no preceding vehicle exists. |[-]
|precedingId |The id of the preceding vehicle in the same lane. This value is set to 0, if no preceding vehicle exists. |[-]
|followingId |The id of the following vehicle in the same lane. This value is set to 0, if no following vehicle exists. |[-]
|leftPrecedingId |The id of the preceding vehicle on the adjacent lane on the left in the direction of travel. This value is set to 0, if no such a vehicle exists. |[-]
|leftAlongsideId |The id of the adjacent vehicle on the adjacent lane on the left in the direction of travel. In order for a vehicle to be adjacent and not e.g. preceding, the vehicles must overlap in the longitudinal direction. This value is set to 0, if no such a vehicle exists. |[-]
|leftFollowingId |The id of the following vehicle on the adjacent lane on the left in the direction of travel. This value is set to 0, if no such a vehicle exists. |[-]
|rightPrecedingId |The id of the preceding vehicle on the adjacent lane on the right in the direction of travel. This value is set to 0, if no such a vehicle exists. |[-]
|rightAlsongsideId |The id of the adjacent vehicle on the adjacent lane on the right in the direction of travel. In order for a vehicle to be adjacent and not e.g. preceding, the vehicles must overlap in the longitudinal direction. This value is set to 0, if no such a vehicle exists. |[-]
|rightFollowingId |The id of the following vehicle on the adjacent lane on the right in the direction of travel. This value is set to 0, if no such a vehicle exists. |[-]
|laneId |The IDs start at 1 and are assigned in ascending order. Since the Lane ids are derived from the positions of the lane markings, the first and last ids typically do not describe any useable lanes. For details, see the definition of the coordinate system. |[-]
|===
A compiler transforms the measured data into a scenario file. This example comes from the highD Dataset. Other data sources might have slightly different measurement procedures. This is just one example for the use case and should be representative for all measured data that needs to be transformed into OpenSCENARIO2.0.
==== Use Case Example 8: Scenario definition for entering a roundabout
Summary::
A left turn at a roundabout should be described as a scenario
Applicable user story(s)::
D1
Covered abstraction levels::
Concrete
Description::
image:usecase_7b.png[align=center,pdfwidth=10cm]
*Textual scenario description:*
[source,msdl]
----
scenario Scenario014:
set_map("MFM_map.xodr")
ego: car
keep(ego.color == green)
keep(ego.category == sedan)
car1: car
keep(car1.category == sedan)
p: path
path_type(p, roundabout)
path_min_lanes(p, 2)
path_min_arms(p, 4)
set_weather: weather(kind: nice, temperature: 20c)
do parallel:
get_ahead_ego: ego.drive(p) with:
speed(0mph, at: start)
lane(1, in: segment1, at: start)
lane(1, in: segment2, at: end)
get_ahead_car1: car1.drive(p) with:
speed(30mph, at: start)
lane(-2, in: segment5, at: start)
lane(1, in: segment2, at: end)
----
==== Use Case Example 9: High-level/low-level description of a motorcycle cut-in
Summary::
The motorcycle cut-in as an example for high-level and low-level description
Applicable user story(s)::
D6
Covered abstraction levels::
Abstract - Concrete
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[]
ifndef::backend-pdf[]
[cols="a,a"]
|===
|
endif::[]
.Abstract
[source,msdl]
----
MotCyc: Motorcycle
PCar: PassengerCar
do serial():
parallel:
PCar.drive with:
direction(straight)
MotCyc.drive with:
speed(faster_than: PCar)
get_ahead: serial:
left: MotCyc.drive with:
direction(straight)
lane(left_of: PCar, at: start)
position(behind: PCar,
at: start)
position(front: PCar, at: end)
right: MotCyc.drive with:
direction(right, at: start)
direction(straight, at: end)
lane(same_as: PCar, at: end)
parallel:
MotCyc.drive with:
speed(faster_than: PCar)
direction(straight)
crash_and_stop: serial:
brake: PCar.applyBrake with:
direction(right)
stop: PCar.drive with:
speed(0)
----
ifndef::backend-pdf[]
|
endif::[]
.Concrete
[source,msdl]
----
MotCyc: Motorcycle
PCar: PassengerCar
do serial():
parallel:
PCar.drive with:
speed(50kph)
direction(straight)
lane(0)
MotCyc.drive with:
speed(80kph)
get_ahead: serial:
left: MotCyc.drive with:
direction(straight)
lane(1)
position(20m, behind: PCar,
at: start)
position(2m, front: PCar, at: end)
right: MotCyc.drive with:
direction(30degrees, at: start)
direction(straight, at: end)
lane(same_as: PCar, at: end)
parallel:
MotCyc.drive with:
speed(80kph)
direction(straight)
crash_and_stop: serial:
brake: PCar.applyBrake with:
direction(45degrees)
stop: PCar.drive with:
speed(0)
----
ifndef::backend-pdf[]
|===
endif::[]
==== Use Case Example 10: Scenario usage for SOTIF
Summary::
The process of SOTIF (Safety of the Intended Functionality) according to ISO 21448 requires identification of hazards and their causal analysis in order to relate them to limitations, weaknesses and disturbance susceptibilities of the AV system in their combination with Triggering Conditions. Unlike for traditional Functional Safety according to ISO 26262, this can often no longer be achieved by a safety analyst alone, as the scenario are getting much more complex and the behavior of the AV function is much less predictable by humans than traditional component failures that have been considered for Functional Safety. Therefore, the safety analyst might want to submit simulation request to the simulation specialists, attaching descriptions of abstract scenarios (scenario stubs) in OpenSCENARIO2.0. Additionally, he will have to specify monitoring conditions that denote the hazardous situations he is interested in. In order to create runnable scenarios for simulation, a scenario generator will have to fill up the abstract scenarios with more details and objects, and choose parameter values for the parameters that are unspecified or only specified in terms of value ranges in the abstract scenarios, thereby transforming them into concrete scenarios, again expressed in OpenSCENARIO2.0.
Applicable user story(s)::
B3, C1, E1
Covered abstraction levels::
Abstract
Description::
The safety analyst uses established techniques (see ISO 21448, ISO 26262) to find out hazards of the automated vehicle, e.g. sudden unjustified braking or hitting another vehicle. After that, he uses techniques like (modified) Fault Tree Analysis (FTA) or System Theoretic Process Analysis (STPA) to find out about the causes. Of particular interest in the context of SOTIF are the causes that are not failures or defects, but limitations of the nominal performance of the system or lack of fitness for its purpose. For instance, too restricted contrast resolution of a camera, in combination with dark color of a target vehicle and poor light conditions, can lead to a late or weak detection of the target vehicle, which results in not qualifying the vehicle fast enough to brake on time – the end result could be a rear-and crash into that vehicle. Often, the analyst finds out what could go wrong in the worst case, but cannot decide if the scenario is really a hazardous one, and under which parameters and side conditions (e.g. How dark must it be to overlook the vehicle? Which colors of the target vehicle are rather safe or rather critical? What initial distance and speed difference?).
+
Simulation can help to find this out but given the number of relevant details and the number of such potentially critical scenarios to evaluate, a pure table based or natural-language interface between safety analyst and simulation expert will not be an acceptable solution. OpenSCENARIO2.0 can close the gap. The ability to specify abstract/functional scenarios, specifying only the details and objects that are relevant (see ISO 21448 CD, Clause 7.3 for examples) and only ranges for parameters (e.g. 80 .. 100 km/h), allows the safety analyst to concentrate on his core activities instead of forcing him to become a simulation professional. The missing details are manually or automatically added by a scenario generator, ensuring a sufficient level of feature and parameter range coverage according to pre-defined criteria. One abstract scenario (scenario stub) can be translated into hundreds, if not thousands of executable concrete scenarios in OpenSCENARIO2.0, which form the set of representative samples for the problem to be evaluated. If (a prototype of) the actual control software and sensor equipment of the future automated vehicle is already available, the simulation can be performed as closed-loop simulation (Model-in-the-Loop or Hardware-in-the-Loop), to include the appropriateness of the realistic vehicle response to the Triggering Condition in the observation (see ISO 21448 CD, Clause 7.4).
+
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]