Skip to content
drawtonomy drawtonomy

What is OpenSCENARIO?

OpenSCENARIO is an ASAM open standard for describing dynamic driving scenarios — what the ego vehicle and other traffic participants do over time, in a form that simulators can replay. It’s the de-facto exchange format for scenario-based testing of automated driving systems.

The two OpenSCENARIO families

Section titled “The two OpenSCENARIO families”

There are two largely independent specs that share the name:

  • OpenSCENARIO 1.x — XML-based. Stable, widely supported. The 1.3 revision is the current production target for most tools.
  • OpenSCENARIO 2.0 / DSL — a domain-specific language for abstract, parametric, and probabilistic scenarios. Newer, more expressive, with growing tooling support.

The two formats are not interchangeable, but 1.x is what most simulators and SOTIF / ISO 21448 testing pipelines consume today.

What goes into an OpenSCENARIO 1.x file

Section titled “What goes into an OpenSCENARIO 1.x file”

A 1.x scenario typically consists of:

  • A RoadNetwork reference — usually an OpenDRIVE .xodr file, optionally paired with a scene-graph file like .osgb.
  • An Entities block — the vehicles, pedestrians, and miscellaneous objects.
  • Storyboard — the time-ordered acts, maneuvers, and events the entities perform.
  • Init actions — starting positions, speeds, and parameter assignments.

The XML reads naturally for a single short scenario but becomes hard to maintain once you scale to dozens of variants. That’s where authoring tools and DSLs help.

Common authoring approaches

Section titled “Common authoring approaches”
  • Hand-written XML. Common for small teams and ground-truth fixtures.
  • DSL / codegen. OpenSCENARIO 2.0 DSL, Scenic, or in-house generators emit XML from higher-level descriptions.
  • Python libraries. scenariogeneration (formerly pyoscx / pyodrx) provides a programmatic API for OpenSCENARIO + OpenDRIVE, with coverage of OpenSCENARIO V1.0 through V1.3.1.
  • Simulator-bundled scenario engines. CARLA ScenarioRunner defines and executes scenarios for CARLA, with Python and OpenSCENARIO 1.0 / 2.0 support.
  • Visual editors. MathWorks RoadRunner (exports XML and DSL), Truevision Designer (OpenDRIVE-focused), Blender Driving Scenario Creator (Blender add-on), and drawtonomy (authors full OpenSCENARIO 1.x storyboards and runs them in-browser on esmini-WASM).

Production scenario authoring typically uses one or more of these — often a Python library or DSL for the scenarios themselves, alongside a visual editor for the road network.

Where drawtonomy fits

Section titled “Where drawtonomy fits”

drawtonomy is a browser-based OpenSCENARIO 1.x authoring and execution environment — a whiteboard where the scene you draw becomes a runnable storyboard. It imports OpenSCENARIO 1.x and exports OpenSCENARIO 1.0–1.2 (1.3 coming soon), alongside OpenDRIVE 1.8:

  • Drop lanes, intersections, vehicles, pedestrians, traffic lights, and road markings onto a 2D top-down canvas.
  • Build the storyboard visually — phases, events, 35 actions, and 19 trigger conditions — and run it in the browser on esmini compiled to WebAssembly, with a 3D preview (Chase / bird’s-eye / driver cameras) alongside the 2D canvas.
  • Import an existing .xosc + .xodr pair and edit it, or export the pair for a native esmini run.
  • Generate a scenario from a natural-language description: drawtonomy drafts a storyboard, checks it against four validation gates (including an actual esmini run), and applies it to the canvas.

The exporter now emits OpenDRIVE <junction> / <connection> / <laneLink> structures and <signal> entries — this is no longer a roadmap item. The accuracy split that matters: roads carried through unedited from an imported .xodr reach their original junction topology with high fidelity, but junctions synthesized from lanes you draw from scratch are not yet reliable. Still missing: parameter sweeps and custom or ML-driven controllers.

Scenario fleets — large parameterised batches — are still best generated from a DSL or a Python library; that stays out of scope for the visual editor. What drawtonomy adds is a fast visual path from an idea (or a natural-language prompt) to a runnable, reviewable scenario.

Section titled “Related reading”