Executive Summary

The OpenSCENARIO Concept Project (P2019-02), was initiated in parallel to the transfer project of the OpenSCENARIO standard to the ASAM domain. The goal of this transfer project (P2019-01) was a revision of OpenSCENARIO to ensure adherence to the ASAM standard format, leading to a major version release of v1.0.

The purpose of the Concept Project was thus to address features and adaptations to be implemented in future versions of the OpenSCENARIO standard. The concept project summary was delivered to ASAM TSC – OSC 2.0 Concept Document. This project proposal is aimed at taking the concepts specified in the concept document and continue and develop the next generation of OpenSCENARIO standard – OpenSCENARIO 2.0. A rough estimate is that the development of such a standard can be achieved within a year, aiming at release in Q2 of 2021.

Based on the considerations of the concept group, OpenSCENARIO 2.0 is proposed to be founded on the concept of a domain-specific language (see Methodology and Language Concepts chapters in the concept document), that should support all levels of scenario description, from the very abstract to the very concrete in a suitable way.

The OpenSCENARIO 2.0 concepts take proven features and capabilities of OpenSCENARIO 1.0, like its event-based scenario execution model, and place them in a more general and expressive language framework, to serve as the foundation for both incremental improvements and more revolutionary enhancements.

In comparison to OpenSCENARIO 1.0, a more detailed set of actions and attributes for the relevant simulation models shall be defined to allow for a more comprehensive scenario description and to improve exchangability. This is addressed by the introduction of a domain model (see Concept document chapter: Architecture).

Beyond such improvements, the proposed domain-specific language supports the creation of more complex scenarios through flexible composition and parametrization of component scenarios in ways that allow realistic, emergent behavior to occur. This is expected to enable massive testing and verification of new, complex hardware and software systems, and their interaction with the complex environment of driving.

The concept group believes that the proposed concepts and direction will enable OpenSCENARIO 2.0 to supply a step-function in its ability to describe full, complex simulations and/or tests, addressing all the required elements, and utilizing existing building blocks (like OpenDRIVE or OpenCRG).

In order to leverage investments in OpenSCENARIO 1.0, a clear migration path and compatibility concept is part of the overall OpenSCENARIO 2.0 concepts, as described in Concept document: Backward Compatibility to Earlier Releases.

1. Overview

1.1. Motivation

The OpenSCENARIO Concept Project (P2019-02), was initiated in parallel to the transfer project of the OpenSCENARIO standard to the ASAM domain. The goal of this transfer project (P2019-01) was a revision of OpenSCENARIO to ensure adherence to the ASAM standard format, leading to a major version release of v1.0.

The purpose of the Concept Project was thus to address features and adaptations to be implemented in future versions of the OpenSCENARIO standard. The concept project summary was delivered to ASAM TSC – OSC 2.0 Concept Document. This project proposal is aimed at taking the concepts specified in the concept document and continue to develop the next generation of OpenSCENARIO standard – OpenSCENARIO 2.0

1.2. Use Cases

AV use cases are influenced by a variety of factors, such as ODDs, map features, traffic model, weather model, and others. The scenarios assigned to the use cases can be parametrized and typically run in multiple modes of operations. These modes include:

  • On track test

  • On road tests

  • In sim tests

  • In replay (i.e. resimulation) tests

The intent of OpenScenario 2.0 is to cover use cases at varying levels of autonomy. Hence, they should represent an adequate level of complexity including maneuvers and ODD features that are not accounted for otherwise. An example is an AV driving on a complex road with road features such as roundabouts, bus stops, highway ramps, entries and exits or in dense traffic where various maneuvers like cut-ins, lane reductions and cross traffic with other agents on the road.

A detailed breakdown of the usecases can be found in the OpenSCENARIO 2.0 Concept Document here.

1.3. User Stories

1.3.1. SHARE

  1. As an AV/ADAS developer company, I can share with other companies the scenarios I built to test my technology.

  2. As an AV/ADAS developer company, I can search, review and reuse scenarios built by other companies.

  3. As a test engineer working for an AV/ADAS development company, I can build and run tests as similarly as possible to tests other developers at other companies are running.

  4. As a test engineer, I can build and run tests as similarly as possible on different execution platforms.

  5. As a researcher developing new technology, I can reutilize industry and open source scenarios to advance my research.

1.3.2. CERTIFY & ANALYSE

  1. As an auditor/regulator, I can understand how AV/ADAS developers are testing their products.

  2. As an auditor/regulator, I can compare the outcome of different execution platforms when they have the same OpenSCENARIO input.

  3. As a safety consultant, I can recommend specific scenarios and related conditions (parameters) to my clients to test their products.

  4. As a member of the public, I can learn more details about how AV/ADAS products are tested by AV/ADAS developers.

  5. As government agency, I can understand what parts of the Operational Domain are verified by an AV/ADAS developer through each scenario.

1.3.3. DEVELOP

  1. As a tool developer, I can reutilize constructs, artifacts and libraries to create tools compatible with other tool vendors in industry.

  2. As a service provider, I can integrate tools from multiple tool vendors to provide an integrated solution to test AV/ADAS scenarios.

  3. As a system engineer working for an AV/ADAS developer company, I can fully trace which hardware and software in the AV/ADAS stack is verified by which tests.

  4. As a software developer, I can process scenario information from different software/hardware releases and produce comparison charts to provide trend and gap analysis.

  5. As an existing tool provider or consumer, I can migrate information from previous versions of OpenSCENARIO into OpenSCENARIO 2.0.

  6. As a system engineer working for an AV/ADAS developer, I can decompose high level use cases in a standardised way.

1.3.4. CREATE

  1. As a content developer, I can use OpenSCENARIO 2.0 to create test scenarios that I can supply to my customers who use a OpenSCENARIO 2.0 compliant toolchain.

  2. As a test engineer, I can transform abstract test descriptions into OpenSCENARIO 2.0 (e.g. NCAP tests, UNECE regulations, any requirement list, …).

  3. As a development project lead, I can write scenarios on an abstract level to discuss the functional behavior with the stakeholders.

  4. As a development project lead, I can create scenarios on an abstract level to document the functional behavior for legal reasons.

  5. As a stakeholder, I can create natural language scenarios without having any knowledge about technical details.

1.3.5. SOTIF-BASED RISK CONSIDERATION

  1. As a SOTIF safety engineer and/or V&V engineer, AV developer, scenario creator, I can use OpenSCENARIO 2.0 to discover scenarios that are going to uncover safety hazards. This refer to SOTIF and safety hazards that can be present even if the system is functioning as designed, without a malfunction.

  2. As a SOTIF safety engineer and/or V&V engineer, AV developer, scenario creator, I can use OpenSCENARIO 2.0 to create scenarios that are going to produce emergent behavior of the DUT to discover unknown unknows. OpenSCENARIO 2.0 shall enable to demonstrate that minimum residual risk is attained by the DUT. This is because SOTIF focuses on ensuring the absence of unreasonable risk due to hazards resulting from insufficiencies in the intended functionality or from reasonably foreseeable misuse.

