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
.xodrfile, 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.
- Import an existing
.xosc+.xodrpair 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.
Related reading
Section titled “Related reading”- Scenario editor — author phases, events, actions, and triggers in the browser, then run them.
- Build your first scenario — a lane change from an empty canvas.
- RoadRunner and OpenSCENARIO terms — a translation table between the two vocabularies.
- What is OpenDRIVE?
- What is esmini?
- Compare: drawtonomy vs hand-written OpenSCENARIO XML