Project Proposal: ASAM OpenSCENARIO V1.x

Executive Summary

This project is intended to further develop the ASAM standard OpenSCENARIO 1.0. OpenSCENARIO provides the data model, the specification and examples for the description of dynamic content in driving simulation. OpenSCENARIO is used in driving simulation, traffic simulation, virtual development, test and validation of driving assistance functions, automated and autonomous driving.

Within these use cases, OpenSCENARIO describes all entities acting on or interacting with the road. It does not describe the road network, road infrastructure or road surface. This content is complemented by the ASAM standards OpenDRIVE and OpenCRG. The consolidated content of the three standards provides comprehensive input for above-mentioned use-cases.

The goals of the proposed project incorporate the completion of tasks that could not be completed within the predecessor project, i.e. the ASAM OpenSCENARIO Transfer project, whose outcome is the release of ASAM OpenSCENARIO 1.0. Another goal of the proposed project is to provide support for users and implementers of OpenSCENARIO 1.0 and 1.x. Finally, close collaboration with the proposed ASAM OpenSCENARIO 2.0 project forms a goal of the proposed project. Result of this cooperation shall be a migration path for ASAM OpenSCENARIO 1.x outcomes and developments to the next major release. Nevertheless, it cannot be guaranteed that the migration path can be fully elaborated within the proposed project. This may require further releases 1.x of OpenSCENARIO, which will be developed in subsequent OpenSCENARIO 1.x projects.

1. Overview

1.1. Motivation

This is a proposal for the further development of ASAM OpenSCENARIO 1.0 within an ASAM OpenSCENARIO 1.x project in order to ensure further development, maintenance and a sustainable migration path to the next major release of the standard.

OpenSCENARIO is used in driving simulation and in virtual development, test and validation of driving assistance functions, automated and autonomous driving. Within these use cases, it describes the dynamic content of the world, i.e. the entities acting on or interacting with the road. It does not describe the road network, road infrastructure or road surface. This content is complemented by the ASAM standards OpenDRIVE and OpenCRG.

OpenSCENARIO was transferred to ASAM by an industry consortium in late 2018. By February 2020, OpenSCENARIO evolved to the ASAM standard OpenSCENARIO 1.0 within the ASAM OpenSCENARIO Transfer project. The project focused on completion of existing artifacts, e.g. the addition of missing descriptions and clarifications. The implementation of new features was not planned.

After completion of the ASAM OpenSCENARIO Transfer project, ASAM OpenSCENARIO 1.0 is released in March 2020. This version is the first complete and fully documented version of OpenSCENARIO. First significant user feedback can be expected from the use and implementation of this version. Therefore, the author of this proposal strongly suggests the evaluation of this feedback and its consideration for the further development and maintenance of ASAM OpenSCENARIO.

Moreover, a list of open issues has been created within the ASAM OpenSCENARIO Transfer project. This list is based on the Bugzilla items created during the project. It was reviewed and prioritized by the project group members at the end of the project. In addition to the above-mentioned maintenance tasks, this list shall be reviewed and considered as work backlog for the ASAM OpenSCENARIO 1.x project. It is suggested by the author of this proposal to deal with these tasks in order to complete the standard with features that have already been discussed and prioritized by domain experts and OpenSCENARIO users.

Finally, within the ASAM Simulation Coordination Group, it was decided to develop a migration path from ASAM OpenSCENARIO 1.x to ASAM OpenSCENARIO 2.0 in a joint effort of the two corresponding projects such that "[…] run time behavior of any scenario converted between the latest 1.x and 2.0 OSC languages shall be the same.[…]". The two projects shall therefore develop a migration path from 1.x to 2.0. The first release of a corresponding ruleset shall be delivered with the first release of 2.0 by the ASAM OpenSCENARIO 2.0 project. For the proposed ASAM OpenSCENARIO 1.x project, this implicates that close synchronization with the ASAM OpenSCENARIO 2.0 project shall be sought and that technical changes may have to be discussed throughout the projects in order to support the integration of OpenSCENARIO 1.x features in OpenSCENARIO 2.0. In order to achieve sustainability throughout releases of ASAM OpenSCENARIO, the author of this proposal strongly supports this plan. Nevertheless, it cannot be guaranteed that the migration path can be fully elaborated within the proposed project. This may require further releases 1.x of OpenSCENARIO, which will be developed in subsequent OpenSCENARIO 1.x projects.