1.3.6. DRIVING MISSION-BASED SCENARIOS

  1. As an end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable specification of a driving mission through inclusion of multiple maneuvers in a sequence or in parallel for both DUT and any other traffic agents.

  2. As an end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable accomplishing a select driving mission with an indication of whether the mission has been accomplished, what are the mission KPIs and how they are computed, and whether the unambiguous goals of the mission have been attained.

1.3.7. TRAFFIC MODEL INCLUSION

  1. As a traffic model developer, an ADS developer, or end-to-end V&V engineer, I can use OpenSCENARIO 2.0 to enable inclusion of multiple traffic models and AI-based traffic agents in the scenarios and evaluators. Also, OpenSCENARIO 2.0 shall enable inclusion of mechanisms to extract scenarios from the traffic models.

  2. As a test engineer, I can transform from high level scenario description to low level scenario descriptions and vice versa.

1.3.8. EXECUTE

  1. As a test engineer, I can execute different OpenSCENARIO 2.0 files in an automated way with my OpenSCENARIO 2.0 compliant toolchain; no file modifications are needed.

  2. As a test engineer, I can execute the same OpenSCENARIO 2.0 files on different OpenSCENARIO 2.0 compliant toolchains.

  3. As a test engineer, I can convert abstract scenarios into tests.

1.3.9. DESCRIBE OBSERVATIONS

  1. A simulation tool can describe randomly executed simulation runs. If the Simulation was run with stochastic metrics, the user wants to have the concrete description of what has happened in OSC2.0 Format.

  2. A traffic observer can describe what occured in real world with OSC2.0

  3. A test engineer on a test track can describe with OSC2.0 what specific scenario he has observed on a test track. In such a way tolerances and deviations between test description and test execution will become obvious.

1.4. Requirements

OpenSCENARIO 2.0 should address the basic requirements and features stated in the concept project proposal document. These are repeated here for clarity and their detailed description can be found in the concept project proposal document for OSC 2.0.

Table 1. Features
Feature Type

F001: Maneuver model

Change

F008: High level maneuver descriptions

New

F003: Traffic Model

New

F007: Parameter stochastics

New

F002: Driver Model

New

F004: Environmental Condition Model

New

F009: Replay of Recorded Scenarios

New

F010: Automatic parameter calculation

New

F005: Infrastructure Event Model

New

F006: Vehicle dynamics model

Change

F011: Additional metadata for parameters

New

F012: Language Constructs for Localization

New

Proposal workshop and revisions can be found in the workshop summary set of slides.

Table 2. Issue Descriptions
ID Title/Description

R001

Avoid Different Ways to Model

R002

Define Elements as 'Mandatory' Only When Absolutely Needed

R003

Maintain Independence and Open Linking Between Standards.

R004

Define Three Levels of Control for Ego Vehicles.

R005

Allow Tool-Vendor Specific Extensions.

R006

Allow Definition of Feature Subsets

R007

Define Semantics to Enable Reproducibility and Single Interpretation. (Workshop phrasing was: Well Defined Semantics Requirement )

R008

Allow both Open-loop and Closed-loop Simulation by the Same Maneuver Descriptions. (Workshop phrasing: Maneuver Description Shall be Suitable for Open-loop and Closed-loop Simulation)

R009

Define Parameter Boundaries

R010

Synchronize Maneuvers and Events

R011a

Allow Definition of Success Criteria for Individual Maneuvers, and for Full Scenarios and Tests - DUT criteria

R011b

Allow Definition of Success Criteria for Individual Maneuvers, and for Full Scenarios and Tests - non-DUT criteria

R012

Allow Textual Editing of the Format. (Workshop phrasing was: Suitability for textual editing)

Another major requirement is the migration path from OpenSCENARIO 1.0 – this is described in details in the next chapter – “Backward Compatibility to Earlier Releases”

For completeness – the following are explicit non requirements of the standard:

  1. A specific software architecture and tools aimed at using the format.

  2. Assumption on the testing platform and simulation tools being used.

  3. Method to store and categorize scenarios.

  4. Methods to specify Operational Design Domains (ODD).

  5. OSC is not enforcing any standard API to simulators and testing platform, although such a standard might be desirable in future.

ASAM is addressing some of these goals through other activities, like OSI, OpenODD and more.

1.5. Relations to Other Standards or Organizations

1.5.1. Backward Compatibility to Earlier Releases

OpenSCENARIO 2.0 is intended to be a full superset of the features of OpenSCENARIO 1.0. This means that a migration path for OpenSCENARIO 1.x scenarios to OpenSCENARIO 2.0 will be included in the release version of OpenSCENARIO 2.0.

Migration of scenarios might require conversion to 2.0 syntax and semantics. The run time behavior of any scenario converted from the latest OpenSCENARIO 1.x to OpenSCENARIO 2.0 shall be the same.

A conversion of OpenSCENARIO 2.0 scenarios to OpenSCENARIO 1.x will in general not be possible, since OpenSCENARIO 2.0 is intended to be a true superset of OpenSCENARIO 1.x. However, conversion of a subset of OpenSCENARIO 2.0 that maps to the feature set of OpenSCENARIO 1.x will be possible.

The standard development projects for the 1.x and the 2.0 tracks shall ensure an up-to-date ruleset for a migration path from 1.x to 2.0.

1.5.2. References to Other Standards

At the time of writing OpenSCENARIO is the only proposed standard to describe maneuvers and testing scenarios. The standard is designed to integrate with the requirements of other safety standards being developed in parallel. These include:

ISO

21448 (SOTIF), 34501 (Terms and Terminology for test scenarios), 34502 (Engineering framework for test scenarios), 34503 (ODD taxonomy for test scenarios), 34504 (Test scenario cartograms)

SAE - J3164 is a proposed document to describe manuevers and behaviours.

UL - UL4600 is a standard published by UL, describing how to write a safety case for AVs.

2. Technical Content

Based on the considerations of the concept group, OpenSCENARIO 2.0 is proposed to be founded on the concept of a domain-specific language (see Methodology and Language Concepts chapters in the concept document), that should support all levels of scenario description, from the very abstract to the very concrete in a suitable way.

The OpenSCENARIO 2.0 concepts take proven features and capabilities of OpenSCENARIO 1.0, like its event-based scenario execution model, and place them in a more general and expressive language framework, to serve as the foundation for both incremental improvements and more revolutionary enhancements.

In comparison to OpenSCENARIO 1.0, a more detailed set of actions and attributes for the relevant simulation models shall be defined to allow for a more comprehensive scenario description and to improve exchangeability. This is addressed by the introduction of a domain model (see Concept document chapter: Architecture).

Beyond such improvements, the proposed domain-specific language supports the creation of more complex scenarios through flexible composition and parametrization of component scenarios in ways that allow realistic, emergent behavior to occur. This is expected to enable massive testing and verification of new, complex hardware and software systems, and their interaction with the complex environment of driving.

