Commit 56181f33 authored by Jakob Kaths's avatar Jakob Kaths
Browse files

Mostly language refinements

parent 1e85cc6a
...@@ -30,7 +30,7 @@ The technical content description shall be understandable for readers with an en ...@@ -30,7 +30,7 @@ The technical content description shall be understandable for readers with an en
[NOTE] [NOTE]
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. 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. 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.
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. 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.
...@@ -39,9 +39,9 @@ Car manufacturers for example will work with multiple different suppliers and wo ...@@ -39,9 +39,9 @@ Car manufacturers for example will work with multiple different suppliers and wo
[[feature_sets_image]] [[feature_sets_image]]
image:../images/featureSets.png["Feature Sets Proposal"] 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. 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.
Additionally the planned migration path from the already published https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard] has to be considered. Additionally, the planned migration path from the already published https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard] has to be considered.
==== Domain Model ==== Domain Model
...@@ -49,16 +49,16 @@ Additionally the planned migration path from the already published https://www.a ...@@ -49,16 +49,16 @@ Additionally the planned migration path from the already published https://www.a
[NOTE] [NOTE]
Responsibles for filling this sub-chapter: J. Tscheak (maybe), M. Kluge, J.Kaths, F. Bock (maybe), S. Rosenberg (maybe) Responsibles for filling this sub-chapter: J. Tscheak (maybe), M. Kluge, J.Kaths, F. Bock (maybe), S. Rosenberg (maybe)
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 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:
*WP_DM1_Transfer1x* *WP_DM1_Transfer1x*
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. 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.
[NOTE] [NOTE]
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 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)
*WP_DM2_Extend2x* *WP_DM2_Extend2x*
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. 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) Responsibles for filling this sub-chapter: S. Rosenberg, H. Bothe (maybe)
......
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