Skip to content

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.

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.

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.

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

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.
  • Import an existing .xosc + .xodr pair and edit it, or export the pair for a native esmini run.

Things the exporter still does not emit today (noted as roadmap items in the SDK):

  • OpenDRIVE junction primitives (<junction>).
  • Traffic signs as OpenDRIVE <signal> entries.
  • Parameter sweeps, custom or ML-driven controllers.

Scenario fleets are still best generated from a DSL or a Python library. What drawtonomy adds is a fast visual path from an idea to a runnable, reviewable scenario.