Merge branch 'submissions-by-email' into 'master'

Submissions by email

See merge request !17

images/usecases/usecase_1_lk.svg

+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1133 188"><defs><style>.cls-1{fill:#b3b3b3;}.cls-1,.cls-5,.cls-7{stroke:#000;}.cls-1,.cls-3,.cls-4,.cls-5,.cls-7{stroke-miterlimit:10;}.cls-2,.cls-3,.cls-4,.cls-7{fill:none;}.cls-3,.cls-4{stroke:#fff;}.cls-3,.cls-4,.cls-7{stroke-width:2px;}.cls-4{stroke-dasharray:12.04 12.04;}.cls-5{fill:#006da2;stroke-width:0.5px;}.cls-6{font-size:18.8px;fill:#fff;}.cls-6,.cls-8{font-family:Hack-Regular, Hack;}.cls-8{font-size:18px;}</style></defs><title>usecase_1_lk</title><g id="road"><rect class="cls-1" x="0.5" y="0.5" width="1132" height="187"/><path class="cls-2" d="M1133,187"/><path class="cls-2" d="M1,187"/><line class="cls-3" x1="1" y1="94" x2="7" y2="94"/><line class="cls-4" x1="19.04" y1="94" x2="1120.98" y2="94"/><line class="cls-3" x1="1127" y1="94" x2="1133" y2="94"/></g><g id="Layer_1" data-name="Layer 1"><path class="cls-2" d="M1026,352.52"/><path class="cls-2" d="M913.41,39.4"/><path id="path5362" class="cls-5" d="M955.51,71c1.31.06,2.18-1.2.55-4.11,12.87.23,25-.06,38.75.29,5.45.13,9.91-.53,16.39-.41,4.9-.25,12.94-.67,16.29-4.17,4.7-4.91,6.12-13.73,6.15-21.37h0v-.79h0c0-7.64-1.45-16.46-6.15-21.37-3.35-3.5-11.41-3.68-16.29-4.17-3.36-.34-10.94-.55-16.39-.41-13.78.35-25.88.06-38.75.29,1.63-2.92.76-4.18-.55-4.11a3.91,3.91,0,0,0-3.22,3.85c-4.4.1-7.42.26-12.73.27-9,0-12.58.93-17.25,5.24-3.79,3.5-8.11,8.5-9.3,13.59.06,3.22,0,4-.09,7.07h0a.66.66,0,0,1,0,.14.76.76,0,0,1,0,.15h0c.11,3.1.15,3.84.09,7.07,1.19,5.09,5.51,10.08,9.3,13.58,4.67,4.31,8.24,5.22,17.25,5.24,5.31,0,8.33.18,12.73.28A3.92,3.92,0,0,0,955.51,71Zm17.71-8.53-23.84-.61s4.09-1.23,6.15-1.82,4.06-1.3,6.15-1.75a23.19,23.19,0,0,1,2.5-.38c1.89-.2,3.79-.35,5.7-.38,6.61-.08,13.21.39,19.81.84,3.55.24,7.28.42,10.63,1a.82.82,0,0,1,.61.53c.2.67-.54,2-.54,2Zm-26.93-1.2a1.22,1.22,0,0,1-.8-.29,10.11,10.11,0,0,1-4.72-4,25.89,25.89,0,0,1-3.83-9.59,29.59,29.59,0,0,1-.62-6.56,29.65,29.65,0,0,1,.62-6.56,25.84,25.84,0,0,1,3.83-9.58,10.08,10.08,0,0,1,4.72-4,1.43,1.43,0,0,1,1.62-.07l13.12,4.28a25.61,25.61,0,0,0-2,6.46,47.78,47.78,0,0,0,0,19,25.61,25.61,0,0,0,2,6.46l-13.12,4.28A2,2,0,0,1,946.29,61.27Zm55.11-4.63h-.85c-6,0-3.91-.09-9.91-.19a76.92,76.92,0,0,0,1-10.39c0-1.22.08-3,.11-4.56h0c0-.17,0-.46,0-.66s0-.48,0-.66h0c0-1.53-.06-3.34-.11-4.56a77.07,77.07,0,0,0-1-10.39c6-.1,3.91-.18,9.91-.18a4.88,4.88,0,0,1,3.26.68,11.7,11.7,0,0,1,5,7.09,29.47,29.47,0,0,1,.92,8,29.47,29.47,0,0,1-.92,8,11.75,11.75,0,0,1-5,7.1,4,4,0,0,1-2.41.69Zm-29-32.5h-2.47a57,57,0,0,1-5.7-.38,23.19,23.19,0,0,1-2.5-.38c-2.09-.45-4.11-1.15-6.15-1.75s-6.15-1.82-6.15-1.82l23.84-.6,27.17.53s.74,1.37.54,2.05a.86.86,0,0,1-.61.53c-3.35.57-7.08.75-10.63,1-5.77.38-11.55.79-17.34.84Z"/><text class="cls-6" transform="translate(958.58 47.64)">ego</text><line class="cls-7" x1="746.07" y1="41" x2="913" y2="41"/><path d="M734,41c5.68,2.11,12.73,5.7,17.09,9.51L747.65,41l3.44-9.51C746.73,35.3,739.68,38.89,734,41Z"/><line class="cls-7" x1="913" y1="41" x2="913" y2="73.93"/><path d="M913,86c-2.11-5.68-5.7-12.73-9.51-17.09L913,72.35l9.51-3.44C918.7,73.27,915.11,80.32,913,86Z"/><text class="cls-8" transform="translate(813.31 81.33)">Distance</text><text class="cls-8" transform="translate(803.33 32.75)">Speed</text></g></svg>
\ No newline at end of file