The concept group believes that the proposed concepts and direction will enable OpenSCENARIO 2.0 to supply a step-function in its ability to describe full, complex simulations and/or tests, addressing all the required elements, and utilizing existing building blocks (like OpenDRIVE or OpenCRG).

As stated above, the foundational concept of OpenSCENARIO 2.0 is to establish a domain specific language of a declarative nature. A declarative language describes what should happen on scenario execution (including the required parameterization/variation), rather than how to do it. A declarative language can also have a dual interpretation, i.e. provide a single scenario description which can be used to describe both how to make it and how to monitor that it indeed happened. This is important if we want to condition some operation on the fact that some other scenario has happened before, without having to describe in detail how to cause that scenario.

The Concept document used the M-SDL language for demonstration, early ASAM status updates released to provide insight into the development activity on this project may continue to do so. It is expected that features from M-SDL and other available DSLs will be analysed and modified as needed to support the OSC2.0 standard as it is developed.

2.1. Domain Model

The OpenSCENARIO standards target the domain of closed-loop system testing for automotive functions. A domain model provides the semantics for the terms that are used in the Language component of OSC 2.0. Currently, the domain model for the OpenSCENARIO standards does not have an explicit representation. An explicit specification of the domain model, e.g. in the form of a DL ontology, enables the preservation of semantics when scenario definitions are exchanged between different tools. Furthermore, if the specification has a logical foundation, software tools can be developed that use logical inference to provide reasoning capabilities

The Entity Definition work package provides the foundation of the domain model. This definition should cover all of the entities that are necessary to create scenarios according to the requirements identified in the concept document. The definitions must be unambiguous and include the characteristic properties and possible actions of each entity. The development of the entity definition will follow two tracks. First, the existing entity definitions of OSC 1.0 will be analyzed for migration to OSC 2.0 to ensure compatibility between the two versions of the standard. Second, the already identified gaps in OSC 1.0 will be closed by extending the Domain Model with additional entity definitions.

It will neither be possible nor meaningful to try to attempt to cover all possible scenarios and simulators with the entity definition of OSC 2.0. Therefore, a technical concept on a standard-conform Extensibility of the domain model needs to be developed.

As identified in the concept document, the domain model for OpenSCENARIO 2.0 should be specified using some form of predicate logic in order to achieve maximum clarity and portability. This is particularly important for defining the types of relationships that can hold between entities. The Ontology work package provides this formal specification of the domain model in the form of an ontology, possibly using one of the description logics supported by the W3C OWL standard. Having the domain model expressed as a formal ontology enables the use of reasoning software for classifying and matching scenario descriptions as well as providing a basis for computer inference that can assist human authors in creating scenario descriptions in natural language that are logically coherent and semantically valid.

2.1.1. Entity Definition

Entities are actual things in a domain. These can be activities, events, conditions and information, as well as physical objects. Clear and unambiguous definitions of all of the key entities in the domain model are essential for providing the semantics for the vocabulary of the OSC2.0 domain specific language. One major requirement for OpenSCENARIO 2.0 given in the concept document is full support of the OpenSCENARIO 1.0 standard, which has already been released by ASAM. This includes a full migration path from the 1.x versions to the domain specific language to be developed in OpenSCENARIO 2.0, to be delivered by WP_DM1_Transfer1x.

The entity definitions given for the Domain Model in the concept document (OpenSCENARIO 2.0 Concept Project) did not address support for OpenSCENARIO 1.0. OpenSCENARIO 1.0 already contains multiple definitions for entities, which may not be compatible with the entity definitions given in the OpenSCENARIO 2.0 concept document. All entities in the 1.0 model must have a counterpart in 2.0. Inconsistencies in naming and scope must be resolved or, if this is not feasible, a mapping between entities in both models has to be defined.

The need to extend the entity definitions of OSC 1.0 has been identified in the initiation phase of OSC 2.0. The OSC 2.0 concept document provides an initial draft for such an extension. This extension will be refined by focusing on "most important properties, attributes, possible actions and interrelations." All different use cases for the scenario definition in OSC 1.0 must be properly handled by the OSC 2.0 domain specific language. In addition, new entities must be defined, together with their actions and attributes, e.g. to cover the high-level scenario descriptions to be introduced in OpenSCENARIO 2.0. Drawing from experiences in the OSC 2.0 concept project, the team developing this work package will interact closely with the language group.

2.1.2. Extensibility

A standard domain model allows users to:

  • leverage a well-architect model and attributes for productivity

  • Facilitate scenario reuse across teams without upfront planning

At the same time, various users may have extensions that are not common or generic enough to be part of the standard. This section would discuss how the OpenSCENARIO2.0 allows user to extend the standard model to meet their project specific needs.

User may want to:

  • Add an attribute to a standard actor, action or struct

  • Add a user defined actor

  • Add a user-defined action to a standard actor

  • Add other needed entities

On top of addition extensions, user may want to ignore parts of the domain model which are not relevant may not be interesting for his ODD or project needs.

Later, these new extensions be efficiently leveraged for automated user-defined scenarios.

Ontology

In coordination with the Entity Definition work package and the [OpenX Ontology] project, the Ontology work package will augment the definitions of key entities and other concepts for the OSC2.0 DSL. An ontology-engineering approach based on some form of predicate logic (probably a description logic) will be applied to develop the definitions using core concepts and relationships, particularly spatial and temporal relationships between both dynamic and static traffic agents, provided by the OpenX Ontology project. These definitions will take the form of semantic triples (subject entity - relationship type - object entity triples), so they can be expressed and manipulated as labeled graphs.

The main deliverable of the ontology workpackage is envisaged to be a formal specification of the domain model for the OSC2.0 DSL. This specification will contain clear and unambiguous definitions of the following concepts:

  • Road infrastructure, meaning roads, lanes, etc.

  • Traffic infrastructure, meaning traffic signs, signals, etc.

  • Temporal changes in the road and traffic infrastructures, meaning road constructions, diversions, etc.

  • Dynamic traffic agents, such as cars, pedestrians, cyclists, etc.

  • Environment, meaning weather, time of day, etc.

  • V2X communication objects

2.2. Language Concepts

ASAM OpenSCENARIO 2.0 is based on a DSL – Domain Specific Language of declarative nature. This language demonstrates characteristics similar to a programming language, however as this is a declarative language, it specified what should happen, rather than how it should happen. The chapter described the syntax and semantics of the language as well capabilities such as libraries, and the abilities to measure and define success criteria. The language will be designed to deliver key concepts and requirement:

Readability

The quality of being easy to be read and understand by a target audience, which includes not only domain experts, programmers and engineers, but also safety engineers, regulators, and potentially even the general public. While this has clear implications for suitable surface syntax of the language, it also requires the semantics of the language to be well-defined, regular, and focused on the problem domain, and not technical implementation artifacts.

Expressivity

The ability of the language to allow the concise and direct expression of domain subject matter . This interacts with readability and the declarative nature of the language, but also enables for example the ability to query databases of scenarios using language semantics rather than only through meta-data-based queries.

Composability

