Commit a2ccaeef authored by Michael Kluge's avatar Michael Kluge
Browse files

Update subchapters/2_technical-content.adoc

parent 638c45e0
Pipeline #1424 passed with stage
in 14 seconds
......@@ -32,18 +32,10 @@ As identified in the concept document, the domain model for OpenSCENARIO 2.0 sho
==== Entity Definition
Persons responsible for filling this sub-chapter: M. Kluge, S.Kraines
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.
Identify entities and their actions / methods that are introduced by high-level description of OSC 2.0 (so not part of OSC 1.0) (maybe Florian Bock, Michael Kluge, Jakob Kaths, maybe Sharon Rosenberg)
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.
==== Extensibility
......@@ -67,13 +59,11 @@ Later, these new extensions be efficiently leveraged for automated user-defined
===== Ontology
Persons responsible for filling this sub-chapter: S. Kraines, I. Whiteside
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.
......@@ -288,9 +278,6 @@ image::from_test_scenario_to_test_cases.jpg[Test Scenario vs Test Case, 600]
==== Portability
Based on the presentation by Michael Kluge (dSPACE) from[ASAM OpenSCENARIO V2.0 - Proposal Workshop, Topic 6].
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.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment