DE102018126270A1

DE102018126270A1 - Dezentralisierte fahrzeugsteuerung der minimalen risikobedingung

Info

Publication number: DE102018126270A1
Application number: DE102018126270.1A
Authority: DE
Inventors: Ahmad Khalifeh; Beni Tang; Kathryn HAMILTON; Sagar Avaneendra Tatipamula; Sandro Patrick Nuesch; Rashmi Hegde
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-10-24
Filing date: 2018-10-22
Publication date: 2019-04-25
Also published as: US10611381B2; CN109693671A; US20190118827A1

Abstract

Ein Fahrzeugcomputer beinhaltet einen Speicher und einen Prozessor, der programmiert ist, um im Speicher gespeicherte Anweisungen auszuführen. Die Anweisungen beinhalten das Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung und einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung, das Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis und das Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.

Description

TECHNISCHES GEBIET
Die Offenbarung betrifft das Gebiet autonomer Fahrzeuge und insbesondere das Gebiet der autonomen Fahrzeugsteuerung.
STAND DER TECHNIK
Die Society of Automotive Engineers (SAE) hat mehrere Stufen des autonomen Fahrzeugbetriebs definiert. Bei Stufe 0-2 überwacht oder steuert ein menschlicher Fahrzeugführer die Mehrheit der Fahraufgaben, oftmals ohne Hilfe vom Fahrzeug. Beispielsweise ist ein menschlicher Fahrzeugführer bei Stufe 0 („keine Automatisierung“) für alle Fahrzeugabläufe verantwortlich. Bei Stufe 1 („Fahrzeugführerassistenz“) hilft das Fahrzeug manchmal in Bezug auf das Lenken, Beschleunigen oder Bremsen, aber der Fahrzeugführer ist noch immer für die große Mehrheit der Fahrzeugsteuerung verantwortlich. Bei Stufe 2 („partielle Automatisierung“) kann das Fahrzeug das Lenken, Beschleunigen und Bremsen unter bestimmten Umständen ohne menschliche Interaktion steuern. Bei Stufe 3-5 übernimmt das Fahrzeug mehr fahrbezogene Aufgaben. Bei Stufe 3 („bedingte Automatisierung“) kann das Fahrzeug das Lenken, Beschleunigen und Bremsen unter bestimmten Umständen bewältigen sowie die Fahrumgebung überwachen. Bei Stufe 3 ist es jedoch erforderlich, dass der Fahrzeugführer gelegentlich eingreift. Bei Stufe 4 („hohe Automatisierung“) kann das Fahrzeug die gleichen Aufgaben wie bei Stufe 3 bewältigen, aber ohne darauf angewiesen zu sein, dass der Fahrzeugführer in bestimmte Fahrmodi eingreift. Bei Stufe 5 („volle Automatisierung“) kann das Fahrzeug fast alle Aufgaben ohne jegliches Eingreifen des Fahrzeugführers bewältigen.
KURZDARSTELLUNG
Vollständig autonome Fahrzeuge, wie beispielsweise autonome Fahrzeuge der Stufe 5, müssen darauf vorbereitet sein, hochkomplexe Verkehrssituationen ohne menschliches Eingreifen zu navigieren. Parameter der minimalen Risikobedingung (minimum risk condition, MRC) definieren, wie das autonome Fahrzeug auf bestimmte Arten von Fehlern reagiert. Das autonome Fahrzeug kann sozusagen bestimmen, welches Ereignis der minimalen Risikobedingung als Reaktion auf einen bestimmten Fehler auszuführen ist. Das Ereignis der minimalen Risikobedingung ist eine Maßnahme, die vom autonomen Fahrzeug ergriffen wird.
Beispiele von Ereignissen der minimalen Risikobedingung beinhalten nach zunehmendem Schweregrad Nichtstun, Anhalten am Straßenrand an einem idealen Standort, sofortiges Anhalten am Straßenrand und Anhalten des autonomen Fahrzeugs in seiner Fahrspur.
Ein beispielhafter Fahrzeugcomputer, der eine dezentralisierte MRC-Steuerung auszuführen kann, beinhaltet einen Speicher und einen Prozessor. Der Prozessor ist programmiert, um im Speicher gespeicherte Anweisungen auszuführen. Die Anweisungen beinhalten das Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung und einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung. Die Anweisungen beinhalten ferner das Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis und das Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.
Im Fahrzeugcomputer kann der Prozessor programmiert sein, um die erste und zweite MRC-Ereignisempfehlung als ein Ergebnis der jeweiligen ersten und zweiten Plattformsteuerung, die jeweils einen Fahrzeugsystemfehler erfasst, zu empfangen. Der Fahrzeugsystemfehler, der von der ersten Plattformsteuerung erfasst wurde, unterscheidet sich von dem Fahrzeugsystemfehler, der von der zweiten Plattformsteuerung erfasst wurde.
Im Fahrzeugcomputer kann der Prozessor programmiert sein, um eine dritte MRC-Ereignisempfehlung zu erzeugen. In diesem Fall beinhaltet das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung. Ferner kann der Prozessor programmiert sein, um die dritte MRC-Ereignisempfehlung als ein Ergebnis der Erfassung eines Fahrzeugsensorfehlers durch den Prozessor zu erzeugen.
Im Fahrzeugcomputer kann der Prozessor programmiert sein, um das autonome Host-Fahrzeug gemäß dem ausgewählten MRC-Ereignis durch Ausgabe von Bewegungssteuersignalen an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und einer dritten Plattformsteuerung zu steuern. In dieser Ausgestaltung kann der Prozessor programmiert sein, um die Bewegungssteuersignale von einer autonomen Fahrzeugsteuerung zu empfangen und die Bewegungssteuersignale an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und der dritten Plattformsteuerung auszugeben.
Im Fahrzeugcomputer kann der Prozessor programmiert sein, um eine der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf Grundlage eines mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrads und eines mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrads auszuwählen. Die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden sich. In dieser Ausgestaltung kann der Prozessor programmiert sein, um die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen. Der Prozessor kann programmiert sein, um die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen.
Im Fahrzeugcomputer kann der Prozessor programmiert sein, um eine vierte MRC-Ereignisempfehlung auf Grundlage eines kumulierten Schweregrads der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung auszuwählen, wobei sich die vierte MRC-Ereignisempfehlung von der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheidet.
Ein beispielhaftes Fahrzeugsystem, das eine dezentralisierte MRC-Steuerung ausführt, beinhaltet eine erste Plattformsteuerung, die programmiert ist, um eine erste MRC-Ereignisempfehlung auszugeben, und eine zweite Plattformsteuerung, die programmiert ist, um eine zweite MRC-Ereignisempfehlung auszugeben. Das Fahrzeugsystem beinhaltet ferner eine Steuerung der minimalen Risikobedingung (MRC), die programmiert ist, um die erste MRC-Ereignisempfehlung und die zweite MRC-Ereignisempfehlung zu empfangen, um eine der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis auszuwählen und um ein autonomes Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis zu steuern.
Im Fahrzeugsystem kann die MRC-Steuerung programmiert sein, um die erste und zweite MRC-Ereignisempfehlung als ein Ergebnis der jeweiligen ersten und zweiten Plattformsteuerung, die jeweils einen Systemfehler erfasst, zu empfangen. Der Systemfehler, der von der ersten Plattformsteuerung erfasst wurde, unterscheidet sich von dem Systemfehler, der von der zweiten Plattformsteuerung erfasst wurde.
Im Fahrzeugsystem ist die MRC-Steuerung ferner programmiert, um eine dritte MRC-Ereignisempfehlung als ein Ergebnis der Erfassung eines Fahrzeugsensorfehlers durch die MRC-Steuerung zu erzeugen. Das Auswählen des ausgewählten MRC-Ereignisses beinhaltet das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung.
Im Fahrzeugsystem kann die MRC-Steuerung programmiert sein, um das autonome Host-Fahrzeug gemäß dem ausgewählten MRC-Ereignis durch Ausgabe von Bewegungssteuersignalen an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und einer dritten Plattformsteuerung zu steuern. In dieser Ausgestaltung kann die MRC-Steuerung programmiert sein, um die Bewegungssteuersignale von einer autonomen Fahrzeugsteuerung zu empfangen und die Bewegungssteuersignale an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und der dritten Plattformsteuerung auszugeben.
Im Fahrzeugsystem kann die MRC-Steuerung programmiert sein, um eine der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf Grundlage eines mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrads und eines mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrads auszuwählen. Die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden sich. Die MRC-Steuerung kann programmiert sein, um die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen. Die MRC-Steuerung kann programmiert sein, um die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen.
Ein Verfahren für dezentralisierte MRC-Steuerung beinhaltet das Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung, Empfangen einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung, Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis und Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.
Das Verfahren kann ferner das Erzeugen einer dritten MRC-Ereignisempfehlung beinhalten, wobei das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung beinhaltet.
Im Verfahren kann das Auswählen der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf einem mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrad und einem mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrad basieren. Die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden sich, und die erste MRC-Ereignisempfehlung ist als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, ausgewählt, und die zweite MRC-Ereignisempfehlung ist als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, ausgewählt.
Figurenliste