The quality of being able to use standard language building blocks to incrementally build up more complex behavior in well-defined ways. This requires clear rules for composition and composition operators, that afford some level of predictable behavior post composition, while also allowing for interesting emergent behavior to occur, to ensure coverage of overall realistic traffic behavior.

Portability

The quality of being able to use the language and scenarios written in it across many execution platforms (including simulation platforms as well as real-world test tracks), without undue adjustments needing to be made. This includes the provision of suitable fallback mechanisms to deal with necessary differences between platforms.

Support for Reuse

The quality of being able to reuse scenarios and parts of scenarios across multiple levels of abstraction, platforms, and use cases without undue adjustments needing to be made. This comprises suitable library concepts and mechanisms in the language, as well as

Extendibility

The quality of allowing for easy extension of the underlying language mechanisms and domain model towards new requirements, including new traffic participants, their models and properties, compositions, and constraints.

2.2.1. Semantics, syntax and structure

This section will describe the overall structure of OpenScenario 2.0 programs, including partition into modules (files), the mechanism for module inclusion and related syntactic aspects such as defining comments, scoping (defined by indentation), character set and so on.

Language type definitions will include scalars, strings, enumerations, structs, actors, scenarios and modifiers, as well as their properties and members. Language constructs shall be described with their concrete syntax, their semantics, their relation to other constructs and any limitations on their usage. Where appropriate, formal denotational semantics will be provided to eliminate ambiguity.

Inheritance mechanisms that apply to structs, actors and scenarios shall be clearly outlined. Operators for numeric expressions, Boolean expressions, strings and other types will be listed, along with their precedence. Composition rules for scenarios and modifiers, including argument passing mechanism shall be defined. The syntax of constraints and their implied semantics will be described where applicable. Declaration and invocation of external functions, including argument passing will be defined as well.

Finally, the overall semantics of the language should be clearly and unambigously defined. In order to achieve this, it is important to define how behavior is specified by combining actors, actions, modifiers and events to atomic phases and how possible semantic unambiguities are resolved. This also includes how conditions can be used to define events (e.g. raising/falling edge, etc) and which expressiveness we allow (compared e.g. to temporal logic languages).

Also included is the definition of the exact semantics of temporal composition operators like serial, parallel and mix. Another important aspect is how to combine the two different approaches of specifying behavior: a) the declarative way (like intended for OpenScenario 2.0) and b) the more execution/command-oriented way of OpenScenario 1.0 (that still should be supported)."

2.2.2. Considerations for 1.x

OpenSCENARIO 2.0 shall be a full superset of the features of OpenSCENARIO 1.0, and it shall be possible to convert any OpenSCENARIO 1.0 scenario into an OpenSCENARIO 2.0 scenario with identical run time behavior.

This goal is partially addressed by the work on the Domain Model by ensuring that every entity of OSC 1.0 (including attributes and actions) has a respective counterpart in the OSC 2.0 domain model.

Additional concepts of OpenSCENARIO 1.0 for which a proper mapping to OpenSCENARIO 2.0 must be ensured include:

  • The event-driven temporal behavior as effected by the hierarchy, state machine and condition semantics (e.g. edges) of OpenSCENARIO 1.0 storyboard elements.

  • The concept of longitudinal and lateral domains of actions/controllers as well as their parallel existence.

  • Basic references such as coordinates systems and unit of measure.

  • Reuse-mechanisms such as Parameters and Catalogs

  • Entity Selections

  • Extensibility mechanisms such as Properties, UserActions and Controllers

  • Routes and Trajectories

As the OpenSCENARIO 1.x standard will be further developed in parallel to this project, it will be required to constantly co-ordinate with the OpenSCENARIO 1.x project. At the end of this project a complete semantic mapping (migration path) from the most recent OpenSCENARIO 1.x version to OpenSCENARIO 2.0 shall be provided.

2.2.3. Library Concepts and Packaging (scenario definition & scenario execution)

With the expected usage of scenarios at different abstraction levels, and it being aimed at different ODDs and different automated driving systems, the need for encapsulating scenarios in libraries is obvious.

The requirements for library concepts and packaging however stretch further than this: Not only does the encapsulation of scenarios transitively require the packaging of dependencies of the scenario, like modifiers, extended atomic scenarios, domain extensions, and referenced resources, like e.g. models; rather these entities themselves could/should form the basis of reusable libraries or modules by themselves, since they can form the basis for more powerful scenario creation methods.

Additionally it should be easy to specify and extract meta data, tags and classifications from libraries that will be used to characterize libraries and thereby help in locating suitable libraries for a given use case (consider e.g. smart scenario databases driven by the semantics of the language rather than the usual add-on tagging of meta data).

Since packaging will have to deal with resources referenced in libraries like e.g. models, which might not be as portable as the OpenSCENARIO 2.0 itself, the packaging mechanisms have to include the ability to specify such dependencies while allowing for divergence in implementation to cater to different implementations.

Another dimension of the library concepts and packaging work will addressing its relationship with OpenSCENARIO 1.x catalog concepts, and future evolution thereof.

2.2.4. Measurement and Success Criteria

This section will outline the OpenScenario 2.0 features used to collect and classify information during scenario execution. The collected information will be used to evaluate the quality and extent of the verification process, as well as the performance of the "ego" actor.

These data collection features may include coverage, tracing and recording of Key Performance Indicators as well as similar mechanisms. Semantics, like defining what expressions are sampled, in what resolution and temporal aspects of sampling will be unambiguously defined.

Language properties for grading and classifying collected information will be described. These include filtering values, grouping them into ranges (buckets), assigning minimal and maximal values, setting goals and so on.

The section will also describe language constructs for checking. These include assertions over Boolean and temporal properties, expressed using Boolean expressions and compound scenarios. Mechanisms for handling illegal values and assertion violations shall be provided, allowing the classification of errors (distinguishing between scenario failures, ego performance issues, ego failures and so on).

2.3. Usage and Pragmatics

This section includes different topics about the usage of scenarios and the corresponding workflows.

The content of a scenario can be modified in different ways: Data can be altered, data can be added or removed. The latter two are important regarding the different abstraction levels. Whereas functional scenarios are quite abstract and therefore do not included very much details about the objects and subjects, concrete scenarios that can be used for simulation naturally have to include a tremendous amount of details to allow that. To get from one abstraction level to the other, two ways are common: Concretization (adding more details) and abstraction (removing details).

One important point, that has to be discussed within the project is the linkage or respectively the interfacing to previous OpenSCENARIO version (0.x and 1.x). At least a migration plan to convert artifacts from previous version should be available to amplify the usage and prominence of OSC 2.0.

To create, use and maintain scenarios, a corresponding process or workflow has to be defined in order to guide the user. This workflow should cover all use cases defined in the use case section.

This is also true for a proper testing workflow, that should describe the interaction between requirements, scenarios and test cases within the development.

2.3.1. Abstraction, Concretization of Scenarios

