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 5th, 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:

  1. A high level overview of the project status

  2. 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

Zuqiu 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

DLR

Germany

25

Heinrich Ody

heinrich.ody@dlr.de

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

722

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

  1. Push content to the protected project branches

  2. 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

722

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.

timeline

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