Skip to content
drawtonomy drawtonomy

Driving scenario classification — functional, logical, concrete

Scenario-based testing of advanced driver assistance (ADAS) and automated driving (AD) systems leans on a three-level abstraction inherited from the PEGASUS research project and now standard practice across ADAS / AV test pipelines:

  1. Functional scenario — qualitative, in natural language.
  2. Logical scenario — parametric, with ranges for each parameter.
  3. Concrete scenario — fully instantiated, every parameter fixed to a value.

This page is a neutral primer on what each level is, how it relates to the ODD and to formats like OpenSCENARIO, and where drawtonomy fits.

The three abstraction levels

Section titled “The three abstraction levels”

Functional scenario

Section titled “Functional scenario”

A functional scenario is a qualitative, natural-language description of a driving situation. It names the actors, the road layout, and the manoeuvres but does not commit to numbers.

Example: “On a two-lane highway, a faster vehicle in the left lane cuts in front of the ego vehicle from the right lane after passing it.”

Functional scenarios live in test plans, design-review documents, slide decks, paper figures, and safety-case narratives. They’re how humans communicate the scenario to each other.

Logical scenario

Section titled “Logical scenario”

A logical scenario turns the functional description into a structured form with parameter ranges. Each variable (initial speeds, distances, TTC, lateral offset, weather, road curvature) is given a domain rather than a single value.

Example: “Ego speed ∈ [70, 130] km/h, cut-in vehicle relative speed ∈ [+10, +30] km/h, time-to-collision at cut-in start ∈ [1.5, 4.0] s, …”

Logical scenarios are what gets sampled, swept, or searched over during test campaigns. Tools and DSLs that target this level include Scenic, scenariogeneration (pyoscx / pyodrx), and OpenSCENARIO 2.0 / DSL.

Concrete scenario

Section titled “Concrete scenario”

A concrete scenario is one specific instance — every parameter fixed to a single value. This is what gets executed in a simulator or a closed-track test.

Example: “Ego at 90 km/h, cut-in vehicle at +20 km/h relative, TTC = 2.5 s at cut-in start, dry asphalt, …”

Concrete scenarios are the level at which OpenSCENARIO 1.x XML, esmini playback, and most replay tooling operate.

How the levels relate to the ODD

Section titled “How the levels relate to the ODD”

The Operational Design Domain (ODD) is the set of conditions under which a driving function is intended to operate (road types, weather, time of day, geographic region, etc.). Scenario classification and ODD interact at every level:

  • Functional scenarios are written within the ODD (“highway driving on a sunny day”).
  • Logical scenarios constrain parameter ranges to respect the ODD (e.g. speed ranges that fit the ODD’s highway-only constraint).
  • Concrete scenarios are instances that should fall inside the ODD, plus deliberately chosen edge cases that probe its boundary.

Scenario classification in standards

Section titled “Scenario classification in standards”
  • PEGASUS — the German research project that crystallised the functional / logical / concrete vocabulary used here.
  • ISO 21448 (SOTIF) — safety of the intended functionality; uses scenario classification as the spine of its argument that the function behaves correctly across the ODD.
  • ASAM OpenSCENARIO — 1.x targets concrete scenarios; 2.0 / DSL targets logical scenarios.
  • ASAM OpenDRIVE — provides the static-world layer that all three scenario levels reference.

Where drawtonomy fits

Section titled “Where drawtonomy fits”

drawtonomy is not a logical-scenario sampler or a concrete-scenario executor. It is a browser whiteboard tuned for driving scenarios. The narrow places it sits in the classification:

  • Functional-scenario figures. The diagrams that go into test plans, design reviews, safety-case documents, slide decks, and paper figures are functional scenarios in visual form. drawtonomy is reasonable for those.
  • Logical-scenario illustration. The “shape” of a logical scenario (the geometry, the actors, the rough motion) is what readers actually need to grasp before the parameter table makes sense. drawtonomy is reasonable for the figure; the parameter table itself lives in your DSL or spreadsheet.
  • Concrete-scenario sketch before authoring. If you’re about to hand-write a specific OpenSCENARIO 1.x XML, drawtonomy can produce a 2D sketch and a starter .xosc you iterate from. See Use case: Sketching before OpenSCENARIO authoring.

For the actual logical / concrete scenario authoring at scale — parameter sweeps, conditional triggers, complex storyboards — use Scenic, scenariogeneration, hand-written OpenSCENARIO XML, or OpenSCENARIO 2.0 / DSL. drawtonomy is for the picture, not the test logic.

In the same scenario-test ecosystem

Section titled “In the same scenario-test ecosystem”
Section titled “Related reading”