Pular para o conteúdo
drawtonomy drawtonomy

O que é OpenSCENARIO?

OpenSCENARIO é o padrão aberto da ASAM para descrever cenários dinâmicos de condução: o que o veículo ego e os demais participantes do tráfego fazem ao longo do tempo, em um formato que os simuladores conseguem reproduzir. É hoje o formato de intercâmbio de fato para testes baseados em cenários de sistemas de condução automatizada.

Duas famílias com o mesmo nome

Seção intitulada “Duas famílias com o mesmo nome”

Existem duas especificações praticamente independentes que compartilham o nome OpenSCENARIO:

  • OpenSCENARIO 1.x — baseado em XML, estável e amplamente suportado. A revisão 1.3 é hoje o alvo de produção da maioria das ferramentas.
  • OpenSCENARIO 2.0 / DSL — uma linguagem de domínio específico voltada a cenários abstratos, paramétricos e probabilísticos. Mais recente, mais expressiva, com suporte de ferramentas ainda em crescimento.

Os dois formatos não são intercambiáveis, mas é o 1.x que a maioria dos simuladores e dos pipelines de teste SOTIF / ISO 21448 consome hoje.

O que compõe um arquivo OpenSCENARIO 1.x

Seção intitulada “O que compõe um arquivo OpenSCENARIO 1.x”

Um cenário 1.x normalmente reúne:

  • Uma referência RoadNetwork — geralmente um arquivo OpenDRIVE .xodr, às vezes acompanhado de um arquivo de cena como .osgb.
  • Um bloco Entities — os veículos, pedestres e demais objetos da cena.
  • O Storyboard — os atos, manobras e eventos que as entidades executam ao longo do tempo.
  • As ações Init — posições e velocidades iniciais, além de atribuições de parâmetros.

O XML é legível para um cenário único e curto, mas fica difícil de manter assim que o projeto cresce para dezenas de variantes. É nesse ponto que ferramentas de autoria e DSLs entram em cena.

Abordagens comuns de autoria

Seção intitulada “Abordagens comuns de autoria”
  • XML escrito à mão. Comum em equipes pequenas e em fixtures de referência.
  • DSL / geração de código. O DSL do OpenSCENARIO 2.0, o Scenic ou geradores internos emitem XML a partir de descrições de mais alto nível.
  • Bibliotecas Python. O scenariogeneration (antigo pyoscx / pyodrx) oferece uma API programática para OpenSCENARIO + OpenDRIVE, cobrindo do OpenSCENARIO V1.0 ao V1.3.1.
  • Motores de cenário embutidos no simulador. O CARLA ScenarioRunner define e executa cenários para o CARLA, com suporte a Python e a OpenSCENARIO 1.0 / 2.0.
  • Editores visuais. O MathWorks RoadRunner (exporta XML e DSL), o Truevision Designer (focado em OpenDRIVE), o Blender Driving Scenario Creator (add-on do Blender) e o drawtonomy (que monta storyboards completos em OpenSCENARIO 1.x e os executa direto no navegador, sobre esmini-WASM).

Na prática, projetos de autoria de cenários em produção combinam mais de uma dessas abordagens — geralmente uma biblioteca Python ou um DSL para os cenários em si, junto de um editor visual para a rede viária.

Onde o drawtonomy se encaixa

Seção intitulada “Onde o drawtonomy se encaixa”

O drawtonomy é um ambiente de autoria e execução de OpenSCENARIO 1.x direto no navegador — um quadro branco onde a cena que você desenha vira um storyboard executável. Ele importa OpenSCENARIO 1.x e exporta OpenSCENARIO 1.0 a 1.2 (a exportação em 1.3 ainda está a caminho), além de OpenDRIVE 1.8:

  • Posicione faixas, cruzamentos, veículos, pedestres, semáforos e marcações viárias em uma tela 2D vista de cima.
  • Monte o storyboard visualmente — fases, eventos, 35 ações e 19 condições de gatilho — e rode tudo no navegador sobre esmini compilado para WebAssembly, com uma prévia 3D (câmeras de perseguição, vista aérea e do motorista) ao lado da tela 2D.
  • Importe um par .xosc + .xodr existente e edite-o, ou exporte o par para rodar nativamente no esmini.
  • Gere um cenário a partir de uma descrição em linguagem natural: o drawtonomy rascunha um storyboard, valida-o em quatro portões de verificação (incluindo uma execução real no esmini) e aplica o resultado direto na tela.

O exportador já emite as estruturas OpenDRIVE <junction> / <connection> / <laneLink>, além de entradas <signal> — isso deixou de ser item de roadmap. O que importa entender é a diferença de precisão: estradas que atravessam o pipeline sem edição, vindas de um .xodr importado, preservam sua topologia de cruzamento original com alta fidelidade, mas cruzamentos sintetizados a partir de faixas desenhadas do zero ainda não são confiáveis. O que continua faltando: varreduras de parâmetros e controladores personalizados ou guiados por ML.

Frotas de cenários — lotes grandes e parametrizados — continuam mais bem geradas por um DSL ou por uma biblioteca Python; isso segue fora do escopo do editor visual. O que o drawtonomy acrescenta é um caminho visual rápido, da ideia (ou de um prompt em linguagem natural) até um cenário executável e revisável.

Leitura relacionada

Seção intitulada “Leitura relacionada”