Abstraction Level definitions are needed to expand beyond OpenScenario 1.0 and distinguish between scenarios that are written for natural language, machine language or OpenScenario 2.0 DSL, which explains handing of undefined values as abstractions. Abstract scenarios are defined as a scenario that:

  1. Has every intention of being understood and tested by a machine (i.e. machine readable)

  2. Uses an object oriented "structure for abstraction"

  3. Follows "rules of abstraction" to realize a scenario within realized ODD as part of driving domain.

Concretization or Concretion processes should explain and define reasons for why an abstract scenario intentionally does not define all dimensions and values (i.e. so they can later be optimized or explained by a supporting ODD to be made concrete.)

A Concretization definition should define simple process steps. These steps should explain through examples the process of taking an Abstract Scenario and converting it step-by-step to a Concreate Scenario, where all parameters are assigned to a single value.

Scenario summary to functional Scenario (i.e. Rules of Abstraction)

When considering a "Scenario Summary", define a best practice to create scenario summaries that that can be linked to ontology / taxonomy word choices. A Scenario summary is a paragraph of natural language that lends itself to an ontology that defines a scene in detail using a list all actors performing specified actions.

When considering a "Functional Scenario", also natural language, a definition would also lend itself to an ontology but is distinctly connected to specific ODD Categories, Behaviors and / or operational concepts. A list of specific relationships should be developed to defined to establish what distinguishes a "Functional Scenario" from a "Scenario Summary". A Functional Scenario may distinguish itself by how it influences the ODD test plan, functional test plan or design intentions.

Functional Scenario to concrete scenario (i.e. Rules of Concretization)

The rules of concretion should be defined to ensure rational semantic definition for necessary rules that are needed to make an object realized, initialized and located in an environment and ensure that parameter values may be assigned to bring an activity, phase or scenario to a point where all modifiers may be made concrete using a single value for each. An abstract scenario needs a list of modifier rules to follow for concretion expression based on some list of suggestions. Activities would include: defining rules needed for concretion and how they might be expressed in a syntax for each example maneuver / scenario. These rules might be different for the first activity of an actor; this activity might require information for location: position, lane, RoadSegment (i.e. laneSection), distance and/or relationship to another object, etc.

A detailed process or set of possible processes should explained how values are assigned as part of either: 1) parameter definition or 2) expressed through modifier "parameter space" as single value (Note: This may negate the need for a constraint(s) in the final concrete scenario.)

An example rule of concretion could be: a rule where every named parameter space must have a parameter definition, thus assigning a parameter type. Units may also need to be considered to be logically abstract so that when values are assigned they actually hold a true meaning. Units in this way could be expressed in a: 1) parameter definition, 2) a constraint or 3) parameter space representation where the parameter name is used or referred to.

2.3.2. Creation of Scenarios & Scenario Workflow (from creation to maintenance of scenarios)

As already stated, scenarios are used throughout the development process with different levels of detail. The corresponding use cases (at least the ones that the concept project group could think of) were mentioned in Section X. Due to the fact, that each use case partially represents different people from different groups with different goals, constraints and circumstances, their intention of the usage of scenarios and their way of using them sometimes may, but often will divert.

The goal of defining one single workflow for the creation and usage of scenarios seems ambitious and possibly unachievable. To cover all defined use cases, this would result in a very complex process, that would be hardly usable. Nevertheless, the goal should be to cover as much use cases as possible. To do so, an iterative approach for the application within the OSC 2.0 standardization project seems reasonable.

This implies several steps:

  • A review of the already defined use cases should be done to identify missing use cases, improve the description and the differentiation among themselves and finalize the list (Use cases and usage&pragmatics section of the concept document)

  • Cluster/restructure the user stories/use case examples (e.g., grouping according to the feature sets)

  • Link all user stories/use case examples to corresponding content from the usage & pragmatics section if possible

  • Representatives for each use case should be determined to deliver insight in the background and the underlying assumptions

  • Each representative should write down his or her workflow/definition in a similar way (e.g., by using the same type of diagram or template)

  • Each workflow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements

  • All workflows should be checked for duplicates (either in whole or in parts)

  • All workflows should be split into atomic parts that can be separated

  • A generic workflow should be created/designed based on the separated atomic parts

  • Any gaps in the workflow, that are identified in the standard should be communicated to the other working groups, so that they are able to fill the gaps

  • Each covered use case should be documented within the workflow and all user stories/use case examples have to be linked appropriately

  • Uncovered use cases should be documented with ideas, how to proceed with them

  • Review and discuss key requirements and decide about a reference implementation/API/interface

A requirement for all other points above is that the reusability of subelements from a scenario should be possible.

The created workflow should include all lifetime phases for a scenario, from prerequisites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed.

As an illustration of the concept, e.g., the creation of a scenario can be done by using different methods, from manual writing, over tool-assisted (either textual or graphical) creation to extraction or generation out of a predefined data pool. All those ways should be covered within the defined process.

2.3.3. Scenario based testing workflow

OpenSCENARIO 2.0 allows building modular, encapsulated, reusable scenarios that can be ported to different testing platforms. This section will describe the basic flow to construct a test, which contains all the elements and ingredients required for a testing platform, Ingredients like road topology, scenery. Road surface, driver and traffic models and more.

This section will describe how scenarios can be mixed and combined to construct a test. Interaction with usage restriction and guidelines will be presented.

For specific platforms, the user will need to provide context and implementation details to enable its execution. For example, in simulation the user may provide for a reusable scenario:

  • A map to be executed on with specific location details

  • Desired ODD restrictions

Various topics related to combining scenarios into meaningful tests will be discussed in this section.

2.3.4. Test definition

How to test scenarios?

Clarification of boundaries test cases and scenarios Outputs:

  • Workflow guidelines (e.g. when integrated with a scenario vs. defined separately)

In this section we’ll try to detail how a scenario should be tested.

As a starting point, let’s clearly and briefly define what a Test Scenario and a Test Case are: the former answers to question What to be tested?, while the latter to How to be tested?.

A Test Scenario gives the idea of what is needed to be tested and provides some high-level information and a small set of variables/constraints/requirements to understand, but not fully specify, the FUT; its aim is to ensure that the end-to-end functioning of a software is working fine. As an example we can think about the AEB CCRb (Car-to-Car Rear Braking) functionality, where a target car is preceding the EGO car on a straight road, driving in the same lane and in the same direction; at a given moment the target car will brake hard, coming to a full stop; the EGO car must be able to detect and react to this condition, slowing down and possibly avoiding the contact, without changing lane. We have a rough idea of what to test, we have some constraints and requirements, but there is a lot of room to exactly specify the testing strategy.

A Test Case is the set of positive and negative execution steps and detailed variables/constraints/requirements specification using which a test engineer can determine if the FUT is functioning according to the customer’s requirements; several Test Cases can (and should…​) be derived from the same Test Scenario in order to ensure that the FUT meets the requirements on a wide range of specialization. Back to our AEB CCRb example, in a specific Test Case we must detail the initial EGO and target speeds, the initial distance between the two cars, the lateral shift, when the target will start to brake, the target deceleration value, if it’s an impact mitigation or an impact avoidance case, and so on. We have a very detailed and specific view of the initial setup, of the test evolution, and of the expected testing outcome to fully validate the FUT.

