DE102017218143A1

DE102017218143A1 - Verfahren und Vorrichtung zum Ansteuern eines fahrzeugelektronischen Planungsmodules

Info

Publication number: DE102017218143A1
Application number: DE102017218143.5A
Authority: DE
Inventors: Christian Becker-Asano; Hana Boukricha
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2017-10-11
Filing date: 2017-10-11
Publication date: 2019-04-11

Abstract

Verfahren (10) zum Ansteuern eines fahrzeugelektronischen Planungsmodules (13),gekennzeichnet durch folgende Merkmale:- eine Ausgangsszene (11) wird aus der Szenendatenbank (12) ausgewählt (1) und dem Planungsmodul (13) übergeben,- die Ausgangsszene (11) wird in einen Ausgangszustandsgraphen (20) konvertiert (2),- anhand einer vom Planungsmodul (13) für die Ausgangsszene (11) ausgegebenen Verhaltensbeschreibung (14) wird ein Zustandsmodell über einen Zeitschritt simuliert (3),- ausgehend vom Ausgangszustandsgraphen (20) wird nach vorgegebenen Transformationsregeln (40) mindestens ein möglicher Folgezustandsgraph (17) bestimmt (4),- der Folgezustandsgraph (17) wird in eine Folgeszene (15) konvertiert (5),- anhand einer vom Planungsmodul (13) für die Folgeszene (15) ausgegebenen Verhaltensbeschreibung (14) wird das Zustandsmodell über einen weiteren Zeitschritt simuliert (3),- das Simulieren (3), Bestimmen (4) und Konvertieren (5) wird wiederholt, bis ein vorgegebenes Abbruchkriterium (18) erfüllt ist,- sobald das Abbruchkriterium (18) erfüllt ist, werden die Folgeszenen (15) einer Bewertung (6) anhand mindestens eines vorgegebenen Optimierungskriteriums (21) unterzogen und- ist das Optimierungskriterium nicht erfüllt (21, N), so werden aus der Bewertung (6) Planungsparameter (22) abgeleitet und das Planungsmodul (13) wird mit den Planungsparametern (22) angesteuert.

Description

Die vorliegende Erfindung betrifft ein Verfahren (10) zum Ansteuern eines fahrzeugelektronischen Planungsmodules (13). Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
Stand der Technik
Eingebettete Systeme (embedded systems) sind auf schlüssige Eingangssignale von Sensoren angewiesen und stimulieren wiederum ihre Umwelt durch Ausgangssignale an unterschiedlichste Aktoren. Im Zuge der Verifikation und vorgelagerter Entwicklungsphasen eines solchen Systems wird daher in einer Regelschleife dessen Modell (model in the loop, MiL), Software (software in the loop, SiL), Prozessor (processor in the loop, PiL) oder gesamte Hardware (hardware in the loop, HiL) gemeinsam mit einem Modell der Umgebung simuliert. In der Fahrzeugtechnik werden diesem Prinzip entsprechende Simulatoren zur Prüfung elektronischer Steuergeräte je nach Testphase und -objekt mitunter als Komponenten-, Modul- oder Integrationsprüfstände bezeichnet.
DE102015200300A1 betrifft ein Verfahren zum Simulieren einer Maschine, wobei in einer nicht-echtzeitfähigen Recheneinheit eine Simulation der Maschine durchgeführt wird, eine Steuereinheit über ein nicht-echtzeitfähiges Kommunikationssystem mit der nicht-echtzeitfähigen Recheneinheit verbunden ist, wobei in der Steuereinheit ein Steuerungsprogramm umfassend Steuerungsprogrammschritte zum Steuern der Maschine ausgeführt wird, wobei, wenn eine Auslösebedingung erfüllt ist, von der nicht-echtzeitfähigen Recheneinheit ein Auslösesignal ausgegeben wird und das Auslösesignal von der Steuereinheit empfangen wird und wobei auf das empfangene Auslösesignal hin wenigstens ein Steuerungsprogrammschritt des Steuerungsprogramms in der Steuereinheit ausgeführt wird.
Offenbarung der Erfindung
Die Erfindung stellt ein Verfahren (10) zum Ansteuern eines fahrzeugelektronischen Planungsmodules (13), eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
Ein Vorzug dieser Lösung liegt in der eröffneten Möglichkeit zur automatischen Optimierung von Planungsmodulen, wie sie im Rahmen der Realisierung von hochautomatisierten Fahrfunktionen als zentrale Komponenten für zukünftige Steuergeräte von Automobilen entwickelt werden. Das externe, zu optimierende Planungsmodul braucht hierzu lediglich über eine Softwareschnittstelle angebunden zu werden. Die semantisch annotierten Ausgangsszenen, die dem Planungsmodul als Eingabe dienen und als potentiell kritisch für das Planungsmodul eingeschätzt werden, können manuell in einer vorab erstellten, externen Datenbank gesammelt werden.
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So können als Ausgabe des vorgeschlagenen Verfahrens Parameter für das Planungsmodul vorgesehen sein, die im Hinblick auf formal definierte Optimierungskriterien optimiert sind.
Figurenliste
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:

