Commit b0fc302a authored by Benjamin Engel's avatar Benjamin Engel
Browse files

Add Scenario abstraction chapter 2.3, R.Heidtman

parent 3d2cb694
...@@ -159,13 +159,35 @@ This is also true for a proper testing workflow, that should describe the intera ...@@ -159,13 +159,35 @@ This is also true for a proper testing workflow, that should describe the intera
===== Abstraction, Concretization of Scenarios ===== Abstraction, Concretization of Scenarios
Responsible: ? 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) ====== Scenario summary to functional Scenario (i.e. Rules of Abstraction)
Responsible: ? 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) ====== Functional Scenario to concrete scenario (i.e. Rules of Concretization)
Responsible: ? 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 ====== Interfacing with concrete scenarios from OSC 1.x
Responsible: Sandeep P. Responsible: Sandeep P.
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