Executive Summary

This proposal describes the development of an ASAM OpenXOntology that shall provide a foundation of common definitions, attributes, and relations for central concepts of the ASAM OpenX standards, including OpenDRIVE, OpenSCENARIO, OpenLABEL, and others.

The OpenX standards are intended to work in the common domain of road traffic. The goal of the OpenXOntology project is to define an ontology-based architecture for specifying the domain model that is shared by the OpenX standards. In addition, the project will implement core parts of the ontology, possibly in a modular fashion.

The term "domain model" refers to the conceptualization or mental model a person has of a particular domain. However, each person’s domain model is slightly different. An ontology is a way to specify an explicit representation of the domain model that enables a shared understanding by all participants. If a computer-processible protocol such as OWL is used, that understanding can be shared not just between humans but also with computers.
We differentiate between "concepts" and "entities" in the following way: Entities are actual things in a domain. These can be activities, events, conditions and information, as well as physical objects. Concepts are abstract sets of entities that share common characteristics. We consider the terms "property", "characteristic" and "attribute" to be essentially equivalent. We use the term "relationship" to refer to specific types of relationships between two entities.

The proposed OpenXOntology architecture is intended to cover the following concepts from the domain of road traffic:

  • 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

The core ontology components will be implemented in a way that facilitates extension to the OpenX standards, including OpenLABEL, OpenDRIVE, OpenSCENARIO, Open Simulation Interface (OSI), and OpenODD.

  • OpenLABEL will mainly use concepts from the OpenXOntology related to identification of entities and their spatial relationships in image data.

  • OpenDRIVE will draw on the OpenXOntology to define connective and spatial relationships between elements of road infrastructure and traffic infrastructure.

  • OpenSCENARIO will draw on the OpenXOntology to define spatial and temporal relationships between both dynamic and static traffic agents. In particular, the domain-specific language of OpenSCENARIO 2.0 will use concepts and relationships from the core ontology to provide clear and unambiguous, logically based definitions for the language terms. Note that OpenSCENARIO is intended to use the OpenDRIVE standard to describe information related to controllers of road and traffic infrastructure (e.g. traffic lights and toll gates).

  • Open Simulation Interface (OSI) will use concepts and relationships from the OpenXOntology to designate ground truth from sensor models and sensor fusion models.

  • OpenODD will use concepts and relationships from the OpenXOntology to build specific ODDs.

The following figure illustrates the interdependencies between OpenXOntology and the OpenX standards.


1. Overview

1.1. Motivation

ASAM’s OpenX standards describe the domain of road traffic. They cover concepts like road infrastructure, traffic participants, and scenarios for driving simulations. The standards play an increasing role in the automotive and driving simulation industries.

All OpenX standards come from the same domain - road traffic. However, they are not founded on a common domain model. Thus, central concepts are redundantly defined and described in each of the standards. Definitions sometimes contradict each other. Overlapping definitions currently exist, for example, for lane references (OpenSCENARIO and OpenDRIVE).

This deficiency makes it difficult to link data created under the different OpenX standards. Also, compatibility within data sets complying to the same standard, but coming from different suppliers, cannot be guaranteed. An example of this are scenario labels for driving simulations. The concepts used in scenarios, their parameters, and their relations are not standardized. This makes it considerably more difficult to:

  • Extract scenarios from logged data in a standardized way

  • Manually create unambiguous scenarios

  • Automatically generate synthetic scenarios in a traceable manner

  • Use common labels for objects and scenes

  • Retrieve scenarios based on common queries

These difficulties apply to both humans and machines responsible for defining, labeling, and retrieving scenarios. They also apply to both existing and future standards related to road traffic.

An ASAM ontology that describes among others the concepts of traffic infrastructure, interactions of traffic participants, and environmental conditions can fill this gap by providing a standardized vocabulary and a domain model for the OpenX standards. This will also facilitate the use of artificial intelligence for OpenX applications.

1.1.1. What is an ontology

An ontology is often described as a specification of a conceptualization of a domain. This means that the role of an ontology is to provide standardized definitions for the concepts of a specific domain. The ontology defines classes (concepts) for sets of actual things in the domain that have common characteristics. These things include specific events, actions, times, places and ideas in addition to physical objects. In addition to the concepts, the ontology describes their characteristics or attributes, and defines typed relationships that may hold between actual things that belong to one or more concepts. Ontologies thus provide explicit knowledge models for domains that can help overcome the problem of data ambiguity. They enable both humans and machines to understand the semantics of data in a common way and thus enable efficient communication and information exchange between different systems.

Information is encoded in an ontology as a list of triples, where each triple takes the form of "subject-relationship-object", e.g. a typed binary relationship between two things. These things may be entities or concepts. In this way, an ontology creates a semantic web of linked data. In this web, reasoning can be used to derive new facts about the things that are not expressed in the ontology or the database explicitly. Also, the data can be checked for semantic errors, meaning logical incoherencies.

