Zum Inhalt springen
drawtonomy drawtonomy

Fahrszenario-Klassifikation — funktional, logisch, konkret

Das szenariobasierte Testen von Fahrerassistenzsystemen (ADAS) und automatisierten Fahrsystemen (AD) stützt sich auf eine dreistufige Abstraktion, die aus dem PEGASUS-Forschungsprojekt stammt und heute Standardpraxis in ADAS/AV-Testpipelines ist:

  1. Funktionales Szenario — qualitativ, in natürlicher Sprache.
  2. Logisches Szenario — parametrisch, mit Wertebereichen für jeden Parameter.
  3. Konkretes Szenario — vollständig instanziiert, jeder Parameter auf einen Wert festgelegt.

Diese Seite ist eine neutrale Einführung in die jeweiligen Ebenen, ihren Bezug zum ODD und zu Formaten wie OpenSCENARIO, sowie die Rolle von drawtonomy.

Die drei Abstraktionsebenen

Abschnitt betitelt „Die drei Abstraktionsebenen“

Funktionales Szenario

Abschnitt betitelt „Funktionales Szenario“

Ein funktionales Szenario ist eine qualitative, natürlichsprachliche Beschreibung einer Fahrsituation. Es benennt Akteure, Straßenlayout und Manöver, legt sich aber auf keine Zahlenwerte fest.

Beispiel: „Auf einer zweispurigen Autobahn überholt ein schnelleres Fahrzeug auf der linken Spur das Ego-Fahrzeug und schert von rechts auf dessen Spur ein.”

Funktionale Szenarien finden sich in Testplänen, Design-Review-Dokumenten, Folien, Paper-Abbildungen und Sicherheitsfalldokumenten. Sie sind die Art und Weise, wie Menschen ein Szenario kommunizieren.

Logisches Szenario

Abschnitt betitelt „Logisches Szenario“

Ein logisches Szenario überführt die funktionale Beschreibung in eine strukturierte Form mit Parameterwertebereichen. Jede Variable (Ausgangsgeschwindigkeiten, Abstände, TTC, Querversatz, Wetter, Straßenkrümmung) erhält einen Bereich statt eines Einzelwerts.

Beispiel: „Ego-Geschwindigkeit ∈ [70, 130] km/h, Relativgeschwindigkeit des einscherenden Fahrzeugs ∈ [+10, +30] km/h, Kollisionszeit beim Einscherbeginn ∈ [1,5; 4,0] s, …”

Logische Szenarien werden bei Testkampagnen abgetastet, variiert oder durchsucht. Werkzeuge und DSLs für diese Ebene sind u. a. Scenic, scenariogeneration (pyoscx / pyodrx) und OpenSCENARIO 2.0 / DSL.

Konkretes Szenario

Abschnitt betitelt „Konkretes Szenario“

Ein konkretes Szenario ist eine spezifische Instanz — jeder Parameter auf einen Einzelwert festgelegt. Dies ist das, was in einem Simulator oder auf einem Testgelände ausgeführt wird.

Beispiel: „Ego bei 90 km/h, einscherendes Fahrzeug bei +20 km/h relativ, TTC = 2,5 s beim Einscherbeginn, trockener Asphalt, …”

Konkrete Szenarien sind die Ebene, auf der OpenSCENARIO 1.x XML, esmini-Wiedergabe und die meisten Replay-Werkzeuge operieren.

Bezug der Ebenen zum ODD

Abschnitt betitelt „Bezug der Ebenen zum ODD“

Der Operational Design Domain (ODD) ist die Menge der Bedingungen, unter denen eine Fahrfunktion bestimmungsgemäß betrieben werden soll (Straßentypen, Wetter, Tageszeit, geografische Region usw.). Szenario-Klassifikation und ODD interagieren auf jeder Ebene:

  • Funktionale Szenarien werden innerhalb des ODD geschrieben („Autobahnfahrt bei Sonnenschein”).
  • Logische Szenarien begrenzen Parameterwertebereiche so, dass sie den ODD respektieren (z. B. Geschwindigkeitsbereiche, die zur Autobahn-only-Bedingung des ODD passen).
  • Konkrete Szenarien sind Instanzen, die innerhalb des ODD liegen, plus bewusst gewählte Grenzfälle, die dessen Rand austesten.

Szenario-Klassifikation in Normen und Projekten

Abschnitt betitelt „Szenario-Klassifikation in Normen und Projekten“
  • PEGASUS — das deutsche Forschungsprojekt, das die hier verwendete Terminologie „funktional / logisch / konkret” geprägt hat.
  • ISO 21448 (SOTIF) — Safety of the Intended Functionality; nutzt die Szenario-Klassifikation als Rückgrat des Nachweises, dass die Funktion korrekt über den gesamten ODD hinweg arbeitet.
  • ASAM OpenSCENARIO — 1.x zielt auf konkrete Szenarien ab; 2.0 / DSL auf logische Szenarien.
  • ASAM OpenDRIVE — liefert die statische Weltschicht, auf die alle drei Szenarioebenen verweisen.

Rolle von drawtonomy

Abschnitt betitelt „Rolle von drawtonomy“

drawtonomy ist kein logischer Szenario-Sampler oder konkreter Szenario-Executor. Es ist ein Browser-Whiteboard für Fahrszenarien. Die eingeschränkten Bereiche, in denen es in der Klassifikation angesiedelt ist:

  • Abbildungen funktionaler Szenarien. Die Diagramme, die in Testpläne, Design-Reviews, Sicherheitsfalldokumente, Folien und Paper-Abbildungen einfließen, sind funktionale Szenarien in visueller Form. drawtonomy ist dafür geeignet.
  • Illustration logischer Szenarien. Die „Form” eines logischen Szenarios (Geometrie, Akteure, grobe Bewegung) ist das, was Leser erfassen müssen, bevor die Parametertabelle Sinn ergibt. drawtonomy eignet sich für die Abbildung; die Parametertabelle selbst gehört in Ihre DSL oder Tabellenkalkulation.
  • Konkrete Szenario-Skizze vor dem Authoring. Wenn Sie im Begriff sind, ein spezifisches OpenSCENARIO-1.x-XML von Hand zu schreiben, kann drawtonomy eine 2D-Skizze und eine Basis-.xosc-Datei erzeugen, von der aus Sie iterieren. Siehe Anwendungsfall: Skizzieren vor OpenSCENARIO-Authoring.

Für das eigentliche logische / konkrete Szenario-Authoring im großen Maßstab — Parametervariationen, konditionelle Trigger, komplexe Storyboards — verwenden Sie Scenic, scenariogeneration, handgeschriebenes OpenSCENARIO XML oder OpenSCENARIO 2.0 / DSL. drawtonomy ist für das Bild, nicht für die Testlogik.

Im selben Szenario-Test-Ökosystem

Abschnitt betitelt „Im selben Szenario-Test-Ökosystem“

Weiterführende Informationen

Abschnitt betitelt „Weiterführende Informationen“