2_technical-content.adoc

ifndef::imagesdir[] 
:imagesdir: ../images
endif::imagesdir[]


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 is using M-SDL language to demonstrate all the concept. It is expected to examine if this language can serve as the foundation of the standards.

Provide a detailed description, how the identified usecases, features or issues (as per preceding chapter) shall be solved or implemented through the proposed project. Descriptions shall include, if applicable:

* Components of a system, which shall be standardized
* Features or functionality of the standardized components
* Method of standardization
* Potentially donated IP from member companies
* Toplevel requirements to be considered for developing the standard
* Statements about backwardcompatibility towards earlier versions of the standard
* Improvements & benefits of the changes as compared to earlier releases of the standard
* Assumptions

The technical content description shall be understandable for readers with an engineering background, but with no specific domainexpertise. Consequently, a brief technical introduction may be needed.

==== Portability
[NOTE]
Based on the presentation by Michael Kluge (dSPACE) from https://www.asam.net/conferences-events/detail/asam-openscenario-v20/[ASAM OpenSCENARIO V2.0 - Proposal Workshop, Topic 6]. Please move chapter to suitable location if necessary.

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_image]]
image:../images/featureSets.png["Feature Sets Proposal"]

The __feature sets__ proposed in picture <<feature_sets_image>> might be an option for a segmentation of the standard to achieve partial support. It has still to be discussed how those __feature sets__ 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 https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard] has to be considered.

==== Domain Model

 OSC lies within the domain of closed-loop system testing for automotive functions. The Domain Model introduces domain-specific content to the otherwise generic Language Concept of OSC 2.0. The domain model provides the semantics, whereas the Language Concept delivers the syntax. Therefore, the Domain Model enables the preservation of semantics when scenario definitions are exchanged between different tools.

 The <<Entity Definition>> builds the core of the Domain Model. This definition should cover all objects that are necessary to describe a wide range of relevant scenarios. The definitions of the identified entities should be unambiguous and should include the main properties and possible actions of each entity. The development of the entity definition will follow two tracks. First, the existing domain model of OSC 1.0 needs to be analyzed and transferred to OSC 2.0 to ensure compatibility between the two versions of the standard. Second, the already identified gaps in OSC 1.0 need to be closed by extending the Domain Model.

 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.

 Another pillar of the Domain Model is the definition of the relationships between the entities with predicate logic. Such an <<Ontology>> will support an unambiguous formulation and categorization of scenarios as it enables inferrment with natural language.


===== Entity Definition 
[NOTE]
Responsibles for filling this sub-chapter: J. Tscheak (maybe), M. Kluge, J.Kaths, F. Bock (maybe), S. Rosenberg (maybe)

The definition of the domain model specific entities is essential as they build the vocabulary of the new language. A full support of the https://www.asam.net/standards/detail/openscenario/#[OpenSCENARIO 1.0 standard], which has already been released by ASAM, is one major requirement for OpenSCENARIO 2.0. This includes a full migration path from the 1.x versions to the language to be developed in this project, which directly leads to the first work packages for  the domain model group:

*WP_DM1_Transfer1x*
The domain model, that has been defined in the https://www.asam.net/index.php?eID=dumpFile&t=f&f=3460&token=14e7c7fab9c9b75118bb4939c725738fa0521fe9[OpenSCENARIO 2.0 Concept Project], did not focus on the compatibility to OpenSCENARIO 1.0. However, OpenSCENARIO 1.0 already contains multiple domain model entities, for which possible deviations to the new model have to be identified. For each of those deviations it has to be defined how they should be handled in order to achieve compatibility. Inconsistent naming and terminology has to be resolved or, if this is not feasible, a mapping between entities in both models has to be defined. All entities in the 1.0 model must have a counterpart in 2.0.

[NOTE]
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)

*WP_DM2_Extend2x*
The need to extend the domain model of OSC 1.0 has been identified in the initiation phase of OSC 2.0. The model draft of the OSC 2.0 concept project provides an initial draft for such an extension. During the development of OSC 2.0, it needs to be refined and extended, as the result of the concept project focused on "most important properties, attributes, possible actions and interrelations.". New entities, their actions and attributes have to defined, for example to cover high-level scenario descriptions, which will be introduced in OpenSCENARIO 2.0. All different use cases for the scenario definition and contents from the 1.0 domain model have to be properly integrated in the final model for 2.0. As experienced in the OSC 2.0 concept project, a close working-level interaction and interrelation with the language group is essential for the success of this work package. This needs to be established already in the beginning of the project.

===== 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
Responsibles for filling this sub-chapter: F. Sanchez, I. Whiteside, P. Parekh, S. Kraines (maybe), M. Nieto (maybe)
WP DM-Ontology - Develop ontology to establish relations between entities
    * synchronize with global ontology developed by ASAM
    * what are the technical artifacts that come out of the ontology development
    * Fran (FiveAI) can contribute, FiveAI developed own ontology for scenario description
    * Iain Whiteside (FiveAI) can provide a presentation on practical usage of their ontology
    * UK has developed a standard (or a PAS really) called 1883 for a driving ontology (Siddhartha could help here)
    * possible input as well from Steven and Florian Bock (Audi)

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

===== 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)."

===== Considerations for 1.x
===== 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.

===== 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).
 
 
===== Siddartha's Paragraphs


==== Usage and Pragmatics
Responsible: Florian Bock

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.


===== Abstraction, Concretization of Scenarios
Responsible: R. Heidtman

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: 

. Has every intention of being understood and tested by a machine (i.e. machine readable) 
. Uses an object oriented "structure for abstraction" 
. 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)
Responsible: R. Heidtman

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)
Responsible: R. Heidtman

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.


====== Interfacing with concrete scenarios from OSC 1.x
Responsible: Sandeep P.

===== Creation of Scenarios & Scenario Workflow (from creation to maintenance of scenarios)
Responsible: Florian Bock

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 worfklow 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

Note: 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 prerequesites 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.

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



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

[.text-center]
image::from_test_scenario_to_test_cases.jpg[Test Scenario vs Test Case, 600]
.Test Scenario vs Test Case

.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_
|===