1 veranschaulicht ein beispielhaftes autonomes Fahrzeug mit dezentralisierter Fahrzeugsteuerung der minimalen Risikobedingung.
2 ist ein Blockdiagramm, das eine beispielhafte Ausführung der dezentralisierten Fahrzeugsteuerung der minimalen Risikobedingung veranschaulicht.
3 ist ein Ablaufdiagramm eines beispielhaften Prozesses der dezentralisierten Fahrzeugsteuerung der minimalen Risikobedingung.

DETAILLIERTE BESCHREIBUNG
Die dargestellten Elemente können viele verschiedene Formen annehmen und mehrere und/oder alternative Komponenten und Einrichtungen beinhalten. Die veranschaulichten beispielhaften Komponenten sollen nicht einschränkend sein. Vielmehr können zusätzliche oder alternative Komponenten und/oder Ausführungen verwendet werden. Ferner sind die dargestellten Elemente nicht zwangsläufig maßstabsgetreu gezeichnet, außer wenn explizit angegeben ist, dass sie dies sind.
1 veranschaulicht ein autonomes Host-Fahrzeug 100 mit dezentralisierter Steuerung der minimalen Risikobedingung (MRC). Wie in 1 veranschaulicht, beinhaltet das Host-Fahrzeug 100 ein virtuelles Fahrzeugführersystem 105, eine automatisierte Fahrzeugplattform 110 und eine Steuerung der minimalen Risikobedingung, auch als eine MRC-Steuerung 115 bezeichnet. Mindestens einige Teile des virtuellen Fahrzeugführersystems 105 und der MRC-Steuerung 115 können durch einen Fahrzeugcomputer ausgeführt sein. Obwohl das Host-Fahrzeug 100 als eine Limousine dargestellt ist, kann es sich um einen beliebigen Personen- oder Nutzkraftwagen handeln, wie beispielsweise ein Auto, einen Lastkraftwagen, einen SUV, ein Crossover-Fahrzeug, einen Van, einen Minivan, ein Taxi, einen Bus usw. Das Host-Fahrzeug 100 ist ein autonomes Fahrzeug, das in einem autonomen (z.B. fahrzeugführerlosen) Modus, einem teilautonomen Modus und/oder einem nichtautonomen Modus betrieben werden kann.
Das virtuelle Fahrzeugführersystem ist eine Rechenplattform, die mittels Sensoren 125, Steuerungen, Schaltkreisen, Chips und anderen elektronischen Komponenten, die die verschiedenen autonomen Abläufe des Host-Fahrzeugs 100 steuern, ausgeführt ist. Das virtuelle Fahrzeugführersystem 105 beinhaltet eine autonome Fahrzeugsteuerung 120, die programmiert ist, um die von den Sensoren 125, die einen LIDAR-Sensor, einen Radar-Sensor, eine Kamera, Ultraschallsensoren usw. beinhalten können, erfassten Daten zu verarbeiten. Die autonome Fahrzeugsteuerung 120 ist programmiert, um Steuersignale an Komponenten der automatisierten Fahrzeugplattform 110 auszugeben, um das Host-Fahrzeug 100 gemäß der von den Sensoren 125 erfassten Daten autonom zu steuern.
Die automatisierte Fahrzeugplattform 110 bezieht sich auf die Komponenten, die den autonomen Fahrzeugbetrieb auf Anweisung des virtuellen Fahrzeugführersystems 105, und insbesondere der autonomen Fahrzeugsteuerung 120, ausführen. Als solche beinhaltet die automatisierte Fahrzeugplattform 110 verschiedene, in das Host-Fahrzeug 100 eingebaute Aktuatoren 135 (siehe 2), die Lenken, Vortrieb und Bremsen des Host-Fahrzeugs 100 steuern. Die automatisierte Fahrzeugplattform 110 beinhaltet ferner verschiedene Plattformsteuerungen 130 (manchmal im Fachbereich als „Module“ bezeichnet) (siehe 2), wie beispielsweise eine Chassis-Steuerung, eine Antriebsstrangsteuerung, eine Karosseriesteuerung, eine elektrische Steuerung usw.
Die MRC-Steuerung 115 ist mittels Schaltkreisen, Chips oder anderen elektronischen Komponenten ausgeführt, die programmiert sind, um das Host-Fahrzeug 100 gemäß dem Ereignis der minimalen Risikobedingung (nachstehend als „MRC-Ereignis“ bezeichnet) autonom zu steuern. Ein MRC-Ereignis ist eine Maßnahme, die vom Host-Fahrzeug 100 als ein Ergebnis eines Systemfehlers ergriffen wird. Beispiele eines MRC-Ereignisses beinhalten nach abnehmendem Schweregrad das Anhalten des Host-Fahrzeugs 100 in seiner Fahrspur, das sofortige Anhalten des Host-Fahrzeugs 100 am Straßenrand, das Anhalten des Host-Fahrzeugs 100 in Kürze am Straßenrand (d. h. an einem idealen Standort, anstatt das Host-Fahrzeug 100 zu veranlassen, dies sofort zu tun) oder das Veranlassen des Host-Fahrzeugs 100, weiter zum Zielort zu fahren. Die MRC-Steuerung 115 ist programmiert, um das MRC-Ereignis gemäß der erfassten Art des Systemfehlers auszuwählen.
Das Auswählen eines MRC-Ereignisses beinhaltet, dass die MRC-Steuerung 115 Informationen in Betracht zieht, die von einer oder mehreren Steuerungen, die der automatisierten Fahrzeugplattform 110 zugehören, empfangen wurden. Jede Steuerung der automatisierten Fahrzeugplattform 110 (z. B. die Chassis-Steuerung, die Antriebsstrangsteuerung, die Karosseriesteuerung, die elektrische Steuerung usw.) ist programmiert, um Fehler eines oder mehrerer, mit der jeweiligen Steuerung assoziierten Fahrzeugsysteme zu erfassen. Beispielsweise kann die Antriebsstrangsteuerung programmiert sein, um verschiedene Motor- oder Getriebefehler zu erfassen. Jede Steuerung ist programmiert, um ein MRC-Ereignis auf Grundlage der Art des erfassten Fehlers zu empfehlen. Bei einem geringfügigen Fehler kann die Plattformsteuerung 130 programmiert sein, zu empfehlen, dass das Host-Fahrzeugs 100 den Auftrag vollendet. Bei einem etwas ernsthafteren Fehler kann die Plattformsteuerung 130 programmiert sein, zu empfehlen, dass das Host-Fahrzeug 100 am Straßenrand an einem idealen Standort, wie beispielsweise einem Parkplatz, anhält oder möglicherweise bis zu einer Tankstelle weiterfährt. Bei einem ernsthafteren Fehler kann die Plattformsteuerung 130 programmiert sein, zu empfehlen, dass das Host-Fahrzeug 100 sofort am Straßenrand, z. B. auf einem Standstreifen, anhält. Bei den schwerwiegendsten Fehlern kann die Plattformsteuerung 130 programmiert sein, zu empfehlen, dass das Host-Fahrzeug 100 sofort anhält, selbst wenn sich das Host-Fahrzeug 100 in einer Fahrspur befindet.
Die MRC-Steuerung 115 ist programmiert, um die Empfehlung von jeder Plattformsteuerung 130 im Host-Fahrzeug 100 zu empfangen. Die MRC-Steuerung 115 ist ferner programmiert, um das MRC-Ereignis gemäß den Empfehlungen der Plattformsteuerungen 130 auszuwählen. Die MRC-Steuerung 115 kann programmiert sein, um das MRC-Ereignis, das mit der schwerwiegendsten Art eines Fahrzeugsystemfehlers assoziiert ist, auszuwählen. So kann bei Erhalt der Information, dass das Beleuchtungssystem und das Bremssystem versagt haben, die MRC-Steuerung 115 programmiert sein, die Empfehlung des MRC-Ereignisses, das mit dem Bremssystemfehler assoziiert ist, auszuwählen. In einigen Ausführungen kann die MRC-Steuerung 115 programmiert sein, um ihre eigene Empfehlung des MRC-Ereignisses bereitzustellen. Beispielsweise kann die MRC-Steuerung 115 programmiert sein, um Fehler, die mit dem virtuellen Fahrzeugführersystem 105 assoziiert sind, zu erfassen, einschließlich Fehler, die mit den Sensoren 125, die im virtuellen Fahrzeugführersystem 105 enthalten sind, assoziiert sind, Fehler der autonomen Fahrzeugsteuerung 120 usw. Ein Fehler der autonomen Fahrzeugsteuerung 120 kann durch die MRC-Steuerung 115 als ein Ergebnis dessen erfasst werden, dass die autonome Fahrzeugsteuerung 120 versagt, ein MRC-Ereignis zu empfehlen, wenn ansonsten eins erwartet werden würde.
Wenn Fehler erfasst werden, kann die MRC-Steuerung 115 programmiert sein, ihr eigenes empfohlenes MRC-Ereignis zu bestimmen, das sie in Betracht zieht, wenn sie die von den Plattformsteuerungen 130 empfohlenen MRC-Ereignisse berücksichtigt. Die MRC-Steuerung 115 ist programmiert, um das ausgewählte MRC-Ereignis auszulösen, indem der autonomen Fahrzeugsteuerung 120 befohlen wird, das Host-Fahrzeug 100 gemäß dem ausgewählten MRC-Ereignis autonom zu betreiben. Die MRC-Steuerung 115 kann sogar noch zwischen den verschiedenen MRC-Empfehlungen der Plattformsteuerungen 130 und bezüglich ihrer eigenen Empfehlung vermitteln. Ferner wird dadurch, dass den Plattformsteuerungen 130 erlaubt wird, MRC-Empfehlungen abzugeben, die MRC-Ausführung des Host-Fahrzeugs 100 „verteilt“ oder „dezentralisiert“ was die Robustheit der MRC-Ausführung erhöht.
Die MRC-Steuerung 115 kann in die autonome Fahrzeugsteuerung 120 eingebaut sein, kann eine separate Vorrichtung (z. B. eine eigenständige Steuerung, die außerhalb der autonomen Fahrzeugsteuerung 120 betrieben wird) sein oder in eine verschiedene Steuerung eingebaut sein.
2 ist ein Blockdiagramm, das eine beispielhafte Ausführung der dezentralisierten MRC-Steuerung veranschaulicht. Insbesondere weist jede Plattformsteuerung 130 ihre eigene MRC-Steuerlogik auf, die die jeweilige Plattformsteuerung 130 ausführt, um der MRC-Steuerung 115 empfohlene MRC-Ereignisse bereitzustellen. In der Ausführung der 2 ist die MRC-Steuerung 115 von dem virtuellen Fahrzeugführersystem 105 und der automatisierten Fahrzeugplattform 110 getrennt. Die MRC-Steuerung 115 empfängt die MRC-Ereignisempfehlungen von den verschiedenen Plattformsteuerungen 130 der automatisierten Fahrzeugplattform 110, von der autonomen Fahrzeugsteuerung 120 oder einer Kombination aus beiden. Die MRC-Steuerung 115 verarbeitet diese Empfehlungen, wählt eine der Empfehlungen aus (oder bestimmt ansonsten ihr eigenes ausgewähltes MRC-Ereignis auf der Basis von z. B. Sensordaten, dem kumulierten Schweregrad der MRC-Ereignisempfehlungen usw.) und gibt Bewegungssteuerbefehle an die Aktuatoren 135 der automatisierten Fahrzeugplattform 110 aus, um das ausgewählte MRC-Ereignis auszuführen. In einigen Fällen können die Bewegungssteuerbefehle vom virtuellen Fahrzeugführersystem 105 (z. B. von der autonomen Fahrzeugsteuerung 120) erzeugt werden und an die Aktuatoren 135 der automatisierten Fahrzeugplattform 110 entweder direkt von der autonomen Fahrzeugsteuerung 120 oder über die MRC-Steuerung 115 ausgegeben werden.
Wie dargestellt, beinhaltet die MRC-Steuerung 115 (oder hat ansonsten Zugang zu) einen (einem) Speicher 140 und einen (einem) Prozessor 145. Der Speicher 140 ist mittels Schaltkreise, Chips oder anderer elektronischer Komponenten ausgeführt und kann einen oder mehrere Nur-Lese-Speicher (ROM), Random-Access Memory (RAM), Flash-Speicher, elektrisch programmierbare Speicher (EPROM), elektrisch programmierbare und löschbare Speicher (EEPROM), Embedded Multimedia Card (eMMC), eine Festplatte oder beliebige flüchtige oder nichtflüchtige Medien usw. beinhalten. Der Speicher 140 kann Anweisungen, die vom Prozessor 145 der MRC-Steuerung 115 ausgeführt werden, und Daten, wie beispielsweise Tabellen, die verschiedenartige Systemfehler verschiedenartigen MRC-Ereignissen zuordnen, und Logik, um zwischen verschiedenen empfohlenen MRC-Ereignissen zu vermitteln, speichern. Die Anweisungen und Daten, die im Speicher 140 gespeichert sind, können für den Prozessor 145 und möglicherweise andere Komponenten des Host-Fahrzeugs 100 zugänglich sein.
Der Prozessor 145 der MRC-Steuerung 115 ist mittels Schaltkreise, Chips oder anderer elektronischer Komponenten ausgeführt und kann eine oder mehrere Mikrosteuerungen, einen oder mehrere feldprogrammierbare Gate-Arrays (field programmable gate arrays - FPGAs), einen oder mehrere anwendungsspezifische integrierte Schaltkreise (application specific integrated circuits - ASICs), einen oder mehrere digitale Signalprozessoren (digital signal processors - DSPs), einen oder mehrere kundenspezifische integrierte Schaltkreise usw. beinhalten. Der Prozessor 145 ist programmiert, um empfohlene MRC-Ereignisse zu empfangen und zwischen verschiedenen empfohlenen MRC-Ereignissen durch Auswählen eines der empfohlenen MRC-Ereignisse oder möglicherweise eines verschiedenen MRC-Ereignisses zu vermitteln. Beispielsweise ist der Prozessor 145 programmiert, um eine erste MRC-Ereignisempfehlung, die von einer der Plattformsteuerungen 130 ausgegeben wurde, und eine zweite MRC-Ereignisempfehlung, die von einer weiteren der Plattformsteuerungen 130 ausgegeben wurde, zu empfangen. Der Prozessor 145 ist programmiert, um das MRC-Ereignis aus der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung auszuwählen, z. B. durch Auswählen des empfohlenen MRC-Ereignisses, das mit dem schwerwiegendsten Systemfehler assoziiert ist.
Der Prozessor 145 kann ferner programmiert sein, um ein verschiedenes MRC-Ereignis auszuwählen, wie beispielsweise ein MRC-Ereignis, das schwerwiegender als das empfohlene MRC-Ereignis ist, bei Erfassung eines Fehlers, der nicht durch das empfohlene MRC-Ereignis repräsentiert wird. In diesem Fall ist der Prozessor 145 programmiert, um Fehler, die ansonsten nicht durch eine der Plattformsteuerungen 130 erfasst werden würden, zu erfassen und um beispielsweise eine dritte MRC-Ereignisempfehlung als ein Ergebnis der Erfassung dieser Art von Fehlern zu erzeugen. Solche Fehler, die von der MRC-Steuerung 115 erfasst werden können, können z. B. Fehler eines oder mehrerer der Sensoren 125, Fehler der autonomen Fahrzeugsteuerung 120 usw. beinhalten. Der Prozessor 145 ist programmiert, um die dritte MRC-Ereignisempfehlung (d. h. das mit dem Fehler des Sensors 125 assoziierte MRC-Ereignis) auszuwählen, wenn der Fehler des Sensors 125 ein schwerwiegenderes MRC-Ereignis als die erste und zweite MRC-Ereignisempfehlung rechtfertigt. Der Prozessor 145 ist programmiert, um die Tabelle, die im Speicher 140 für das mit dem Fehler des Sensors 125 assoziierte MRC-Ereignis gespeichert ist, zu konsultieren.
3 ist ein Ablaufdiagramm eines beispielhaften Prozesses 300, der von einer oder mehreren Komponenten des Host-Fahrzeugs 100 ausgeführt werden kann, um eine dezentralisierte MRC-Steuerung auszuführen. Der Prozess 300 kann jederzeit anfangen, während das Host-Fahrzeug 100 in einem autonomen oder teilautonomen Betriebsmodus betrieben wird.
Im Block 305 empfängt die MRC-Steuerung 115 von jeder der Plattformsteuerungen 130 MRC-Ereignisempfehlungen (z. B. die oben besprochene erste und zweite MRC-Ereignisempfehlung). Die MRC-Steuerung 115 kann MRC-Empfehlungen von jeder der Plattformsteuerungen 130 über einen Kommunikationsbus empfangen. Jede Plattformsteuerung 130 kann eine MRC-Ereignisempfehlung als ein Ergebnis der Plattformsteuerung 130, die einen Fahrzeugsystemfehler erfasst, erzeugen. In einigen Fällen kann, selbst wenn kein Fehler erfasst wurde, die Plattformsteuerung 130 ein MRC-Ereignis empfehlen, das empfiehlt, dass das Host-Fahrzeug 100 seinen Auftrag vollendet (d. h. an seinen Zielort fährt). Die MRC-Ereignisempfehlung kann mit einem bestimmten Systemfehler in z. B. einer Tabelle, die im Speicher 140 gespeichert ist, korrelieren, und die Plattformsteuerungen 130 können das MRC-Ereignis durch Befragen der Tabelle nach dem mit dem Systemfehler assoziierten MRC-Ereignis empfehlen und das empfohlene MRC-Ereignis an die MRC-Steuerung 115 übertragen.
Im Entscheidungsblock 310 bestimmt die MRC-Steuerung 115, ob sie weitere Systemfehler erfasst hat. Die MRC-Steuerung 115 sucht sozusagen nach Systemfehlern, die nicht von irgendeiner der Plattformsteuerungen 130 erfasst werden würden, die aber von der MRC-Steuerung 115 erfasst werden können. Beispielsweise kann die MRC-Steuerung 115 feststellen, ob irgendeiner der Sensoren 125 versagt hat. Wenn die MRC-Steuerung 115 feststellt, dass mindestens ein Sensor 125 versagt hat, oder wenn es weitere nicht nachgewiesene Systemfehler gibt, kann der Prozess 300 mit Block 315 fortfahren. Wenn die MRC-Steuerung 115 feststellt, dass es keine weiteren nicht nachgewiesenen Fehler gibt, kann der Prozess 300 mit Block 320 fortfahren.
Im Block 315 empfiehlt die MRC-Steuerung 115 ein MRC-Ereignis auf der Basis von den Fehlern, die im Entscheidungsblock 310 erfasst wurden. Wenn zum Beispiel die MRC-Steuerung 115 einen Fehler des Sensors 125 oder einen Fehler der autonomen Fahrzeugsteuerung 120 identifiziert, kann die MRC-Steuerung 115 eine MRC-Ereignisempfehlung (z. B. die dritte MRC-Ereignisempfehlung) gemäß dem Fehler des Sensors 125 erzeugen. Die MRC-Ereignisempfehlung kann sozusagen mit einem bestimmten Systemfehler in z. B. einer Tabelle, die im Speicher 140 gespeichert ist, korrelieren. Die MRC-Steuerung 115 kann das MRC-Ereignis, das mit dem Fehler des Sensors 125 assoziiert ist, durch Befragen der Tabelle empfehlen.
Im Block 320 wählt die MRC-Steuerung 115 eins der empfohlenen MRC-Ereignisse aus. Die empfohlenen MRC-Ereignisse beinhalten gegebenenfalls jene, die im Block 305 und im Block 315 empfangen wurden. Die empfohlenen MRC-Ereignisse können somit die erste MRC-Ereignisempfehlung und die zweite MRC-Ereignisempfehlung beinhalten. Die MRC-Ereignisempfehlungen können ferner die dritte MRC-Ereignisempfehlung und möglicherweise andere beinhalten. In einer möglichen Vorgehensweise kann die MRC-Steuerung 115 programmiert sein, um das MRC-Ereignis, das mit der schwerwiegendsten vom Host-Fahrzeug 100 ergriffenen Maßnahme assoziiert ist, auszuwählen. Anders ausgedrückt kann jede MRC-Ereignisempfehlung mit einem Schweregrad assoziiert sein, und die MRC-Steuerung 115 kann programmiert sein, um das MRC-Ereignis mit dem höchsten Schweregrad auszuwählen. Beispielsweise kann, wenn die erste MRC-Ereignisempfehlung das sofortige Anhalten des Host-Fahrzeugs 100 am Straßenrand beinhaltet und die zweite MRC-Ereignisempfehlung das Anhalten des Fahrzeugs in seiner Fahrspur beinhaltet, die MRC-Steuerung 115 programmiert sein, die zweite MRC-Ereignisempfehlung auszuwählen, da sie eine schwerwiegender Maßnahme darstellt, die vom Host-Fahrzeug 100 ergriffen werden muss. Alternativ oder zusätzlich kann die MRC-Steuerung 115 programmiert sein, im Block 320 ein verschiedenes MRC-Ereignis (z. B. eine vierte MRC-Ereignisempfehlung) als jene, die in Blöcken 305 und 315 empfohlen wurden, auszuwählen, wenn z.B. der kumulierte Schweregrad der empfohlenen MRC-Ereignisse nahelegt, dass eine schwerwiegendere Maßnahme als die von den empfohlenen MRC-Ereignissen reflektierten Maßnahmen ergriffen werden sollte.
Im Block 325 erzeugt die MRC-Steuerung 115 Bewegungssteuersignale. Die Bewegungssteuersignale können die automatisierte Fahrzeugplattform 110 dazu veranlassen, das Host-Fahrzeug 100 autonom zu betreiben, um das ausgewählte MRC-Ereignis auszuführen. In einigen Fällen könnte die MRC-Steuerung 115 nicht die Bewegungssteuersignale erzeugen. Stattdessen können die Bewegungssteuersignale vom virtuellen Fahrzeugführersystem 105 erzeugt werden. In diesem Fall kann die MRC-Steuerung 115 das ausgewählte MRC-Ereignis an das virtuelle Fahrzeugführersystem 105 kommunizieren, und das virtuelle Fahrzeugführersystem 105 kann die Bewegungssteuersignale als ein Ergebnis des Empfangens des ausgewählten MRC-Ereignisses erzeugen.
Im Block 330 gibt die MRC-Steuerung 115 die Bewegungssteuersignale aus, um das Host-Fahrzeug 100 gemäß dem ausgewählten MRC-Ereignis zu steuern. Das Bewegungssteuersignal kann an eine oder mehrere Plattformsteuerungen 130 ausgegeben werden, wie beispielsweise an die Antriebsstrangsteuerung und die Chassis-Steuerung. Die Plattformsteuerungen 130, die die Bewegungssteuersignale empfangen, könnten nicht dieselbe Plattformsteuerung 130 sein, die die MRC-Ereignisempfehlung, die letztendlich im Block 320 ausgewählt wurde, bereitstellt. Die Plattformsteuerungen 130 können als ein Ergebnis des Empfangens der Bewegungssteuersignale verschiedene Aktuatoren 135 aktivieren, um das ausgewählte MRC-Ereignis auszuführen. Ferner kann in einigen Fällen die MRC-Steuerung 115 Bewegungssteuersignale an eine oder mehrere der Plattformsteuerungen 130 bereitstellen, ungeachtet dessen, ob die MRC-Steuerung 115 oder das virtuelle Fahrzeugführersystem 105 die Bewegungssteuersignale im Block 325 erzeugt haben. Alternativ oder zusätzlich kann das virtuelle Fahrzeugführersystem 105 einige oder alle der Bewegungssteuersignale direkt an die entsprechende Plattformsteuerung 130 bereitstellen.
Im Allgemeinen können die beschriebenen Rechensysteme und/oder -vorrichtungen ein beliebiges einer Reihe von Computerbetriebssystemen einsetzen, einschließlich, jedoch in keiner Weise beschränkt auf Versionen und/oder Varianten der SYNC® Anwendung von Ford, AppLink/Smart Device Link Middleware, des Betriebssystems Microsoft Automotive®, des Betriebssystems Microsoft Windows®, des Betriebssystems Unix (z. B. das Betriebssystem Solaris®, vertrieben durch die Oracle Corporation in Redwood Shores, Kalifornien), des Betriebssystems AIX UNIX, vertrieben durch International Business Machines in Armonk, New York, des Betriebssystems Linux, der Betriebssysteme Mac OSX und iOS, vertrieben durch die Apple Inc. in Cupertino, Kalifornien, BlackBerry OS, vertrieben durch Blackberry, Ltd. in Waterloo, Kanada, und des Betriebssystems Android, entwickelt von Google, Inc. und der Open Handset Alliance, oder der Plattform QNX® CAR für Infotainment, angeboten von QNX Software Systems. Beispiele für Rechenvorrichtungen beinhalten, ohne Beschränkung darauf, einen Bord-Fahrzeugcomputer, eine Computer-Workstation, einen Server, einen Desktop-, Notebook-, Laptop- oder Handheld-Computer oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung.
Rechenvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen von einer oder mehreren Rechenvorrichtungen, wie beispielsweise den oben aufgelisteten, ausführbar sein können. Computerausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -technologien erstellt werden, einschließlich, ohne Beschränkung darauf, und entweder alleine oder in Kombination, Java™, C, C++, Visual Basic, Java Script, Perl usw. Einige dieser Anwendungen können auf einer virtuellen Maschine, wie beispielsweise der Java Virtual Machine, der virtuellen Maschine Dalvik oder dergleichen, kompiliert und ausgeführt werden. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, zum Beispiel von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wobei dabei ein oder mehrere Prozesse ausgeführt werden, einschließlich eines oder mehrerer der vorliegend beschriebenen Prozesse. Derartige Anweisungen und anderen Daten können unter Verwendung einer Vielfalt von computerlesbaren Medien gespeichert und übertragen werden.
Ein computerlesbares Medium (auch ein prozessorlesbares Medium genannt) weist ein beliebiges nichtflüchtiges (z. B. greifbares) Medium auf, das an einer Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von einem Prozessor eines Computers) gelesen werden können. Ein derartiges Medium kann viele Formen annehmen, einschließlich, aber ohne Beschränkung darauf, nichtflüchtige Medien und flüchtige Medien. Nichtflüchtige Medien können zum Beispiel optische oder magnetische Speicherplatten und andere persistente Speicher beinhalten. Flüchtige Medien können zum Beispiel einen dynamischen Speicher mit wahlfreiem Zugriff (dynamic random access memory - DRAM), der typischerweise einen Hauptspeicher bildet, beinhalten. Derartige Anweisungen können durch ein oder mehrere Übertragungsmedien übertragen werden, einschließlich Koaxialkabeln, Kupferdraht und Faseroptik, einschließlich der Drähte, die einen an einen Prozessor eines Computers gekoppelten Systembus umfassen. Übliche Formen computerlesbarer Medien beinhalten zum Beispiel eine Floppy Disk, eine Diskette, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physikalisches Medium mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EEPROM, ein beliebiger anderer Speicherchip, eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium, das ein Computer lesen kann.
Hierin beschriebene Datenbanken, Datenbestände oder sonstigen Datenspeicher können verschiedene Arten von Mechanismen zum Speichern von, Zugreifen auf und Abrufen von verschiedenen Arten von Daten beinhalten, einschließlich einer hierarchischen Datenbank, einem Datensatz in einem Dateisystem, einer Anwendungsdatenbank in einem proprietären Format, einem relationalen Datenbankverwaltungssystem (Relational Database Management System, RDBMS) usw. Jeder dieser Datenspeicher ist im Allgemeinen in eine Rechenvorrichtung eingeschlossen, die ein Computerbetriebssystem, wie beispielsweise eines der vorstehend erwähnten, einsetzt, und es wird auf eine oder mehrere verschiedenste Arten über ein Netzwerk darauf zugegriffen. Auf ein Dateisystem kann von einem Computerbetriebssystem zugegriffen werden, und es kann in unterschiedlichen Formaten gespeicherte Dateien beinhalten. Ein RDBMS setzt im Allgemeinen die strukturierte Abfragesprache (Structured Query Language - SQL) zusätzlich zu einer Sprache zum Erstellen, Speichern, Bearbeiten und Ausführen gespeicherter Abläufe ein, wie etwa die vorstehend erwähnte PL/SQL-Sprache.
In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Servern, PCs usw.) ausgeführt sein, gespeichert auf damit verbundenen computerlesbaren Medien (z. B. Platten, Speichern usw.). Ein Computerprogrammprodukt kann solche auf computerlesbaren Medien gespeicherte Anweisungen zum Ausführen der hierin beschriebenen Funktionen umfassen.
In Bezug auf die Prozesse, Systeme, Verfahren, Heuristiken usw., die hier beschrieben sind, versteht es sich, dass, auch wenn die Schritte solcher Prozesse usw. als gemäß einer bestimmten Ordnungsabfolge ablaufend beschrieben wurden, diese Prozesse mit den beschriebenen Schritten auch in einer anderen Reihenfolge als der hier beschriebenen ausgeführt werden können. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig ausgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass bestimmte hier beschriebene Schritte ausgelassen werden könnten. Anders ausgedrückt werden die Beschreibungen von Prozessen hier lediglich zum Zweck der Veranschaulichung bestimmter Ausführungsformen bereitgestellt, und sie sind in keiner Weise als Einschränkung der Patentansprüche auszulegen.
Entsprechend versteht es sich, dass die vorstehende Beschreibung lediglich veranschaulichend und nicht einschränkend sein soll. Zahlreiche andere Ausführungsformen und Anwendungen als die bereitgestellten Beispiele werden beim Lesen der vorstehenden Beschreibung offensichtlich. Der Schutzumfang soll nicht bezogen auf die vorstehende Beschreibung bestimmt werden, sondern soll stattdessen unter Bezugnahme auf die beigefügten Patentansprüche zusammen mit dem vollen Schutzumfang von Äquivalenten, denen derartige Schutzansprüche zustehen, bestimmt werden. Es ist vorauszusehen und beabsichtigt, dass zukünftige Entwicklungen in den hierin erörterten Technologien erfolgen werden und dass die offenbarten Systeme und Verfahren in solche zukünftigen Ausführungsformen einbezogen werden. Zusammengefasst versteht es sich, dass die Anwendung modifizierbar und abwandlungsfähig ist.
Es ist beabsichtigt, dass sämtlichen Begriffen, die in den Ansprüchen verwendet werden, ihre gebräuchlichen Bedeutungen verliehen werden, die für die Fachleute auf dem Gebiet der hierin beschriebenen Technologien nachvollziehbar sind, sofern es hier nicht ausdrücklich anders angegeben wird. Insbesondere sollte die Verwendung der Artikel in der Einzahl, wie „ein/eine/einer“, „der/die/das“, „besagtes“ usw. als ein oder mehrere der angezeigten Elemente aufführend gelesen werden, sofern ein Anspruch keine ausdrückliche gegensätzliche Begrenzung aufführt.
Die Zusammenfassung ist bereitgestellt, um dem Leser eine schnelle Bestimmung der Beschaffenheit der technischen Offenbarung zu ermöglichen. Sie wird mit dem Verständnis unterbreitet, dass sie nicht zur Interpretation oder Begrenzung des Schutzumfangs oder der Bedeutung der Ansprüche verwendet wird. Darüber hinaus kann in der vorhergehenden Detaillierten Beschreibung gesehen werden, dass verschiedene Merkmale zum Zwecke der Straffung der Offenbarung in verschiedenen Ausführungsformen zusammengruppiert werden. Diese Vorgehensweise der Offenbarung ist nicht als eine Absicht widerspiegelnd aufzufassen, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als die ausdrücklich in jedem Anspruch angeführt sind. Wie die nachfolgenden Ansprüche widerspiegeln, ist der erfindungsgemäße Gegenstand stattdessen in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform begründet. Die folgenden Ansprüche werden also hiermit in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich als separat beanspruchter Gegenstand steht.
Gemäß der vorliegenden Erfindung ist ein Fahrzeugcomputer bereitgestellt, der einen Speicher und einen Prozessor, der programmiert ist, im Speicher gespeicherte Anweisungen auszuführen, aufweist, wobei die Anweisungen beinhalten: Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung, Empfangen einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung, Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis und Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um die erste und zweite MRC-Ereignisempfehlung als ein Ergebnis der jeweiligen ersten und zweiten Plattformsteuerung, die jeweils einen Fahrzeugsystemfehler erfasst, zu empfangen, wobei sich der Fahrzeugsystemfehler, der von der ersten Plattformsteuerung erfasst wird, vom Fahrzeugsystemfehler, der von der zweiten Plattformsteuerung erfasst wird, unterscheidet.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um eine dritte MRC-Ereignisempfehlung zu erzeugen, wobei das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung beinhaltet.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um die dritte MRC-Ereignisempfehlung als ein Ergebnis der Erfassung eines mit einem virtuellen Fahrzeugführersystem assoziierten Fehlers zu erzeugen.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um das autonome Host-Fahrzeug gemäß dem ausgewählten MRC-Ereignis durch Ausgabe von Bewegungssteuersignalen an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und einer dritten Plattformsteuerung zu steuern.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um die Bewegungssteuersignale von einer autonomen Fahrzeugsteuerung zu empfangen und die Bewegungssteuersignale an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und der dritten Plattformsteuerung auszugeben.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um eine der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf Grundlage eines mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrads und eines mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrads auszuwählen, wobei sich die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen und wobei der Prozessor programmiert ist, um die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen.
Gemäß einer Ausführungsform ist der Prozessor programmiert, um eine vierte MRC-Ereignisempfehlung auf Grundlage eines kumulierten Schweregrads der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung auszuwählen, wobei sich die vierte MRC-Ereignisempfehlung von der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheidet.
Gemäß der vorliegenden Erfindung ist ein Fahrzeugsystem bereitgestellt, aufweisend eine erste Plattformsteuerung, die programmiert ist, um eine erste MRC-Ereignisempfehlung auszugeben, eine zweite Plattformsteuerung, die programmiert ist, um eine zweite MRC-Ereignisempfehlung auszugeben, und eine Steuerung der minimalen Risikobedingung (MRC), die programmiert ist, um die erste MRC-Ereignisempfehlung und die zweite MRC-Ereignisempfehlung zu empfangen, um eine der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis auszuwählen und um ein autonomes Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis zu steuern.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um die erste und zweite MRC-Ereignisempfehlung als ein Ergebnis der jeweiligen ersten und zweiten Plattformsteuerung, die jeweils einen Systemfehler erfasst, zu empfangen, wobei sich der Systemfehler, der von der ersten Plattformsteuerung erfasst wird, vom Systemfehler, der von der zweiten Plattformsteuerung erfasst wird, unterscheidet.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um eine dritte MRC-Ereignisempfehlung als ein Ergebnis der MRC-Steuerung, die einen Fahrzeugsensorfehler erfasst, zu erzeugen, wobei das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung beinhaltet.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um das autonome Host-Fahrzeug gemäß dem ausgewählten MRC-Ereignis durch Ausgabe von Bewegungssteuersignalen an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und einer dritten Plattformsteuerung zu steuern.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um die Bewegungssteuersignale von einer autonomen Fahrzeugsteuerung zu empfangen und die Bewegungssteuersignale an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und der dritten Plattformsteuerung auszugeben.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um eine der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf Grundlage eines mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrads und eines mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrads auszuwählen, wobei sich die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen.
Gemäß einer Ausführungsform ist die MRC-Steuerung programmiert, um die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen.
Gemäß der vorliegenden Erfindung umfasst ein Verfahren: Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung, Empfangen einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung, Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis und Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.
Gemäß einer Ausführungsform ist die Erfindung ferner durch das Erzeugen einer dritten MRC-Ereignisempfehlung gekennzeichnet, wobei das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung beinhaltet.
Gemäß einer Ausführungsform basiert das Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf einem mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrad und auf einem mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrad, wobei sich die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden, wobei die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, ausgewählt ist und wobei die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, ausgewählt ist.