1.2. Use Cases

Use Case 1: Traffic Simulation
Description	Macroscopic simulation of traffic on road networks. Traffic simulation may incorporate large numbers of various traffic participants, e.g. pedestrians, cyclists, cars etc. Traffic simulation is used to simulate surrounding traffic of a vehicle under test, traffic volume in specific areas, accident probabilities etc. Complemented by OpenDRIVE (i.e. the road network description), OpenSCENARIO is used for scenario description in this use-case.
Actors	Authorities Vehicle manufacturers and their suppliers Simulation tool vendors Urban planners

Use Case 2: Vehicle Dynamics Simulation
Description	Virtual development, test and evaluation of the dynamic subsystem of a vehicle using driver inputs and a given roadmap as input. Vehicle dynamics simulation provides valuable results in early development stages. It further allows parallel execution of time-consuming physical test runs at low costs. Vehicle dynamics simulation enables tests at the limits of dynamic driving performance and within hazardous situations. Complemented by OpenDRIVE (i.e. the road network description) and OpenCRG (i.e. the road surface description), OpenSCENARIO is used for scenario description in this use-case.
Actors	Vehicle manufacturers and their suppliers Simulation tool vendors

Use Case 3: Sensor Simulation
Description	Simulation of sensors as a device, module or subsystem of a vehicle is indispensable for the selection of individual sensors as wells as for the compilation of sensor sets and the development of sensors and sensor-based functionalities in the automotive context. A sensors ability to detect obstacles, events or changes in its environment is heavily influenced by vehicle geometry, mounting position, interferences with other sensors and environmental conditions. Sensor simulation offers valuable insights on these complex, heavily entangled phenomena. Due to the strong influence of the sensor setup on vehicle bodywork and electrical systems, this knowledge is particularly valuable in early development stages of a vehicle, where physical sensors may not yet be available. Sensor simulation provides the foundation for development and test of driving assistance functions, as well as for automated and autonomous driving functions. Complemented by OpenDRIVE (i.e. the road network description), OpenSCENARIO is used for scenario description in this use-case.
Actors	Vehicle manufacturers and their suppliers Simulation tool vendors

Use Case 4: Virtual Development, Test and Validation
Description	Development, testing and validation of automated and autonomous driving functions is increasingly carried out virtually. The reproduction of countless, realistic journeys over millions of kilometers requires huge numbers of roadmaps and scenarios as input files. Major requirements on corresponding file formats is standardization and exchangeability. Complemented by OpenDRIVE (i.e. the road network description), OpenSCENARIO is used for scenario description in this use-case.
Actors	Authorities Vehicle manufacturers and their suppliers Simulation tool vendors

Use Case 5: Simulator Verification
Description	Verification of the correctness of a simulator in enacting a given scenario. Regulators are expected to release scenarios as part of standardised verification processes for autonomous driving and ADAS products. Simulators may interpret OpenSCENARIO differently given the complexity of instruction lifetime and parallelism possible, reducing the utility of OpenSCENARIO as a verification tool. To allow verification a given simulator’s interpretation of the standard matches that of a regulator’s, a means of comparing a scenario’s instructions sequentially must be provided. Complemented by OpenDRIVE (i.e. the road network description), OpenSCENARIO is used for scenario description in this use-case.
Actors	Authorities Simulation tool vendors

1.3. Requirements

In the context of ASAM standards this describes requirements that the output of the project should satisfy. In general these requirements should be derived from the use cases described in this document.

A clear understanding of the nature of different OpenScenario elements is fundamental for the development of simulation scenarios. The OpenScenario format should focus in eliminating redundancy and improving clarity for the sake of users and standard health. These are elementary requirements that should govern the growth of the standard and its maintenance, and are therefore ubiquitous in such projects, even if mostly present in the project’s backdrop. However, this project will tackle these issues head-on, in particular for the case of controllers, actions, entities, and their interactions; corner stones of the standard and currently wanting in transparency. Additionally, the project will also address the runtime model of a simulation and the role played by OpenScenario therein; a requirement to aid scenario designers and those developping the tools which interpret and implement the standard.

