Merge branch '2-initial-version-of-entity-definition-wps' into 'master'

Resolve "Initial version of entity definition WPs"

Closes #2

See merge request !7

subchapters/2_technical-content.adoc

@@ -31,22 +31,48 @@ Provide a detailed description, how the identified usecases, features or issues
 
 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.
 
+==== Portability
+[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.
+
+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. 
+
+*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. 
+
+[[feature_sets_image]]
+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 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.
+
 ==== Domain Model
 
+ OSC lies within the domain of closed-loop system testing for automotive functions. The Domain Model introduces domain-specific content to the otherwise generic Language Concept of OSC 2.0. The domain model provides the semantics, whereas the Language Concept delivers the syntax. Therefore, the Domain Model enables the preservation of semantics when scenario definitions are exchanged between different tools.
+
+ The <<Entity Definition>> builds the core of the Domain Model. This definition should cover all objects that are necessary to describe a wide range of relevant scenarios. The definitions of the identified entities should be unambiguous and should include the main properties and possible actions of each entity. The development of the entity definition will follow two tracks. First, the existing domain model of OSC 1.0 needs to be analyzed and transferred to OSC 2.0 to ensure compatibility between the two versions of the standard. Second, the already identified gaps in OSC 1.0 need to be closed by extending the Domain Model.
+
+ It will neither be possible nor meaningful to try to attempt to cover all possible scenarios and simulators with the entity definition of OSC 2.0. Therefore, a technical concept on a standard-conform <<Extensibility>> of the Domain Model needs to be developed.
+
+ Another pillar of the Domain Model is the definition of the relationships between the entities with predicate logic. Such an <<Ontology>> will support an unambiguous formulation and categorization of scenarios as it enables inferrment with natural language.
+
+
 ===== Entity Definition 
+[NOTE]
 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)
+
+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*
+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]
+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*
+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 
 Responsibles for filling this sub-chapter: S. Rosenberg, H. Bothe (maybe)

subchapters/3-1_required_resources.adoc

@@ -12,7 +12,8 @@ A breakdown of the project into individual work packages and the corresponding e
 | *Responsibles* | M. Büker, R. Heidtman, Y. Hollander, H. Hungar
 |*Title / Description* | Temporal aspects of the OpenSCENARIO 2.0 language and its execution
 |*Deliverable*	| Full description of the temporal aspects of the language, including formal model if any
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP LC-Syntax
@@ -22,7 +23,8 @@ A breakdown of the project into individual work packages and the corresponding e
 | *Responsibles* | Y. Hollander, R. Heidtman
 |*Title / Description* | Syntax definition of the OpenSCENARIO 2.0 language
 |*Deliverable*	| Full syntax definition, including grammar, of the OpenSCENARIO 2.0 language.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP LC-CompoundTypes
@@ -32,7 +34,8 @@ A breakdown of the project into individual work packages and the corresponding e
 | *Responsibles* | Y. Hollander
 |*Title / Description* | Compound types for OpenSCENARIO 2.0
 |*Deliverable*	| Semantic description of the definition, inheritance and extensiblity mechanisms for all compound data types of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the compound data types.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP LC-BasicTypes
@@ -42,7 +45,8 @@ A breakdown of the project into individual work packages and the corresponding e
 | *Responsibles* | Y. Hollander
 |*Title / Description* | Basic data types for OpenSCENARIO 2.0
 |*Deliverable*	| Semantic description of the definition of all basic, i.e. non-compound data types of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the basic data types.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP LC-Expressions
@@ -52,7 +56,8 @@ A breakdown of the project into individual work packages and the corresponding e
 | *Responsibles* | P. Mai, J. Krasser
 |*Title / Description* | Expression language for OpenSCENARIO 2.0
 |*Deliverable*	| Full semantic description of the expression language of the OpenSCENARIO 2.0 language.  Input for LC-Syntax on syntax aspects of the expression language.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP LC-Semantics
@@ -73,7 +78,8 @@ As the levels of abstraction have been raised, so the effort and understanding n
 | *Responsibles* | P. Mai, Y. Hollander
 |*Title / Description* | Libraries, Modules, Packaging and Namespace aspects of OpenSCENARIO 2.0
 |*Deliverable*	|Full semantic description of the library, modules, packaging and namespace aspects of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the libraries, modules, packaging and namespaces aspects.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP LC-Transfer1x