main.adoc

@@ -16,8 +16,8 @@ include::subchapters/1-5_relations_to_other_standards_projects_or_organizations.
 include::subchapters/2_technical-content.adoc[]
 
 == Project Resources
-include::subchapters/3-1_required_resources.adoc[]
-include::subchapters/3-2_committed_resources.adoc[]
+include::subchapters/3-1_work_packages.adoc[]
+include::subchapters/3-2_company_commitments.adoc[]
 include::subchapters/3-3_resource_summary.adoc[]
 
 == Project Plan

subchapters/1-4_requirements.adoc

 
-=== Requirements
+=== User Stories
+
+[[a-share]]
+==== A) SHARE
+
+1.  As an AV/ADAS developer company, I can share with other companies the scenarios I built to test my technology.
+2.  As an AV/ADAS developer company, I can search, review and reuse scenarios built by other companies.
+3.  As a test engineer working for an AV/ADAS development company, I can build and run tests as similarly as possible to tests other developers at other companies are running.
+4.  As a test engineer, I can build and run tests as similarly as possible on different execution platforms.
+5.  As a researcher developing new technology, I can reutilize industry and open source scenarios to advance my research.
+
+[[b-certify-analyse]]
+==== B) CERTIFY & ANALYSE
+
+1.  As an auditor/regulator, I can understand how AV/ADAS developers are testing their products.
+2.  As an auditor/regulator, I can compare the outcome of different execution platforms when they have the same OpenSCENARIO input.
+3.  As a safety consultant, I can recommend specific scenarios and related conditions (parameters) to my clients to test their products.
+4.  As a member of the public, I can learn more details about how AV/ADAS products are tested by AV/ADAS developers.
+5.  As government agency, I can understand what parts of the Operational Domain are verified by an AV/ADAS developer through each scenario.
+
+[[c-develop]]
+==== C) DEVELOP
+
+1.  As a tool developer, I can reutilize constructs, artifacts and libraries to create tools compatible with other tool vendors in industry.
+2.  As a service provider, I can integrate tools from multiple tool vendors to provide an integrated solution to test AV/ADAS scenarios.
+3.  As a system engineer working for an AV/ADAS developer company, I can fully trace which hardware and software in the AV/ADAS stack is verified by which tests.
+4.  As a software developer, I can process scenario information from different software/hardware releases and produce comparison charts to provide trend and gap analysis.
+5.  As an existing tool provider or consumer, I can migrate information from previous versions of OpenSCENARIO into OpenSCENARIO 2.0.
+6.  As a system engineer working for an AV/ADAS developer, I can decompose high level use cases in a standardised way.
+
+[[d-create]]
+==== D) CREATE
+
+1.  As a content developer, I can use OpenSCENARIO 2.0 to create test scenarios that I can supply to my customers who use a OpenSCENARIO 2.0 compliant toolchain.
+2.  As a test engineer, I can transform abstract test descriptions into OpenSCENARIO 2.0 (e.g. NCAP tests, UNECE regulations, any requirement list, …).
+3.  As a development project lead, I can write scenarios on an abstract level to discuss the functional behavior with the stakeholders.
+4.  As a development project lead, I can create scenarios on an abstract level to document the functional behavior for legal reasons.
+5.  As a stakeholder, I can create natural language scenarios without having any knowledge about technical details.
+
+[[e-sotif-based-risk-consideration]]
+==== E) SOTIF-BASED RISK CONSIDERATION
 
