Declarative Scenario-based Testing with RoadLogic

Die Arbeit stellt RoadLogic vor, ein Open-Source-System, das deklarative OpenSCENARIO-Spezifikationen mithilfe von Answer Set Programming, Bewegungsplanung und Überwachung in ausführbare, realistische Simulationen für das systematische Testen autonomer Fahrzeuge übersetzt.

Das Wesentliche

Hier ist eine einfache Erklärung des Papers „RoadLogic" auf Deutsch, verpackt in anschauliche Bilder und Alltagsbeispiele.

Das große Problem: Der „Wunschzettel" vs. die Realität

Stell dir vor, du bist ein Chefkoch, der ein neues Restaurant eröffnet. Du hast einen Wunschzettel (eine abstrakte Idee) für ein Gericht: „Ein Steak, das knusprig gebraten ist, innen aber rosa bleibt, serviert mit Kartoffeln, die nicht anbrennen."

Das ist dein OpenSCENARIO DSL (OS2)-Spektrum. Es beschreibt das Was (das Ziel), aber nicht das Wie.

Das Problem bei autonomen Fahrzeugen ist bisher so gewesen: Um zu testen, ob ein selbstfahrendes Auto sicher ist, mussten Ingenieure diesen Wunschzettel in eine extrem detaillierte Kochanleitung umwandeln. Sie mussten manuell festlegen: „Schalte den Herd auf Stufe 5, wende das Fleisch nach 3 Minuten, drehe den Ofen um..."
Das ist mühsam, teuer und führt dazu, dass man nur sehr wenige Varianten testet. Wenn das Auto dann doch mal die Kartoffeln anbrennen lässt, weil die Anleitung zu starr war, hast du ein Problem.

Bisher gab es keine kostenlose, offene Lösung, die diesen Wunschzettel automatisch in eine funktionierende Kochanleitung (eine Simulation) verwandelt.

Die Lösung: RoadLogic – Der „Übersetzer"

Die Forscher haben RoadLogic entwickelt. Man kann sich RoadLogic wie einen genialen Dolmetscher vorstellen, der zwischen zwei Welten vermittelt:

1. Die Welt der Idee (Declarative): Hier steht nur das Ziel: „Das rote Auto muss das blaue Auto überholen."
2. Die Welt der Physik (Concrete): Hier muss das Auto tatsächlich bremsen, lenken, beschleunigen und keine Wand berühren.

RoadLogic nimmt den Wunschzettel und baut daraus automatisch eine realistische Simulation.

Wie funktioniert das? (Die drei Schritte)

RoadLogic arbeitet in drei Phasen, ähnlich wie ein Regisseur, der einen Film plant:

1. Der Drehbuch-Entwurf (Symbolische Automaten)

Zuerst nimmt RoadLogic den abstrakten Text und wandelt ihn in eine Art Landkarte mit Wegpunkten um.

• Analogie: Stell dir vor, du planst eine Wanderung. Du sagst nicht: „Setze den linken Fuß 30 cm nach vorne, dann den rechten..." Du sagst: „Gehe zum See, dann zum Berggipfel, dann zurück."
• RoadLogic erstellt diese Landkarte mit Regeln: „Am Punkt A muss das Auto links vom anderen sein. Am Punkt B muss es rechts sein."

2. Der Logik-Koch (Answer Set Programming - ASP)

Jetzt kommt das Gehirn ins Spiel. RoadLogic nutzt eine spezielle Logik-Maschine (ASP), um herauszufinden, wie man diese Wegpunkte erreicht.

• Analogie: Der Logik-Koch denkt: „Okay, um zum See zu kommen, muss ich erst über die Brücke. Aber die Brücke ist eng. Also muss ich langsamer fahren. Und wenn ich langsamer fahre, komme ich später am Gipfel an."
• Er rechnet im Kopf durch, welche Schritte (manövrieren, beschleunigen, warten) nötig sind, um alle Regeln einzuhalten. Er erstellt einen rohen Plan: „Zuerst Spurwechsel, dann beschleunigen, dann Spurwechsel zurück."

3. Der Realitäts-Check (Motion Planning & Monitoring)

Der rohe Plan ist noch nicht perfekt. Jetzt wird er in eine echte Simulation übersetzt (mit dem FrenetiX-Planer). Das Auto fährt tatsächlich los.

• Der Sicherheits-Check: Während das Auto fährt, läuft ein Wachmann (ein Monitor) mit. Dieser Wachmann hält den ursprünglichen Wunschzettel in der Hand.
• Die Regel: „Wenn das rote Auto das blaue überholt hat, aber dabei in die Gegenfahrbahn gerutscht ist oder die Geschwindigkeitsgrenze verletzt hat -> Stopp! Das war kein gültiger Test."
• Nur wenn das Auto genau das tut, was auf dem Wunschzettel stand (und dabei sicher bleibt), wird der Test als „Bestanden" gewertet.

