drawtonomy vs. handgeschriebenes OpenSCENARIO XML

Handgeschriebenes OpenSCENARIO XML

Das Handschreiben von OpenSCENARIO-XML ist ein gängiger Workflow und für viele Anwendungsfälle der richtige Ansatz.

Wann XML der geeignete Weg ist:

Das Szenario ist klein, und Byte-genaue Kontrolle ist gewünscht.
XML wird programmatisch aus einer DSL oder einer Codegen-Pipeline erzeugt.
Spezifikationsmerkmale werden benötigt, die drawtonomy nicht erzeugt — Parametervariationen, benutzerdefinierte oder KI-gesteuerte Controller, dichte Verkehrsfluss-Modelle, OpenSCENARIO 1.3.
Ein neues Straßennetz mit Kreuzungen entsteht von Grund auf, und produktionsreife <junction>-Geometrie wird benötigt — der Junction-Export von drawtonomy ist präzise, wenn eine importierte, unveränderte .xodr-Datei durchgereicht wird; das Erzeugen neuer Junction-Geometrie aus handgezeichneten Fahrspuren ist dagegen noch wenig präzise.
An einem großen Katalog wird über Git zusammengearbeitet, und stabile Byte-genaue XML-Diffs sind wichtig.

Für diese Fälle ist handgeschriebenes oder codegeneriertes XML der kanonische Ansatz. Für das Erstellen und Ausführen eines einzelnen konkreten Szenarios — Aktionen, Trigger und ein PASS-/FAIL-Urteil — ist ein visueller Editor meist schneller.

Was drawtonomy heute ausdrücken kann

Ein visueller Editor für OpenSCENARIO 1.2, der das gesamte Storyboard auf der Zeichenfläche erstellt und direkt im Browser ausführt — ganz ohne XML zu tippen:

Ein 2D-Straßennetz von oben — Fahrspuren, Kreuzungen, Linestrings — exportiert als OpenDRIVE-1.8-.xodr, dazu die Platzierung von Fahrzeugen, Fußgängern, Ampeln und Fahrbahnmarkierungen als Entitäten.
Ein vollständiges Storyboard: Phasen (Acts), Ereignisse, alle 35 Aktionen der Spezifikation (Geschwindigkeit, Spurwechsel, Teleport, Trajektorienverfolgung, Controller-Aktivierung und mehr) sowie alle 19 Trigger-Bedingungen (plus 6 erweiterte) kombinierbar mit UND-/ODER-Logik.
END- und FAIL-Bedingungen, die beim Ausführen des Szenarios ein PASS-/FAIL-Urteil liefern.
Ausführung im Browser auf esmini, kompiliert zu WebAssembly — mit Transportsteuerung, framegenauem Sprung, Verfolgungskamera, Ghost-Trails und einer optionalen 3D-Vorschau des Durchlaufs —, sodass sich das laufende Szenario überprüfen lässt, ohne die Seite zu verlassen. Die .xosc-Datei läuft unverändert auch in einer nativen esmini-Installation.
Export nach OpenSCENARIO 1.0, 1.1 oder 1.2 (1.3 steht noch nicht zur Verfügung), zusätzlich OpenDRIVE-<junction>-/<connection>-Primitive und Verkehrszeichen als <signal>-Einträge.

Was drawtonomy nicht ausdrückt

Die tatsächlichen Lücken, die weiterhin handgeschriebenes oder generiertes XML erfordern:

OpenSCENARIO-1.3-Export — das Format wird beim Import unterstützt, steht aber noch nicht als Exportziel zur Verfügung.
Produktionsreife OpenDRIVE-<junction>-Geometrie beim Aufbau eines Straßennetzes von Grund auf. Die Junction-Konnektivität wird beim Durchreichen einer importierten, unveränderten .xodr-Datei präzise erhalten; das Erzeugen neuer Junction-Geometrie aus handgezeichneten Fahrspuren ist noch wenig präzise, und analytische Klothoiden-Geometrie wird nicht modelliert.
Parametervariationen, benutzerdefinierte oder KI-gesteuerte Controller sowie dichte Verkehrsfluss-Modelle.
OpenSCENARIO 2.0 / M-SDL (drawtonomy zielt auf die 1.x-Reihe).

Für diese Fälle bleibt handgeschriebenes oder generiertes XML der richtige Weg.

Eine sinnvolle Kombination

Für die meisten Szenarien, die vollständig in drawtonomy erstellt und ausgeführt werden, ist der Browser die Quelle der Wahrheit. Handgeschriebenes XML kommt nur an den Rändern zum Einsatz:

Die Szene und das Storyboard in drawtonomy erstellen — Fahrspur-Netz, Verkehrsteilnehmer, Aktionen, Trigger, End-/Fail-Bedingungen — und ausführen, um das Urteil zu bestätigen.
Wird ein Spezifikationsmerkmal benötigt, das drawtonomy nicht erzeugt (ein Junction-Primitiv, eine Parametervariation, ein benutzerdefinierter Controller), die .xosc-Datei exportieren und diesen einen Teil von Hand bearbeiten oder codegenerieren.
Für Byte-genaue Git-Diffs über einen großen Katalog hinweg bleibt das kanonische XML im Code, während drawtonomy zum Erstellen, Überprüfen und Abspielen einzelner konkreter Szenarien dient.

drawtonomy ist der Ort, an dem das Szenario erstellt und ausgeführt wird; handgeschriebenes XML bleibt das Ausweichventil für Spezifikationsecken, die drawtonomy noch nicht erreicht.

In derselben OpenSCENARIO-Community

Handgeschriebenes XML ist der grundlegende Authoring-Weg für OpenSCENARIO — jedes andere Werkzeug im Ökosystem erzeugt es letztlich (oder sein DSL-Äquivalent). Der Exporter von drawtonomy, scenariogeneration, Scenic, RoadRunner, Blender DSC und die übrigen Werkzeuge geben irgendwann alle das XML aus. Das direkte Lesen und Schreiben des XML hält den Standard zu einem Standard, und Werkzeuge, die es erzeugen, profitieren von der werkzeugübergreifenden Interoperabilität, die die Community darum herum aufgebaut hat.

Weiterführende Informationen

Szenario-Editor — Aktionen, Trigger und End-/Fail-Bedingungen im Browser erstellen.
Erstes Szenario erstellen — ein Spurwechsel von der leeren Zeichenfläche aus.
Was ist OpenSCENARIO?
Anwendungsfall OpenSCENARIO-Editor
Nach ASAM OpenDRIVE / OpenSCENARIO exportieren