+1.  As a SOTIF safety engineer and/or V&V engineer, AV developer, scenario creator, I can use OpenSCENARIO 2.0 to discover scenarios that are going to uncover safety hazards. This refer to SOTIF and safety hazards that can be present even if the system is functioning as designed, without a malfunction.
+2.  As a SOTIF safety engineer and/or V&V engineer, AV developer, scenario creator, I can use OpenSCENARIO 2.0 to create scenarios that are going to produce emergent behavior of the DUT to discover unknown unknows. OpenSCENARIO 2.0 shall enable to demonstrate that minimum residual risk is attained by the DUT. This is because SOTIF focuses on ensuring the absence of unreasonable risk due to hazards resulting from insufficiencies in the intended functionality or from reasonably foreseeable misuse.
+
+[[f-driving-mission-based-scenarios]]
+==== F) DRIVING MISSION-BASED SCENARIOS
+
+1.  As an end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable specification of a driving mission through inclusion of multiple maneuvers in a sequence or in parallel for both DUT and any other traffic agents.
+2.  As an end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable accomplishing a select driving mission with an indication of whether the mission has been accomplished, what are the mission KPIs and how they are computed, and whether the unambiguous goals of the mission have been attained.
+
+[[g-traffic-model-inclusion]]
+==== G) TRAFFIC MODEL INCLUSION
+
+1.  As a traffic model developer, an ADS developer, or end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable inclusion of multiple traffic models and AI-based traffic agents in the scenarios and evaluators. Also, OpenSCENARIO 2.0 shall enable inclusion of mechanisms to extract scenarios from the traffic models.
+2.  As a test engineer, I can transform from high level scenario description to low level scenario descriptions and vice versa.
+
+[[h-execute]]
+==== H) EXECUTE
+
+1.  As a test engineer, I can execute different OpenSCENARIO 2.0 files in an automated way with my OpenSCENARIO 2.0 compliant toolchain; no file modifications are needed.
+2.  As a test engineer, I can execute the same OpenSCENARIO 2.0 files on different OpenSCENARIO 2.0 compliant toolchains.
+3.  As a test engineer, I can convert abstract scenarios into tests.
+
+[[i-describe-observations]]
+==== I) DESCRIBE OBSERVATIONS
+
+1.  A simulation tool can describe randomly executed simulation runs. If the Simulation was run with stochastic metrics, the user wants to have the concrete description of what has happend in OSC2.0 Format.
+2.  A traffic observer can describe what occured in real world with OSC2.0
+3.  A test engineer on a test track can describe with OSC2.0 what specific scenario he has observed on a test track. In such a way tolerances and deviations between test description and test execution will become obvious.
+
+=== Requirements
 
 OpenSCENARIO 2.0 should address the basic requirements and features stated in the concept project proposal document. These are repeated here for clarity and their detailed description can be found in the concept project proposal document for OSC 2.0.
 

subchapters/2_technical-content.adoc

@@ -75,13 +75,24 @@ Identify entities and their actions / methods that are introduced by high-level
 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)
-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.
+A standard domain model allows users to:
+
+*	leverage a well-architect model and attributes for productivity
+*	Facilitate scenario reuse across teams without upfront planning
+
+At the same time, various users may have extensions that are not common or generic enough to be part of the standard. This section would discuss how the OpenSCENARIO2.0 allows user to extend the standard model to meet their project specific needs. 
+
+User may want to:
+
+*	Add an attribute to a standard actor, action or struct
+*	Add a user defined actor
+*	Add a user-defined action to a standard actor
+*	Add other needed entities 
+
+On top of addition extensions, user may want to ignore parts of the domain model which are not relevant may not be interesting for his ODD or project needs. 
+
+Later, these new extensions be efficiently leveraged for automated user-defined scenarios.  
+
 
 ===== Ontology
 Responsibles for filling this sub-chapter: F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe)