Test Scenario vs Test Case
Table 3. Test Scenario vs Test Case

Test Scenario

Test case

A one, liner possibly associated with multiple Test Cases

A name, some pre-conditions, test steps, expected results and post-conditions

Guides a user on What to test

Guides a user on How to test

Tests the end-to-end functionality of a software application

Validates a Test Scenario by executing a set of steps

Is derived from a Use Case

Is derived from a Test Scenario

Consists of high-level actions

Consists of low-level actions

Easy to maintain, due to the hight-level design

Hard to maintain, due to the heavy specialization

Less time consumption compared to Test Cases

More time consumption compared to Test Scenarios

2.3.5. Portability

The definition of a new standard OpenSCENARIO 2.0 should aim for a widest possible acceptance in its domain. This holds true for every standard, but might be hard to achieve given the wide set of use cases and requirements. These will result in an extremely capable language. This, in return, will allow the language to be used in numerous projects, but comes with the trade off of limited portability and exchangeability. It will be hard or even infeasible for tool providers to guarantee a support of OpenSCENARIO 2.0 as this support will very likely be limited to parts of the language.

Car manufacturers for example will work with multiple different suppliers and would like to use OpenSCENARIO 2.0 as one of the exchange formats. The selection of those suppliers relies on their credible statement on how they support the standard e.g. in their simulation environment.

The standardization project should enable partial support of the standard. This on the one hand allows companies to step by step improve their compatibility to the standard and on the other hand enables proper selection of project partners.

Feature Sets Proposal
Figure 1. A Proposal for feature subsets in OpenSCENARIO 2.0

The feature subsets proposed in picture A Proposal for feature subsets in OpenSCENARIO 2.0 might be an option for a segmentation of the standard to achieve partial support. It has still to be discussed how those feature subsets should be defined and how they can be integrated in the standard. If a separate working group will be defined to tackle those questions, a close interaction with at least the domain model, the use cases and the language working groups is highly advisable. The definition of a core feature set might be helpful to define a basis all supporting parties commit to.

Additionally, the planned migration path from the already published OpenSCENARIO 1.0 standard has to be considered.

3. Project Resources

3.1. Work Packages

A breakdown of the project into individual work packages and the corresponding effort required to complete them. Effort should be given in man-hours.

3.1.1. Language Concepts

WP 1: LC-BasicTypes

Description

Basic data types for OpenSCENARIO 2.0

This WP will address the semantic description of the basic generic datatypes (integers, booleans, floats, enums), domain specific physical types (such as speed, distance and angle) with their corresponding units. We will talk about implicit and explicit type conversions.

Responsibles

Sharon Rosenberg

Deliverable

Semantic description of the definition of all basic, i.e. non-compound data types of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the basic data types.

Effort

100 man-days

WP 2: LC-CompoundTypes

Description

Compound types for OpenSCENARIO 2.0

This WP will address the semantic description of the compound datatypes (structs, actors, scenarios, lists etc.). It will also describe the generic capabilities of these datatypes: Ability to precisely define allowed generatable sub types, ability to freely extend any type in a modular way (so as to enhance / restrict it), and so on.

Responsibles

Y. Hollander

Deliverable

Semantic description of the definition, inheritance and extensiblity mechanisms for all compound data types of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the compound data types.

Effort

100 man-days

WP 3: LC-Expressions

Description

Expression language for OpenSCENARIO 2.0

This comprises the generic parts of expressions (e.g. arithmetic, logic, etc.) based on the properties of the domain model, as well as ways to define more complex domain-specific expressions.

Responsibles

P. Mai

Deliverable

Full semantic description of the expression language of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the expression language.

Effort

50 man-days

WP 4: LC-Syntax

Description

Syntax definition of the OpenSCENARIO 2.0 language

Responsibles

R. Hadar

Deliverable

Full syntax definition, including grammar, of the OpenSCENARIO 2.0 language. Basic building blocks are file organization, type definitions, compound type definitions and their internals, temporals, behavior description and expressions. Integration of the other WG syntax definition into a single syntactic entity that shares the same look and feel. To cover functional scenarios, abstract descriptions of road topologies/infrastructure elements have to be included. For the use case of regulatory reviews, a natural-language syntax has to be supported.

Effort

100 man-days

WP 5: LC-Semantics

Description

A well-defined semantics for OpenSCENARIO 2.0.

As the levels of abstraction have been raised, so the effort and understanding needed for tool developers (e.g., for simulation engines or document processors) to implement support for this standard is raised. As such, the semantics of a scenario become more important: to give an unambiguous understanding of a) whether that scenario could be executed at all; on a given map; and unambiguously. Additionally, especially for legally required reviews of functional specification documents by regulatory institutions, natural language semantics have to be covered.

Responsibles

I. Whiteside

Deliverable

Semantic rules for the OpenSCENARIO 2.0 language.

Effort

100 man-days

WP 6: LC-Coverage

Description

OpenSCENARIO 2.0 introduces the concept of coverage.

This WP shall provide language constructs allowing collection of data during runtime. The data will enable verifying verification goals, analysis of execution as well as multi-run analyses. Similarly, this work package shall provide the constructs to measure certain variables that may be of interest for the user, allowing the definition of KPIs and success criteria to automatically report whether a specific simulation was (or not) successful.

Language constructs for coverage, measurements and KPIs

Responsibles

Rich Heidtman, Joan Roca, Ronen Hadar

Deliverable

Full semantic description for the definition of mechanisms to define coverage parameters, parameters to be measured (logged) and the definition of user-defined KPIs.

Effort

100 man-days

WP 7: LC-Libraries

Description

Libraries, Modules, Packaging and Namespace aspects of OpenSCENARIO 2.0

This WP will address the necessary ways of packaging functionality into libraries and modules in ways that foster re-use across users and implementations. Related namespacing problems are addressed. Relation to OpenSCENARIO 1.0 re-use concepts will be addressed.

Responsibles

P. Mai, Y. Hollander

Deliverable

Full semantic description of the library, modules, packaging and namespace aspects of the OpenSCENARIO 2.0 language. Input for LC-Syntax on syntax aspects of the libraries, modules, packaging and namespaces aspects.

Effort

50

WP 8: LC-Transfer1x

Description

Additional features in OpenSCENARIO 2.0 to support OpenSCENARIO 1.0/1.x features not otherwise part of 2.0

Responsibles

J. Krasser

Deliverable

Semantic extensions to the OpenSCENARIO 2.0 language to support specific 1.0/1.x concepts not otherwise supported. This WP will monitor the featureset of both projects and provide recommendations accordingly. It will also coordinate with the corresponding WPs from OSC 1.x. Input for LC-Syntax on syntax aspects of these extensions. Semantic mapping (migration path) from the most recent OpenSCENARIO 1.x version to OpenSCENARIO 2.0

Effort

70

3.1.2. Domain Model

WP 9: DM-Extend2x

Description

Extend Entity Definition from Concept project and other working packages towards OSC 2.0

Responsibles

