Commit 01c84d88 authored by Benjamin Engel's avatar Benjamin Engel
Browse files

Add 2.1.2 Extensibility and

2.3.3 scenario based testing workflow
by S.Rosenberg
parent b0fc302a
...@@ -75,13 +75,24 @@ Identify entities and their actions / methods that are introduced by high-level ...@@ -75,13 +75,24 @@ Identify entities and their actions / methods that are introduced by high-level
The need to extend the domain model of OSC 1.0 has been identified in the initiation phase of OSC 2.0. The model draft of the OSC 2.0 concept project provides an initial draft for such an extension. During the development of OSC 2.0, it needs to be refined and extended, as the result of the concept project focused on "most important properties, attributes, possible actions and interrelations.". New entities, their actions and attributes have to defined, for example to cover high-level scenario descriptions, which will be introduced in OpenSCENARIO 2.0. All different use cases for the scenario definition and contents from the 1.0 domain model have to be properly integrated in the final model for 2.0. As experienced in the OSC 2.0 concept project, a close working-level interaction and interrelation with the language group is essential for the success of this work package. This needs to be established already in the beginning of the project. The need to extend the domain model of OSC 1.0 has been identified in the initiation phase of OSC 2.0. The model draft of the OSC 2.0 concept project provides an initial draft for such an extension. During the development of OSC 2.0, it needs to be refined and extended, as the result of the concept project focused on "most important properties, attributes, possible actions and interrelations.". New entities, their actions and attributes have to defined, for example to cover high-level scenario descriptions, which will be introduced in OpenSCENARIO 2.0. All different use cases for the scenario definition and contents from the 1.0 domain model have to be properly integrated in the final model for 2.0. As experienced in the OSC 2.0 concept project, a close working-level interaction and interrelation with the language group is essential for the success of this work package. This needs to be established already in the beginning of the project.
===== Extensibility ===== Extensibility
Responsibles for filling this sub-chapter: S. Rosenberg, H. Bothe (maybe) A standard domain model allows users to:
WP DM-Extensibility - Develop technical concept for extensibility of Domain Model
* check with OTX where there are working groups for extensions (more firm extensions in line with Michael's (dSPACE) proposal) * leverage a well-architect model and attributes for productivity
* feature sets may add parts to the domain model * Facilitate scenario reuse across teams without upfront planning
* "quick" extensions by (even single) users need to be possible as well
* possibly introduce mandatory / optional At the same time, various users may have extensions that are not common or generic enough to be part of the standard. This section would discuss how the OpenSCENARIO2.0 allows user to extend the standard model to meet their project specific needs.
* align with WP modules, libraries, etc.
User may want to:
* Add an attribute to a standard actor, action or struct
* Add a user defined actor
* Add a user-defined action to a standard actor
* Add other needed entities
On top of addition extensions, user may want to ignore parts of the domain model which are not relevant may not be interesting for his ODD or project needs.
Later, these new extensions be efficiently leveraged for automated user-defined scenarios.
===== Ontology ===== Ontology
Responsibles for filling this sub-chapter: F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe) Responsibles for filling this sub-chapter: F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe)
...@@ -223,7 +234,18 @@ The created workflow should include all lifetime phases for a scenario, from pre ...@@ -223,7 +234,18 @@ The created workflow should include all lifetime phases for a scenario, from pre
As an illustration of the concept, e.g., the creation of a scenario can be done by using different methods, from manual writing, over tool-assisted (either textual or graphical) creation to extraction or generation out of a predefined data pool. All those ways should be covered within the defined process. As an illustration of the concept, e.g., the creation of a scenario can be done by using different methods, from manual writing, over tool-assisted (either textual or graphical) creation to extraction or generation out of a predefined data pool. All those ways should be covered within the defined process.
===== Scenario based testing workflow ===== Scenario based testing workflow
Responsible: Sharon Rosenberg
OpenSCENARIO 2.0 allows building modular, encapsulated, reusable scenarios that can be ported to different testing platforms. This section will describe the basic flow to construct a test, which contains all the elements and ingredients required for a testing platform, Ingredients like road topology, scenery. Road surface, driver and traffic models and more.
This section will describe how scenarios can be mixed and combined to construct a test. Interaction with usage restriction and guidelines will be presented.
For specific platforms, the user will need to provide context and implementation details to enable its execution. For example, in simulation the user may provide for a reusable scenario:
* A map to be executed on with specific location details
* Desired ODD restrictions
Various topics related to combining scenarios into meaningful tests will be discussed in this section.
===== Test definition ===== Test definition
......
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