@@ -83,7 +89,19 @@ As the levels of abstraction have been raised, so the effort and understanding n
 | *Responsibles* | Y. Hollander, J. Krasser
 |*Title / Description* | Additional features in OpenSCENARIO 2.0 to support OpenSCENARIO 1.0/1.x features not otherwise part of 2.0
 |*Deliverable*	| Semantic extensions to the OpenSCENARIO 2.0 language to support specific 1.0/1.x concepts not otherwise supported.  Input for LC-Syntax on syntax aspects of these extensions.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	|Estimated work effort to complete this WP.
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
+|===
+
+.WP DM-AbstractionRoads
+[cols="1,2"]
+|===
+| *WP Number* | DM-AbstractionRoads
+| *Responsibles* | M. Kluge, J.Kaths
+|*Title / Description* | Create road network domain model based on concept project proposal.
+|*Deliverable*	| A road network UML domain model, which provides an intuitive way of addressing elements in the network. This for example will be used to define conditions in the behavior definition, e.g. "turn right at the second 4-way junction". An ID based access with detailed knowledge of the road network content must also be possible. The abstract road network domain model should allow the usage of different map sources like OpenDRIVE in OpenSCENARIO 1.0 or HD maps.
+| *Effort (Man-days)*	| 30
+| *Service Provider*	| Finalization of the UML model draft (10%).
 |===
 
 .WP DM-Transfer1x
@@ -93,49 +111,43 @@ As the levels of abstraction have been raised, so the effort and understanding n
 | *Responsibles* | J. Tscheak (maybe), M. Kluge, J.Kaths
 |*Title / Description* | Rework Entity Definition from Concept project with regard to OSC 1.0
 |*Deliverable*	| Consolidated entity definition that covers existing features of OSC 1.0 and deviates only when necessity is clearly identified and reasoned. Needs to be finished before WP DM-Extend2x.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	| 30
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP DM-Extend2x
 [cols="1,2"]
 |===
 | *WP Number* | DM-Extend2x
-| *Responsibles* | Michael Kluge, Jakob Kaths, F. Bock (maybe), S. Rosenberg (maybe)
-|*Title / Description* | Extend Entity Definition from Concept project and from WP DM-Transfer1x towards OSC 2.0
-|*Deliverable*	| Entity definition that extends the ones from Concept Project and from WP DM-Transfer1x with high-level scenario descriptions (e.g. drive()) and missing features (e.g. road).
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Responsibles* | J. Kaths, M. Kluge
+|*Title / Description* | Extend Entity Definition from Concept project and other working packages towards OSC 2.0
+|*Deliverable*	| UML entity definition that extends the ones from OSC 2.0 Concept Project and from work package DM-Transfer1x with high level scenario descriptions (e.g. drive()) and other missing features. It will also incorporate the road model developed in work package DM-AbstractionRoads. The result is the full entity definition for OSC 2.0. Similar to the separation of DM-AbstractionRoads, this work package is likely to be split into further work packages as the project progresses.
+| *Effort (Man-days)*	| 40
+| *Service Provider*	| Finalization of the UML model draft (10%).
 |===
 
 .WP DM-Extensibility
 [cols="1,2"]
 |===
 | *WP Number* | DM-Extensibility
-| *Responsibles* | S. Rosenberg, H. Bothe (maybe)
+| *Responsibles* | S. Rosenberg
 |*Title / Description* | Develop technical concept for extensibility of Domain Model
 |*Deliverable*	| Technical concept to enable standard-conform extensions of the Domain Model. This should cover special features that can be introduced by single users, but may be extended towards bigger feature sets that a whole user-group agrees upon. 
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	| 40
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
 .WP DM-Ontology
 [cols="1,2"]
 |===
 | *WP Number* | DM-Ontology
-| *Responsibles* | F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe)
+| *Responsibles* | S. Kraines, F. Sanchez, I. Whiteside, P. Parekh
 |*Title / Description* | Develop ontology to establish relations between entities
 |*Deliverable*	| Extension of the entity definition delivered by WP DM-Extend2x with an ontology that describes relations between the entities to enable inferrment. 
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
+| *Effort (Man-days)*	| 60
+| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
-...
-
-.WP XX
-[cols="1,2"]
-|===
-| *WP Number* | A unique number by which to identify the WP
-|*Title / Description* |	Provide a brief description of the task to be performed or give a descriptive title.
-|*Deliverable*	|List of deliverables, including intermediate results of this task.
-| *Effort (Man-days)*	|Estimated work effort to be performed by the service provider.
-|===
 
 .Total effort
 [options="header", cols="1,2,2,2"]