Zum Inhalt springen
drawtonomy drawtonomy

Was ist OpenSCENARIO?

OpenSCENARIO ist ein offener ASAM-Standard zur Beschreibung dynamischer Fahrszenarien: was das Ego-Fahrzeug und andere Verkehrsteilnehmer im Zeitverlauf tun, in einer Form, die Simulatoren abspielen können. Es ist das De-facto-Austauschformat für das szenariobasierte Testen automatisierter Fahrsysteme.

Die zwei OpenSCENARIO-Familien

Abschnitt betitelt „Die zwei OpenSCENARIO-Familien“

Unter dem gemeinsamen Namen stehen zwei weitgehend unabhängige Spezifikationen:

  • OpenSCENARIO 1.x — XML-basiert, stabil und breit unterstützt. Revision 1.3 ist das aktuelle Produktionsziel der meisten Werkzeuge.
  • OpenSCENARIO 2.0 / DSL — eine domänenspezifische Sprache für abstrakte, parametrische und probabilistische Szenarien. Jünger, ausdrucksstärker, mit wachsender Tool-Unterstützung.

Die beiden Formate sind nicht ineinander überführbar, aber 1.x ist das, was die meisten Simulatoren und SOTIF-/ISO-21448-Testpipelines heute konsumieren.

Inhalt einer OpenSCENARIO-1.x-Datei

Abschnitt betitelt „Inhalt einer OpenSCENARIO-1.x-Datei“

Ein typisches 1.x-Szenario besteht aus:

  • einer RoadNetwork-Referenz — meist eine OpenDRIVE-Datei (.xodr), optional ergänzt um eine Szenengraph-Datei wie .osgb,
  • einem Entities-Block mit Fahrzeugen, Fußgängern und sonstigen Objekten,
  • dem Storyboard, den zeitlich geordneten Acts, Maneuvers und Events, die die Entitäten ausführen,
  • Init-Aktionen für Startpositionen, Geschwindigkeiten und Parameterzuweisungen.

Für ein einzelnes kurzes Szenario liest sich das XML noch gut, wird aber mühsam zu pflegen, sobald Dutzende Varianten hinzukommen. Genau hier setzen Authoring-Werkzeuge und DSLs an.

Gängige Authoring-Ansätze

Abschnitt betitelt „Gängige Authoring-Ansätze“
  • Handgeschriebenes XML. Verbreitet bei kleinen Teams und für Ground-Truth-Fixtures.
  • DSL / Codegenerierung. OpenSCENARIO 2.0 DSL, Scenic oder interne Generatoren erzeugen XML aus höherstufigen Beschreibungen.
  • Python-Bibliotheken. scenariogeneration (früher pyoscx / pyodrx) bietet eine programmatische API für OpenSCENARIO + OpenDRIVE mit Abdeckung von OpenSCENARIO V1.0 bis V1.3.1.
  • Szenario-Engines der Simulatoren selbst. CARLA ScenarioRunner definiert und führt Szenarien für CARLA aus, mit Python- und OpenSCENARIO-1.0/2.0-Unterstützung.
  • Visuelle Editoren. MathWorks RoadRunner (exportiert XML und DSL), Truevision Designer (OpenDRIVE-fokussiert), Blender Driving Scenario Creator (Blender-Add-on) und drawtonomy (erstellt vollständige OpenSCENARIO-1.x-Storyboards und führt sie direkt im Browser auf esmini-WASM aus).

Beim produktiven Szenario-Authoring kommen typischerweise mehrere dieser Ansätze zusammen zum Einsatz — oft eine Python-Bibliothek oder DSL für die Szenarien selbst, dazu ein visueller Editor für das Straßennetz.

Wo drawtonomy einzuordnen ist

Abschnitt betitelt „Wo drawtonomy einzuordnen ist“

drawtonomy ist eine browserbasierte Umgebung zum Erstellen und Ausführen von OpenSCENARIO-1.x-Szenarien — ein Whiteboard, auf dem die gezeichnete Szene zu einem lauffähigen Storyboard wird. Es importiert OpenSCENARIO 1.x und exportiert OpenSCENARIO 1.0–1.2 (1.3 folgt), zusammen mit OpenDRIVE 1.8:

  • Fahrspuren, Kreuzungen, Fahrzeuge, Fußgänger, Ampeln und Fahrbahnmarkierungen werden auf einem 2D-Canvas in Vogelperspektive platziert.
  • Das Storyboard entsteht visuell — Phases, Events, 35 Actions und 19 Trigger-Bedingungen — und läuft direkt im Browser auf esmini, kompiliert zu WebAssembly, mit einer 3D-Vorschau (Chase-, Vogelperspektiven- und Fahrerkamera) neben dem 2D-Canvas.
  • Ein bestehendes .xosc+.xodr-Paar lässt sich importieren und bearbeiten, oder für einen nativen esmini-Lauf wieder exportieren.
  • Ein Szenario lässt sich aus einer Freitext-Beschreibung generieren: drawtonomy entwirft ein Storyboard, prüft es gegen vier Validierungs-Gates (darunter ein echter esmini-Lauf) und wendet es auf den Canvas an.

Der Exporter erzeugt inzwischen OpenDRIVE-<junction>-/<connection>-/<laneLink>-Strukturen sowie <signal>-Einträge — das ist kein Roadmap-Punkt mehr. Wichtig ist der Genauigkeitsunterschied: Straßen, die unbearbeitet aus einer importierten .xodr-Datei übernommen werden, behalten ihre ursprüngliche Junction-Topologie mit hoher Treue; Junctions, die aus frei gezeichneten Fahrspuren neu synthetisiert werden, sind dagegen noch nicht zuverlässig. Weiterhin fehlend: Parameter-Sweeps sowie benutzerdefinierte oder KI-gesteuerte Controller.

Szenario-Flotten — große parametrisierte Batches — werden nach wie vor am besten aus einer DSL oder einer Python-Bibliothek generiert; das bleibt außerhalb des Scopes des visuellen Editors. Was drawtonomy beisteuert, ist ein schneller visueller Weg von einer Idee (oder einem Freitext-Prompt) zu einem lauffähigen, überprüfbaren Szenario.

Weiterführende Themen

Abschnitt betitelt „Weiterführende Themen“