@@ -117,6 +128,24 @@ Finally, the overall semantics of the language should be clearly and unambigousl
 Also included is the definition of the exact semantics of temporal composition operators like serial, parallel and mix. Another important aspect is how to combine the two different approaches of specifying behavior: a) the declarative way (like intended for OpenScenario 2.0) and b) the more execution/command-oriented way of OpenScenario 1.0 (that still should be supported)."
 
 ===== Considerations for 1.x
+
+OpenSCENARIO 2.0 shall be a full superset of the features of OpenSCENARIO 1.0, and it shall be possible to convert any OpenSCENARIO 1.0 scenario into an OpenSCENARIO 2.0 scenario with identical run time behavior.
+
+This goal is partially addressed by the work on the Domain Model by ensuring that every entity of OSC 1.0 (including attributes and actions) has a respective counterpart in the OSC 2.0 domain model.
+
+Additional concepts of OpenSCENARIO 1.0 for which a proper mapping to OpenSCENARIO 2.0 must be ensured include:
+
+*	The event-driven temporal behavior as effected by the hierarchy, state machine and condition semantics (e.g. edges) of OpenSCENARIO 1.0 storyboard elements.
+*	The concept of longitudinal and lateral domains of actions/controllers as well as their parallel existence.
+*	Basic references such as coordinates systems and unit of measure.
+*	Reuse-mechanisms such as Parameters and Catalogs
+*	Entity Selections
+*	Extensibility mechanisms such as Properties, UserActions and Controllers
+*	Routes and Trajectories
+
+As the OpenSCENARIO 1.x standard will be further developed in parallel to this project, it will be required to constantly co-ordinate with the OpenSCENARIO 1.x project. At the end of this project a complete semantic mapping (migration path) from the most recent OpenSCENARIO 1.x version to OpenSCENARIO 2.0 shall be provided.
+
+
 ===== Library Concepts and Packaging (scenario definition & scenario execution)
 
 With the expected usage of scenarios at different abstraction levels, and it being aimed at different ODDs and different automated driving systems, the need for encapsulating scenarios in libraries is obvious.
@@ -159,13 +188,35 @@ This is also true for a proper testing workflow, that should describe the intera
 
 
 ===== Abstraction, Concretization of Scenarios
-Responsible: ?
+Responsible: R. Heidtman
+
+Abstraction Level definitions are needed to expand beyond OpenScenario 1.0 and distinguish between scenarios that are written for natural language, machine language or OpenScenario 2.0 DSL, which explains handing of undefined values as abstractions.  Abstract scenarios are defined as a scenario that: 
+
+. Has every intention of being understood and tested by a machine (i.e. machine readable) 
+. Uses an object oriented "structure for abstraction" 
+. Follows "rules of abstraction" to realize a scenario within realized ODD as part of driving domain.  
+
+Concretization or Concretion processes should explain and define reasons for why an abstract scenario intentionally does not define all dimensions and values (i.e. so they can later be optimized or explained by a supporting ODD to be made concrete.)
+
+A Concretization definition should define simple process steps.  These steps should explain through examples the process of taking an Abstract Scenario and converting it step-by-step to a Concreate Scenario, where all parameters are assigned to a single value.
+
 
 ====== Scenario summary to functional Scenario (i.e. Rules of Abstraction)
-Responsible: ?
+Responsible: R. Heidtman
+
+When considering a "Scenario Summary", define a best practice to create scenario summaries that that can be linked to ontology / taxonomy word choices.  A Scenario summary is a paragraph of natural language that lends itself to an ontology that defines a scene in detail using a list all actors performing specified actions.  
+
+When considering a "Functional Scenario", also natural language, a definition would also lend itself to an ontology but is distinctly connected to specific ODD Categories, Behaviors and / or operational concepts.  A list of specific relationships should be developed to defined to establish what distinguishes a "Functional Scenario" from a "Scenario Summary".  A Functional Scenario may distinguish itself by how it influences the ODD test plan, functional test plan or design intentions.
 
 ====== Functional Scenario to concrete scenario (i.e. Rules of Concretization)
