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 (browser whiteboard with a partial export).
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 whiteboard with a partial OpenSCENARIO 1.3 / OpenDRIVE 1.8 exporter. Per its exporter documentation:
- Drop lanes, intersections, vehicles, pedestrians, traffic lights, and road markings onto a 2D top-down canvas.
- Export a
.xosc+.xodr+run.shzip that plays back simple scenes in esmini.
The exporter covers a deliberate subset of the spec. Things it does not emit today (noted as roadmap items in the SDK):
- OpenDRIVE junction primitives (
<junction>). - Traffic signs as OpenDRIVE
<signal>entries. - Acceleration profiles, dwell / stop events, signal-aware paths, lane-change actions, or richer multi-actor storyboards.
- Conditional triggers, parameter sweeps, custom or ML-driven controllers.
In practice, treat drawtonomy’s OpenSCENARIO export as a sketch starting point — useful as a baseline you can hand-edit or for producing the figure that accompanies a scenario, not as a production scenario authoring path.