In the described Use-Cases OpenSCENARIO is used together with other standardised formats to fulfil the goal of the Use-Case. Therefore a requirement is that OpenSCENARIO is compatible and consistent with other formats.

1.4. Relations to Other Standards or Organizations

The proposed ASAM OpenSCENARIO 1.x project is the successor project of the ASAM OpenSCENARIO Transfer project. Other related standards are ASAM OpenDRIVE, ASAM OpenCRG and the upcoming ASAM OSI standard.

2. Technical Content

As mentioned in the previous chapters, the ASAM OpenSCENARIO standard in release 1.0 comprises a UML data model, derived XML schema files, a two-part specification documentation (Programmers Reference Guide and Users Guide) and examples. Within the follow-up project proposed in this document, all before-mentioned deliverables shall be maintained and extended not only based on work results of the group, but also on user and implementer feedback.

Besides this general task of standard maintenance, within the predecessor project ASAM OpenSCENARIO Transfer project, a list of open issues was collected by the project members, this can be found in the repository for OpenSCENARIO.

The completion of these tasks may incorporate changes in the data model, documentation in the specification documents and the creation of explanatory examples.

Finally, within the ASAM Simulation Coordination Group meeting on February 5^th, 2020, it was decided to develop a migration path from ASAM OpenSCENARIO 1.x to ASAM OpenSCENARIO 2.0 in a joint effort of the two corresponding projects such that "[…] run time behavior of any scenario converted between the latest 1.x and 2.0 OSC languages shall be the same.

Both projects shall ensure an up-to-date ruleset for a migration path from 1.x to 2.0. The first release of such a ruleset shall be with the first release of 2.0

Project updates for OSC will be published and vetted by ASAM: These will include:

A high level overview of the project status
Technical information on features, document snippets, etc. to provide insight into the technical development of the standards. These will not be full specification documents or drafts.

The full feature set of 1.x shall be supported by 2.0 (i.e. 1.x is a subset of 2.0). I.e. everything you can do in 1.x you can do in 2.0, with the requirement that the result is the same.

New concepts introduced in 1.x must be synchronized with developments in the 2.0 project.[…]".

The above points indicate that, besides the data model, the specification documents and examples, the proposed ASAM OpenSCENARIO 1.x project shall provide a document on the migration of OpenSCENARIO 1.x features to OpenSCENARIO 2.0, which has to be developed in collaboration with the ASAM OpenSCENARIO 2.0 project.

2.1. Actions & Controllers

OpenSCENARIO defines a data model and a derived data format for describing the dynamic content of a virtual world. Actions are a key feature to modify or even create dynamic elements in the scenario. They are used to change lateral and longitudinal dynamics of a vehicle, change the time of day or setup a traffic situation. In the current version of the standard most of the Actions depend on the static components, like the road network at runtime. From a scenario implementation perspective it is challenging to know at which location the action will be executed at runtime. For this reason we will work on a more abstract way to define actions more independently from predefined content like the road network. Moreover we have several user requests to add more actions to OpenSCENARIO for parking, weather conditions, traffic and non movement actions (e.g. open door of a vehicle). These actions are necessary to describe more sophisticated scenarios, make them more explicit and will evolve the standard. The clarification of some of the already implemented actions will round up this work package.

2.2. Parameters & Conditions

With the expansion of the current existence of the OSC 1.0 standard, it is suggested to include more parameters and conditions to increase the ability of covering more complex scenarios. This requires the ability of involving parameters, especially ranges and distributions, for better representation of the scenarios.

Understand how the to integrate ranges with scenario : How to build a legitimate scenario with given ranges.
Implementation of scenario distributions : How the different type of scenarios included with the given parameter space and its related distributions.

2.3. Runtime Improvements & System Boundaries

A clear understanding of the OpenScenario format is critical to the representation of meaningful simulations. For this, it is imperative to:

Understand how the format is defined : How to build a legitimate scenario according to the rules defined in the standard specifications.
Implications of the scenario architecture in runtime : How the different scenario elements interact in real-time to achieve desired goal of the simulation.

