2_technical-content.adoc 9 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 33 34 35 36 37 38 39 40 41 42 43 44 45
==== 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.

The definition of a new standard/language OpenSCENARIO 2.0 should aim for a widest possible acceptance in its domain. This is true for every standard, but might be even hard to achieve because of the special circumstances. The support of the wide set of use cases and requeriments will result in an extremly capable language. This will allow the language to be used in many different projects, but comes with the trade off of limited portability/exchangeability. It will be very hard for players in simulation domain to state "We support OpenSCENARIO 2.0" as this support will very likely be limited to some parts of the language. 

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"]

The __feature sets__ proposed in picture <<feature_sets_image>> might be an option for a segmentation of the standard to achieve optional 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 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.

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)
51 52 53 54 55 56 57 58 59 60 61

The definition of the domain model specific entities is essential as those build the core of new language. A full support of the https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard], which has already been published 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:

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. That initial version 1.0 already contains multiple domain model entities though, for whom possible deviations to the new model have to be identified. Fore 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.

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)

The existing model draft has 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 might 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 development of the 2.0 concept paper, a close working-level interaction and interrelation with the language group is essential for the success of this work package. This should 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)