1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
2 das Beispiel einer im Rahmen des Verfahrens genutzten Graph-basierten Darstellung einer Ausgangsszene.
3 das Beispiel eines im Rahmen des Verfahrens der 1 genutzten Typgraphen.
4 das Beispiel einer Transformationsregel, die dem Typgraphen der 3 entspricht.
5 das Flussdiagramm einer automatischen Exploration aller potenziellen Szenen für den jeweils nächsten Zeitschritt.
6 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.

Ausführungsformen der Erfindung
1 illustriert den übergeordneten Ablauf des vorgeschlagenen Verfahrens (10), dessen einzelne Schritt nunmehr in Zusammenschau mit den nachfolgenden Figuren erläutert seien.
Zuerst wird zufällig eine noch nicht verwendete Ausgangsszene (11) aus der manuell erstellten Datenbank ausgewählt (1) und an das externe, zu optimierende Planungsmodul (13) übergeben. Unter dem Begriff „Ausgangsszene“ sind in diesem Zusammenhang alle Datenstrukturen zu verstehen, die es dem zu optimierenden, externen Planungsmodul (13) zur Laufzeit gestatten, zumindest auf einem hohen Abstraktionsniveau Verhaltensentscheidungen zu treffen. Zum Beispiel können diese Verhaltensentscheidungen in der Auswahl einzelner, vordefinierter Fahrmanöver wie der Einleitung oder Vollendung eines Spurwechsels bestehen. Technisch können diese Verhaltensentscheidungen wie auch die Ausgangsszenen in einem zeichenkodierten Format wie JSON oder XML oder aber auch in Form eines serialisierten, binärkodierten Objekts über eine Netzwerkschnittstelle übertragen werden.
Die besagte Ausgangsszene (11) wird automatisch durch syntaktische Modelltransformation in eine semantisch äquivalente, Graph-basierte Darstellung konvertiert (2). Dabei nutzt der Konvertierungsprozess (2) vorab modellierte Typgraphen (30), die in einer Datenbank (19) hinterlegt wurden. Unter einer Graph-basierten Darstellung der Ausgangsszene (11) ist eine Datenstruktur zu verstehen, die grundlegend aus Knoten und Kanten besteht. Die Kanten können Attribute besitzen und die Knoten eines Graphen besitzen Attribut-Wert-Paare und zusätzlich einen Typ, durch den eine dem Graphen zu Grunde liegende Typhierarchie zur einfacheren Formulierung von Graph-Transformationsregeln (40), die im weiteren Verlauf des Verfahrens (10) zur Anwendung kommen, genutzt werden kann.
2 zeigt ein Beispiel einer solchen Graph-basierten Darstellung (20) einer Ausgangsszene (11). Dieser graphischen Darstellung entspricht eine interne Datenstruktur, die einem nachfolgend beschriebenen Explorationsprozess (4) als Ausgangspunkt dient. Die syntaktische Modelltransformation (2) wandelt die oben beschriebenen, externen Datenstrukturen (11) unter Erhalt aller für die Graph-Transformation relevanten Elemente und unter Beachtung der zu Grunde liegenden Typgraphen (30) in die besagte Graph-basierte Darstellung (20) um. Dies wird mit Hilfe von XSLT oder ähnlichen Transformationsprozessoren realisiert.
Durch derlei Typgraphen (30) - 3 gibt ein Beispiel wieder - werden die verschiedenen, realen Objekte der modellierten, abstrakten Sicht auf die Ausgangsszene (11) in Klassenhierarchien angeordnet und die Attribute der Knoten und Kanten aller Graph-Instanzen festgelegt. Dabei erben Unterklassen die Attribute ihrer jeweiligen Oberklassen.
Transformationsregeln (40) liegen in Form von einer speziellen Art von Graphen vor, deren Struktur ebenfalls mit den zu Grunde liegenden Typgraphen (30) kompatibel sein muss. Hierdurch wird sichergestellt, dass die Transformationsregeln (40) kompatibel zu den Graphen sind, also die gleichen Objektklassen (in Form von Knoten) und Relationen (in Form von Kanten zwischen Knoten) vorkommen. 4 zeigt ein Beispiel für eine Transformationsregel (40), die konform zu dem in 3 gezeigten Beispiel eines Typgraphen (30) ist. Zusätzlich zu den im Typgraphen (30) vorhandenen Knoten enthalten Transformationsregeln (40) eine vordefinierte Menge spezieller Knoten und Kanten zur Repräsentation von Datentypen (hier „int“), Konstanten und mathematischen sowie logischen Operatoren (hier „add“ in Form der Raute als Produktknoten mit spezieller Operatorkante). Verschiedene, in der Nichtpatentliteratur meist farblich kodierte Kantentypen ermöglichen es, die Veränderungen am Zielgraphen auszudrücken, die nach der Transformation stattgefunden haben sollen. Alle Veränderungen in der Umwelt, also Positionen, Geschwindigkeiten, physikalische Strukturen (z. B. Hinzukommen oder Wegfallen einer Fahrbahn), werden durch derartige Graph-Transformationsregeln (40) ausgedrückt.
Die Ausgabe des Planungsmodules (13) in Form einer Verhaltensbeschreibung (14) für das zu automatisierende Fahrzeug kann nun in Kenntnis des entsprechenden Zustandsgraphen mit dem Initialzustand kombiniert werden (3), und ein iterativer Prozess beginnt. Bemerkt sei an dieser Stelle, dass die Ausgangsszene (11) auch andere Verkehrsteilnehmer mit ihren physikalischen Parametern enthalten mag.
Mittels des vorgeschlagenen Verfahrens (10) können nun alle möglichen Verhaltensweisen (Manöver) aller anderen Verkehrsteilnehmer in allen möglichen Kombinationen systematisch in Kombination mit der Verhaltensentscheidung des Planungsmodules (13) generiert und der resultierende Zustandsraum somit exploriert werden. Insofern kann die Verhaltensbeschreibung (14) symbolische Werte (z. B. die Kennung eines Lenkmanövers), zum anderen aber auch Parameter enthalten (z. B. initialer Lenkwinkel oder maximale Bremskraft). Diese Parameter fließen in entsprechende Graph-Transformationsregeln (40) ein.
Im Rahmen dieser Exploration werden die vorab definierten Transformationsregeln (40), deren syntaktische Struktur den Typgraphen (30) entsprechen muss, auf den Zustandsgraphen (20) angewendet, um alle möglichen Folgeszenen (15) für den nächsten Zeitschritt zu bestimmen (4). Dieser iterative Teilprozess startet mit dem Initialzustand in Kombination mit der ersten Verhaltensbeschreibung (14), wie sie vom externen Planungsmodul (13) ermittelt wurde. Dabei wird in Fällen, bei denen ein Knoten mehrere Nachfolgeknoten hat, in Form einer Breitensuche vorgegangen.
Da die Verhaltensbeschreibung (14) des externen Planers (13) beim Explorieren (4) des Zustandsraumes mit einbezogen werden müssen, ist es erforderlich, dass alle als Graphen vorliegenden Szenen in das Format des externen Planungsmodules (13) umgewandelt werden, bevor sie an es übergeben werden. Dabei sollten alle relevanten Informationen erhalten bleiben, damit der externe Planer (13) eine Verhaltensentscheidung treffen kann. Die Art der erforderlichen Konvertierung hängt von den Datenstrukturen ab, mit denen das externe Planungsmodul (13) arbeitet. Insbesondere könnte es bei einigen Planern nötig sein, auch den internen Zustand des Planungsmodules (13) von außen (zurück-)setzen zu können, wenn ein solcher dynamisch im Planungsmodul (13) aufgebaut wird und die Verhaltensentscheidung mitbestimmt.
Hierzu wird die Menge der wie beschrieben generierten Graph-basierten Szenen sequenziell an einen Konvertierungsprozess weitergegeben. In dessen Rahmen wird jede Graph-basierte Szene (17) in eine äquivalente, semantisch annotierte Szene (15) konvertiert (5), um sie als Eingabe an das externe Planungsmodul (13) übergeben zu können. Dieses kann nun eine neue Verhaltensbeschreibung (14) generieren, die wie oben beschrieben mit der aktuellen Szene kombiniert wird (3). Jede Folgeszene (15) kann so mit der Verhaltensentscheidung des externen Planungsmodules (13) kombiniert (3) werden, um von dort aus weiter explorieren (4) zu können. Sobald der maximale Simulationszeitschritt t_max erreicht wurde, der als freier Parameter zu spezifizieren ist, werden keine weiteren potenziellen Szenen (17) mehr generiert (4).
5 zeigt ein Ablaufdiagramm, das diese innere Schleife und insbesondere den Zusammenhang zwischen der Auswahl von Fahrmanövern (25 - 28) und deren Abbildung auf Einzelaktionen (29) beschreibt. Beispielsweise könnte, wenn kein anderweitiges Manöver eines Fremdfahrzeuges erkannt wurde (Entscheidung 24, Zweig N), im Rahmen der obigen Zustandsraumexploration (4) ein mögliches Manöver nichtdeterministisch ausgewählt werden (25). In Betracht kommen etwa ein Spurwechsel nach links (26), die Weiterfahrt geradeaus (27) sowie ein Spurwechsel nach rechts (28).
Um die in 5 dargestellte Integration der vom externen Planungsmodul (13) bestimmten Aktionen zu ermöglichen, müssen diese auf interne Aktionen abgebildet werden. Zum Beispiel kann eine vom Planungsmodul (13) vorgeschlagene Aktion mit ihren Parametern auf eine Transformationsregel (40) abgebildet werden, die dieser Aktion mit ihren Parametern hinreichend exakt entspricht. Dies kann zum Beispiel durch die Kombination einer Lookup-Tabelle und einer geeigneten Parameter-Extraktion und -Übertragung geschehen. Die jeweils nächste Aktion (36) kann so etwa zur Aktualisierung der Positionen aller dynamischen Objekte einschließlich aller Fahrzeuge (31) herangezogen werden. Nach einer erneuten Zuordnung von Fahrzeugen zu Fahrspuren (32), Überprüfung auf vollendete Manöver (33), Bereinigung von Flags und Konfigurationen sowie Prüfung auf beginnende oder endende Fahrspuren kann der jeweilige Simulationszeitschritt abgeschlossen werden (34).
Der bis dahin generierte Zustandsraum wird auf Grundlage der formal vorab definierten Optimierungskriterien einer automatischen Bewertung (6) unterzogen. Diese Optimierungskriterien können zum Beispiel Formalisierungen von Aussagen wie „Das hochautomatisierte Fahrzeug hat immer mindestens eine Verhaltensoption, bei der ein Unfall vermieden wird“ sein. Ebenso könnte ein solches Kriterium ein spezifischer Schwellwert für die gewichtete Summe aus der Anzahl der Unterschreitungen des Sicherheitsabstandes zwischen autonomem Fahrzeug gegenüber allen anderen Fahrzeugen und der innerhalb des betrachteten Zeitraumes zurückgelegten Strecke sein, um ein Optimum zwischen defensiver und offensiver Verhaltensstrategie zu erreichen. Bei Vorliegen einer konkreten Instanz eines Transitionssystems könnten beide Parameter durch Abzählen einfach ermittelt und mit dem nicht zu unterschreitenden Schwellwert verglichen werden.
Das weitere Vorgehen setzt eine Parametrisierbarkeit des externen Planungsmodules (13) voraus. Dies trifft auf eine Mehrzahl einschlägiger Module zu, da die notwendige Echtzeitfähigkeit eines solchen Planungsmodules (13) gewöhnlich unter Heranziehung von Heuristiken erreicht wird. Solche Heuristiken basieren in aller Regel auf manuell definierten Bewertungsfunktionen mit einer Reihe von freien Parametern. Diese werden bei der Suche nach einer Lösung des Planungsproblems verwendet, um den Planungsalgorithmus in Richtung der relevanten, weil vielversprechenderen, Suchoptionen zu steuern. Zum Beispiel könnte eine Heuristik darin bestehen, unter Betrachtung der jeweils nächsten n Schritte einen aktuellen Zustand im Suchraum zu bewerten und ihn mit seinen Nachfolgezuständen ggf. komplett bei der Suche zu ignorieren. Die beschriebene Bewertung (6) liefert in diesem Fall ein Maß für die Güte des Planungsmodules (13) mit seinem aktuellen Parameter n, der im Rahmen des vorgeschlagenen Verfahrens (10) systematisch variiert werden könnte, wenn - bezogen auf den durch die ursprüngliche, aus der Szenendatenbank (12) ausgewählte Ausgangsszene (11) definierten Initialzustand - das Kriterium (lokal) nicht erfüllt wird (Entscheidung 21, Zweig N). Hierzu wird für das Planungsmodul (13) ein neuer Parametersatz (22) berechnet und gesetzt. Die Exploration wird ggf. auf die Ausgangsszene (11) zurückgesetzt (7). Diese wird sodann - wie oben beschrieben - mit der durch das modifizierte Planungsmodul (13) neu ermittelten Verhaltensbeschreibung (14) kombiniert.
Zusätzlich hängt die Erfüllbarkeit des Optimierungskriteriums (21) auch von der Ausgangsszene (11) ab, mit der die Zustandsraumexploration (4) begonnen hat. Wenn die Optimierungskriterien lokal erfüllt werden (Entscheidung 21, Zweig Y), wird daher in einer „äußeren“ Schleife überprüft (Entscheidung 23), ob sie unabhängig von der konkreten Ausgangsszene (11) auch global erfüllt werden, was von der Anzahl der betrachteten Initialzustände und deren Ähnlichkeit untereinander abhängt. Diese Bewertung könnte zum Beispiel derart gestaltet sein, dass das Kriterium dann als global erfüllt (Entscheidung 23, Zweig Y) gilt, wenn es für eine Mindestanzahl an Ausgangsszenen (11) lokal erfüllt (Entscheidung 21, Zweig Y) wurde. Sollte dies nicht der Fall sein, so wird die Exploration wie oben beschrieben auf einen neuen Initialzustand zurückgesetzt (7), der erneut zufällig aus der Szenendatenbank (12) ausgewählt wird (1), und der Prozess beginnt von vorne. Sobald auch auf globaler Ebene das Optimierungskriterium (21) erfüllt wird (Entscheidung 23, Zweig Y), werden die optimierten Parameter (16) für das Planungsmodul (13) zurückgegeben und der Prozess endet.
Das Planungsmodul (13) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät (60) implementiert sein, wie die schematische Darstellung der 6 verdeutlicht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102015200300 A1 [0003]

