Project Number

P2021-05

Domain

Simulation

Relevant Standard

ASAM OpenSCENARIO V1.2.0 or V1.6.0 (with breaking changes)

Project Name

P_2021_05_OpenSCENARIO_BS_V1-X-0_Minor

Project Type

Minor Version Development

Start Date

03.09.2021

End Date

15.04.2022

ASAM Funds

49.000€

1. Executive Summary

This project is the successor to the OpenSCENARIO 1.x project and is intended to further develop ASAM OpenSCENARIO V1.1.0. The standard ASAM OpenSCENARIO 1 provides the data model, the specification and examples for the description of dynamic content in driving simulation. It 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 1 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 standards ASAM OpenDRIVE and ASAM OpenCRG. The consolidated content of the three standards provides comprehensive input for above-mentioned use-cases.

One goal of the proposed project is the completion of tasks that could not be completed within the predecessor project OpenSCENARIO 1.x, whose outcome was the release of ASAM OpenSCENARIO V1.1.0. Another goal of the proposed project is to provide support for users and implementers of OpenSCENARIO 1. Finally, close collaboration with the ASAM OpenSCENARIO 2.0 project is part of the proposed project, to shape a convergence path for ASAM OpenSCENARIO 1 outcomes and developments. Yet, it cannot be guaranteed that the convergence path can be fully developed within the proposed project. It may require further releases of ASAM OpenSCENARIO 1, which will be developed in subsequent OpenSCENARIO 1.x projects.

2. Overview

2.1. Motivation

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

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

After completion of the ASAM OpenSCENARIO Transfer project, ASAM OpenSCENARIO 1.0.0 was released in March 2020. This version was the first complete and fully documented version of OpenSCENARIO. First significant user feedback came from the use and implementation of this version by research institutes, tool vendors and OEMs. The feedback was transformed into issues in the ASAM GitLab of the standard project. Many of them were handled during the recent OpenSCENARIO 1.x project and finalized in the OpenSCENARIO V1.1.0 release. Due to the great interest and the resulting amount of issues created (~60 at start of project, ~120 created during project), not all issues could be handled. Therefore, the author of this proposal strongly suggests the continued development and maintenance of ASAM OpenSCENARIO 1 to support, sustain and increase the application of the standard by the above mentioned parties.

During the recent OpenSCENARIO 1.x project, the remaining issues were reviewed and prioritized by the project group members in preparation for a successor 1.x project. This list shall be considered as work backlog for the new OpenSCENARIO 1.x project. It’s suggested by the author of this proposal to use this backlog to realize 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 convergence path between ASAM OpenSCENARIO 1 and ASAM OpenSCENARIO 2 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 first release of a corresponding ruleset shall be delivered with the first release of the ASAM OpenSCENARIO 2.0 project. To enable this, the new 1.X project includes a work package that is tasked with harmonization between OpenSCENARIO 1 and OpenSCENARIO 2. 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 convergence 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.

2.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) and OpenSimulationInterface (i.e. interfaces of simulator modules like virtual sensors), 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

2.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 ASAM OpenSCENARIO 1 is used together with other standardised formats to fulfil the goal of the Use-Case. Therefore a requirement is that ASAM OpenSCENARIO 1 is compatible and consistent with other formats.

2.4. Relations to Other Standards or Organizations

The proposed ASAM OpenSCENARIO 1.x project is the successor project to the previous OpenSCENARIO 1.x project. Other related standards are ASAM OpenDRIVE, ASAM OpenCRG and ASAM OpenSimulationInterface standard.

3. Technical Content

