Executive Summary

1. Introduction:

Safety is fundamental to the development of public trust and acceptance of Connected and Autonomous Vehicles (CAVs). Safety of CAVs has two aspects: safe design and safe use of the system. In order to ensure safe use of the system, it is important to convey the knowledge of the true capabilities and limitations of the systems to the users to prevent misuse of the systems.

In order to establish their true capabilities and limitations, we need to first define its Operational Design Domain (ODD). ODD refers to the operating environment (road type, weather conditions, traffic conditions) in which a vehicle can drive safely. For example, for Low-Speed Automated Driving (LSAD) systems such as pods and shuttles, the ODD may include urban areas with predefined routes that include pedestrians and cyclists. On the other hand, for a motorway chauffer system, an ODD may include a four-lane divided motorway and dry conditions only. The types of scenarios a vehicle may encounter will be a function of its defined ODD, making this fundamental to any safety evaluation and scenario identification.

A more formal definition of ODD as defined by SAE J3016 (2018) states that "Operating conditions under which a given driving automation system or feature thereof is specifically designed to function, including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics".

In order to enable stakeholders to share, compare and re-use ODD definitions, there is a need for standards to provide guidance to the stakeholders on both the attributes to be used for ODD definition and a format for defining the ODD using those attributes. BSI PAS 1883 (UK) provides a taxonomy for ODD. Additionally, ISO 34503 uses the taxonomy to provide a high-level definition format for ODD. While these standardisation activities address the important needs of the industry, a gap still exists in the industry for an ODD definition format for simulation.

ASAM OpenODD is a representation of the abstract ODD specification in a more well-defined syntax and semantics which enables machines to interpret and perform the required analysis. Additionally, the OpenODD specification shall be measureable and verifiable for the attributes it specifies.

DRAFT SCOPE of OpenODD (Format) @ ASAM:

An Operation Design domain Definition (ODD) shall be valid through out the whole vehicle lifetime. The definition of an ODD is part for the saftey concept of the vehicle. Depending on the current development step different informations need to be derived from that overall ODD. OpenODD focuses on a machine readable format. The ODD has to be represented so it can easily be used within simulation and other machine processed environments. The content of the OpenODD will be derived from an abstract "Vehicle ODD", providing the information in a usable manner. For the purpose of using this ODD description for simulations and post-processing the format must fullfil the following requirements:

  • Searchable

  • Exchangable

  • Extensible

  • Machine readable

  • Measureable and verfiable

  • Human readable / contstrained natural language

overview

The OpenODD specification will ensure that it is possible to statistically quantify 1) exposures against the ODD, 2) the performance of an AV against the ODD, 3) the tightening or expansion of the ODD over time.

OpenODD has to be comaptible with OpenDRIVE and OpenSCENARIO and OpenXOntology. The OpenODD will be consistent with the ISO activites.

2. Overview

2.1. Motivation

Provide a general explanation for the motivation of the project proposal. This may include the description of the history that led to the proposal, general problems with current industry practices or existing standards, identified areas for improvement or economic constraints that require the solutions proposed for this project.

2.2. User Stories

In this chapter the Usecase for the OpenODD are defined, also the actors in those usecase are defined beforehand.

2.2.1. Actors for an OpenODD

Who will use and create the ODD and therefore use the OpenODD

  1. Development Engineer (for development Usecases)

  2. Test Engineer (for Simulation)

  3. Data Scientist (Analysis of results, coverage)

  4. Tool developer (for Simulation)

  5. Scenario Editor / creator

  6. Data Annotation Engineer

  7. Safety Engineer

  8. Infrastructure operator (include regulators, authorities)

    1. regulatory

    2. Procurment

    3. Safety Operator

2.2.2. User Stories