J. Kaths, M. Kluge

Deliverable

UML entity definition that extends the ones from OSC 2.0 Concept Project and from work package DM-Transfer1x with high level scenario descriptions (e.g. drive()) and other missing features. It will also incorporate the road model developed in work package DM-AbstractionRoads. The result is the full entity definition for OSC 2.0. Similar to the separation of DM-AbstractionRoads, this work package is likely to be split into further work packages as the project progresses.

Effort

40

WP 10: DM-Ontology

Description

Use ontology-engineering techniques to create a logic-based specification of the OSC2.0 Domain Model

Responsibles

S. Kraines, F. Sanchez, I. Whiteside, P. Parekh

Deliverable

- extensions of entity definitions developed under WP DM-Extend2x using concepts and relationships from the OpenX Ontology

- guidelines for how to use semantic inference to classify and match scenario descriptions based on their meaning

- guidelines for how to implement computer reasoning to identify semantic errors in scenario definitions

- guidelines for how to use computer reasoning to assist people in creating abstract-level scenarios that are complete and logically coherent

Effort

60

WP 11: DM-AbstractionRoads

Description

Create road network domain model based on concept project proposal.

Responsibles

M. Kluge, J.Kaths

Deliverable

UML entity definition of the road network, which provides an intuitive way of addressing elements in the network. This for example will be used to define conditions in the behavior definition, e.g. "turn right at the second 4-way junction". An ID based access with detailed knowledge of the road network content must also be possible. The abstract road network domain model should allow the usage of different map sources like OpenDRIVE in OpenSCENARIO 1.0 or HD maps.

Effort

30

WP 12: DM-Extensibility

Description

Domain model extensibility capabilities for OpenSCENARIO 2.0

This WP will address the ability of adding and removing entities for the standard domain-model

Deliverable

Description of how to add entities (attributes, actor, action, etc.) to the design model and how to leverage the modified model for user specific scenarios and coverage,

Effort

20

WP 13: DM-Transfer1x

Description

Rework entity definition from concept project with regard to OpenSCENARIO 1.0.

Responsibles

J. Tscheak (maybe), M. Kluge, J.Kaths

Deliverable

Consolidated UML entity definition that covers existing features of OpenSCENARIO 1.0 standard. Differences between 1.0 and the concept project domain model should be identified, listed and resolved. Deviations should only be allowed when necessity is clearly identified and reasoned. This work package is a predecessor of DM-Extend2x and should be finished first.

Effort

30

3.1.3. Usage & Pragmatics

WP 14: UP-ScenarioCreation

Description

Create and document the workflow/process for the scenario creation (based on all use cases)

Responsibles

F. Bock

Deliverable

Unified process for the scenario creation workflow, that covers all use cases mentioned in the use case section of the concept project document. The resulting process should be based on already existing workflows and incorporate the input from all working group members. Process documentation should use a common format (such as, e.g., UML).

Effort

50

WP 15: UP-ScenarioAbstractionConcretization
Description Concretization or Concretion processes should explain and define reasons for why an abstract scenario intentionally does not define all dimensions and values (i.e. so they can later be optimized or explained by a supporting ODD to be made concrete.)

Responsibles

Deliverable

Documentation & guidelines on transitioning between different degrees of scenario abstraction. Requirements to Language Concepts WPs.

Effort

50

WP 16: UP-SuccessCriteria

Description

This WP will supply usage guidelines and approaches for specifying success and measurement criteria to evaluate scenarios.

Responsibles

Deliverable

Guidelines & reccomendations for success criteria of various scenario types. Requirements to Language Concepts Wps.

Effort

30

WP 17: UP-TestDefinition

Description

Definition of tests based on scenarios

Responsibles

L. Costantino

Deliverable

Clarification of boundaries between test case & scenarios

Workflow guidelines (e.g. when integrated with a scenario vs. defined separately)

Effort

30

WP 18: UP-Transfer1x

Description

This WP deals with the migration of concrete scenarios from 1.x to 2.0. It will elaborate in detail the set of rules to migrate a concrete scenario in OpenSCENARIO 1.x to a scenario in OpenSCENARIO 2.0. This will enable users of the previous versions to start using OpenSCENARIO 2.0 at the earliest.

Apart from the migration rules, any other interfacing forms should also be discussed and outlined. An example of such interfacing could be the ability to directly refer an OpenSCENARIO 1.x construct in an OpenSCENARIO 2.0 scenario in an appropriate way.

Responsibles

Sandeep Pendharkar

Deliverable

Migration guidelines from 1.x to 2.0

Effort

50

3.1.4. Feature Subsets

WP 19: FS-FeatureSubsetsConcept

Description

Create a concept for support of predefined feature subsets of the standard. If viable, propose specific feature subsets and guidelines/methodology for validating them.

Responsibles

M. Kluge

Deliverable

Concept to fragment content of the standard into clusters (feature subsets). Has to contain the approach on how to cluster the content (e.g. on domain model level), a first draft of viable feature subsets and an idea on how to check language files for feature subset compatibility. Definition and documentation of feature subsets.. Might also contain the addition of new elements in the language to declare feature subset compatibility. Definition, documentation and implementation of validation approach of language files against feature subsets. Necessary for actual usage of feature subsets. An example for such a subset may be an OpenSCENARIO 1.0 compatible subset.

Effort

100 man-days

3.2. Company Commitments

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

Table 4. Work Effort
Company Location Commitment Participant(s) Participant Email

Advanced Data Controls Corp.

Japan

10

Yasuyuki Nakanishi

nakanisi@adac.co.jp

AKKA

Germany

20

Rolf Magnus

rolf.magnus@akka.eu

ANSYS

France

36

Luca Costantino; Bernhard Kaiser

luca.costantino@ansys.com; bernhard.kaiser@ansys.com

Applied Intuition

USA

15

Romain Kuntz

rk@applied.co

APTIV

USA

60

Rich Heidtman

rich.heidtman@aptiv.com

Audi

Germany

25

Florian Bock

florian1.bock@audi.de

AVL List GmbH

Austria

25

Juergen Krasser; Mirko Bulaja

juergen.krasser@avl.com; mirko.bulaja@avl.com

Beijing Saimo Technology Co. Ltd.

China

25

Xue Xiaoqing

xuexiaoqing@saimo.ai

BMW AG

Germany

25

Andreas Rauschert; Clemens Habedank; Stanislav Braun

andreas.rb.rauschert@bmw.de; clemens.habedank@partner.bmw.de; Stanislav.Braun@bmw.de

BTC Embedded Systems AG

Germany

37

Matthias Bueker

matthias.bueker@btc-es.de

CARLA Simulator

Germany

10

Guillermo Lopez; Fabian Oboril

glopez@cvc.uab.es; fabian.oboril@intel.com

CATARC

China

30

Qidong Zhao; Chen Chen

zhaoqidong@catarc.ac.cn; chenchen2018@catarc.ac.cn

Change Vision

Japan

20

Toshinori Takai

toshinori.takai@change-vision.com

Connected Places Catapult

UK

28

Richard Holland