The current version of the OpenScenario requires improvements on the relationship between actions, controllers, and entities. It is not always clear how these elements interact in runtime, and in the particular case of controllers and actions, their roles often overlap. Furthermore, understanding of the underlying conceptual runtime model can be further improved. While developing tools that employ the OpenScenario format, it is vital to understand what is under the responsibility of said tools and what is relayed to a common simulation tool, i.e. the system boundaries.

This group will further develop the existing characterization of the runtime model to improve its clarity and ground the expectations of scenario designers and tool developers alike. This endeavour will be reinforced by explicitly addressing the concept of system boundaries so as to facilitate the development of tools revolving around OpenScenario and promote their integration in a wider range of simulation environments.

2.4. Harmonization with OpenX

A further work package in the project will be the harmonization of the OpenSCENARIO 1.x standard with other OpenX standards.

As already mentioned above the development of the OpenSCENARIO 1.x standard needs to be aligned with the parallel OpenSCENARIO 2.0 development. The goal is that the two standards converge instead of diverge for being able to eventually merge them in a later project.

Furthermore there are several existing ASAM standards in the simulation domain like OpenDRIVE and OpenCRG, which complement OpenSCENARIO. Therefore the interfaces between these standards need to be compatible and changes in the interfaces need to be reflected in both affected standards.

Finally there are new upcoming standards like ASAM OSI, OpenONTOLOGY, OpenLABEL and OpenODD. Compatibility between OpenSCENARIO and these standards also needs to be ensured.

3. Project Resources

3.1. Work Packages [WPs]

3.1.1. General

WP 1: Harmonization with other OpenX standards
Description	With the ASAM OpenSCENARIO, OpenDRIVE and OpenCRG standards the static and evolving state of the environment of a vehicle can be modeled in terms of input files for an environment simulation. The environment simulation shall then forward the current state of the environment to a sensor model of an autonomous driving function using the upcoming ASAM OSI standard. Therefore it is necessary that OpenSCENARIO, OpenDRIVE and OpenCRG share a common set of functionalities with OSI, so ideally all neccessary functionality of OSI can be used and the standards are compatible. On the other hand clear system boundaries of OpenSCENARIO shall be defined, if single functionalities of the OSI standard shall not be provided by OpenSCENARIO. These functionalities could then be provided by other standards or customized inputs for an environment simulation. Examples of inconsistencies between OpenSCENARIO 1.0 and OSI are details of the environmental conditions and of entity attributes. Furthermore this work package can serve to keep OpenSCENARIO compatible with new versions of the existing OpenDRIVE and OpenCRG standards and the upcoming OpenODD, OpenONTOLOGY and OpenSCENARIO 2.0 standards.
Deliverable	Concept, changes in UML Model, documentation, examples
Effort (Man-days)	70 Man Days.
Responsible	Andreas Rauschert, BMW

WP 2: Maintenance
Description	This WP will run for the entire project lifetime and will deal with clarifications & fixes to the specification & documentation based on user feedback and experiences. It will interface with users of the standard and the community being fostered by ASAM to ensure feedback is integrated into the other WPs.
Deliverable	Adjustments to the standard documents to improve usability and clarity
Effort (Man-days)	20
Responsible	WP Coordinator

3.1.2. Parameters & Conditions

WP 3: Complex Conditions
Description	Perform an exploratory study on a more general mechanism for constructing complex conditions. Currently, for example, we have a requirement for conditions such as "a car is in front of another", "the lane next to an agent is empty" etc. We expect that these are just a few examples of what could be many. One potential avenue for exploration would be to have an 'object model' on top of OpenDrive that could be used to build conditions.
Deliverable	A proposal for how complex conditions could be constructed in general.
Effort (Man-days)	60 man-days
Responsible	Iain Whiteside (FiveAI)

WP 4: Parameters
Description	Build on top of the test case and existing executable scenario, generating a more generic terms for some of the shareable parameters and terms. More generally, the parameters and terms should match with the OSC 2.0 related terms. Those parameters should include basic ability of simple calculations, extractions and exchange. This part should also focusing on the range and distribution of the parameters for futher elaboration.
Deliverable	A generic terms and description of the parameters, a matching relations with the OSC 2.0, and within the OpenOntology project.
Effort (Man-days)	90
Responsible	Bolin Zhou (CATARC)

3.1.3. Actions & Controllers