Development engineer

  1. As a development engineer, I need to understand the relevant parameters and their ranges that can occur during automated driving within the ODD and the scenarios the automated driving system might be confronted with, and be able to trace my requirements to this kind of input data.

  2. As a development engineer, I need clear criteria how to detect at runtime that I am unintentionally leaving the ODD so that I can implement detection and reaction functions for this case.

  3. As a development engineer, I need input (e.g. List) on foreseeable situations in the ODD to test my sensor setup and software algorithms appropriately before vehicle simulation and road testing even starts.

  4. As a development engineer, I desire a machinereadable ODD decription that support the systematic segementation of the ODD in sub-areas where different capabilities of the AD system are needed or different grades of AD functions are safe to operate.

  5. As a development engineer I want to check tests, scenarios, recordings, etc. against the ODD description.

Test engineer

  1. as a test engineer, I would like to be able to declare an ODD to test against

  2. as a test engineer, I would like to know that a scenario that I have created is within the ODD

  3. as a test engineer, I would like to understand which element of my driving ontology/domain model is in or out of my ODD

  4. as a test engineer, I would like to know if the ODD that I have defined is well-formed and non-contradictory

Data scientist

OpenODD Data Scientist Use-Cases, extending the Ontology (i.e. need to support ontology by reference)

  1. As a data scientist, given a scenario library, I need to determine the parameter distribution, and coverage, so that I can assess the confidence in the results and deliver trust.

  2. As a data scientist, given a scenario library, I need to determine which aspects of the ODD are covered, so that I can assess which scenarios need to be added to support effective ODD testing.

  3. As a data scientist, given an ODD I need to determine whether a specific scenario is included in the ODD, so that I can determine whether it needs to be included in the assessment of results.

  4. As a data scientist, given an ODD, I need to determine the exposure to a specific scenario so that I can derermine the weight/contribution of the scenario results in the overall assessment.

  5. As a data scientist, given two versions of the ODD I need to determine which scenarios were added or removed, so that I can determine how the analysis needs to be adapted.

  6. As a data scientist, given an ODD, I need to determine whether an occurrence is allowed by the ODD, so that I can determine whether the vehicle behaved as per the ODD specification.

  7. As a data scientist, given an ODD, I need to determine the exposure to a specific "occurrence" so that I can derermine the weight/contribution of the behavior results in the overall assessment.

    • Test use-cases

Tool developer

  1. as a tool developer, I would like to have a common format that I can share to define an ODD.

  2. as a tool developer, I would like the ODD format to be formal enough that I can execute and process the containing information.

  3. as a tool developer, I would like to be able to substitute multiple driving ontologies and still use the same ODD Format.

  4. as a tool developer, I would like to test my testbench capabilites against the ODD, with the goal if the capabilites suite the ODD needs.

Scenario editor

  1. As a scenario editor, I want to create the scenarios for an ADS which are within the defined ODD of the ADS.

  2. As a scenario editor, I want to create scenarios to test the ODD attribute boundaries to test the fall-back or Minimal Risk Manoeuvre capability of the ADS.

  3. As a scenario editor, I want to create ​scenarios at different levels of abstraction.

Data annotation engineer

  1. As a label annotator I need to assemble a data library which is relevant to the ODD so the data (recordings, synthic sensor data, etc) can be annotated accordingly

  2. As a label annotator I need to analyze data to identify ODD related situations and occurrences so that I can annotate them.

  3. As a label annotator I need to estimate the compleness of data to be annotated relative to the ODD so that users of the annotations can estimate achievable coverage.

  4. As a label annotator I need to estimate the coverage of annotations relative to the ODD so that users of the annotations can estimate coverage achieved.

Safety Engineer

  1. As a safety engineer I want to (semi-automatically) derive a situation catalog for Hazard Identification from the formal ODD definition.

  2. As a safety engineer I want to demonstrate the metrics of coverage of my considered scenarios w.r.t. the total ODD and estimate the remaining risk of hazardous scenarios within the ODD that were not covered by my safety concept and my validation approach.

  3. As a safety engineer I want to identify scenarios of unintentionally leaving the ODD from a formal definition of the limits of the ODD, in order to handle these situations using appropriate detection and reaction possibilities.

  4. As a safety engineer I want to get an understandable representation which partitions or sub-areas of the ODD exist, which failures or degradations could lead to hazards in each of them and grades of AD functions or which behaviors ensure acceptably safe operation in each of them.