Claims

Fahrzeugcomputer, umfassend: einen Speicher; und einen Prozessor, der programmiert ist, um im Speicher gespeicherte Anweisungen auszuführen, die Anweisungen beinhaltend: Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung und einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung; Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis; und Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.
Fahrzeugcomputer nach Anspruch 1, wobei der Prozessor programmiert ist, um die erste und zweite MRC-Ereignisempfehlung als ein Ergebnis der jeweiligen ersten und zweiten Plattformsteuerung, die jeweils einen Fahrzeugsystemfehler erfasst, zu empfangen, wobei sich der Fahrzeugsystemfehler, der von der ersten Plattformsteuerung erfasst wird, vom Fahrzeugsystemfehler, der von der zweiten Plattformsteuerung erfasst wird, unterscheidet.
Fahrzeugcomputer nach Anspruch 1, wobei der Prozessor programmiert ist, um eine dritte MRC-Ereignisempfehlung zu erzeugen, wobei das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung beinhaltet.
Fahrzeugcomputer nach Anspruch 3, wobei der Prozessor programmiert ist, um die dritte MRC-Ereignisempfehlung als ein Ergebnis der Erfassung eines Fahrzeugsensorfehlers durch den Prozessor zu erzeugen.
Fahrzeugcomputer nach Ansprüchen 1, 2 oder 3, wobei der Prozessor programmiert ist, um das autonome Host-Fahrzeug gemäß dem ausgewählten MRC-Ereignis durch Ausgabe von Bewegungssteuersignalen an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und einer dritten Plattformsteuerung zu steuern.
Fahrzeugcomputer nach Anspruch 5, wobei der Prozessor programmiert ist, um die Bewegungssteuersignale von einer autonomen Fahrzeugsteuerung zu empfangen und die Bewegungssteuersignale an mindestens eine der ersten Plattformsteuerung, der zweiten Plattformsteuerung und der dritten Plattformsteuerung auszugeben.
Fahrzeugcomputer nach Ansprüchen 1, 2 oder 3, wobei der Prozessor programmiert ist, um eine der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf Grundlage eines mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrads und eines mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrads auszuwählen, wobei sich die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden.
Fahrzeugcomputer nach Anspruch 7, wobei der Prozessor programmiert ist, um die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen und wobei der Prozessor programmiert ist, um die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, auszuwählen.
Fahrzeugcomputer nach Ansprüchen 1, 2 oder 3, wobei der Prozessor programmiert ist, um eine vierte MRC-Ereignisempfehlung auf Grundlage eines kumulierten Schweregrads der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung auszuwählen, wobei sich die vierte MRC-Ereignisempfehlung von der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheidet.
Verfahren, umfassend: Empfangen einer ersten Empfehlung eines Ereignisses der minimalen Risikobedingung (MRC) von einer ersten Plattformsteuerung; Empfangen einer zweiten MRC-Ereignisempfehlung von einer zweiten Plattformsteuerung; Auswählen einer der ersten und zweiten MRC-Ereignisempfehlung als ein ausgewähltes MRC-Ereignis; und Steuern eines autonomen Host-Fahrzeugs gemäß dem ausgewählten MRC-Ereignis.
Verfahren nach Anspruch 10, ferner umfassend das Erzeugen einer dritten MRC-Ereignisempfehlung, wobei das Auswählen des ausgewählten MRC-Ereignisses das Auswählen aus der ersten, zweiten und dritten MRC-Ereignisempfehlung beinhaltet.
Verfahren nach Anspruch 11, wobei das Auswählen der ersten und zweiten MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis auf einem mit der ersten MRC-Ereignisempfehlung assoziierten Schweregrad und einem mit der zweiten MRC-Ereignisempfehlung assoziierten Schweregrad basiert, wobei sich die Schweregrade der ersten MRC-Ereignisempfehlung und der zweiten MRC-Ereignisempfehlung unterscheiden, wobei die erste MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad, ausgewählt ist, und wobei die zweite MRC-Ereignisempfehlung als das ausgewählte MRC-Ereignis als ein Ergebnis der Feststellung, dass der mit der zweiten MRC-Ereignisempfehlung assoziierte Schweregrad höher ist als der mit der ersten MRC-Ereignisempfehlung assoziierte Schweregrad, ausgewählt ist.
Verfahren nach einem der Ansprüche 10-12, durchgeführt von einem Fahrzeugcomputer.