WP 5: Abstract Definition of Actions
Description	The definition of actions in the current standard often require precise knowledge about the underlying road network. This can be challenging if an action has to be defined beforehand while it is unknown where exactly in the road network the action will be executed. Therefore this work package will focus on either extending already existing actions or implementing new action definitions if necessary in order to allow definitions of actions more independently form concrete configurations of the underlying road infrastructure. Abstract definitions of actions may also require the consideration of further aspects like extended opportunities to parameterize actions or the transformation between more concrete (e.g. follow a trajectory) and abstract (e.g. change a lane or turn) actions. Especially for the conversion from abstract definitions of actions into concrete ones, this work package will elaborate already existing mechanisms like NURBS curves and will enhance these mechanisms if applicable. The tasks within this work package will address the following issues: 22: Parameterized shape concept 145: Add relative turn maneuver as private action 155: Conversion of high-level maneuver descriptions to trajectories using parameterized NURBS 158: Define abstract lanechange target
Deliverable	Concept, Changes in UML model, documentation, examples.
Effort (Man-days)	40 Man Days.
Responsible	Rico Auerswald, Fraunhofer IVI.

WP 6: Requests for new Actions
Description	Propose additions to the UML model for new actions that were requested by users. These new actions include (the number indicates the issue #): 10: non movement actions, such as indicator, horn, opening of doors, head/taillights, emergency lights 163: Police officers regulating traffic, e.g. controlling the right of way at intersections, guiding to other lanes 164: Wind as environment action. Parameters could be speed / speed distribution, direction, height-profile 144: Parking maneuvers, parking spaces parallel / orthogonal / diagonal to the road, forward / reverse, park in / out, one go or multiple steps, 3 point turn, level change in a parking garage, u-turn For these new actions, the UML model needs to be extended. The actions need to be allocated to the appropriate group (private or global actions), new child elements for actions need to be created with appropriate hierarchy and attributes. The resulting additions of the UML model need to be aligned with the other changes of actions, and also with other projects (OpenX, OSI).
Deliverable	Concept, Changes in UML model, documentation, examples.
Effort (Man-days)	40 Man Days.
Responsible	Christian Koenig, Luxoft

WP 7: Clarifications and Completion of existing Actions
Description	With the current OpenSCENARIO 1.0 release several question on how to use certain Actions arose. Also for some Actions extensions were requested. The work package handles the issue #: 129: TrafficSwarmAction can endup with undefined velocity 141: Trajectory definition issues 117: Clarify how private actions are applied on multiple actors 111: Create new DeassignRoute action 105: Command Element 78: Clarification of references (Entity, ScenarioObjects, EntitySelections) 11: Override parameters required to assign controller in manoeuvre
Deliverable	Concept, Changes in UML model, documentation, examples.
Effort (Man-days)	40 Man Days.
Responsible	Andreas Rauschert, BMW

WP 8: Extension of Traffic Actions
Description	Autonomous traffic models like sources, sinks and traffic jams were identified as critical and promising features of OpenSCENARIO. Starting from the OpenSCENARIO 1.0 standard, these models are subject of review and enhancement. The conceptual models as well as their controlling actions. These issues refer to concrete requests: 71: Allow for TrafficActions to have different geometries 70: Allow more options in TrafficDefinition 69: Allow targeted driving/routing of vehicles in TrafficAction 68: Allow for teleportation of elements in Sinks 67: Re-add the TrafficAction "Jam"
Deliverable	Concept, Changes in UML model, documentation, examples.
Effort (Man-days)	60 Man Days.
Responsible	Andreas Hege, RA Consulting

3.1.4. Runtime & System Boundaries

WP 9: Enhancing the Conceptual Runtime Model
Description	This workpackage will focus on clarifying the nature of controllers, actions, and entities, as well as their interaction. The previously documented issues concerning these OSC elements, together with user experience, will be the starting point. This work will analyse the nature of these issues and attempt to develop an unifying set of rules that govern interaction. Where rules are lacking, changes to the nature of actions, controllers and actions, will be considered. It is expected that these efforts will lead to an improved understanding of the format, from the point of view of scenario designers and developers of scenario engines. Additionally, a cleaner connection between controllers and actions will enhance the sustainability of the format by improving malleability. Description of the conceptual runtime model is also in the scope of this work. Herein, clarifications will be added to address the responsabilities of a scenario engine, implementing the open scenario standard, and a simulation engine with which the scenario engine interacts. Improved descriptions of responsabilities should also contribute to the clarity of the format, thus benefiting desginers, implementers, and standard maintainers.
Deliverable	Expected updates to UML model and clarifications to the Programmer’s guide and user’s guide. Documentation on Potential recommendations on follow up work.
Effort (Man-days)	80 Man Days. Programmers’s guide and User’s guide.
Responsible	Bruno Augusto

WP 10: Sharpening the System Boundaries
Description	The standardization of scenarios affects many specific models: Sensor models, driver models, cybernetic models, environment models, traffic models etc. While OpenSCENARIO is best in describing the conceptual flow of stories, acts, maneuvers, events and actions, other models seem to be too complex and too volatile to fit into in the scope of the standard. By sharpening the system boundaries of OpenSCENARIO the working group will identify the core concepts and define interfaces to the systems that are out of scope. While focusing on the flow in the OpenSCENARIO standard, interfaces to a simulation environment would provide access to its entities like vehicles, pedestrians, controllers, traffic signals and environment conditions e.g. weather etc. This working package will likely be related to the OSI working group (Open Simulation Interface)
Deliverable	Concept, Changes in UML model, documentation, examples. Proposals for interfaces to a simulation environment.
Effort (Man-days)	50
Responsible	Andreas Hege

WP 11: Sequential Simulation Guidelines
Description	Support of sequential simulation environments , that require a well-defined execution order of actions, the behavior of an actor has to be defined in a sequential order. For those environments the entries in the XOSC file need to represent the sequence of the actions in the scenario. The event-driven architecture of OpenSCENARIO 1.0 does not provide a sequential scenario definition natively, although a large amount of scenarios could basically be defined sequentially. In addition, the readability of the scenario will be increased if the behavior of the actors is presented concentrated and in a sequential manner. In this work package an approach for a sequential definition shall be developed, which allows both creators and consumers of XOSC files to clearly distinguish sequential from event-driven scenarios (e.g. by a dedicated flag). This for example enables sequential simulation environments to decide if a provided XOSC-file can be processed correctly, and therefore enlarges the number of tools, which support OpenSCENARIO 1.x.
Deliverable	UML Model, User Guide
Effort (Man-days)	10
Responsible	Patrick Bouillon

3.2. Company Commitments

Member companies contribute resources for the project as per the following table.

Table 1. Commitments
Company	Location	Commitment	Participant(s)	Participant Email
51WORLD High Technology Co. Ltd.	China	25	Zugiu Mao; Shiqiang Bao	maozuqiu@51hitech.com; baoshiqiang@51hitech.com
AUDI AG	Germany	25	Laura Osterried	laura.osterried@audi.de
AVL List GmbH	Austria	25	Hannes Schneider; Eren Mungan; Daniel Stracabosko; Mirko Bulaja; Ilona Cieslik;	hannes.schneider@avl.com; Eren.Mungan@avl.com; Daniel.Stracabosko@avl.com; mirko.bulaja@avl.com; ilona.cieslik@avl.com;
Beijing Saimo Technology Co. Ltd.	China	25	Xue Xiaoqing	xuexiaoqing@saimo.ai
BMW AG	Germany	25	Andreas Rauschert	andreas.rb.rauschert@bmw.de
CATARC	China	50	Bolin Zhou	zhoubolin@catarc.ac.cn
DJI	China	25	Xihu Lai	laird.lai@dji.com
dSPACE GmbH	Germany	25	Patrick Bouillon	pbouillon@dspace.de
FiveAI	United Kingdom	25	Alex Heavens; Iain Whiteside	alex.heavens@five.ai; iain.whiteside@five.ai
Fraunhofer IVI	Germany	25	Rico Auerswald	rico.auerswald@ivi.fraunhofer.de
Huawei	China	25	Jianqin Liu	liujianqin@huawei.com
iASYS	India	25	Puran Parekh; Deepak Patil; Shantaram Jashav	ppuran@iasys.co.in; pdeepak@iasys.co.in;jshantaram@iasys.co.in
IKA RWTH Aachen University	Germany	25	Hendrik Weber	hendrik.weber@ika.rwth-aachen.de
IRT SystemX	France	25	Ismet Addoui	ismet.addoui@irt-systemx.fr
KPIT Technologies GmbH	Germany	25	Winifred Paul	Winifred.Paul@kpit.com
LiangDao GmbH	China	25	Jiaxin Sun	jiaxin.sun@liangdao.ai
Luxoft	Germany	22	Dr Christian König	ckoenig@luxoft.com
Navinfo	China	25	Wei Sun	sunwei60804@navinfo.com
PMSF	Germany	25	Pierre R. Mai	pmai@pmsf.eu
SAIC MOTOR	China	25	Cheng Cheng; Lu JunYan; Jean Wang	chengcheng@saicmotor.com; lujunyan@saicmotor.com; wangyuanjing@saicmotor.com
Siemens AG	Netherlands	25	Joan Roca	joan.roca@siemens.com
Tracetronic GmbH	Germany	35	Jens Grünberg	jens.gruenberg@tracetronic.de
VIRES Simulationstechnologie GmbH	Germany	25	Andreas Biehn	Andreas.Biehn@hexagon.com
Volvo Car Corp.	Sweden	25	Emil Knabe	emil.knabe@volvocars.com
VTI	Sweden	25	Bruno Augusto	bruno.augusto@vti.se
WMG University of Warwick	United Kingdom	40	Dr Jason Zhang; Siddartha Khastgir	Jason.Zhang@warwick.ac.uk; s.khastgir.1@warwick.ac.uk
TOTAL		697

Members of the CCB are project participants with the necessary permissions on the OpenSCENARIO repository to:

Push content to the protected project branches
Accept merge requests from other project members

Table 2. Change Control Board (CCB)
Participant contact details (name, phone, email)	Company (Name, Location)

The following intellectual property will be transferred from member companies to ASAM:

Table 3. Intellectual Property
Company (Name, Location)	IP Description	Value (Euros)

3.3. Effort Summary

Table 4. Required Effort (man-days)
WP Category	Project Members	Service Provider	Total
Harmonization & Maintenance (WP1-WP2)	77	13	90
Parameters & Conditions (WP3-WP4)	135	15	150
Actions & Controllers (WP5-WP8)	155	25	180
Runtime & System Boundaries (WP9-WP10)	115	15	130
Sequential Simulation (WP11)	8	2	10
Total	490	70	560

Tasks for a service provider will include, but are not limited to:

Adjustments to the UML model, the derived .xsd schema and the model documentation - this includes maintenance functions based on user feedback as well as implementation of new features
Support creation of examples
Support creation of concepts that e.g. demonstrate new features

Table 5. Resource Check
	Project Members	Service Provider	Total
Required	490	70	560
Committed	697

3.3.1. Budget

This section details the budget required by the project to e.g. pay service providers and the funds to be provided by ASAM. The limits are determined as a factor of the total required work effort. The corresponding effort is allocated a fixed price of 700 EURO per man-day.

Table 6. Funding limits
Project Type	Factor
New, major, minor or revision standard development project	0.25
Study project	0.25
Concept project	0.75

Table 7. Funds required for Service Providers
Task Description	Effort [man-days]	Cost [€700 / day]
UML model modification	50	35.000 EUR
1.x documentation (UML model, migration guidelines)	20	14.000 EUR

4. Project Plan

4.1. Timeline

For the proposed ASAM OpenSCENARIO 1.x project, a project duration of one year is planned, i.e. the project deadline is planned for Q2/2021. Within the project, a release 1.1 is planned for Q4/2020. After this release, work within the project group shall focus on collecting open issues, providing user support and supporting the migration towards OpenSCENARIO 2.0.

4.2. Deliverables

At the end of the project, the project group will hand over the following deliverables to ASAM:

Item No.	Description
01	Specification Users Guide
02	Specification Language Reference
03	UML Data Model
04	XSD Schema Files
05	List of analyzed deficits and proposed improvements
06	Examples
07	Migration documentation for OpenSCENARIO 1.0 features to OpenSCENARIO 1.x
08	Migration documentation for OpenSCENARIO 1.x features to OpenSCENARIO 2.0

4.3. Review Process

The following quality assurance measures shall be carried out by the project:

Project member review
Public review
Reference implementation