As mentioned in the previous chapters, the ASAM OpenSCENARIO standard in release V1.1.0 comprises a UML data model, a model reference documentation, derived XML schema files, a two-part specification documentation (Modeling Rules 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 1.X, a list of open issues was collected and prepared by the project members. It list 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 convergence path between OpenSCENARIO 1 and OpenSCENARIO 2 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 OpenSCENARIO 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.

New concepts introduced in this OpenSCENARIO 1.x project must be synchronized with the development in the 2.0 project.

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

3.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 suporting those will evolve the standard. The clarification of some of the already implemented actions will round up this work package.

3.2. Parameters & Conditions

With the expansion of the current existence of the ASAM OpenSCENARIO V1.1.0 standard, it is suggested to include more parameters and conditions to increase the ability to cover more complex scenarios. This requires the ability to involve parameters, especially ranges and distributions.

  1. Understand how the to integrate ranges with scenario: How to build a legitimate scenario with given ranges.

  2. Implementation of scenario distributions: How the different type of scenarios included with the given parameter space and its related distributions.

3.3. Runtime Improvements, System Boundaries, and General Clarifications

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

  1. Understand how the format is defined: How to build a legitimate scenario according to the rules defined in the standard specifications.

  2. Implications of the scenario architecture in runtime: How the different scenario elements interact in real-time to achieve desired goal of the simulation.

As the format adopted by the simulation community, it is imperative to keep up with users and provide clarifications on the standard’s concepts as issues arise. This group will focus on maintaining a clear definition of the underlying conceptual runtime model by ensuring that the existing definitions are still relevant.

Additional effort will be placed in highlighting system boundaries, i.e. what is under the responsibility of different simulation components and how they relate to the OpenSCENARIO standard. A sharp definition of system boundaries promotes uniform levels of understanding between users which facilitates interaction, and tool adoption.

Finally, general questions that arise from using the standard will be address by this group. These are usually questions that are not tightly coupled to one concept, but instead arise from the interaction of different elements of the OpenSCENARIO model, and thus require a more holistic approach in their solutions.

3.4. Harmonization with OpenX

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

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

Furthermore there are several existing ASAM standards in the simulation domain like OpenDRIVE, OpenCRG and OpenSimulationInterface, 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 OpenONTOLOGY, OpenLABEL and OpenODD. Compatibility between OpenSCENARIO and these standards also needs to be ensured.

4. Project Resources

4.1. Work Packages [WPs]

4.1.1. General

WP 1: Project lead

Description

This WP will run for the entire project lifetime and will deal with leading the technical developments the CCB and improvements of the project workflow.

Deliverable

Adjustments to the workflow processes (e.g. GitLab labels/boards), hosting of CCB meetings, preparation of member meetings.

Effort (Man-days)

20

Responsible

Andreas Rauschert (BMW Group)

WP 2: Harmonization with OpenX

Description

This WP will run for the entire project lifetime and will deal with harmonizing the domain models of the several OpenX standards (OpenSCENARIO 2, OpenSimualtionInterface, OpenXOntology, OpenLABEL, OpenODD). It also supports the convergence path of 1.x and 2.x. The task will be mainly the identification of overlaps and differences and the coordinated resolution of these together with the members of the other OpenX projects.

Deliverable

Adjustments to the OpenSCENARIO 1.x domain model. Input for adjustments of the domain models of the other standards in their projects.

Effort (Man-days)

40

Responsible

Andreas Rauschert (BMW Group)

4.1.2. Parameters & Conditions

WP 3: Concept for a generic road network integration

Description

Currently the road network for OpenSCENARIO is pretty close linked to OpenDRIVE. In fact a scenario needs some definitions from the road network to make calculations on trajectories and routes reproduceable with the scenario engine. Currently it highly depends on the implementation of the scenario engine.
We want to create a concept how a generic road network can be linked to a scenario and standardize these aspects.

The tasks within this work package will address the following issues:
#322 Distance for positions on different roads
#294 How longitudinal reference line offsets crossing multiple roads should be defined is unclear
#359 Dependency of OSC actor positions to road network files
#256 Clarify RouteStrategy behavior for Waypoints in Routes

Deliverable

Concept, Changes in UML model, documentation, examples.

Effort (Man-days)

90

Responsible

Jens Grünberg (Tracetronic GmbH)

WP 4: Maintenance for parameters and conditions

Description

In OpenSCENARIO 1.1 we integrated more generic terms and description of the parameters and parameter distributions to improve the reuseability of scenarios. Parameters include the basic ability of simple calculations, extractions and exchange. Moreover it is possible to define a deterministic and stochastic distribution of parameters. In these work package we want to refine and extend these concepts and align them more to with the OSC 2.0 related terms and the OpenONTOLOGY.

The tasks within this work package will address the following issues:
#353 Check, if deterministic and stochastic distributions can be mixed
#356 Random seed needs to be of type integer
#138 Parameters during runtime (Runtime Variables)
#339 Explain how runtime parameters (ParameterActions, …​) are used
#37 Condition allowing for check of free lane?
#266 New property for Trigger - TriggeringTimes?
#362 Allow definition of abstract parameters and scenarios

Deliverable

Concept, Changes in UML model, documentation, examples.

Effort (Man-days)

70

Responsible

Jens Grünberg (Tracetronic GmbH)

4.1.3. Actions & Controllers

WP 5: Extension of existing actions

Description

Some use-cases require existing concepts to be extended or refined. Additional attributes may be required, or other extensions may be necessary to allow users of the standard to express their desired situation. This group will take care of integrating such additions to the standard.

The tasks within this work package will address the following issues:
#11 Override parameters required to assign controller in manouvre
#22 Parametrized shape concept
#158 Define abstract lanechange target i.e. independent from lane enumeration in XODR e.g. “leftmost lane”
#165 Harmonize LaneChangeAction and LaneOffsetAction
#224 Trajectory of a reversing / backing vehicle?
#352 Speed profile for speed action
#274 Support multiple shapes in trajectory

Deliverable

Concept, Changes in UML model, documentation, examples.

Effort (Man-days)

40

Responsible

Andreas Rauschert (BMW Group)

WP 6: Addition of new actions

Description

With the growing acceptance and usage of OpenSCENARIO 1.1, demand for new actions also increases. In this group, proposals for new actions will be discussed and implemented into the standard.

The tasks within this work package will address the following issues:
#10 Non movement actions
#111 Create new DeassignRoute action
#145 New private action like a “relative turn” for OpenSCENARIO 1.x
#155 Conversion of high-level maneuver descriptions to trajectories using parametrized NURBS
#144 Parking Maneuvers in OpenScenario 1.x
#163 Police officers regulating the traffic

Deliverable

Concept, Changes in UML model, documentation, examples.

Effort (Man-days)

40

Responsible

Christian Koenig (Luxoft)

WP 7: Clarifications and completion of existing actions

Description

Actions that exist in OpenSCENARIO 1.1 are sometimes specified in an ambiguous way, and leave room for interpretation, or may even be contradictory. This hinders acceptance of the standard by scenario designers and tool providers. This work package will handle tasks that describe such ambiguities or errors.

The tasks within this work package will address the following issues:
#120 Do trajectories have global or “local” (relative) positioning in the road network?
#178 Speed undefined for added entity during runtime (time > 0)
#196 Clarification needed for Source/Sink/Swarm in TrafficAction
#226 followTrajectory “closed” trajectories is unclear
#240 Gear number in OverrideGearAction is a double
#247 LongitudinalDistanceAction timeGap and distance are mutually exclusive but stereotyped as attributes
#268 Can SynchronizeAction work with Pedestrians?
#269 Relationship of DynamicConstraints of Lateral/LongitudinalDistanceAction and Performance of Vehicle
#278 One entity can only have one controller
#297 Entity heading while following a trajectory
#308 Fix XOR bug in FollowTrajectoryAction
#309 Fix cardinalities in DynamicConstraints
#341 SynchronizeAction – missing proposed additions to user guide is OK
#306 Problem with UserDefinedAction in Init Section
#141 Trajectory definition issues

Deliverable

Concept, Changes in UML model, documentation, examples.

Effort (Man-days)

40

Responsible

Andreas Rauschert (BMW Group)

WP 8: Extension of traffic actions

Description

Probabilistic distributions of traffic participants may become more relevant in the future, as ADAS development becomes more mature. To support that, a comprehensive approach to describe traffic participants and their actions is needed.

The tasks within this work package will address the following issues:
#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"
#252 TrafficDefinition for TrafficSinkAction
#288 Extend TrafficDefinition to pedestrians

Deliverable

Concept, Changes in UML model, documentation, examples.

Effort (Man-days)

40

Responsible

Christian Koenig (Luxoft)

4.1.4. Runtime, System Boundaries, and General Clarifications

WP 9: Clarifications on existing concepts

Description

This workpackage will focus on improving the description of different concepts that form the standard. The aim is to improve the documentation, and the work will be guided by the clarification requests created in the previous project:

#319 Impact of entity models choices in runtime.
#318 How Actions take in consideration actor performance.
#317 How to track a goal with a motion control action.
#299 Interaction between actions which share a control domain, both with different levels of control.
#298 Meaning of speed (representation referential, impact of lateral actions).

Deliverable

Clarifications to the User’s guide. Modifications to the UML model should be contained to annotations

Effort (Man-days)

80

Responsible

???

WP 10: New functionality and legacy components

Description

The OpenSCENARIO standard needs to evolve to account for simulation imposed by its users. This work package will consider the expansion of existing functionality in order to cover the presently identified needs of the consortium members.

Additionally, legacy components remain in OpenSCENARIO which were not completely rooted in the previous releases. Some of these are couplings to other standards, in terms of references and nomenclature. Where applicable, these will be addressed by explicitly highlighting the relationship/connections between standards. If not longer relevant, these couplings will be rooted out.

The work will be guided by the currently existing issues:
#307 Creating platform agnostic scenarios.
#358 Consider the possibility to support error injection in the standard.
#349 Remove dependencies from OpenDRIVE in traffic light controllers.

Deliverable

Utilization concepts, updated UML model and user guide.

Effort (Man-days)

80

Responsible

???

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

BMW Group

Germany

25

Andreas Rauschert

andreas.rb.rauschert@bmw.de

IAV GmbH

Germany

25

Clemens Habedank (on behalf of BMW)

clemens.habedank@partner.bmw.de

Fraunhofer IVI

Germany

25

Rico Auerswald

rico.auerswald@ivi.fraunhofer.de

Advanced Data Controls Corp.

Japan

15

YASUYUKI NAKANISHI

nakanisi@adac.co.jp

Ansys

Germany

25

Benedikt Eberhardinger

benedikt.eberhardinger@ansys.com

Aptiv

Germany

25

Michele Giorelli

michele.giorelli@aptiv.com

Automotive Artificial Intelligence (AAI) GmbH

Pakistan

30

Muhammed Idrees

Muhammed.Idrees@automotive-ai.com

Automotive Data of China (Tianjin) Co. Ltd

-

30

Bolin Zhou

zhoubolin@catarc.ac.cn

AVL

Croatia

25

Daniel Stracaboško

daniel.stracabosko@avl.com

AVL

Turkey

25

Eren Mungan

eren.mungan@avl.com

AVL GmbH

Croatia

30

Mirko Bulaja

mirko.bulaja@avl.com

DLR

Germany

25

Heinrich Ody

heinrich.ody@dlr.de

dSPACE

Germany

25

Michael Kluge

MKluge@dspace.de

Five AI

United Kingdom

15

Alexander Heavens

alex.heavens@five.ai

Hexagon

Germany

25

Adrian Schultz

adrian.schultz@hexagon.com

IASYS

India

25

Puran Parekh

ppuran@iasys.co.in

IPG Automotive GmbH

Germany

25

Jannik Müller

jannik.mueller@ipg-automotive.com

JOYNEXT GmbH

Germany

25

Lars Franke

Lars.Franke@joynext.com

KAN Engineering

United Kingdom

20

Amir Soltani

a.soltani@kanengineering.co.uk

Kontrol GmbH

Österreich

25

Jinwei Zhou

j.zhou@kontrol.tech

Luxoft (A DXC Technology company)

-

25

Igor Skakunov

igor.skakunov@dxc-luxoft.com

Luxoft GmbH

Germany

25

Christian König

christian.koenig@dxc.com

RA Consulting GmbH

Germany

25

Andreas Hege

a.hege@rac.de

Ridecell Inc.

United States

30

Arpan Chakraborty

arpan@ridecell.com

Shanghai Motor Vehicle Inspection Certification&Tech Innovation Center Co. Ltd.

China

60

Guan Wang

guanw@smvic.com.cn

Siemens

Netherlands

25

Martijn Schut

martijn.schut@siemens.com

Tata Consultancy Services Limited

India

25

Asutosh Mishra

asutosh.mishra@tcs.com

Tencent

China

25

Haining Du

hainingdu@tencent.com

TraceTronic GmbH

Deutschland

35

Jens Grünberg

jens.gruenberg@tracetronic.de

University of Applied Sciences Kempten

Germany

15

Arsalan Haider

arsalan.haider@hs-kempten.de

Volvo Cars

Sweden

25

Emil Knabe

emil.knabe@volvocars.com

VTI

Sweden

25

Bruno Augusto

bruno.augusto@vti.se

TOTAL

805

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)

