drawtonomy vs XML OpenSCENARIO écrit à la main

XML OpenSCENARIO écrit à la main

Écrire le XML OpenSCENARIO à la main est un workflow courant, et pour beaucoup de cas d’usage, c’est le bon.

Quand le XML reste l’approche à privilégier :

• Le scénario est petit et vous voulez un contrôle au niveau de l’octet.
• Vous générez le XML programmatiquement, depuis un DSL ou un pipeline de génération de code.
• Vous avez besoin de fonctionnalités de la spécification que drawtonomy n’exporte pas encore — balayages de paramètres, contrôleurs personnalisés ou pilotés par IA, modèles de flux de trafic dense, OpenSCENARIO 1.3.
• Vous construisez un réseau routier neuf avec des jonctions depuis zéro et avez besoin d’une géométrie <junction> de qualité production — l’export de jonctions de drawtonomy est fidèle quand il reprend tel quel un .xodr importé, mais générer une géométrie de jonction inédite à partir de voies dessinées à la main reste peu précis.
• Vous travaillez à plusieurs sur un grand catalogue via git, où la stabilité des diffs XML au niveau de l’octet compte.

Dans ces cas-là, le XML écrit à la main ou généré par code reste l’approche canonique. Pour rédiger et exécuter un scénario concret unique — actions, déclencheurs, verdict PASS / FAIL — un éditeur visuel est généralement plus rapide.

Ce que drawtonomy sait exprimer aujourd’hui

Un éditeur visuel pour OpenSCENARIO 1.2 qui rédige un storyboard complet sur le canevas et l’exécute dans le navigateur — sans taper une seule ligne de XML :

• Un réseau routier 2D en vue de dessus — voies, intersections, linestrings — exporté en OpenDRIVE 1.8 .xodr, avec le placement des véhicules, piétons, feux tricolores et marquages au sol comme entités.
• Un storyboard complet : phases (actes), événements, les 35 actions de la spécification (vitesse, changement de voie, téléportation, suivi de trajectoire, activation de contrôleur, et plus), et les 19 conditions de déclenchement (plus 6 avancées) combinables en logique ET / OU.
• Des conditions de fin et d’échec qui produisent un verdict PASS / FAIL à l’exécution du scénario.
• Une exécution dans le navigateur sur esmini compilé en WebAssembly — contrôles de lecture, positionnement image par image, caméra de poursuite, traînées fantômes, et une prévisualisation 3D optionnelle — pour relire le scénario sans quitter la page. Le .xosc s’exécute aussi tel quel dans une installation esmini native.
• L’export vers OpenSCENARIO 1.0, 1.1 ou 1.2 (le 1.3 n’est pas encore disponible), ainsi que les primitives OpenDRIVE <junction>/<connection> et les panneaux de signalisation en entrées <signal>.

Ce que drawtonomy n’exprime pas encore

Les véritables lacunes qui justifient encore de passer par du XML écrit à la main ou généré :

• L’export OpenSCENARIO 1.3 — le format est pris en charge à l’import mais pas encore proposé comme cible d’export.
• Une géométrie OpenDRIVE <junction> de qualité production lors de la construction d’un réseau routier depuis zéro. La connectivité des jonctions se conserve fidèlement quand elle reprend un .xodr importé et non modifié ; générer une nouvelle géométrie de jonction à partir de voies dessinées à la main reste peu précis, et la géométrie analytique en clothoïdes n’est pas modélisée.
• Les balayages de paramètres, les contrôleurs personnalisés ou pilotés par IA, et les modèles de flux de trafic dense.
• OpenSCENARIO 2.0 / M-SDL (drawtonomy cible le 1.x).

Pour ces cas, écrire ou générer le XML reste la bonne approche.

Un hybride raisonnable

Pour la plupart des scénarios que vous rédigez et exécutez entièrement dans drawtonomy, le navigateur fait référence. Ne passez au XML écrit à la main qu’aux marges :

1. Rédigez la scène et le storyboard dans drawtonomy — réseau de voies, participants, actions, déclencheurs, conditions de fin / d’échec — puis exécutez-le pour confirmer le verdict.
2. Si vous avez besoin d’une fonctionnalité de la spécification que drawtonomy n’exporte pas (une primitive de jonction, un balayage de paramètres, un contrôleur personnalisé), exportez le .xosc et éditez ou générez cette partie à la main.
3. Quand vous voulez des diffs git au niveau de l’octet sur un grand catalogue, gardez le XML canonique dans le code et utilisez drawtonomy pour rédiger, relire et rejouer les scénarios concrets un par un.

drawtonomy est l’endroit où vous rédigez et exécutez le scénario ; le XML écrit à la main reste la solution de secours pour les coins de la spécification qu’il n’atteint pas encore.

Dans la même communauté OpenSCENARIO

Le XML écrit à la main est le chemin de rédaction fondamental pour OpenSCENARIO — tous les autres outils de l’écosystème finissent par le produire (ou son équivalent DSL). L’exporteur de drawtonomy, scenariogeneration, Scenic, RoadRunner, Blender DSC et les autres émettent tous le XML à un moment donné. Lire et écrire le XML directement, c’est ce qui permet au standard de rester un standard, et les outils qui le produisent bénéficient de l’interopérabilité que la communauté a construite autour de lui.

Pour aller plus loin

• Éditeur de scénario — rédigez actions, déclencheurs et conditions de fin / d’échec dans le navigateur.
• Créer votre premier scénario — un changement de voie à partir d’un canevas vide.
• Qu’est-ce qu’OpenSCENARIO ?
• Cas d’usage : éditeur OpenSCENARIO
• Exporter vers ASAM OpenDRIVE / OpenSCENARIO