1.2. Project goals

The goal of the ASAM OpenX Ontology project is to define an architecture for an ontology that acts as a clear and unambiguous specification of the shared domain model of road traffic for the OpenX domain. In addition, the project will provide implementations of core modules of the ontology for describing concepts and relationships of entities and environments relevant to road traffic. The project will focus on central OpenX concepts shared by all OpenX standards rather than focusing on one specific OpenX standard. The ontology shall ensure that all common concepts are defined in a central place rather than repeatedly throughout the different OpenX standards. By using this ontology, all of the OpenX standards are able to rely on the common definitions of the shared concepts.

The project group suggests the following goals:

  • Develop an ontology that provides a specification of the concepts comprising a core domain model for the OpenX domain of road traffic. Some of the concepts that the domain model will cover are:

    • Road infrastructure

    • Temporary infrastructure, such as construction works

    • Traffic participants

    • Traffic objects, such as signs

    • Environment descriptions, such as weather and times of day

    • Objects of interests

    • Scenario labels

  • Ensure a shared understanding of terms, definitions and relationships. This also covers organizations outside ASAM, for example, other standardization bodies, regulation authorities, OEMs, and suppliers.

  • Provide a foundation for defining application-specific concepts in both existing & upcoming standards.

  • Define guidelines for integration of the ontology into other standards.

The project will leverage existing ontology and semantic standards, for example, the W3C semantic web standards, ISO15926, and ISO704. It will also closely align with ongoing standardization projects, such as OpenSCENARIO and OpenLABEL. === Use Cases

Use cases in the context of ASAM standards describe the external behavior of the standardized system, i.e. the interaction of the system with a user or with another system. The description of use cases is particularly useful for explaining the motivation for new standards, major version development projects or the addition of new features in minor version development projects.

This can be expanded on during a project’s development.

Use cases should adhere to the following template:

[cols="1,5",caption='Use Case {counter:uc1}: ']
|*Description* |	<Write a brief description for the use-case.>
|*Relevant users* |	<One or more relevant user perspectives from <<Users>>>
|*Author* |	<Name, email of the author (for questions)>
Use Case 1: Ontology as scenario description basis


A core ontology will support the creation/generation of scenarios across a wide range of specifications, such as the 6 sub-domain layers and three abstraction levels (functional, logical, concrete) originally proposed by Pegasus. This support is achieved by unambiguously describing the environment of the scenario together with the objects and their maneuvers. As such, this ontology should be used throughout all standards that refer to scenario content.

Relevant users

Label annotator


Florian Bock (florian1.bock@audi.de)

Use Case 2: Common core ontology for different standards


Within different standards (e.g., OpenDRIVE, OpenSCENARIO, OpenLABEL), the same type of base information might be required to define each language or file format. For example OpenLABEL describes labels for scenarios and OpenSCENARIO describes scenarios. In such cases, defining the common concepts in a core ontology makes sure that the same concepts are not reinvented in each of the standards. This reduces the size of the standards, avoids redundant effort, and unifies the structure.

Relevant users

Developer of an ASAM standard


Florian Bock (florian1.bock@audi.de)

Use Case 3: Core ontology as a language basis for all parties


A core ontology for the road traffic domain provides a common language basis for all vendors, suppliers, developers, end users, and other stakeholders. Those parties can use the core ontology to implement their tools, develop their processes or describe/write their artifacts. This prevents each party from defining its own base language structures that might prevent the artifacts from being exchangeable.

Relevant users

Label annotator, tool developer, scenario creator


Florian Bock (florian1.bock@audi.de)

Use Case 4: Natural-language authoring interface


Using a logically formalized ontology, a reasoning engine can make inferences about what a person is trying to communicate. Based on those inferences, a computer agent can make suggestions in natural language to help the person make a clear and complete description that is logically consistent. This can also help with the creation of unambiguous scenarios by multiple authors.

Relevant users

Scenario creator, model creator, label annotator, specification engineer


Steven Kraines (steven@symphonies.co.jp)

Use Case 5: Semantic error checking


Using a logically formalized ontology, a reasoning engine can detect logical incoherencies in a statement. Incoherencies can occur within the statement and also with respect to the background knowledge given in the core ontology. Because the incoherencies are with respect to the logical expressions of the concept meanings in the core ontology, this provides a form of semantic error checking.

Relevant users

Scenario creator, label annotator, model creator, tool developer, specification engineer, ontology maintainer


Steven Kraines (steven@symphonies.co.jp)

Use Case 6: Semantic searching and matching


Using a logically formalized ontology, a reasoning engine can match statements that mean the same thing even if they do not say the same thing. This enables users to search for descriptions that match the meaning of the search query rather than just the list of search terms. This also enables users to find groups of statements that say (almost) the same thing and extract common semantic motifs from a large repository of statements that have been authored in compliance with the core ontology.

Relevant users

Label annotator, scenario creator, model creator, data scientist, systems engineer


Steven Kraines (steven@symphonies.co.jp)

Use Case 7: Extending core ontology to create application-specific ontologies


Different parties can "extend" the core ontology, which is defined in a standard semantic web format, to create their own application-specific ontology. They do this by integrating their own concepts with the ASAM central concepts.

Relevant users

Developer of ASAM standard, tool developer, ontology maintainer


Steven Kraines (steven@symphonies.co.jp)

Use Case 8: Common core ontology for data analysis


A core ontology can help identify structures, elements and parameters within recorded driving/test/sensor data, for example, images or video feed. The knowledge about which elements there are/should be in the actual situation being observed by the sensors makes the search by recognition within the data streams easier to direct and control.

Relevant users

Model creator


Florian Bock (florian1.bock@audi.de)

Use Case 9: Classifying things and systems of things using logical inference


Using a logically structured ontology, a reasoning engine can classify things in the domain (or even systems of things) using logical inference based on the characteristics of concepts defined in the ontology. For example, given the attributes and characteristics of an object in an image collected by a drive recorder, the reasoning engine can infer to which classes in the ontology the object is likely to belong.

Relevant users

Label annotator, test engineer, specification engineer, public domain user


Steven Kraines (steven@symphonies.co.jp)

1.3. User Perspectives

  1. Model creator (e.g. sensors or other actors)

  2. Test engineer

  3. Developer of an ASAM standard

  4. Ontology maintainer

  5. Label annotator

  6. Public domain user

  7. Tool developer (e.g. simulation interface developer)

  8. Scenario creator

  9. Specification engineer

  10. Data Scientist

  11. ODD designer

  12. Systems Engineer

User 1: Model Creator / Model user in OSI

Who are they?

People who create sensor models / sensor fusion models in accordance to the Open Simulation Interface (OSI) standard

How do they work?

Create models which will be interfaced with driving simulator for scenario execution. Those models will create a simulated ground truth for entities that are defined in the core ontology model and present this truth to the autonomous driving function during the simulation execution.


Use the standard ontology from the core domain model to present simulated ground truth for the traffic domain

User 2: Test Engineer

Who are they?

  • Specify and execute the test cases (from scenarios given to them)

  • Be part of DVP&R (Design Verification/Validation Plan & Report)

  • Use scenarios defined with standard ontology which can be interpreted by different driving simulators and XIL rigs

How do they work?

Functional/abstract scenarios (inherit) → define scenario parametrisation ranges/values → test case definition → test plan → test environment setup → test case execution → test data analysis


  • Remove ambiguity in data exchange

  • Test cases should be executable on different platforms

  • Formal natural/intuitive language (self- explanatory) should be used

User 3: Developer of an ASAM standard

Who are they?

Engineers with experience in the automotive and/or software sector participating in ASAM projects for implementing or extending ASAM OpenX standards.

How do they work?

Work in ASAM project groups, participate in regular work group meetings, develop data models and code for their specific standard, write concept papers, author documentation for the standard


Have clear guidelines for how they can apply the core concepts and relationships provided by the ASAM OpenXOntology in order to provide formal, logic-based definitions for the main concepts in their particular domain. Additionally, provide recommendations for which concepts must be used to ensure interoperability with other OpenX standards. If migration is required, they need migration guidelines. They expect an easy-to-access and easy-to-understand documentation for the OpenX ontology.

User 4: Ontology maintainer

Who are they?

Ontology experts with a background in (software) engineering, linguistics, technical communication or similar.

How do they work?

Analyze documentation and data models of specific domains, such as road traffic, to define and describe central concepts of this domain in a formalized knowledge representation (knowledge graph). To do so, they apply methods from terminology management, knowledge engineering, programming, and technical communication.


Develop an extensible representation of the domain’s concepts that can be used by as many stakeholders as possible, for different programming environments and subdomains. Achieve a regular alignment with subject matter experts from relevant subdomains for constant further development of the central knowledge model.

User 5: Label annotator

Who are they?

Persons working for labeling companies, who create or edit labels about scenes (typically object and scene classes and attributes).

How do they work?

Receive data and lists of to-be-labeled concepts from customer, use labeling tools (semi-automated), validate and return label files. If concepts are defined in an ontology, cross-project/customer interoperability is possible.


Create accurate and searchable labels for machine learning, for ground truth for XiL, and for scene database creation.

User 6: Public domain user

Who are they?

People outside of ASAM who might be interested in accessing the data content of the OpenX projects

How do they work?

Share data via Open Linked Data standards such as RDF and RDF-S. Use standard REST APIs as data-sharing endpoints. Often government / public service agencies that create "mashup" websites for public benefit.


Employ Open Linked Data standards (RDF, RDF-S, OWL, JSON, etc.) for expressing the core ontology and provide support for OpenX projects to use those standards in their data storage formats. Provide guidelines to other OpenX projects for how to create APIs for making their data available in the public domain, using technologies such as SPARQL.

User 7: Tool developer

Who are they?

People developing tools for data recording and for the design, measurement, simulation, testing and verification of components, driving systems, driving dynamics, environments, etc. (XiL). The tools are often part of a tool suite provided by a larger company.

How do they work?

Use scenarios in driving simulation and component testing, presenting those scenarios to autonomous driving components.

What are their goals

Simulation with ground truth data, providing a large set of (critical) scenarios for autonomous function testing. Interaction with standardized labeling (OpenLABEL) and standardized scenario description (OpenSCENARIO)

User 8: Scenario creator

Who are they?

People who want to create scenario descriptions by writing them textually (either in natural language or in a technical format such as XML) or by drawing them graphically

How do they work?

Identify necessary information for the scenario description, and write or draw the resulting scenario using an appropriate authoring tool. For that, a corresponding ontology is is necessary to allow the identification and usage of the relevant scenario aspects.


Create/write appropriate scenario descriptions as text or image, which are grounded in a well-defined core ontology

User 9: Specification engineer

Who are they?

People, who are responsible to create, review and share specification documents for functional development projects

How do they work?

  • They create specification documents (and implicitly scenario descriptions) at an abstract level to define and describe the function- or system-to-develop. *They provide such specification (textual) documents to other stakeholders (test engineers, systems engineer, management, regulators etc.).


  • Remove ambiguities in the exchanged data and documents. *Have a unambiguous, easy, formal, intuitive (self-explanatory) natural-language style notation format that can be used to express the necessary artifacts in a common way. *Reduce the development life cycle time by avoiding to redefine internal ontologies.

User 10: Data scientist

Who are they?

  • Link between system engineers, test engineers and vehicle performance over time

  • Understand aggregated scenario library content, related performance data and test results data.

  • Maintains coherency and quality of data across multiple data life cycles.

  • Maintains the data building blocks in terms of feature pipelines.

  • Identify missing scenarios based on the test data analysis.

How do they work?

Extract features from the data (based on ontology)


  • Ensure reverse compatibility (i.e. linking versions of ontologies)

  • Remove ambiguity in data exchange

User 11: Systems engineer

Who are they?

  • Specify the capabilities (e.g. ODD, functional/abstract scenarios)

  • Specify architectures (system, functional, firmware, hardware, software)

  • Designing the systems to sub-systems

How do they work?

  • Desired capabilities (+ functional/abstract scenarios) → architectures → design (not V&V)

  • Knowledge of list of components and their relationships

  • Exchange data between systems (and organisations)


  • Common understanding (and traceability) across all roles in product development

  • Basis for the ODD (+ functional scenario) definition (ontology should be capable of defining the ODD)

  • Remove ambiguity in data exchange

  • Ontology for external behaviour (incl. actions): to define functional scenarios

User 12: ODD Designer

Who are they?

  • Specify system capabilities

  • Specify architectures for the system based on the capabilities

How do they work?

  • Based on the desired capabilities (including identification of functional/abstract scenarios), they identify architectures

  • They are responsible for the exchange of data between different stakeholders (manufacturers, regulators, tier 1 suppliers)


  • Unambiguous ODD definition

  • Measurable attributes ODD definition

  • Derive scenarios from ODD

1.4. User Stories

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.

If using user stories, please maintain the following format:

As a <user role> I want to <do>, <have>, <use> something because / in order to …​

e.g. As an AV/ADAS developer company, I want to search, review and reuse scenarios built by other companies, because we rely on spezialized external suppliers for scenario data for our development activities.

Label annotator
  1. As a label annotator I want to be able to easily access a list/graph of concepts that can help me understanding which are the categories I have to label.

  2. As a label annotator I need to be guided and constrained by the annotation tool to produce labels that are logical and consistent.

  3. As a label annotator I want to access empirical datapoints to verify that the anntotations are correct in order to reduce ambiguities.

Model creator (e.g. sensors or other actors)
  1. As a model creator I want to have unambiguous descriptions of concepts (objects, spatio-temporal and physical properties) needed to build models for a simulation environment, in order to avoid confusion when communicating with external systems.

  2. As a model creator I should know that the application of the model in the development process is clearly defined by the Key Performance Indicators (KPI) in order to choose technologies or make decisions based on standards.

  3. As a model creator I want to understand the semantic relations between objects in order to associate them across their representations on different sensing technologies.

Tool developer (e.g. simulation interface developer)
  1. As a tool developer I want the followed standards to be easily translatable into software code, in order to make the development process less prone to errors.

  2. As a tool developer I want to have a unified common language and metrics to make interfaces understandable by other components.

  3. As a tool developer I want to have an API/SDK (Application Programming Interface/Software Development Kit) to easily access information from the ontology during development to be able to make implementing the standards more accesible.