Warum ist das so wichtig?

Bisher mussten Ingenieure tausende von manuellen Tests schreiben, um sicherzustellen, dass ein autonomes Auto in verschiedenen Situationen (Überholen, Ausweichen, Folgen) funktioniert. Das ist wie das manuelle Ausprobieren von tausenden Kochrezepten.

Mit RoadLogic können sie jetzt einen Wunschzettel eingeben (z. B. „Überholmanöver") und das System generiert automatisch viele verschiedene, realistische Versionen davon:

• Mal überholt das Auto schnell.
• Mal fährt es langsam.
• Mal ist das Wetter schlecht (in der Simulation).

Das System prüft dabei automatisch, ob das Ergebnis dem ursprünglichen Wunsch entspricht.

Das Ergebnis

Die Forscher haben gezeigt, dass RoadLogic in wenigen Minuten realistische Simulationen erstellt, die genau das tun, was sie sollen. Es ist das erste kostenlose, offene Werkzeug, das diese Lücke zwischen der abstrakten Idee („Was soll passieren?") und der konkreten Realität („Wie fährt das Auto wirklich?") schließt.

Kurz gesagt: RoadLogic ist der Assistent, der aus einem einfachen Satz wie „Das Auto muss überholen" eine ganze Serie von sicheren, realistischen Fahrtests macht, ohne dass ein Mensch jedes Detail manuell programmieren muss. Das macht das Testen von selbstfahrenden Autos schneller, billiger und sicherer.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Declarative Scenario-based Testing with RoadLogic" auf Deutsch:

1. Problemstellung

Das Testen autonomer Fahrzeuge (AVs) ist komplex, teuer und gefährlich, wenn es ausschließlich in der realen Welt erfolgt. Daher ist simulationsbasiertes Testen essenziell. Ein zentraler Ansatz hierfür ist das szenariobasierte Testen.

• Herausforderung: Bestehende Ansätze nutzen oft imperativ definierte Szenarien (z. B. OpenSCENARIO XML), bei denen Entwickler viele Varianten manuell enumerieren müssen, um eine ausreichende Abdeckung zu erreichen.
• Lücke: Deklarative Sprachen wie OpenSCENARIO DSL (OS2) erhöhen die Abstraktionsebene, indem sie das „Was" (die Absicht) vom „Wie" (der Ausführung) trennen. OS2 erlaubt die Definition von parametrisierten, logischen Szenarien.
• Defizit: Bisher fehlte eine systematische, open-source Lösung, um diese abstrakten OS2-Spezifikationen automatisch in ausführbare, spezifikationskonforme Simulationen zu überführen. Ohne solche Tools bleibt die Lücke zwischen der hochleveligen Beschreibung und der konkreten Simulation unüberbrückt.

2. Methodik: RoadLogic Framework

RoadLogic ist ein Open-Source-Framework, das diese Lücke schließt. Es generiert automatisch realistische Simulationen aus OS2-Spezifikationen und stellt sicher, dass diese den abstrakten Anforderungen entsprechen. Der Prozess besteht aus fünf Hauptphasen:

1. Parsing und Symbolische Automaten:

   • Die OS2-Spezifikation wird in eine symbolische endliche Automaten (SFA)-Darstellung übersetzt.
   • Jeder Knoten im Automaten repräsentiert eine Manöverphase, und Übergänge sind mit Prädikaten (räumliche/zeitliche Constraints) annotiert.
   • Dies dient als Zwischenrepräsentation für die Planung und das Monitoring.

2. Encoding in Answer Set Programming (ASP):

   • Das SFA-Modell wird in ein ASP-Problem (Answer Set Programming) kodiert.
   • Diskretisierung: Raum und Zeit werden in ein Raster diskretisiert (Segment-Länge, Fahrspur-IDs, Zeitschritte).
   • Planung: Das ASP-System (basierend auf dem Solver clingo) berechnet einen hochleveligen diskreten Plan. Dieser Plan definiert eine Sequenz von Zuständen und Aktionen (z. B. Spurwechsel, Beschleunigung), die die Constraints des SFA erfüllen.
   • Inkrementelles Lösen: Durch Multi-Shot-Solving wird der Zeithorizont schrittweise erweitert, bis alle Ziele erreicht sind.

3. Konkretisierung durch Motion Planning:

   • Der diskrete Plan wird in eine physikalisch realistische Trajektorie umgewandelt.
   • Dafür wird der FrenetiX-Motion-Planner innerhalb der CommonRoad-Simulationsumgebung verwendet.
   • Da Standard-Planner oft nur ein einziges Ziel unterstützen, wurde RoadLogic erweitert, um Zwischenziele (Intermediate Goals) sequenziell zu verfolgen und den Referenzpfad dynamisch anzupassen.

4. Monitoring und Verifikation:

   • Während der Simulation wird die erzeugte Spur (Trace) in Echtzeit gegen das ursprüngliche symbolische Automaten-Modell überwacht.
   • Ein Runtime-Monitor (basierend auf algebraischer Laufzeitverifikation) prüft, ob die Simulation die abstrakten Constraints einhält.
   • Falls die Simulation nicht konform ist (z. B. Kollision, falsche Spurfolge), wird die Instanz verworfen und ein neuer Plan generiert.

3. Wichtige Beiträge

• RoadLogic Framework: Das erste Open-Source-Framework, das deklarative OS2-Spezifikationen automatisch in spezifikationskonforme Simulationen übersetzt.
• End-to-End-Pipeline: Eine integrierte Kette, die von der OS2-Eingabe über symbolische Planung (ASP), Motion Planning bis hin zur formalen Konformitätsprüfung reicht.
• Kombination von Techniken: Erfolgreiche Integration von Answer Set Programming für die logische Planung und symbolischen Automaten für das Monitoring mit modernen Motion-Plannern.
• Open Source: Verfügbarkeit des Codes, Parser und Experiment-Skripte, um die Reproduzierbarkeit zu gewährleisten.

4. Ergebnisse und Evaluation

Die Evaluation wurde an 7 verschiedenen OS2-Szenarien durchgeführt (z. B. Überholen, Spurwechsel, Hindernisvermeidung) unter Verwendung von zwei Strategien: einer Basis-Strategie und einer verfeinerten Strategie mit Parameter-Sampling.

• Effektivität (RQ1): RoadLogic konnte in allen getesteten Szenarien konforme Simulationen generieren. Die meisten Szenarien wurden innerhalb weniger Minuten vollständig durchlaufen (Planung, Ausführung, Monitoring).
  • Engpass: Die ASP-Planung kann bei komplexen Manövern (z. B. mehrere aufeinanderfolgende Spurwechsel) rechenintensiv werden.
  • Dominanz: In den meisten Fällen dominiert die Simulationsausführung die Gesamtzeit, nicht die Planung.
• Vielfalt (RQ2):
  • Die Basis-Strategie (nur ASP-Planung) erzeugte wenig diverse Szenarien, da der Solver oft tiefenorientiert (Depth-First) sucht und ähnliche Präfixe beibehält.
  • Die verfeinerte Strategie (Sampling von Eingabeparametern) erzeugte signifikant höhere Vielfalt (gemessen mittels Jaccard-Index auf Occupancy-Grids).
  • Trade-off: Höhere Vielfalt führt zu einer geringeren Erfolgsquote (Timeouts oder nicht konforme Szenarien bei komplexen Parametrisierungen) und längeren Berechnungszeiten.
• Erkennung von Unbekannten: Das Framework konnte Szenarien identifizieren, die formal die Spezifikation erfüllen, aber nicht der menschlichen Intention entsprechen (z. B. ein Überholmanöver, bei dem das überholte Fahrzeug ebenfalls die Spur wechselt). Dies zeigt das Potenzial für die Entdeckung von „Edge Cases" und Missverständnissen in der Spezifikation.

5. Bedeutung und Ausblick

RoadLogic adressiert ein kritisches Problem in der Validierung autonomer Fahrzeuge: die Automatisierung der Generierung von Testfällen aus hochabstrakten Spezifikationen.

• Systematisches Testen: Es ermöglicht die systematische Exploration des Szenarienraums, um kritische und seltene Situationen zu finden, ohne manuell jede Variante definieren zu müssen.
• Qualitätssicherung: Durch das integrierte Monitoring wird garantiert, dass nur Simulationen akzeptiert werden, die tatsächlich den ursprünglichen Absichten (Intent) entsprechen.
• Zukunft: Die Autoren planen, die Unterstützung für weitere OS2-Konstrukte (Events, nicht-autobahnähnliche Netze) zu erweitern, die Effizienz der ASP-Kodierung zu optimieren und das Framework auf andere Simulatoren (wie CARLA oder BeamNG) zu portieren.

Zusammenfassend stellt RoadLogic einen bedeutenden Schritt hin zu einer vollständig automatisierten, deklarativen Testpipeline für autonome Fahrzeuge dar, die die Lücke zwischen logischem Design und physikalischer Simulation schließt.