Claims

Verfahren (10) zum Ansteuern eines fahrzeugelektronischen Planungsmodules (13) anhand einer Szenendatenbank (12), gekennzeichnet durch folgende Merkmale: - eine Ausgangsszene (11) wird aus der Szenendatenbank (12) ausgewählt (1) und dem Planungsmodul (13) übergeben, - die Ausgangsszene (11) wird in einen Ausgangszustandsgraphen (20) konvertiert (2), - anhand einer vom Planungsmodul (13) für die Ausgangsszene (11) ausgegebenen Verhaltensbeschreibung (14) wird ein Zustandsmodell über einen Zeitschritt simuliert (3), - ausgehend vom Ausgangszustandsgraphen (20) wird nach vorgegebenen Transformationsregeln (40) mindestens ein möglicher Folgezustandsgraph (17) bestimmt (4), - der Folgezustandsgraph (17) wird in eine Folgeszene (15) konvertiert (5), - anhand einer vom Planungsmodul (13) für die Folgeszene (15) ausgegebenen Verhaltensbeschreibung (14) wird das Zustandsmodell über einen weiteren Zeitschritt simuliert (3), - das Simulieren (3), Bestimmen (4) und Konvertieren (5) wird wiederholt, bis ein vorgegebenes Abbruchkriterium (18) erfüllt ist, - sobald das Abbruchkriterium (18) erfüllt ist, werden die Folgeszenen (15) einer Bewertung (6) anhand mindestens eines vorgegebenen Optimierungskriteriums (21) unterzogen und - ist das Optimierungskriterium nicht erfüllt (21, N), so werden aus der Bewertung (6) Planungsparameter (22) abgeleitet und das Planungsmodul (13) wird mit den Planungsparametern (22) angesteuert.
Fehler! Verweisquelle konnte nicht gefunden werden, nach Anspruch 1, gekennzeichnet durch folgendes Merkmal: - ist das Optimierungskriterium nicht erfüllt (21, N), so wird ferner das Zustandsmodell auf die Ausgangsszene (11) zurückgesetzt (7) und das Verfahren (10) wiederholt.
Fehler! Verweisquelle konnte nicht gefunden werden, nach Anspruch 1 oder 2, gekennzeichnet durch folgendes Merkmal: - die Transformationsregeln (40) werden aus einer Regeldatenbank (19) abgerufen.
Fehler! Verweisquelle konnte nicht gefunden werden, nach einem der Ansprüche 1 bis 3, gekennzeichnet durch folgendes Merkmale: - das Konvertieren (2, 5) erfolgt anhand vorgegebener Typgraphen (30).
Fehler! Verweisquelle konnte nicht gefunden werden, nach einem der Ansprüche 1 bis 4, gekennzeichnet durch folgendes Merkmal: - ist das Optimierungskriterium global erfüllt (23, Y), so werden die optimierten Planungsparameter ausgegeben (16).
Fehler! Verweisquelle konnte nicht gefunden werden, nach einem der Ansprüche 1 bis 5, gekennzeichnet durch folgende Merkmale: - nach den Transformationsregeln (40) werden durch eine Breitensuche alle möglichen Folgezustandsgraphen (17) bestimmt und - die Folgezustandsgraphen (17) werden sequenziell in die Folgeszenen (15) konvertiert.
Fehler! Verweisquelle konnte nicht gefunden werden, nach einem der Ansprüche 1 bis 6, gekennzeichnet durch folgendes Merkmal: - das Abbruchkriterium (18) betrifft die Anzahl der Zeitschritte.
Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.
Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
Vorrichtung (60), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.