richard.holland@cp.catapult.org.uk

deepen.ai

USA

10

Nicola Croce

nico@deepen.ai

Deloitte Tohmatsu Consulting LLC

Japan

25

Kazuhiko Hanaya; Takuya Sugahara

khanaya@tohmatsu.co.jp; tsugahara@tohmatsu.co.jp

Denso

Germany

25

Nicolas Ochoa Lleras

n.ochoa@denso-auto.de

DLR

Germany

25

Heinrich Ody

heinrich.ody@dlr.de

dSPACE

Germany

35

Michael Kluge;Patrick Bouillon

mkluge@dspace.de;pbouillon@dspace.de

Elektrobit

Germany

20

Wolfgang Lindner

wolfgang.lindner@elektrobit.com

FiveAI

UK

25

Iain Whiteside; Alex Heavens; Fran Sanchez

iain.whiteside@five.ai; alex.heavens@five.ai; fran.sanchez@five.ai

Foretellix

Israel

70

Gil Amid; Sharon Rosenberg; Yoav Hollander; Ronen Hadar

gil.amid@foretellix.com; sharon.rosenberg@foretellix.com; yoav.hollander@foretellix.com; ronen.hadar@foretellix.com

FZI

Germany

25

Thilo Braun; Barbara Schuett

braun@fzi.de; schuett@fzi.de

Hoechstleistungsrechenzentrum Stuttgart

Germany

28

Jutta Sauer

hpcfloh@hlrs.de

Honda motor

Japan

30

Koichiro Ozawa

Koichiro_Ozawa@jp.honda

Huawei

China

25

Jianqin Liu; Tommi Jaemsae

liujianqin@huawei.com; tommi.jamsa@huawei.com

iASYS

India

25

Puran Parekh; Deepak Patil; Shantaram Jashav

ppuran@iasys.co.in; pdeepak@iasys.co.in;jshantaram@iasys.co.in

IRT-SystemX

France

25

Adeline Lanugue; Mohamed Tlig; Alex Grandjean

adeline.lanugue@irt-systemx.fr; mohamed.tlig@irt-systemx.fr; alex.grandjean@irt-systemx.fr

itemis AG

Germany

25

Alexander Rimer

rimer@itemis.de

Jaguar Land Rover

Hungary

20

Adam Nagy

anagy1@jaguarlandrover.com

JARI

Japan

15

Jacobo Antona-Makoshi; Hanna Chouchane; Yokota Masanori

ajacobo@jari.or.jp; channa@jari.or.jp; myokota@jari.or.jp

Kanagawa Institute of technology (KAIT)

Japan

25

Hideo Inoue

inoue@cco.kanagawa-it.ac.jp

KPIT Technologies GmbH

Germany

25

Winifred Paul

Winifred.Paul@kpit.com

Liangdao GmbH

China

20

Xiaotong Liu

xiaotong.liu@liangdao.de

Luxoft

Germany

20

Christian Koenig

ckoenig@luxoft.com

Mitsubishi Precision

Japan

25

Atsushi Araki; Masami Nerio

aaraki@mpcnet.co.jp; nerio@mpcnet.co.jp

Navinfo

China

25

Wei Sun

sunwei60804@navinfo.com

NTT DATA

Germany

25

Johannes Kreckel

Johannes.Kreckel@nttdata.com

NVIDIA

USA

25

Ahmed Nassar; Justyna Zander

anassar@nvidia.com; justynaz@nvidia.com

OFFIS e.V.

Germany

10

Lukas Westhofen

lukas.westhofen@offis.de

PMSF

Germany

30

Pierre R. Mai

pmai@pmsf.eu

RA Consulting GmbH

Germany

10

Frank Hantschel; Thomas Kotschenreuther; Armin Rupalla

F.Hantschel@rac.de; t.kotschenreuther@rac.de; a.rupalla@rac.de

Robert Bosch GmbH

Germany

5

Max Bauer

bosch.b.bauer@extaccount.com

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

SOLIZE Engineering Corporation

Japan

30

Shinji Minami; Yuki Agata

shinji.minami@solize.com; yuki.agata@solize.com

Symphony

Japan

30

Steven Kraines; Ai Takagi

steven@kraines.net; takagi@symphonies.co.jp

Toyota motor

Japan

25

Satoshi Taniguchi

satoshi_taniguchi_ad@mail.toyota.co.jp

TU Dresden IAD

Germany

20

Stefan Plaettner; Thomas Tueschen

stefan.plaettner@tu-dresden.de; thomas.tueschen@tu-dresden.de

TUEV Sued

Germany

25

Christoph Miethaner

Christoph.miethaner@tuev-sued.de

Vayavya Labs

India

30

Sandeep Pendharkar

sandeep@vayavyalabs.com

Vector Informatik GmbH

Germany

25

Jakob Kaths

jakob.kaths@vector.com

Vicomtech

Spain

7

Oihana Otaegui

ootaegui@vicomtech.org

Virtual Vehicle

Austria

21

Patrick Weissensteiner

patrick.weissensteiner@v2c2.at

WMG University of Warwick

UK

40

Dr Jason Zhang; Siddartha Khastgir

s.khastgir.1@warwick.ac.uk; Jason.Zhang@warwick.ac.uk

TOTAL

1367

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 5. Change Control Board (CCB)
Participant Company

PMSF, Germany

ANSYS, France

FiveAI, UK

FiveAI, UK

AVL List GmbH, Austria

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

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

3.3. Effort Summary

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

Language Concepts (WP1-WP8)

570

100

670

Domain Model (WP9-WP13)

150

30

180

Usage & Pragmatics (WP14-WP18)

200

10

210

Feature Subsets (WP19)

90

10

100

Total

1010

150

1160

Table 8. Resource Check
Project Members Service Provider Total

Required

1010

150

1160

Committed

1367

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 9. Funding limits

Project Type

Factor

New, major, minor or revision standard development project

0.25

Study project

0.25

Concept project

0.75

Table 10. Funds required for Service Providers
Task Description Effort
[man-days]
Cost
[€700 / day]

OpenSCENARIO 2.0 set of documentation (language manual, usage guides)

100

70.000 EUR

Domain Model implementation

50

35.000 EUR

Total

150

105.000 EUR

4. Project Plan

4.1. Timeline

The work packages shall be carried out as per the following time schedule:

3 4 project plan

4.2. Deliverables

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

  1. Language reference manual
    Complete language documentation

  2. Domain model specification
    Documentation detailing the core domain model as used by OpenSCENARIO 2.0

  3. Scenario creation guidelines
    Usage guide on the creation of scenarios for different workflows using OpenSCENARIO 2.0

  4. Domain model extension guidelines
    Documentation on extending the depth (more detail) & breadth (larger domain) of the domain model

  5. Feature Subset definition
    Prepared proof of concept for separating OpenSCENARIO 2.0 into modular components

  6. Migration path OSC 1.x <→ 2.0
    Documentation detailing the migration path between the two standard versions

4.3. Review Process

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

  • Project member review

  • Public review

  • Reference implementation