Developer of an ASAM standard
  1. As a developer of an ASAM standard, I want to use clear and unambiguous definitions from the OpenXOntology for my ASAM standard. Examples: vehicle definition. The reason is that the definition needs to be interpreted in the same way by humans and machines and also that I want to save effort and avoid creating my own definitions.

  2. As a developer of an ASAM standard, I want to use the building blocks provided by the OpenXOntology to define the domain-specific concepts of my standard so that our domain-specific concepts comply with OpenXOntology.

  3. As a developer of an ASAM standard, I want to rely on a ontology that provides central concepts, but is not too large so that I can still cover our specific use cases and definitions in our specific standard. And to avoid that the central ontology is hard to maintain.

  4. As a developer of an ASAM standard, I want to be sure about the attributes that a specific concept possesses, e.g. height of a pedestrian.

  5. As a developer of an ASAM standard, I want the update and revision process of the ontology to be in line with the development processes of the other OpenX standards so that the different standards are always in sync.

OpenXOntology maintainer
  1. As an OpenXOntology maintainer, I want the ontology to have a modular architecture that enables us to easily modularize different dimensions of the ontology (e.g. spatial, temporal relationships) and plug in subdomains.

  2. As an OpenXOntology maintainer, I want the ontology to be consistent and use methods/tools that make sure that the ontology stays logically coherent and compatible.

  3. As an OpenXOntology maintainer, I want to use a W3C standard language for modeling the ontology (or a compatible language) so that I can rely on established technologies and approaches for building and maintaining ontologies.

  4. As an OpenXOntology maintainer, I want to reuse upper-level ontologies that define basic concepts like compositional, spatial and temporal relationships because we can reuse the knowledge from the upper-level ontologies and their robust data models.

  5. As an OpenXOntology maintainer, I want to reuse/refer to definitions from other ontologies and international stanardization initiatives in order to keep the OpenXOntology compatible and relevant. And in order not to reinvent the wheel or make life easier for implementations already relying on other standards.

Public domain user
  1. As a public domain user, I want to use standard interface like SPARQL and standard formats like RDF to access the knowledge available in OpenXOntology. The reason is that most open linked data is available in these formats, and there are many tools available for manipulating data that is in these formats.

  2. As a public domain user, I want to use the OpenXOntology free of charge and with tools of my own choice. The reason is that while access to ASAM OpenX standards standard may incur a charge, the OpenXOntology will be necessary for people in the public domain to process data that adhere to that ontology, and so it would be beneficial to make the OpenX Ontology itself open access free of charge.

  3. As a public domain user, I want to understand the OpenXOntology easily, e.g. by reading the documentation. The reason is that the OpenXOntology may be the only form of schema available for making sense of open linked data published according to the standard.

  4. As a public domain user, I want the OpenXOntology to be used to annotate open source/open access data that are then available in the open linked data space. The reason is that it is envisaged that many non-profit organizations may use the OpenXOntology to describe their open-source / open-access data in the interest of promoting wide-scale usage of that data.

Scenario creator
  1. As a scenario creator, I want to be able to create unambiguous descriptions of scenarios at various levels of abstraction. The reason is that I want my scenario to be usable by as many different applications as possible and to be self-describing so that I do not need to write extensive documentation.

  2. As a scenario creator, I want a scenario creation tool for constructing scenario descriptions that is easy to use and in particular has "low cognitive overhead," meaning that I do not need to learn about special rules or formats. The reason is that scenario creators come from a wide range of backgrounds with varying levels of expertise in techniques for creating unambiguous computer-understandable descriptions.

  3. As a scenario creator, I want a scenario creation tool that actively helps me to create a description of a scenario that completely describes all of the information that I want to give. The reason is that particularly for abstract scenarios where many details are not provided concretely, it is still important that the scenario description contains all of the information that it is intended to contain.

  4. As a scenario creator, I want a scenario creation tool that actively identifies errors in the scenario description I am creating, not only in syntax, but also in semantics. The reason is that particularly for abstract scenarios, it is difficult for the scenario creator to check all of the possible incoherencies in the meaning given by the components of the scenario description.

Data Scientist
  1. As a data scientist, I want a clear and unambiguous definition from an Ontological perspective regarding element and relationship definitions.

  2. As a data scientist, I want to ensure that there is reverse compatibility between different versions of the Ontology (as ontology will be updated during project life cycle)

  3. As a data scientist, I want to be able to extract features from the test logged data (based on my ontology)

ODD Designer
  1. As an ODD designer, I want a clear and unambiguous definition from an Ontological perspective regarding element and relationship definitions in the driving domain.

  2. As an ODD designer, I want the ontology elements and relationships to be measurable.

  3. As an ODD designer, I want the ODD definition to be understandable by regulators, systems designers, test engineers, simulation engineers, etc.

  4. As an ODD designer, I want to use the ODD definition to be the input for test scenario creation.

1.5. Relations to Other Standards or Organizations

1.5.1. Description Logics

