Commit db160b1e authored by Ben Engel's avatar Ben Engel

Formatting fixes (blank lines, spell check)

parent ab3c5b69
Pipeline #1448 passed with stage
in 14 seconds
......@@ -2,4 +2,4 @@
=== Motivation
The OpenSCENARIO Concept Project (P2019-02), was initiated in parallel to the transfer project of the OpenSCENARIO standard to the ASAM domain. The goal of this transfer project (P2019-01) was a revision of OpenSCENARIO to ensure adherence to the ASAM standard format, leading to a major version release of v1.0.
The purpose of the Concept Project was thus to address features and adaptations to be implemented in future versions of the OpenSCENARIO standard. The concept project summary was delivered to ASAM TSC – OSC 2.0 Concept Document. *This project proposal is aimed at taking the concepts specified in the concept document, and continue and develop the next generation of OpenSCENARIO standard – OpenSCENARIO 2.0*
The purpose of the Concept Project was thus to address features and adaptations to be implemented in future versions of the OpenSCENARIO standard. The concept project summary was delivered to ASAM TSC – OSC 2.0 Concept Document. *This project proposal is aimed at taking the concepts specified in the concept document and continue to develop the next generation of OpenSCENARIO standard – OpenSCENARIO 2.0*
......@@ -2,7 +2,7 @@
=== User Stories
[[a-share]]
==== A) SHARE
==== SHARE
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.
......@@ -11,7 +11,7 @@
5. As a researcher developing new technology, I can reutilize industry and open source scenarios to advance my research.
[[b-certify-analyse]]
==== B) CERTIFY & ANALYSE
==== CERTIFY & ANALYSE
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.
......@@ -20,7 +20,7 @@
5. As government agency, I can understand what parts of the Operational Domain are verified by an AV/ADAS developer through each scenario.
[[c-develop]]
==== C) DEVELOP
==== DEVELOP
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.
......@@ -30,7 +30,7 @@
6. As a system engineer working for an AV/ADAS developer, I can decompose high level use cases in a standardised way.
[[d-create]]
==== D) CREATE
==== CREATE
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, …).
......@@ -39,34 +39,34 @@
5. As a stakeholder, I can create natural language scenarios without having any knowledge about technical details.
[[e-sotif-based-risk-consideration]]
==== E) SOTIF-BASED RISK CONSIDERATION
==== SOTIF-BASED RISK CONSIDERATION
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.
[[f-driving-mission-based-scenarios]]
==== F) DRIVING MISSION-BASED SCENARIOS
==== DRIVING MISSION-BASED SCENARIOS
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.
[[g-traffic-model-inclusion]]
==== G) TRAFFIC MODEL INCLUSION
==== TRAFFIC MODEL INCLUSION
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.
[[h-execute]]
==== H) EXECUTE
==== EXECUTE
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.
[[i-describe-observations]]
==== I) DESCRIBE OBSERVATIONS
==== DESCRIBE OBSERVATIONS
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.
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 happened 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.
......@@ -107,7 +107,6 @@ Proposal workshop and revisions can be found in the workshop summary set of slid
|R005 |Allow Tool-Vendor Specific Extensions.
|R006 |Allow Definition of Feature Subsets
|R007 |Define Semantics to Enable Reproducibility and Single Interpretation. (Workshop phrasing was: Well Defined Semantics Requirement )
|*ID* |*Title/Description*
|R008 a|
Allow both Open-loop and Closed-loop Simulation by the Same Maneuver Descriptions. (Workshop phrasing: Maneuver Description Shall be Suitable for Open-loop and Closed-loop Simulation)
......@@ -128,4 +127,4 @@ For completeness – the following are explicit non requirements of the standard
4. Methods to specify Operational Design Domains (ODD).
5. OSC is not enforcing any standard API to simulators and testing platform, although such a standard might be desirable in future.
ASAM is addressing some of these goals through other activities, like OSI, OpenODD, and more.
\ No newline at end of file
ASAM is addressing some of these goals through other activities, like OSI, OpenODD and more.
\ No newline at end of file
......@@ -136,14 +136,9 @@ These data collection features may include coverage, tracing and recording of Ke
Language properties for grading and classifying collected information will be described. These include filtering values, grouping them into ranges (buckets), assigning minimal and maximal values, setting goals and so on.
The section will also describe language constructs for checking. These include assertions over Boolean and temporal properties, expressed using Boolean expressions and compound scenarios. Mechanisms for handling illegal values and assertion violations shall be provided, allowing the classification of errors (distinguishing between scenario failures, ego performance issues, ego failures and so on).
==== Siddartha's Paragraphs
Responsible: Siddartha Khastgir
=== Usage and Pragmatics
Responsible: Florian Bock
This section includes different topics about the usage of scenarios and the corresponding workflows.
......@@ -157,7 +152,6 @@ This is also true for a proper testing workflow, that should describe the intera
==== Abstraction, Concretization of Scenarios
Responsible: R. Heidtman
Abstraction Level definitions are needed to expand beyond OpenScenario 1.0 and distinguish between scenarios that are written for natural language, machine language or OpenScenario 2.0 DSL, which explains handing of undefined values as abstractions. Abstract scenarios are defined as a scenario that:
......@@ -171,14 +165,12 @@ A Concretization definition should define simple process steps. These steps sho
===== Scenario summary to functional Scenario (i.e. Rules of Abstraction)
Responsible: R. Heidtman
When considering a "Scenario Summary", define a best practice to create scenario summaries that that can be linked to ontology / taxonomy word choices. A Scenario summary is a paragraph of natural language that lends itself to an ontology that defines a scene in detail using a list all actors performing specified actions.
When considering a "Functional Scenario", also natural language, a definition would also lend itself to an ontology but is distinctly connected to specific ODD Categories, Behaviors and / or operational concepts. A list of specific relationships should be developed to defined to establish what distinguishes a "Functional Scenario" from a "Scenario Summary". A Functional Scenario may distinguish itself by how it influences the ODD test plan, functional test plan or design intentions.
===== Functional Scenario to concrete scenario (i.e. Rules of Concretization)
Responsible: R. Heidtman
The rules of concretion should be defined to ensure rational semantic definition for necessary rules that are needed to make an object realized, initialized and located in an environment and ensure that parameter values may be assigned to bring an activity, phase or scenario to a point where all modifiers may be made concrete using a single value for each. An abstract scenario needs a list of modifier rules to follow for concretion expression based on some list of suggestions. Activities would include: defining rules needed for concretion and how they might be expressed in a syntax for each example maneuver / scenario. These rules might be different for the first activity of an actor; this activity might require information for location: position, lane, RoadSegment (i.e. laneSection), distance and/or relationship to another object, etc.
......@@ -188,7 +180,6 @@ An example rule of concretion could be: a rule where every named parameter space
==== Creation of Scenarios & Scenario Workflow (from creation to maintenance of scenarios)
Responsible: Florian Bock
As already stated, scenarios are used throughout the development process with different levels of detail. The corresponding use cases (at least the ones that the concept project group could think of) were mentioned in Section X. Due to the fact, that each use case partially represents different people from different groups with different goals, constraints and circumstances, their intention of the usage of scenarios and their way of using them sometimes may, but often will divert.
......@@ -234,9 +225,12 @@ Various topics related to combining scenarios into meaningful tests will be disc
==== Test definition
How to test scenarios?
Clarification of boundaries test cases and scenarios
Outputs:
- Workflow guidelines (e.g. when integrated with a scenario vs. defined separately)
In this section we'll try to detail *how a scenario should be tested*.
......@@ -276,9 +270,9 @@ Car manufacturers for example will work with multiple different suppliers and wo
*The standardization project should enable partial support of the standard.* This on the one hand allows companies to step by step improve their compatibility to the standard and on the other hand enables proper selection of project partners.
[[feature_sets_image]]
.A Proposal for featuresets in OpenSCENARIO 2.0
.A Proposal for feature subsets in OpenSCENARIO 2.0
image::FeatureSets.png["Feature Sets Proposal"]
The __feature sets__ proposed in picture <<feature_sets_image>> might be an option for a segmentation of the standard to achieve partial support. It has still to be discussed how those __feature sets__ should be defined and how they can be integrated in the standard. If a separate working group will be defined to tackle those questions, a close interaction with at least the domain model, the use cases and the language working groups is highly advisable. The definition of a __core feature set__ might be helpful to define a basis all supporting parties commit to.
The __feature subsets__ proposed in picture <<feature_sets_image>> might be an option for a segmentation of the standard to achieve partial support. It has still to be discussed how those __feature subsets__ should be defined and how they can be integrated in the standard. If a separate working group will be defined to tackle those questions, a close interaction with at least the domain model, the use cases and the language working groups is highly advisable. The definition of a __core feature set__ might be helpful to define a basis all supporting parties commit to.
Additionally, the planned migration path from the already published https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard] has to be considered.
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