-Responsible: ?
+Responsible: R. Heidtman
+
+The rules of concretion should be defined to ensure rational semantic definition for necessary rules that are needed to make an object realized, initialized and located in an environment and ensure that parameter values may be assigned to bring an activity, phase or scenario to a point where all modifiers may be made concrete using a single value for each.  An abstract scenario needs a list of modifier rules to follow for concretion expression based on some list of suggestions.  Activities would include: defining rules needed for concretion and how they might be expressed in a syntax for each example maneuver / scenario.  These rules might be different for the first activity of an actor; this activity might require information for location: position, lane, RoadSegment (i.e. laneSection), distance and/or relationship to another object, etc.
+
+A detailed process or set of possible processes should explained how values are assigned as part of either: 1) parameter definition or 2) expressed through modifier "parameter space" as single value (Note: This may negate the need for a constraint(s) in the final concrete scenario.)
+
+An example rule of concretion could be: a rule where every named parameter space must have a parameter definition, thus assigning a parameter type.  Units may also need to be considered to be logically abstract so that when values are assigned they actually hold a true meaning.  Units in this way could be expressed in a: 1) parameter definition, 2) a constraint or 3) parameter space representation where the parameter name is used or referred to.
+
 
 ====== Interfacing with concrete scenarios from OSC 1.x
 Responsible: Sandeep P.
@@ -201,7 +252,18 @@ The created workflow should include all lifetime phases for a scenario, from pre
 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
+
+OpenSCENARIO 2.0 allows building modular, encapsulated, reusable scenarios that can be ported to different testing platforms.  This section will describe the basic flow to construct a test, which contains all the elements and ingredients required for a testing platform, Ingredients like road topology, scenery. Road surface, driver and traffic models and more. 
+
+This section will describe how scenarios can be mixed and combined to construct a test. Interaction with usage restriction and guidelines will be presented.  
+
+For specific platforms, the user will need to provide context and implementation details to enable its execution. For example, in simulation the user may provide for a reusable scenario:
+
+*	A map to be executed on with specific location details
+*	Desired ODD restrictions
+
+Various topics related to combining scenarios into meaningful tests will be discussed in this section.
+
 
 
 ===== Test definition

subchapters/3-1_required_resources.adoc → subchapters/3-1_work_packages.adoc

-=== Required 
+=== Work Packages 
 A breakdown of the project into individual work packages and the corresponding effort required to complete them. Effort should be given in man-hours.
 
-==== Effort
 
-===== Breakdown by Work Packages [WPs]
 
-.WP LC-Temporal
-[cols="1,2"]
+.LC-Temporal
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-Temporal
+|*Description* | Temporal aspects of the OpenSCENARIO 2.0 language and its execution
 | *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 complete this WP.
+| *Effort*	|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
-[cols="1,2"]
+.LC-Syntax
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-Syntax
-| *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 complete this WP.
-| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
+|*Description* | Syntax definition of the OpenSCENARIO 2.0 language
+| *Responsibles* | R. Hadar
+|*Deliverable*	| Full syntax definition, including grammar, of the OpenSCENARIO 2.0 language. Basic building blocks are file organization, type definitions, compound type definitions and their internals, temporals, behavior description and expressions. Integration of the other WG syntax definition into a single syntactic entity that shares the same look and feel. 
+| *Effort*	| 35 man-days
+| *Service Provider*	| Documentation of language syntax. ~25% of effort.
 |===
 
-.WP LC-CompoundTypes
-[cols="1,2"]
+.LC-CompoundTypes
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-CompoundTypes
+|*Description* | Compound types for OpenSCENARIO 2.0
+
+This WP will address the semantic description of the compound datatypes (structs, actors, scenarios, lists etc.). It will also describe the generic capabilities of these datatypes: Ability to precisely define allowed generatable sub types, ability to freely extend any type in a modular way (so as to enhance / restrict it), and so on. 
+
 | *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 complete this WP.
-| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
+| *Effort*	| 100 man-days
+| *Service Provider*	| Documentation of compound types parts of the specification. ~25% of effort.
 |===
 
-.WP LC-BasicTypes
-[cols="1,2"]
+.LC-BasicTypes
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-BasicTypes
-| *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 complete this WP.
-| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
+|*Description* | Basic data types for OpenSCENARIO 2.0  
+
+This WP will address the semantic description of the basic generic datatypes (integers, booleans, floats, enums), domain specific physical types (such as speed, distance and angle) with their corresponding units. We will talk about implicit and explicit type conversions. 
+
+| *Responsibles* | Sharon Rosenberg
+|*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*	| 100 man-days
+| *Service Provider*	| Documentation of basic types parts of the specification. ~25% of effort.
 |===
 