In information science an ontology is "a specification of a conceptualization of a domain." In other words, an ontology functions to specify the way that a domain is conceptualized. DL ontologies (DL = description logics) do this by specifying a set of elemental concepts (termed classes in OWL) covering the main types of things that are of interest in the domain together with their attributes (termed properties in OWL) and binary relationships that can be expressed between specific things in the domain. Things include not only physical objects, but also specific events, actions, times, places and ideas, etc. Furthermore, by applying the logical constraints supplied by the description logic framework to the definitions of the concepts, attributes and relationships, a DL ontology can provide a logically grounded theory about the nature and possible relationships of things in the domain. In particular, an ontology specifies axioms that define constraints on attributes and relationships for specific concepts. In this way, an ontology gives well-defined semantics that can overcome the problems of data ambiguity. For example, in the context of autonomous vehicle test scenarios, an ontology can be constructed so that the concepts in the ontology, together with expressions of their attributes and relationships can define any situation in which a self-driving vehicle is placed. This part of a DL ontology is called the "T-Box".

A DL ontology also provides a mechanism for instantiating the concepts given in the T-Box. Using this mechanism, users can make assertions about situations and conditions in the target domain which may or may not be true. In particular, users can specify the concept types of individual things together with the specific properties that are believed to exist between those individuals. This part of a DL ontology is called the "A-Box".

1.5.2. ISO704

ISO704 provides a methodology for creating terminologies that are essentially consistent with the requirements for creating the T-Box of a DL ontology. From ISO704, objects are: "things in the world that are perceived or conceived (including actions and ideas)."

Furthermore, like DL ontologies, ISO704 differentiates between actual individual objects in the domain (a particular vehicle or an actual merge maneuver that took place yesterday) from concepts that are formed as abstractions of sets of objects having similar features (vehicles in general, merge maneuvers in general).

We intend to use ISO704 as an approach to identify key concepts in the road traffic domain.

1.5.3. OWL

The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies. Because OWL is based on XML and certified by W3C, many reasoning engines available today can interpret and infer new meaning from descriptions written in OWL. Reasoning engines, such as Pellet and HermiT, are often provided in modern graph databases and semantic tools such as Protégé.

1.5.4. ISO15926

Ontology development can benefit from building upon a standard upper-level ontology that describes a set of basic types of things and relationships in the world independently of the target domain / purpose.

Several standard upper-level ontologies have been proposed and applied to various extents. For engineering domains, the ISO15926 is one candidate for an upper level-ontology. A subset of the ISO15926 may be sufficient to cover the target domains of OpenX while being easier to understand for workers in those domains. We intend to use ISO15926 to represent spatio temporal aspects and data modeling for the key concepts defined using ISO 704.

As an example, the following subset of ISO15926 is being considered for adoption in the development of the proposed OpenX core ontology:

  • abstract object

    • class

      • role

      • status

      • property

    • relationship

  • possible individual

    • whole life individual

    • arranged individual

    • physical object

    • activity

    • event

    • point in time

    • point in space

1.6. Relations to Previous Work

Menzel and colleagues have published initial efforts to design ontologies for the field of autonomous driving.

  • In "Scenarios for Development, Test and Validation of Automated Vehicles", they highlight the need for a consistent terminology to support scenario creation for the functional, logical and concrete abstraction levels defined by the ISO26262.

  • In "From Ontology based Scene Creation for the Development of Automated Vehicles", they observe that in the field of autonomous driving, ontologies have already been demonstrated to be useful in building knowledge-based systems for assisting decision making and scene understanding for scenarios to assess automated driving functions.

They summarize the benefits of an ontology approach as follows:

  • Identify hierarchical missing concepts in the background knowledge (T-Box)

  • Check for conflicts in the modeled concepts

  • Check if similar concepts exist over the knowledge base

  • Check consistency of assertions in the knowledge base (A-Box)

  • Infer situational knowledge by associating assertions with background knowledge and formally specified rules (e.g. in SWRL)

  • Knowledge and assumptions are represented explicitly in formal logic

  • Complexity is reduced compared to the resulting scene catalog (because of the organizational structure of the ontology)

  • If the elements are correctly modeled in the ontology, the elements will also be correctly combined with other layers in the resulting scene catalog.

2. Technical Content

Based on the motivations, goals, user perspectives and user stories outlined in section 1, the OpenX Ontology project will use an ontology-engineering approach to define a formal specification of the core concepts and relationships for the domain of road traffic. In particular, building on the previous work and existing standards for creating ontologies and terminologies described in section 1, a conceptual framework for basing the semantics of entity and term definitions in other OpenX projects will be produced at three levels: core, domain and application.

2.1. Core Ontology

At the core level, it is envisaged that a relatively small set of basic concepts and relationships will be defined as building blocks for more complex and domain-specific concepts. The core concepts will cover at least concepts of identifiable physical objects and their changes in state, activities including actions and behaviors that involve those physical objects in active and passive roles, and events that mark the changes in states of physical objects as well as critical points in time and triggers for activities. The core ontology will also provide meta models for describing common compositional, spatial and temporal relationships between actual entities in the domain.

