2_technical-content.adoc 9.84 KB
Newer Older
Benjamin Engel's avatar
Benjamin Engel committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Based on the considerations of the concept group, OpenSCENARIO 2.0 is proposed to be founded on the concept of a domain-specific language (see Methodology and Language Concepts chapters in the concept document), that should support all levels of scenario description, from the very abstract to the very concrete in a suitable way.

The OpenSCENARIO 2.0 concepts take proven features and capabilities of OpenSCENARIO 1.0, like its event-based scenario execution model, and place them in a more general and expressive language framework, to serve as the foundation for both incremental improvements and more revolutionary enhancements.

In comparison to OpenSCENARIO 1.0, a more detailed set of actions and attributes for the relevant simulation models shall be defined to allow for a more comprehensive scenario description and to improve exchangeability. This is addressed by the introduction of a domain model (see Concept document chapter: Architecture).

Beyond such improvements, the proposed domain-specific language supports the creation of more complex scenarios through flexible composition and parametrization of component scenarios in ways that allow realistic, emergent behavior to occur. This is expected to enable massive testing and verification of new, complex hardware and software systems, and their interaction with the complex environment of driving.

The concept group believes that the proposed concepts and direction will enable OpenSCENARIO 2.0 to supply a step-function in its ability to describe full, complex simulations and/or tests, addressing all the required elements, and utilizing existing building blocks (like OpenDRIVE or OpenCRG).

As stated above, the foundational concept of OpenSCENARIO 2.0 is to establish a domain specific language of a declarative nature. A declarative language describes what should happen on scenario execution (including the required parameterization/variation), rather than how to do it. A declarative language can also have a _dual interpretation_, i.e. provide a single scenario description which can be used to describe both how to make it and how to monitor that it _indeed_ happened. This is important if we want to condition some operation on the fact that some other scenario has happened before, without having to describe in detail _how_ to cause that scenario.


The Concept document is using M-SDL language to demonstrate all the concept. It is expected to examine if this language can serve as the foundation of the standards.

Provide a detailed description, how the identified usecases, features or issues (as per preceding chapter) shall be solved or implemented through the proposed project. Descriptions shall include, if applicable:

* Components of a system, which shall be standardized
* Features or functionality of the standardized components
* Method of standardization
* Potentially donated IP from member companies
* Toplevel requirements to be considered for developing the standard
* Statements about backwardcompatibility towards earlier versions of the standard
* Improvements & benefits of the changes as compared to earlier releases of the standard
* Assumptions

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
The technical content description shall be understandable for readers with an engineering background, but with no specific domainexpertise. Consequently, a brief technical introduction may be needed.

==== Domain Model

===== Entity Definition 
Responsibles for filling this sub-chapter: J. Tscheak (maybe), M. Kluge, J.Kaths, F. Bock (maybe), S. Rosenberg (maybe)
WP DM-Transfer1x - Rework Entity Definition from Concept project with regard to OSC 1.0
overhaul entity definition with regard to OSC 1.0 (maybe Jupp Tscheak, Michael, Jakob)
    * identify deviations
    * clarify if deviations are necessary or should
    * clarify naming / terminology
    * create a mapping where necessary

WP DM-Extend2x - Extend Entity Definition from Concept project and from WP DM-Transfer1x towards OSC 2.0
identify entities and their actions / methods that are introduced by high-level description of OSC 2.0 (so not part of OSC 1.0) (maybe Florian Bock, Michael Kluge, Jakob Kaths, maybe Sharon Rosenberg)
    * identify new entities, their actions and attributes that are necessary to cover high-level scenario descriptions in OSC 2.0 (e.g. Road, drive(), etc.)
    * integrate them properly in Domain Model
    * close interrelation on working-level with language group (was a lack during concept phase)

===== Extensibility 
Responsibles for filling this sub-chapter: S. Rosenberg, H. Bothe (maybe)
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)
    * feature sets may add parts to the domain model
    * "quick" extensions by (even single) users need to be possible as well
    * possibly introduce mandatory / optional
    * align with WP modules, libraries, etc.

===== Ontology
Responsibles for filling this sub-chapter: F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe)
WP DM-Ontology - Develop ontology to establish relations between entities
    * synchronize with global ontology developed by ASAM
    * what are the technical artifacts that come out of the ontology development
    * Fran (FiveAI) can contribute, FiveAI developed own ontology for scenario description
    * Iain Whiteside (FiveAI) can provide a presentation on practical usage of their ontology
    * UK has developed a standard (or a PAS really) called 1883 for a driving ontology (Siddhartha could help here)
    * possible input as well from Steven and Florian Bock (Audi)
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117




==== Usage and Pragmatics
Responsible: Florian Bock

This section includes different topics about the usage of scenarios and the corresponding workflows.

The content of a scenario can be modified in different ways: Data can be altered, data can be added or removed. The latter two are important regarding the different abstraction levels. Whereas functional scenarios are quite abstract and therefore do not included very much details about the objects and subjects, concrete scenarios that can be used for simulation naturally have to include a tremendous amount of details to allow that. To get from one abstraction level to the other, two ways are common: Concretization (adding more details) and abstraction (removing details). 

One important point, that has to be discussed within the project is the linkage or respectively the interfacing to previous OpenSCENARIO version (0.x and 1.x). At least a migration plan to convert artifacts from previous version should be available to amplify the usage and prominence of OSC 2.0. 

To create, use and maintain scenarios, a corresponding process or workflow has to be defined in order to guide the user. This workflow should cover all use cases defined in the use case section.

This is also true for a proper testing workflow, that should describe the interaction between requirements, scenarios and test cases within the development.


===== Abstraction, Concretization of Scenarios
Responsible: ?

====== Scenario summary to functional Scenario (i.e. Rules of Abstraction)
Responsible: ?

====== Functional Scenario to concrete scenario (i.e. Rules of Concretization)
Responsible: ?

====== Interfacing with concrete scenarios from OSC 1.x
Responsible: Sandeep P.

===== 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.

The goal of defining one single workflow for the creation and usage of scenarios seems ambitious and possibly unachievable. To cover all defined use cases, this would result in a very complex process, that would be hardly usable. Nevertheless, the goal should be to cover as much use cases as possible. To do so, an iterative approach for the application within the OSC 2.0 standardization project seems reasonable. 

This implies several steps:
- A review of the already defined use cases should be done to identify missing use cases, improve the description and the differentiation among themselves and finalize the list
- Representatives for each use case should be determined to deliver insight in the background and the underlying assumptions
- Each representative should write down his or her workflow/definition in a similar way (e.g., by using the same type of diagram or template)
- Each worfklow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements
- All workflows should be checked for duplicates (either in whole or in parts)
- All workflows should be split into atomic parts that can be separated
- A generic workflow should be created/designed based on the separated atomic parts
- Each covered use case should be documented within the workflow
- Uncovered use cases should be documented with ideas, how to proceed with them

The created workflow should include all lifetime phases for a scenario, from prerequesites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed.

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
Responsible: Sharon Rosenberg