-.WP LC-Expressions
-[cols="1,2"]
+.LC-Expressions
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-Expressions
-| *Responsibles* | P. Mai, J. Krasser
-|*Title / Description* | Expression language for OpenSCENARIO 2.0
+|*Description* a| Expression language for OpenSCENARIO 2.0
 
 This comprises the generic parts of expressions (e.g. arithmetic, logic, etc.) based on the properties of the domain model, as well as ways to define more complex domain-specific expressions.
+| *Responsibles* | P. Mai, J. Krasser
 |*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)*	| 50 person days
+| *Effort*	| 50 man-days
 | *Service Provider*	| Documentation of expression language parts of the specification. ~25% of effort.
 |===
 
-.WP LC-Semantics
-[cols="1,2"]
+.LC-Semantics
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-Semantics
-| *Responsibles* | I. Whiteside, Y. Hollander (maybe), S. Rosenberg (maybe)
-|*Title / Description* | A well-defined semantics for OpenSCENARIO 2.0.
+|*Description* a| A well-defined semantics for OpenSCENARIO 2.0.
 
 As the levels of abstraction have been raised, so the effort and understanding needed for a simulation engine to implement support for this standard is raised. As such, the semantics of a scenario become more important: to give an unambiguous understand of a) whether that scenario could be executed at all; b) whether that scenario could be executed on a given map; c) how to execute that scenario unambigously.
+| *Responsibles* | I. Whiteside, Y. Hollander (maybe), S. Rosenberg (maybe)
 |*Deliverable*	| Semantic rules for the OpenSCENARIO 2.0 language.
-| *Effort (Man-days)*	| Estimated work effort: 100 man-days
+| *Effort*	| 100 man-days
 |===
 
-.WP LC-Libraries
-[cols="1,2"]
+.LC-Libraries
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-Libraries
-| *Responsibles* | P. Mai, Y. Hollander
-|*Title / Description* | Libraries, Modules, Packaging and Namespace aspects of OpenSCENARIO 2.0
+|*Description* a| Libraries, Modules, Packaging and Namespace aspects of OpenSCENARIO 2.0
 
 This WP will address the necessary ways of packaging functionality into libraries and modules in ways that foster re-use across users and implementations.  Related namespacing problems are addressed.  Relation to OpenSCENARIO 1.0 re-use concepts will be addressed.
+| *Responsibles* | P. Mai, Y. Hollander
 |*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)*	| 50 person days
+| *Effort*	| 50 man-days
 | *Service Provider*	| Documentation of library, modules, packaging and namespace parts of the specification. ~15% of effort.
 |===
 
-.WP LC-Transfer1x
-[cols="1,2"]
+.LC-Transfer1x
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | LC-Transfer1x
+|*Description* | Additional features in OpenSCENARIO 2.0 to support OpenSCENARIO 1.0/1.x features not otherwise part of 2.0
 | *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 complete this WP.
+| *Effort*	|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"]
+.DM-AbstractionRoads
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | DM-AbstractionRoads
+|*Description* | Create road network domain model based on concept project proposal.
 | *Responsibles* | M. Kluge, J.Kaths
-|*Title / Description* | Create road network domain model based on concept project proposal.
 |*Deliverable*	| UML entity definition of the road network, 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 (Could not find the actual number from the meeting...)
+| *Effort*	| 30 (Could not find the actual number from the meeting...)
 | *Service Provider*	| Finalization of the UML model draft (10%).
 |===
 
-.WP DM-Transfer1x
-[cols="1,2"]
+.DM-Transfer1x
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | DM-Transfer1x
+|*Description* | Rework entity definition from concept project with regard to OpenSCENARIO 1.0.
 | *Responsibles* | J. Tscheak (maybe), M. Kluge, J.Kaths
-|*Title / Description* | Rework entity definition from concept project with regard to OpenSCENARIO 1.0.
 |*Deliverable*	| Consolidated UML entity definition that covers existing features of OpenSCENARIO 1.0 standard. Differences between 1.0 and the concept project domain model should be identified, listed and resolved. Deviations should only be allowed when necessity is clearly identified and reasoned. This work package is a predecessor of DM-Extend2x and should be finished first.
-| *Effort (Man-days)*	| 30 (Could not find the actual number from the meeting...)
+| *Effort*	| 30 (Could not find the actual number from the meeting...)
 | *Service Provider*	| Finalization of the UML model draft (10%).
 |===
 