4.3. Effort Summary

Table 4. Required Effort (man-days)
WP Category Project Members Service Provider Total

General (WP1-WP2)

50

10

60

Parameters & Conditions (WP3-WP4)

140

20

160

Actions & Controllers (WP5-WP8)

140

20

160

Runtime & System Boundaries (WP9-WP10)

140

20

160

Total

470

70

540

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

  • Adjustments to the UML model (Enterprise Architect) and generation of the derived .xsd schema and model documentation - this includes maintenance of features based on user feedback as well as implementation of new features

  • Support creation of example scenarios

  • Technical writing of the 'User Guide' and the 'Modeling guidelines'

  • Support creation of concepts that e.g. demonstrate new features

Table 5. Resource Check
Project Members Service Provider Total

Required

470

70

540

Committed

660

70

730

4.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]

Support creation of concepts and examples, UML model modification including technical writing of Modelling Guidelines, generation of xsd schema and model documentation

50

35.000 EUR

Technical writing of User Guide

20

14.000 EUR

5. Project Plan

5.1. Timeline

Timeline of work packages may change once the project starts.

For the proposed ASAM OpenSCENARIO 1.x project the kick-off is planned for mid of Q3/2021. A project duration of one year is planned, i.e. the project deadline is planned for Q2/2022. Within the project, a release 1.2 is planned for end of Q1/2022. After this release, work within the project group shall focus on preparing a proposal for a next 1.x project, providing user support and supporting the migration towards OpenSCENARIO 2.

timeline.mmd

5.2. Deliverables

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

Item No. Description

01

Specification 'User Guide'

02

UML Data Model

03

XSD Schema Files

04

UML model HTML documentation

05

Examples

06

Migration documentation for OpenSCENARIO 1.1 features to OpenSCENARIO 1.x

07

Specification 'Modelling Guidelines'

08

List of analyzed deficits and proposed improvements (in ASAM GitLab)

5.3. Review Process

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

  • Project member review

  • Public review

  • Reference implementation