The core ontology will leverage existing industrial standards for ontology and terminology creation together with other existing upper ontologies currently in use. By doing this, the resulting core ontology will not only benefit from lessons learned in other ontology development projects, it will also be able to integrate knowledge asserted in those other upper ontologies.

2.2. Domain Ontology

Based on an analysis of the existing OpenX standards, such as OpenLABEL, OpenSCENARIO, OpenODD, OSI, and others, the project will identify basic concepts and relationships that these standards share. This may include concepts like road infrastructure, dynamic and static traffic objects, and V2X communication. These basic concepts will be summarized in the domain ontology of road traffic in order to provide a consistent and meaningful underlying language for the OpenX standards.

As many of the OpenX standards themselves are extensible (e.g. the adding of new actor types to OpenScenario 2.0), the domain ontology will itself be extensible.

The domain ontology will leverage existing industrial standards and standardisation initiatives regarding ontologies for the road traffic domain in order to provide a domain ontology that is consistent with these other standards.

2.3. Application Ontology

Documentation and guidelines on how to extend and integrate the OpenXOntology. This should also touch on the MWPs we want to create and why.

3. Project Resources

3.1. Work packages

For each Work Package (WP), please define a title, provide a short description and the expected outcome(deliverables) of such a WP - e.g. Guidelines, documentation, recommendation to another WP, etc. If possible, identify one or more Persons to coordinate this WP - at a minimum this person will ensure the WP is detailed in the project proposal, at best they will coordinate the WP work during the

Please use the following asciidoc template to define a work package in the proposal:

[cols="1,5",caption='WP {counter:wp1}: ']


a| *Coordinator*

a| *Effort*
a| <Estimate in man-days of the effort required to complete this work package>

3.1.1. Design of the Core Ontology for OpenX

WP 1: Evaluating Modeling Language Options


  • research and evaluate available options, e.g. OWL, SPARQL, SUO-KIF, SBVR, OntoUML, etc.

  • present summary of evaluation to the overall group for final decision on modeling language to use


  • results of research and evaluation of available modeling language options



WP 2: Evaluate possibilities for application and/or reuse of existing upper ontologies


  • finding robust metamodels for different dimensions of the OpenX ontology (e.g. spatial relationships, temporal relationships, causality, etc.)

  • leveraging existing "ontology solutions" provided in existing upper ontologies such as ISO15926, SUMO, Dolce, etc.


  • recommendations for parts of upper ontologies to reuse in the OpenX Ontology



WP 3: Evaluate existing standardization initiatives


  • explore existing initiatives of ASAM and other standardisation bodies in order to identify standards or recommendations that may be related to OpenXOntology, e.g. crystal ontology PAS, PAS 1883, etc.

  • analyze the ontologies or knowledge repositories of such identified standards to describe overlaps and dependencies

  • based on above, recommend methodologies for creating and maintaining the OpenXOntology


  • Report on existing standards related to OpenXOntology

  • Identification of overlaps and dependencies with other ontologies

  • Recommendations for ontology creation/maintenance



WP 4: Decide the architecture of the OpenX Ontology


Addressing questions such as:

  • should the OpenX Ontology have a core? how large should the core be? how many concepts should be included in the core?

  • how modular the OpenX Ontology should be? what should the modules be?

  • how to support definitions for specific concepts that are used in multiple OpenX standards in slightly different ways

  • Identify available tools related to ontologies and how they interface with an ontology. Decisions to adopt those tools will place certain requirements on the global architecture.

Example of an architecture to address the questions above:

  • core ontology: containing a small set of universal concepts and relationships (few as possible)

  • domain ontology: standard concepts shared across OpenX standards defined in terms of the concepts and relations from the core ontology

  • application ontology: extensions of the domain ontology by developers of specific standards to define their standard-specific concepts


architecture model for OpenX Ontology



3.1.2. Domain model for the OpenX standards (domain ontology)

It is not completely clear, which working group will deal with what topic, so maybe some of the identified working packages should be moved to other working groups or packages from other groups should be moved here. The topic of interfaces to OpenX standards is bidirectional, so we have to extract information from other standards as well as provide information to other standards
The "Overall Working Package" is a container for all subpackages concerning ontology for different subtypes of information The working packages should be broken down into smaller packages, the granularity is important and has be to defined in the future
WP 5: Coordination of individual subdomain WPs


  • coordinate over the domain WPs to ensure the concepts are aligned with the overarching architecture of the domain model.


  • Complete specification for a domain ontology incorporating the outputs of the conceptualization WPs



WP 6: Road topology & traffic infrastructure


  • conceptualize all parts of the road topology/traffic infrastructure (incl. temporary changes) based on the identified information extracted within the other working packages

  • synchronization ensured via WP Coordination of individual subdomain WPs.


  • Parts of a conceptualized sub-domain model for the road topology/traffic infrastructure (tree of terms, entities, relations) including documentation of the concepts and relationships