-.WP DM-Extend2x
-[cols="1,2"]
+.DM-Extend2x
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | DM-Extend2x
+|*Description* | Extend Entity Definition from Concept project and other working packages towards OSC 2.0
 | *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
+| *Effort*	| 40 man-days
 | *Service Provider*	| Finalization of the UML model draft (10%).
 |===
 
-.WP DM-Extensibility
-[cols="1,2"]
+.DM-Extensibility
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | DM-Extensibility
+|*Description* | Domain model extensibility capabilities for OpenSCENARIO 2.0  
+
+This WP will address the ability of adding and removing entities for the standard domain-model  
+
 | *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)*	| 40
-| *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
+|*Deliverable*	| Description of how to add entities (attributes, actor, action, etc.) to the design model and how to leverage the modified model for user specific scenarios and coverage, 
+| *Effort*	| 20 man-days
+| *Service Provider*	| Documentation of the domain model extensibility chapter . ~15% of effort.
 |===
 
-.WP DM-Ontology
-[cols="1,2"]
+.DM-Ontology
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | DM-Ontology
+|*Description* | Develop ontology to establish relations between entities
 | *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)*	| 60
+| *Effort*	| 60 man-days
 | *Service Provider*	| Tasks to be performed by a service provider. Also estimate the % of total effort for this WP.
 |===
 
-.WP FS-FeatureSetsConcept
-[cols="1,2"]
+.FS-FeatureSetsConcept
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | FS-FeatureSetsConcept
+|*Description* | Create a concept for partial support of the standard
 | *Responsibles* | M. Kluge
-|*Title / Description* | Create a concept for partial support of the standard
 |*Deliverable*	| Concept to fragment content of the standard into clusters (features sets). Has to contain the approach on how to cluster the content (e.g. on domain model level), a first draft of viable feature sets and an idea on how to check language files for feature set compatibility. Predeccesor for work packages FS-FeatureSetsDefinition.
-| *Effort (Man-days)*	| 30 (Estimation by M Kluge.)
+| *Effort*	| 30 man-days
 | *Service Provider*	| Not applicable.
 |===
 
-.WP FS-FeatureSetsDefinition
-[cols="1,2"]
+.FS-FeatureSetsDefinition
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | FS-FeatureSetsDefinition
+|*Description* | Define viable feature sets
 | *Responsibles* | M. Kluge
-|*Title / Description* | Define viable feature sets
 |*Deliverable*	| Definition and documentation of feature sets based on first draft provided by successor work package FS-FeatureSetsConcept. Might also contain the addition of new elements in the language to declare feature set compatibility. Predeccesor for work packages FS-FeatureSetsValidation.
-| *Effort (Man-days)*	| 30 (Estimation by M Kluge.)
+| *Effort*	| 30 man-days
 | *Service Provider*	| Language checks and possibly UML model finetuning (20%).
 |===
 
-.WP FS-FeatureSetsValidation
-[cols="1,2"]
+.FS-FeatureSetsValidation
+[cols="1,5",caption='WP {counter:wp1}: ']
 |===
-| *WP Number* | FS-FeatureSetsValidation
+|*Description* | Define feature set validation method
 | *Responsibles* | M. Kluge
-|*Title / Description* | Define feature set validation method
 |*Deliverable*	| Definition, documentation and implementation of validation approach of language files against feature sets. Necessary for actual usage of usage of feature sets.
-| *Effort (Man-days)*	| 20 (Estimation by M Kluge.)
+| *Effort*	| 20 man-days
 | *Service Provider*	| Language checks and possibly UML model finetuning (20%).
 |===
 
@@ -192,20 +183,3 @@ This WP will address the necessary ways of packaging functionality into librarie
 | WP No. | Project member (man-days) | Service Provider (man-days) | Total (man-days) 
 ||||
 |===
-
-==== Budget
-This section details the budget required by the project to e.g. pay service providers and the funds to be provided by ASAM.
-
-.Funds required for Service Providers
-[options="header"]
-|===
-| Task Description | Effort| Cost (€700 / man-day) 
-|||
-|===
-
-.Funds Provided by ASAM
-[options="header"]
-|===
-| Amount (Euros)
-|
-|===

subchapters/3-2_committed_resources.adoc → subchapters/3-2_company_commitments.adoc

