Qu'est-ce qu'OpenSCENARIO ?

OpenSCENARIO est un standard ouvert ASAM qui décrit les scénarios de conduite dynamiques : ce que fait le véhicule ego, et tous les autres usagers de la route, au fil du temps — sous une forme que les simulateurs savent rejouer. C’est aujourd’hui le format d’échange de référence pour les tests par scénarios des systèmes de conduite automatisée.

Deux familles OpenSCENARIO, largement indépendantes

Le nom recouvre en réalité deux spécifications distinctes :

• OpenSCENARIO 1.x — basé sur XML. Stable, largement adopté. La révision 1.3 est aujourd’hui la cible de production pour la plupart des outils.
• OpenSCENARIO 2.0 / DSL — un langage dédié pour des scénarios abstraits, paramétriques et probabilistes. Plus récent, plus expressif, avec un outillage encore en construction.

Les deux ne sont pas interchangeables, mais c’est le 1.x que consomment aujourd’hui la plupart des simulateurs et des chaînes de test SOTIF / ISO 21448.

Ce que contient un fichier OpenSCENARIO 1.x

Un scénario 1.x se compose typiquement de :

• Une référence RoadNetwork — en général un fichier OpenDRIVE .xodr, parfois accompagné d’un fichier de scène 3D type .osgb.
• Un bloc Entities — véhicules, piétons et objets divers.
• Un Storyboard — les actes, manœuvres et événements que les entités exécutent, ordonnés dans le temps.
• Des actions Init — positions de départ, vitesses et affectations de paramètres.

Le XML reste lisible pour un scénario court et isolé, mais devient vite pénible à maintenir dès que l’on gère des dizaines de variantes. C’est précisément là que les outils d’édition et les DSL prennent leur valeur.

Les approches de rédaction courantes

• XML écrit à la main. Courant dans les petites équipes, ou pour produire des fixtures de vérité terrain.
• DSL / génération de code. OpenSCENARIO 2.0 DSL, Scenic, ou des générateurs internes qui produisent du XML à partir de descriptions de plus haut niveau.
• Bibliothèques Python. scenariogeneration (anciennement pyoscx / pyodrx) offre une API programmatique pour OpenSCENARIO + OpenDRIVE, avec une couverture de la V1.0 à la V1.3.1.
• Moteurs de scénarios intégrés aux simulateurs. CARLA ScenarioRunner définit et exécute des scénarios pour CARLA, avec un support Python et OpenSCENARIO 1.0 / 2.0.
• Éditeurs visuels. MathWorks RoadRunner (export XML et DSL), Truevision Designer (centré OpenDRIVE), Blender Driving Scenario Creator (extension Blender), et drawtonomy (rédige des storyboards OpenSCENARIO 1.x complets et les exécute directement dans le navigateur sur esmini-WASM).

En production, la rédaction de scénarios combine généralement plusieurs de ces briques — souvent une bibliothèque Python ou un DSL pour les scénarios eux-mêmes, avec un éditeur visuel pour le réseau routier.

La place de drawtonomy

drawtonomy est un environnement de rédaction et d’exécution OpenSCENARIO 1.x dans le navigateur : un whiteboard où la scène que vous dessinez devient un storyboard exécutable. Il importe OpenSCENARIO 1.x et exporte OpenSCENARIO 1.0–1.2 (le 1.3 arrive bientôt), ainsi qu’OpenDRIVE 1.8 :

• Posez voies, intersections, véhicules, piétons, feux tricolores et marquages au sol sur un canevas 2D en vue de dessus.
• Construisez le storyboard visuellement — phases, événements, 35 actions et 19 conditions de déclenchement — et exécutez-le dans le navigateur avec esmini compilé en WebAssembly, avec une prévisualisation 3D (caméras poursuite / vue aérienne / conducteur) en plus du canevas 2D.
• Importez une paire .xosc + .xodr existante et éditez-la, ou exportez la paire pour une exécution esmini native.
• Générez un scénario à partir d’une description en langage naturel : drawtonomy rédige un storyboard, le vérifie via quatre portes de validation (dont une exécution esmini réelle), puis l’applique au canevas.

L’exporteur produit désormais les structures OpenDRIVE <junction> / <connection> / <laneLink>, ainsi que les entrées <signal> — ce n’est plus un simple élément de feuille de route. La nuance qui compte sur la fidélité : les routes reprises telles quelles depuis un .xodr importé conservent leur topologie de jonction d’origine avec une grande fidélité, mais les jonctions synthétisées à partir de voies dessinées à la main ne sont pas encore fiables. Manquent encore : les balayages de paramètres et les contrôleurs personnalisés ou pilotés par IA.

Les flottes de scénarios — de gros lots paramétrés — restent mieux générées par un DSL ou une bibliothèque Python ; cela sort du périmètre de l’éditeur visuel. Ce qu’apporte drawtonomy, c’est un chemin visuel rapide entre une idée (ou une invite en langage naturel) et un scénario exécutable et relisable.

Pour aller plus loin

• Éditeur de scénario — rédigez phases, événements, actions et déclencheurs dans le navigateur, puis exécutez-les.
• Créer votre premier scénario — un changement de voie à partir d’un canevas vide.
• Table de correspondance RoadRunner / OpenSCENARIO — une table de correspondance entre les deux vocabulaires.
• Qu’est-ce qu’OpenDRIVE ?
• Qu’est-ce qu’esmini ?
• Comparatif : drawtonomy vs XML OpenSCENARIO écrit à la main