WP 7: Traffic objects


  • conceptualize all parts of the traffic objects based on the identified information extracted within the other working packages.

  • synchronization ensured via WP Coordination of individual subdomain WPs.


  • Parts of a conceptualized sub-domain model for the traffic objects (tree of terms, entities, relations) including documentation of the concepts and relationships



WP 8: Environment


  • conceptualize all parts of the environment based on the identified information extracted within the other working packages. This includes e.g. weather and other conditions

  • synchronization ensured via WP Coordination of individual subdomain WPs.


  • Parts of a conceptualized sub-domain model for the environment (tree of terms, entities, relations) including documentation of the concepts and relationships



WP 9: Data & communication


  • evaluate the necessity of including information or messaging attributes in an ontology, which may stem from e.g. vehicle internal information or V2X communication

  • This WP is expected to align with the parallel OSI development project

  • synchronization ensured via WP Coordination of individual subdomain WPs.


  • Parts of a conceptualized sub-domain model for the environment (tree of terms, entities, relations) including documentation of the concepts and relationships



3.1.3. Interfacing with other Standards and Activities (Application Ontology)

WP 10: Interfacing with the Ontology


  • provide guidelines on how best to interface (tooling) with the OpenX ontology


  • guideline documentation for different tooling workflows that could leverage the OpenX Ontology



WP 11: Implementing Ontology into OpenX Standards


  • determine explicit step by steps on how to integrate into specific OpenX standards and how to enable standard developers to create their own concept definitions that are consistent with the core ontology

  • create a minimal working example of an ontology for each OpenX standard as a reference for these as well as a demonstrator of the functionality.

  • The first step will be to identify a priority order for defining the working examples based on the status of the other OpenX activities. This will likely begin with OpenLABEL, due to the strong interrelations between the two projects.

  • This WP will be used as a stepping stone for WP Implementing Ontology into OpenX Standards


  • specification and guidelines for implementing the OpenX Ontology for each OpenX standard

  • Minimum working examples of the core ontology for each OpenX standard.



3.2. Company Committments

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

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

Advanced Data Controls Corp.



Yasuyuki Nakanishi; Masahiko Kohda


AVL List GmbH



Jianbo Tao





Qidong Zhao; Bolin Zhou

zhaoqidong@catarc.ac.cn; zhoubolin@catarc.ac.cn




Nicola Croce


Edge Case Research



Wes Doonan





Jannik Wefers





Iain Whiteside


FZI Forschungszentrum Informatik



Christian Steinhauser; Julian Fuchs

Steinhauser@fzi.de; fuchs@fzi.de




Yao Chen





Puran Parekh; Deepak Patil; Shantaram Jashav

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

IKA RWTH Aachen University



Hendrik Weber


Intelligent Automotive Parts Promotion Institute



Bongseob Kim


itemis AG



Andreas Graf





Lukas Westhofen


parson AG



Ulrike Parson


RA Consulting GmbH



Thomas Kotschenreuther; Frank Hantschel

t.kotschenreuther@rac.de; f.hantschel@rac.de

TU Braunschweig - Institut für Regelungstechnik



Till Menzel


WMG University of Warwick



Dr Jason Zhang; Siddartha Khastgir

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




Steven Kraines; Ai Takagi

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



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

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

3.3. Effort Summary

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

Core Ontology(WP1-WP4)




Domain Ontology(WP5-WP10)




Application Ontology(WP11-WP13)








Table 4. Resource Check
Project Members Service Provider Total







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 5. Funding limits
Project Type Factor

New, major, minor or revision standard development project


Study project


Concept project


Table 6. Funds required for Service Providers
Task Description Effort
[€700 / day]

Ontology Implementation


35.000 EUR



24.500 EUR



59.500 EUR

4. Project Plan

4.1. Timeline

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


4.2. Deliverables

  • Recommendations for ontology modeling language to be used and upper-level ontologies to be reused

  • Report and recommendations regarding existing standardization initiatives related to OpenXOntology

  • Architecture model for an OpenXOntology

  • Ontology that

    • covers the currently existing ASAM OpenX domain

    • covers Operational Design Domain definition which is aligned with ODD taxonomy standards (BSI and ISO)

    • contains the minimum set of concepts and relationships needed to achieve the above

  • Documentation for the OpenXOntology including descriptions of the overall design, reused standards, differentiation against other OpenX standards and a reference documentation for all ontology classes and properties.

  • Guidelines for

    • different tooling workflows that could leverage the OpenXOntology

    • for each OpenX standard on how to implement the OpenXOntology

    • extending the ontology for application-specific use cases

    • migration/phasing examples for each OpenX standard

  • Minimum working examples of the core ontology for each OpenX standard

4.3. Review Process

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

  • Project member review

  • Public review

  • Reference implementation