-=== Committed 
+=== Company Commitments 
 Member companies contribute resources for the project as per the following table.
 
 // Company details to be added by individual representatives
@@ -9,26 +9,143 @@ Member companies contribute resources for the project as per the following table
 |DLR                            |                           |
 |Foretellix                     |                           |
 |PMSF                           |30                         | Pierre R. Mai, +49-8161-97696-11, pmai@pmsf.eu
-|BTC                            |                           |
-|APTIV                          |                           |
+
+|BTC Embedded Systems AG                            
+|37            
+|Name: Matthias Büker +
+Mail: matthias.bueker@btc-es.de +
+Phone: +49 441 - 969738 - 33
+
+|APTIV                          
+|   60                        
+| rich.heidtman@aptiv.com, 810.599.8909
+
 |AVL                            |                           |
-|Audi                           |                           |
-|ANSYS                          |36                         a|Luca Costantino, +33-7-82-89-97-88, luca.costantino@ansys.com +
+
+|Audi                           
+|25                           
+| Florian Bock, florian1.bock@audi.de
+
+|ANSYS                          
+|36                         
+a|Luca Costantino, +33-7-82-89-97-88, luca.costantino@ansys.com +
 Bernhard Kaiser, +49-30-348-0770, bernhard.kaiser@ansys.com
-|WMG, University of Warwick     |                           |
-|BMW AG                         |25                         |Andreas Rauschert, +49-89-382-61151, andreas.rb.rauschert@bmw.de
+
+|Applied Intuition                          
+|15                        
+a|Romain Kuntz / rk@applied.co / +49 157 357 09475
+
+| SAIC MOTOR     
+| 25                        
+|Cheng Cheng, chengcheng@saicmotor.com +8613524654642 +
+Lu JunYan, lujunyan@saicmotor.com +8613641721686 +
+Jean Wang, wangyuanjing@saicmotor.com +8615221688042
+
+| WMG, University of Warwick, UK     
+| 40                          
+|Dr Jason Zhang, Jason.Zhang@warwick.ac.uk+
+Siddartha Khastgir, s.khastgir.1@warwick.ac.uk
+
+|BMW AG                         
+|25                         |Andreas Rauschert, +49-89-382-61151, andreas.rb.rauschert@bmw.de
+
 |FiveAI                         |                           |
+
+|Höchstleistungsrechenzentrum Stuttgart                          
+|   28                        
+| Jutta Sauer, hpcfloh@hlrs.de
+
 |dSPACE                         |                           |
 |Vector                         |                           |
-|Luxoft                         |                           |
-|HLRS                           |                           |
-|iASYS                          |                           |
-|Denso                          |                           |
+
+|Luxoft                         
+|       20                    
+|Christian König, ckoenig@luxoft.com, +49 (0) 151 20 34 27 65
+
+|iASYS                          
+|     25                      
+|Puran Parekh, ppuran@iasys.co.in
+
+|Denso                          
+| 25                          
+|Nicolas Ochoa Lleras, n.ochoa@denso-auto.de, (0)8165-944-440
+
 |Elektrobit                     |                           |
-|OFFIS e.V., Germany            | 10 days                   | Lukas Westhofen, +49 441 9722-477, lukas.westhofen@offis.de
-|Virtual Vehicle                | 21 days                   | Patrick Weissensteiner, +43 316 9707, patrick.weissensteiner@v2c2.at
-|FZI                            | 25                        | Thilo Braun, +49 721 9654-152, braun@fzi.de + 
+
+| NTT DATA                      
+| 25                          
+| Johannes Kreckel, Johannes.Kreckel@nttdata.com 
+
+|OFFIS e.V., Germany            
+| 10 days                   
+| Lukas Westhofen, +49 441 9722-477, lukas.westhofen@offis.de
+
+|Virtual Vehicle                
+| 21 days                   
+| Patrick Weissensteiner, +43 316 9707, patrick.weissensteiner@v2c2.at
+
+|FZI                            
+| 25                        
+| Thilo Braun, +49 721 9654-152, braun@fzi.de + 
 Barbara Schütt, +49 30 7017337-336, schuett@fzi.de 
+
+|  Navinfo                          
+|  25                       
+| Wei Sun, sunwei60804@navinfo.com, 0086-01082306399-9644
+
+|   CATARC                         
+| 30