Infrastructure operator

  1. as an infrastructure operator, I want to have easy access to ODD specifications in order to have a clear view on current and future demands on my road network

  2. as an infrastructure operator, I want to have the ability to warn vehicles in advance if they are about to chose a route through my road network which most likely is exceeding their ODD

  3. as an infrastructure operator, I want to give recommendations to automated vehicles which routes/roads/lanes to use depending on their ODD capabilities

  4. as an infrastructure operator, I want to have the ability to provide current ODD restrictions of parts of my network easily

  5. as an infrastructure operator, I want to be able to have a version controlled ODD Format

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.

The OpenODD Format shall be able to represent an abstract ODD Specification

  1. The format shall be able to represent the abstract ODD definition

  2. The format should be human readable

  3. The format should be machine readable

  4. The format should be composable, ( i.e. you can combine ODD definition into a new, wider one or you can use inheritance mechanism ),

  5. The format should be parameterizable

  6. The format should be extensible ( easily extend with new elements/taxnomy )

  7. The format should be consistent with taxonomies used by ODD taxonomy standards.

  8. The format should support the concept of conditional or reduced ODD ( This can be done by using constraints as the mechanism to reflect this. For example, consider an ODD specifying a full operational range for an ADS system. The specification of the range itself ( e.g. the velocity range ) can be thought of as a constraint. Now consider the fact that for a certain ODD attribute, you would like to express the fact that for a certain range of this attribute, the ODD range should be restricted, and not the full range. For example. The velocity in which an ADS system is operating is defined to be between 0 and 80kph. However, in the case of the a heavy fog ( assuming heavy fog is well defined ) , the ADS system is constrained to operate in velocity range of 0 to 40kph.

  9. The format should be able to share same categorization and meta data with OSC2.0

  10. The format will supply ability to refer to ODD definition from scenario specification.

  11. The format should enable queries for attributes of the ODD

  12. The OpenODD format should be aligned with the other OpenX Projects.

2.4. Relations to Other Standards or Organizations

  • ISO 34503

  • BSI 1883

  • SAE AVSC00002202004 AVSC Best Practice for Describing an Operational Design Domain: Conceptual Framework and Lexicon

  • ASAM OpenXOntology

  • ASAM OpenLABEL

  • ASAM ODS

  • …​

3. Technical Content

3.1. Workpackages for the OpenODD

  1. Workpackage for the OpenODD attributes
    This WP will ensure alignment with BSI PAS 1883, ISO 34503, and the ongoing ASAM OpenXOntology Project. In addition, it will also align attributes with the other OpenX Standards and ASAM ODS, where necessary. This workpackage will also evaluate other ODD taxonomies.

  2. Workpackage OpenODD Specification/Format
    This WP will describe the semantic and syntactic description of the ODD description for format for simulation execution. It will include the capability to describe conditional ODD description using some or all ODD attribues.

  3. Workpackage Metrics
    This WP will define the measuring capability of to identify if a scenario / scene / action / situation is within the ODD or not. It will also enable KPI definition.

  4. Workpackage Representing Uncertainty
    This WP will discuss future concepts for using ODD for safety analysis which include rare risks, intentional/unintentional misuse, unkown and unsafe scenariosthe influence of risk.

  5. Workpackage for a Userguide
    This WP will detail how to use OpenODD which include, using OpenODD for simulation, ODD definition, userguide examples for OpenODD and terminology.

4. Project Resources

4.1. Required

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

4.1.1. Effort

Table 1. Breakdown by Work Packages [WPs]

WP Number

A unique number by which to identify the WP

Title / Description

Provide a brief description of the task to be performed or give a descriptive title.

Deliverable

List of deliverables, including intermediate results of this task.

Effort (Man-days)

Estimated work effort to be performed by the service provider.

Table 2. Total effort
WP No. Project member (man-days) Service Provider (man-days) Total (man-days)

4.1.2. Budget

This section details the budget required by the project to e.g. pay service providers and the funds to be provided by ASAM.

Table 3. Funds required for Service Providers
Task Description Effort Cost (€700 / man-day)
Table 4. Funds Provided by ASAM
Amount (Euros)

4.2. Committed

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

Table 5. Work Effort
Company (Name, Location) Committed Work (man-days) Participant contact details (name, phone, email)

Foretellix (Israel)

25 days

Gil Amid, gil.amid@foretellix.com

University of Warwick

60 days

Jason Zhang, Jason.Zhang@warwick.ac.uk
Siddartha Khastgir, S.Khastgir.1@warwick.ac.uk

FiveAI

15 days

Iain Whiteside

TU Braunschweig

12 days

Till Menzel, menzel@ifr.ing.tu-bs.de

IASYS

25 days

Puran Parekh, ppuran@iasys.co.in

ECR

12 days

Wes Doonan ,wdoonan@ecr.ai

CATARC

20 days

Yunzhi Wang, wangyunzhi@catarc.ac.cn

RISE (Research Inst. of Sweden)

12 days

Dr. Fredrik Warg, fredrik.warg@ri.se,
Dr. Anders Thorsén, anders.thorsen@ri.se

Oxfordshire County Council

12 days

George Economides, george.economides@oxfordshire.gov.yj

AVL

20 days

Ilona Cieslik , ilona.cieslik@avl.com
Hannes Schneider, hannes.schneider@avl.com
Jianbo Tao, jianbo.tao@avl.com

OTSL Inc.

15 days

Yutaka Takahashi, takahashi@otsl.jp

Hexagon

30 days

Edward Schwalb, edward.schwalb@hexagon.com

NVIDIA

15 days

Barnaby Simkin, Bsimkin@nvidia.com

SOLIZE Engineering Corporation

15 days

Shinji Minami, shinji.minami@solize.com

BTC Embedded Systems AG

15 days

Christoph Peuser, christoph.peuser@btc-es.de

BOSCH

15 days

Brade Tino ,Tino.Brade@de.bosch.com

KAIT

12 days

Mr. Fumihiko Nakazawa, nakazawa@cco.kanagawa-it.ac.jp
Prof. Hideo Inoue, inoue@cco.kanagawa-it.ac.jp

e-SYNC

15 days

Kikuo Muramatsu, kikuo.muramatsu@e-sync.biz

SIEMENS

15 days

Prioux, Enguerrand, enguerrand.prioux@siemens.com

DENSO

15 days

Adam Molin, a.molin@eu.denso.com

ANSYS

18 days

Bernhard Kaiser ,Bernhard.Kaiser@ansys.com

Advance Data Control Corp.

10 days

Yasuyuki Nakanishi, nakanisi@adac.co.jp

DLR

20 days

Julian Schindler, Julian.Schindler@dlr.de
Thomas Lobig, thomas.lobig@dlr.de

ICCS

15 days

Anastasia Bolovinou, anastasia.bolovinou@iccs.gr

RAC

12 days

Armin Rupalla, a.rupalla@rac.de
Dr. Frank Hantschel, f.hantschel@rac.de
Thomas Kotschenreuther, thomas.kotschenreuther@rac.de

Fraunhofer IKS

12 days

Salvi, Aniket, aniket.salvi@iks.fraunhofer.de

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

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

4.3. Summary

Table 7. Required work effort should be less than or equal to committed work effort + service provider contracts

Committed Work Effort

Contracted to Service Providers

Required Work Effort

5. Project Plan

5.1. Timeline

timeline openODD

5.2. Deliverables

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

Item No. Description

1

Concept for Format Specification for Simulation

2

Concept for User Guide for OpenODD, including Terminology
including a list of use cases

5.3. Review Process

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

  • Peer Review

  • Editorial Review

  • Project Internal Review

  • Public Review

  • Reference Implementation

  • Implementation Project

  • Validator Project

  • <Other QA measure>