-
Die Erfindung betrifft ein Verfahren zum Validieren und der sicheren Applikation von autonomen und teilautonomen Fahrzeugen, bei dem das Entscheidungsmodul (Decision) des Fahrzeugs vor jeder Aktion die Erlaubnis zur Durchführung von einem Sicherheitsmodul einholen muss. Dabei stützt sich das Sicherheitsmodul auf ein Validierungsraum-Modell (Validation space), um Aussagen über die geplante Aktion treffen und dem Entscheidungsmodul alternative Aktionsvorschläge bereitstellen zu können. Erfindungsgemäß wird der Validierungsraum durch Simulationen und reale Fahrten nach und nach vervollständigt, sodass dem Fahrzeug am Anfang wenige sicher ausführbare Manöver zur Verfügung stehen, diese jedoch proportional mit der Zunahme der validierten Bereiche im Validierungsraum zunehmen, wodurch verschiedene Stufen der Autonomie, mit und ohne menschlichem Fahrer in der Funktion des Überwachers, ermöglicht werden. Das Verfahren schließt des Weiteren zwei Teilverfahren ein, die die effiziente Vervollständigung des Validierungsraumes in der Simulation ermöglichen, ohne die das Hauptverfahren aus Effizienzgründen nur mit enormem Aufwand umsetzbar ist.
-
In der
DE 10 2015 200 025 A1 ist beispielsweise ein Fahrerassistenz-System und ein Verfahren zum assistierten Führen eines Fahrzeugs beschrieben. Aus der
DE 2015 224 338 A1 ist ein Verfahren zum automatischen Fahren eines Kraftfahrzeugs bekannt, welches die folgenden Schritte umfasst: Bereitstellen von Umfelddaten, Erkennen von Objekten in den Umfelddaten, Auswählen eines aktuellen Szenarios durch eine Szenario-Interpretationseinrichtung auf Grundlage der erkannten Objekte, wobei ein Szenario mindestens eine elementare Situation aufweist, der als Attribute zumindest ein Überwachungsbereich und ein Freigabekriterium zugeordnet sind. Die
DE 10 2012 008 978 A1 offenbart ein Verfahren zur Durchführung wenigstens eines Berechnungsprozesses in einem Kraftfahrzeug, bei dem Auswertungen von während des Betriebs des Kraftfahrzeugs aufgenommenen Messdaten durchgeführt werden.
-
Es ist bekannt, Fahrassistenzsysteme (ADAS: Advanced Driver Assistance Systems) zu testen und zu validieren.
-
So beschreibt beispielsweise die
DE 10 2015 001 971 A1 ein Verfahren und eine Vorrichtung zur Überwachung eines Fahrerassistenzsystems, welche das sichere Betreiben unterschiedlicher Fahrerassistenzsysteme gewährleisten, insbesondere in Situationen, in denen durch die Fahrerassistenzsysteme Funktionen nicht definiert sind, Funktionen zu Unfällen, also zu Schäden am Fahrzeug oder an beteiligten Personen führen oder Funktionen aufgrund fehlerhafter Komponenten nicht ausführbar sind.
-
Hierbei ist besonders erwähnenswert, dass bei solchen Verfahren nicht garantiert werden muss, dass das Assistenzsystem immer und in jeder Situation richtig und wie erwartet funktioniert. Fahrzeughersteller oder Zulieferer können sich darauf berufen, dass der menschliche Fahrer jederzeit dazu in der Lage sein muss, im Falle eines Fehlverhaltens eingreifen zu können. Des Weiteren betreffen die meisten Fahrassistenzsysteme nur Teilbereiche der Fahrfunktion. So werden beispielsweise Spurhalte-Assistenten, Notbrems-Assistenten oder Abstandsregelungs-Tempomate angeboten. Solche Teilfunktionen, die nur auf einer geringen Menge zu verarbeitender Sensordaten basieren, sind mit hinreichend viel Aufwand zu validieren. Nach den SAE Stufen der Automatisierung können die aktuellsten und fortgeschrittensten ADAS auf Stufe 2 (Partial Automation) eingeordnet werden. Diese Stufe ist dadurch gekennzeichnet, dass der Mensch immer noch Teil der Fahrfunktion ist und eine überwachende Rolle einnehmen muss. Demgegenüber steht der Trend hin zum autonomen Fahren (Stufe 5). Dabei stellt sich die Frage, wie von Stufe 2 der Automatisierung zur Stufe 5 der Automatisierung gelangt werden kann. Hauptproblem dabei stellt das Konzept der Eingriffsanfrage (Request to Intervene) dar. Das autonome Fahrzeug soll ab Stufe 3 in der Lage sein, ohne die Überwachung des Fahrers, die Fahrfunktion ausfüllen zu können. Demnach muss der Fahrer frühzeitig dazu aufgefordert werden, die Kontrolle zu übernehmen, sollte sich das Fahrzeug einer Situation nähern, mit der es nicht zurechtkommt. Die Herausforderung hierbei ist der notwendige Übergabezeitraum, der gewährleistet werden muss, da nicht angenommen werden kann, dass der Fahrer jederzeit eingriffsbereit ist. Dieser schläft unter Umständen und muss zuerst geweckt werden und anschließend in der Lage sein, die Situation zu beurteilen um eingreifen zu können. Während dieser Zeit muss das Fahrzeug in der Lage sein sicher zu handeln. Technisch ist also die frühzeitige Vorhersage der nicht mehr beherrschbaren Situation ausschlaggebend, was bisher ein nicht gelöstes Problem darstellt.
-
Des Weiteren wird versucht, die Validierungstechniken von ADAS Fahrzeugen auf das autonome Fahren zu übertragen. Da die Validierung aus Kosten- und Zeitgründen und der nur aufwändigen Planbarkeit und Wiederholbarkeit nicht im realen Straßenverkehr oder auf Testgeländen durchführbar ist, wird in der Literatur vorgeschlagen, das autonome Fahrzeug in einer virtuellen Umgebung zu testen (SIL = Software In the Loop). Durch die Simulation können die oben genannten Problemfelder der Realtests vermieden oder minimiert werden. Zum Testen autonomer Fahrzeuge in der Simulation stellt sich, wie üblich im Bereich des Software Testens, die Frage, wie Test-Fälle (Test-Cases) entworfen werden sollen, um eine möglichst hohe Testabdeckung bei geringst möglichem Aufwand (maximaler Effizienz) zu erreichen. Diese Frage kann mit unterschiedlichen Ansätzen beantwortet werden, die alle gemeinsam haben, dass SIL-Testen gleichbedeutend mit Szenario testen ist. Dabei wird eine bestimmte Verkehrssituation erzeugt, die das autonome Fahrzeug in einer bestimmten Zeitspanne, dem Szenario meistern muss. Das Szenario ist notwendig, da das Fahrverhalten des zu testenden Fahrzeugs nur evaluiert werden kann, wenn der Test eine bestimmte Zeit dauert. Demnach kann eine Fehlentscheidung des autonomen Fahrzeugs zum Zeitpunkt t=Os des Szenarios zu einem Unfall zum Zeitpunkt t= 10s führen. Szenario-Testen imitiert Realfahrten, was eine sehr natürliche, wenn auch nicht optimale Herangehensweise zur Lösung des Problems darstellt. Durch Szenario-Testen wird ein wichtiger Vorteil, den SIL-Tests bieten vernachlässigt: In der Simulation können Methoden angewandt werden, die der Effizienz dienen, aber bei Realfahrten nicht möglich sind. Teil dieser Erfindung wird deshalb die Ausnutzung dieser Möglichkeiten sein, die das virtuelle Testen ermöglicht.
-
Ein weiteres Problem stellt die typische und vorherrschende Herangehensweise zum Testen von Software dar. Einfache Systeme werden erst dann freigegeben (released), wenn alle wichtigen Kriterien der Spezifikation erfüllt sind. Hierzu werden zuerst alle Testfälle getestet, die zur Absicherung ausgewählt wurden. Zeigt das System dabei kein unerwartetes Verhalten, kann die Software freigegeben (released) werden. Dieses Konzept der Validierung bedeutet für das autonome Fahrzeug als Testsubjekt, dass eine sehr große Menge von Test-Szenarien notwendig ist, um das System zu testen, da ein autonomes Fahrzeug eine sehr große Menge an kontinuierlichen, zeitabhängigen Eingabeparametern (Sensordaten und sonstige Informationen) verarbeiten muss. Nur durch das Testen aller Kombinationen von Eingabeparameter-Werten, kann sichergestellt werden, dass sich das Fahrzeug in jeder erdenklichen Situation richtig verhält. Es wird deshalb ein Verfahren vorgestellt, das nicht darauf beruht alle möglichen Fälle vor der Freigabe (Release) zu testen, sondern dies nach und nach geschieht, während das System beim Kunden im Einsatz ist. Hierzu wird der Validierungsraum eingeführt, der nicht nur das oben genannte Problem der Vorhersage der nicht mehr beherrschbaren Situation, sondern auch das Validierungsproblem löst, in dem das autonome Fahrzeug nur solche Manöver ausführen darf, die so oder so ähnlich schon getestet wurden.
-
Um autonome Fahrzeuge virtuell zu testen, wird ein Netzwerk aus Zustandsgittern (Spatiotemporal State Lattices) im Frenet Frame verwendet. Eine zweidimensionale Abbildung eines solchen Gitters ist in zu sehen, wobei erkennbar ist, dass es sich ausgehend von einem Knoten in dem Netzwerk um einen gerichteten Graphen (Directed Graph) handelt. Die Knoten (Nodes) in dem Netzwerk stellen Position-Zeit-Tupel dar, wohingegen die Kanten (Edges) das Zustandsgitter, also mögliche Trajektorien/Bewegungen verkörpern. Solche Zustandsgitter wurden bereits zur Bewegungsplanung von einzelnen, autonomen Fahrzeugen vorgeschlagen.
-
Abweichend davon werden die Zustandsgitter in dem vorliegenden Verfahren zur Bahnplanung von dynamischen Objekten (andere Verkehrsteilnehmer als Teil des Szenarios) in statischen Szenarien (Static Scenarios) verwendet. Abhängig von der Auflösung des Netzwerks kann somit eine beliebige Anzahl von Szenarien generiert werden.
-
Das Zustandsgitter wird ausdrücklich im Frenet Koordinatensystem der Straße berechnet. Dementsprechend wird das Netzwerk, basierend auf hochauflösenden Karten, überall dort erstellt, wo das autonome Fahrzeug eingesetzt werden soll (z.B. Straßen, aber auch Parkplätze und private Einfahrten oder Feldwege). Für Bereiche, zu denen bei dem Ausliefern des Fahrzeugs noch kein hochauflösendes Kartenmaterial vorhanden ist, muss das Fahrzeug die Bereiche entweder in einem langsamen, autonomen und beaufsichtigten Erkundungsmodus (Exploration Mode) erstellen oder ein Mensch muss das Fahrzeug manuell in diesen Bereichen zur Erkundung bewegen (Manual Mode). Sobald die Karten vorhanden sind, kann das Zustandsnetzwerk in diesen Bereichen erstellt werden.
-
Um das Netzwerk zur Bildung von Trajektorien der das autonome Fahrzeug umgebenden Fahrzeuge zu erstellen, können verschiedene Kanten des Netzwerks die stetig ineinander übergehen miteinander kombiniert und zusammengeschlossen werden.
-
Um das Simulieren effizienter zu gestalten wird die neue Methode des Zustandsspeicherns (State Saving) angewandt. Nutzt man das oben genannte Zustandsgitter ohne diese Methode um Szenarien zu erstellen, wird viel mehr Zeit benötigt, um alle möglichen Kombinationen von Kanten zu testen, was an folgendem Beispiel verdeutlicht wird: Wenn z.B. ein Szenario insgesamt t=10s dauern und die Bewegung der umgebenden Fahrzeuge in der letzten Sekunde (t=9s) verändert werden soll, dann müssten die ersten 9 Sekunden für jede mögliche Bewegungskombination der umgebenden Fahrzeuge für die letzte Sekunde erneut simuliert werden. Dieser Aufwand kann dadurch verringert werden, dass zum Zeitpunkt t=9s der komplette Zustand des zu testenden, autonomen Fahrzeuges gespeichert wird. Dazu wird der Zustand des zu testenden, autonomen Fahrzeuges (Ego Vehicle State) im Kontext der Zustandsspeicherungsmethode wie folgt definiert: „Der Zustand des autonomen Fahrzeugs wird durch interne und externe Charakteristiken des zu testenden Fahrzeugs (Ego-Vehicle) beschrieben. Als externe Charakteristiken kann der regelungstechnische Zustand, welcher durch Position, Orientierung und Geschwindigkeit/Beschleunigung, etc. beschrieben wird, angesehen werden. Interne Charakteristiken hingegen sind beispielsweise die Zeit bis zum nächsten Planungsaufruf, Einstellungen oder die aktuell geplante Trajektorie.“
Um im weiteren Verlauf der Beschreibung auf klar definierte Begriffe/Bezeichnungen zurückgreifen zu können, wird der Zeitpunkt zu dem eine Zustandsspeicherung stattfindet „Situation“ genannt, die wie folgt definiert ist: „Eine Situation wird durch den Zustand des autonomen Fahrzeugs (Ego Vehicle State) zusammen mit allen Zuständen (States) des umgebenden Verkehrs beschrieben. Darüber hinaus beinhaltet eine Situation das statische Umfeld (Straße, Markierungen, Verkehrsschilder) relativ zu dem autonomen Fahrzeug (Ego Vehicle) sowie andere statisch Einflüsse (z.B. Wetter).“
-
Ausgehend von der Definition der Situation wird eine „Szene“ wie folgt definiert: „Eine Szene ist das Zeitintervall und somit das Verbindungsglied zwischen zwei Situationen.“
-
Eine Szene beschreibt also die zeitliche Aneinanderreihung von Situationen, was zu der rein zeitlichen Definition eines Szenarios führt: „Ein Szenario ist die Aneinanderreihung mehrerer Szenen.“
-
Der zeitliche Zusammenhang der Begriffe „Situation“, „Szene“ und „Szenario“ ist in verdeutlicht.
-
Aus den Definitionen für Situation und Szene ergibt sich die Definition für den Validierungsraum: " Der Validierungsraum ist die Ansammlung aller Situationen und deren zeitlicher Verknüpfung durch Szenen".
-
Hieraus ergibt sich, dass der Validierungsraum durch Simulation, aber auch durch reales Testen, verschiedener Situationen und Szenen abgedeckt (covered) werden kann, was wiederum zur „Methode der ähnlichen Situationen“ (Concept of Similar Situations") führt. Es ist möglich, dass verschiedene Situationen über unterschiedliche Szenen zu einer ähnlichen Situation führen, was durch die nachfolgende Definition verdeutlicht wird: „Situationen sind ähnlich, wenn dynamische Objekte (die umgebenden Fahrzeuge) den gleichen oder ähnlichen Zustand haben, während die Zustände des zu testenden, autonomen Fahrzeugs (Ego Vehicle) als auch das Verhältnis des Fahrzeugs zu statischen Einflüssen (Straße, Markierungen, Wetter) gleich oder ähnlich sind. Ähnlich bedeutet in diesem Zusammenhang, dass charakteristische Parameter, die die Ähnlichkeit ausdrücken sollen, sich in bestimmten Intervallen bewegen.“
-
Ein charakteristischer Parameter ist beispielsweise die Position eines Fahrzeugs ausgedrückt in kartesischen Koordinaten (x, y). Dieser charakteristische Parameter ist dann ähnlich, wenn sich x und y für beide Vergleichsfälle in einem bestimmten Intervall bewegen.
-
Durch die Methode der ähnlichen Situationen wird die Validierung (= sukzessive Abdeckung des Validierungsraumes) effizienter, da Szenen die von einer im Validierungsraum bereits validierten Situation ausgehen nicht erneut getestet werden müssen, sollte eine noch nicht validierte Situation zu einer ähnlichen Situation führen. Zur Verdeutlichung der Methode kann das Beispiel in herangezogen werden. Angenommen ein Szenario mit der Situationen-Folge ABCDHIJ wurde bereits validiert, dann kann beim Validieren der unterschiedlichen Folge EFGD die Simulation bei Situation D abgebrochen werden, da DHIJ bereits getestet wurde.
-
Im Allgemeinen wird Software zuerst getestet und erst dann freigegeben, wenn alle Voraussetzungen (Requirements) für die Freigabe erfüllt sind. Erfüllt die Software nicht die gewünschten Bedingungen, muss das Problem behoben werden, wonach erneut getestet wird. Das in diesem Patent beschriebene Verfahren weicht von dieser Vorgehensweise ab, indem das Testen nicht mehr rein herstellerseitig geschieht, sondern zu einem großen Teil auch beim Kunden. Um dies zu ermöglichen ist ein neues Modul in der Architektur des autonomen Fahrzeuges notwendig. Dieses Modul, wie in zusammen mit den übrigen Modulen dargestellt, ist hauptsächlich dafür zuständig die reibungsfreie Applikation des Entscheidungsmoduls (Decision) sicherzustellen. Hierbei ist zu beachten, dass es sich in nur um eine beispielhafte Architektur eines autonomen Fahrzeugs handelt, wie sie (ohne das Sicherheitsmodul) in D. Gonzlez, J. Prez, V. Milans, F. Nashashibi, „A Review of Motion Planning Techniques for Automated Vehicles," in IEEE Transactions on Intelligent Transportation Systems, 2016, pp. 1135-1145. zusammengefasst wurde. Module in diesem Patent müssen nicht zwingend als abgeschlossene Komponente aufgefasst werden, sondern dienen lediglich zur Veranschaulichung des Verfahrens. Demnach wäre es denkbar, dass die Funktion, die hier dem Sicherheitsmodul zugeschrieben wird, vereint mit der Funktion des Entscheidungsmodules, in einer Komponente verwirklicht wird. Anstatt zu versuchen alle möglichen Szenarien vor der Auslieferung zu testen, wird in dem neuen Verfahren nur ein Bruchteil beim Hersteller vor der Auslieferung getestet, um die wichtigsten Bereiche im Validierungsraum abzudecken. Der Validierungsraum muss am Anfang vor der Auslieferung also ausdrücklich nicht komplett validiert sein. Die Abdeckung des Validierungsraumes verhält sich proportional zur SAE Stufe der Automatisierung wie in dargestellt. Demnach kann, je nach Grad der Abdeckung, das Fahrzeug entweder teilautonom oder vollautonom betrieben werden. Da der Validierungsraum ortsgebunden ist, also Situationen und Szenen immer einem Ort zugeordnet werden können, ist es darüber hinaus möglich, dass eine Strecke, deren lokaler Validierungsraum ausreichend abgedeckt ist, vollautonomes Fahren zulässt, während dies mit dem gleichen Fahrzeug auf einer anderen, noch nicht ausreichend validierten Strecke nicht möglich ist. Darüber hinaus kann es auch vorkommen, dass eine bestimmte Strecke zwar vollautonom befahren werden kann, bestimmte Fahrmanöver jedoch noch nicht durchgeführt werden können. So ist es beispielsweise vorstellbar, dass das Fahrzeug zwar autonom auf einer Autobahn fahren kann, aber nur ohne zu überholen, da dieses Manöver nicht ausreichend im Validierungsraum abgedeckt wurde. Die Aufgabe des Sicherheitsmoduls ist es den Aktionsraum (Menge aller möglichen Manöver die das Entscheidungsmodul fahren könnte) auf eine Teilmenge zu reduzieren, die den validierten Bereichen im Validierungsraum entsprechen.
-
Dies kann grundsätzlich auf zwei Wegen erreicht werden: Erstens, das Sicherheitsmodul schickt fortwährend eine Menge möglicher Aktionen an das Entscheidungsmodul, woraus das Entscheidungsmodul dann eine Aktion auswählen kann. Zweitens, das Entscheidungsmodul schickt eine beabsichtigte Aktion an das Sicherheitsmodul, die das Sicherheitsmodul entweder ablehnen oder akzeptieren kann. Enthält das Sicherheitsmodul eine beabsichtigte Aktionsanfrage, leitet das Sicherheitsmodul eine Situationssuche im Validierungsraum ein (Situation Search). Ist die angefragt Situation und sukzessive Szenen/Situationen ausreichend validiert, so kann die Aktion bewilligt werden. Ist die Aktion allerdings nur teilweise und nicht ausreichend validiert, so ist das Sicherheitsmodul in der Lage einen Gegenvorschlag als Antwort auf die Aktionsanfrage an das Entscheidungsmodul zu schicken. Durch den Gegenvorschlag kann das Sicherheitsmodul das Entscheidungsmodul beeinflussen, sodass dieses nur versucht sich in bereits validierten Bereichen des Validierungsraumes zu bewegen. Dieses Kommunikationsmuster wird solange wiederholt, bis eine Lösung gefunden wurde. Der Validierungsraum kann durch das Sicherheitsmodul also auch dafür genutzt werden, Vorhersagen über die Wahrscheinlichkeit einer sicheren Bewältigung eines Teilabschnitts der zu bewältigenden Strecke zu liefern, die für die Eingriffsanfrage genutzt werden kann, wodurch die SAE Stufe 3 (Partial Automation) ermöglicht wird. Das Sicherheitsmodul kann vor der Fahrt dazu genutzt werden dem Fahrer mitzuteilen, mit welchem Grad der Automatisierung er die Strecke zu seinem Ziel bewältigen kann. Während der Fahrt kann das Sicherheitsmodul fortwährend Situationen im Validierungsraum prüfen und somit dem Fahrer frühzeitig signalisieren, dass es zu einer nicht validierten Situation kommen kann, worauf der Fahrer die Kontrolle übernehmen kann.
-
Immer wenn das Entscheidungsmodul während der Fahrt eine Anfrage an das Sicherheitsmodul sendet, und das Sicherheitsmodul die geplante Aktion/Trajektorie ablehnt, da sie noch nicht validiert ist, werden diese Situationen im Validierungsraum gespeichert und nach Häufigkeit der Anfrage sortiert um eine bevorzugte Validierung dieser Bereiche im Validierungsraum zu ermöglichen. Zur simulativen Validierung können diese Situationen nun an einen Server des Herstellers gesendet werden oder aber auf der Hardware des Fahrzeuges getestet werden, dessen Entscheidungsmodul die Situation zuvor ausführen wollte, aber von dem Sicherheitsmodul daran gehindert wurde. Nach der lokalen (= auf der Hardware des Fahrzeugs) Simulation werden die neu validierten Bereiche über einen Server mit allen Fahrzeugen geteilt, sodass jedes Fahrzeug davon profitiert. Des Weiteren werden auf dem Server verschiedene Situationen, die zu verschiedenen Straßenabschnitten gehören, auf Ähnlichkeit geprüft, sodass ein validierter Bereich von einem Streckenabschnitt auf einen andern übertragen werden kann.
-
Die Simulation zum Ausfüllen des Validierungsraumes stellt allerdings nur den ersten Schritt hin zur vollständigen Validierung dar. Da die Validierung via Simulation nicht so aussagekräftig ist wie die Validierung durch Realfahrten, werden Bereiche im Validierungsraum als besonders sicher bewertet, wenn sie nicht nur durch Simulation sondern auch durch eine Realfahrt abgedeckt wurden.
-
Das vorgeschlagene Verfahren kann somit dazu genutzt werden von der SAE Stufe 2 der Validierung, Schritt für Schritt, zu Stufe 5 und somit zu vollautomatisiertem Fahren zu gelangen.
- Zu : Veranschaulichung eines zweidimensionalen Zustandsgitters (Spatiotemporal State Lattices).
- Zu : Verdeutlichung des rein zeitlichen Zusammenhangs der Begriffe Situation, Szene, und Szenario.
- Zu : Methode der ähnlichen Situationen. Markierungen auf den Zeitachsen stellen Situationen dar. Die beiden linken Zeitachsen entsprechen zwei unterschiedlichen Situationen-Folgen, die jedoch gemeinsam haben, dass sie in der ähnlichen Situation D enden. Alle von D ausgehenden Situationen (beispielhafte Folge rechts dargestellt) müssen demnach nicht erneut getestet werden.
- Zu : Verschiedene Stufen der Automatisierung und qualitativ dargestellte Proportionalität zur Abdeckung des Validierungsraumes.
- Zu : Architektur eines bekannten autonomen Fahrzeugs, ergänzt um ein Sicherheitsmodul, welches die sichere Applikation des Fahrzeugs gewährleisten soll.