2_technical-content.adoc 9.15 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
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.

29 30 31 32
==== Portability
Based on the presentation by Michael Kluge (dSPACE) from https://www.asam.net/conferences-events/detail/asam-openscenario-v20/[ASAM OpenSCENARIO V2.0 - Proposal Workshop, Topic 6]. Please move chapter to suitable location if necessary.

Jakob Kaths's avatar
Jakob Kaths committed
The definition of a new standard OpenSCENARIO 2.0 should aim for a widest possible acceptance in its domain. This holds true for every standard, but might be hard to achieve given the wide set of use cases and requirements. These will result in an extremely capable language. This, in return, will allow the language to be used in numerous projects, but comes with the trade off of limited portability and exchangeability. It will be hard or even infeasible for tool providers to guarantee a support of OpenSCENARIO 2.0 as this support will very likely be limited to parts of the language. 
34 35 36 37 38 39 40 41

Car manufacturers for example will work with multiple different suppliers and would like to use OpenSCENARIO 2.0 as one of the exchange formats. The selection of those suppliers relies on their credible statement on how they support the standard e.g. in their simulation environment. 

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

image:../images/featureSets.png["Feature Sets Proposal"]

Jakob Kaths's avatar
Jakob Kaths committed
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.

Jakob Kaths's avatar
Jakob Kaths committed
Additionally, the planned migration path from the already published https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard] has to be considered.

46 47 48
==== Domain Model

===== Entity Definition 
Responsibles for filling this sub-chapter: J. Tscheak (maybe), M. Kluge, J.Kaths, F. Bock (maybe), S. Rosenberg (maybe)

Jakob Kaths's avatar
Jakob Kaths committed
The definition of the domain model specific entities is essential as they build the vocabulary of the new language. A full support of the https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard], which has already been released by ASAM, is one major requirement for OpenSCENARIO 2.0. This includes a full migration path from the 1.x versions to the language to be developed in this project, which directly leads to the first work packages for  the domain model group:
53 54

Jakob Kaths's avatar
Jakob Kaths committed
The domain model, that has been defined in the https://www.asam.net/index.php?eID=dumpFile&t=f&f=3460&token=14e7c7fab9c9b75118bb4939c725738fa0521fe9[OpenSCENARIO 2.0 Concept Project], did not focus on the compatibility to OpenSCENARIO 1.0. However, OpenSCENARIO 1.0 already contains multiple domain model entities, for which possible deviations to the new model have to be identified. For each of those deviations it has to be defined how they should be handled in order to achieve compatibility. Inconsistent naming and terminology has to be resolved or, if this is not feasible, a mapping between entities in both models has to be defined. All entities in the 1.0 model must have a counterpart in 2.0.
56 57 58 59 60

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)

Jakob Kaths's avatar
Jakob Kaths committed
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.
62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

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