DE102017118537A1

DE102017118537A1 - Verwaltung von Störungszuständen autonomer Fahrzeuge

Info

Publication number: DE102017118537A1
Application number: DE102017118537.2A
Authority: DE
Inventors: John P. Joyce; Scott J. Lauffer; Samer Abbas
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-08-15
Filing date: 2017-08-14
Publication date: 2018-02-15
Also published as: CN107757525B; GB201712796D0; US20180046182A1; GB2553668A; MX2017010182A; US10571908B2; RU2017128415A; CN107757525A

Abstract

Ein erster Computer, einschließend einen Prozessor, ist programmiert, um eine Anzeige eines Störungszustands in einem Fahrzeug zu empfangen und die Anzeige des Störungszustands drahtlos zu einem entfernten Server zu übertragen. Der Computer ist ferner programmiert, um eine überarbeitete Route zu einem Ziel, zumindest teilweise auf Grundlage des Störungszustands zu empfangen und das Fahrzeug entlang der überarbeiteten Route zu betreiben.

Description

ALLGEMEINER STAND DER TECHNIK
Störungszustände für autonome Fahrzeuge sind mit unterschiedlichen Risikoniveaus dafür verknüpft, dass der Störungszustand zu einem unerwünschten Ergebnis, wie etwa einer Kollision oder einer Fahrzeugpanne, führt. Einige Störungszustände machen es erforderlich, dass das Fahrzeug umgehend von der Straße abfährt, um das Risiko zu minimieren. In anderen Fällen stellt ein Störungszustand kein unmittelbares Risiko dar und das Fahrzeug kann fortfahren. Das Analysieren des Risikoniveaus, das mit einem Störungszustand verknüpft ist, das Identifizieren von Alternativen zum Verwalten des Störungszustands und das Beurteilen eines Risikos, das mit jeder der Alternativen verknüpft ist, machen eine wesentliche Menge an Rechenleistung und Daten erforderlich. Zusätzlich ändern sich einige Daten, wie etwa Wetterdaten, Verkehrsdaten und die Verfügbarkeit von Ressourcen kontinuierlich. Es ist nicht zwangsläufig praktikabel, die Rechenleistung oder die Daten für jedes Fahrzeug, das einen Störungszustand verwalten muss, zeitnah bereitzustellen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Schema eines beispielhaften Systems zum Verwalten von Störungszuständen autonomer Fahrzeuge.
2A und 2B sind ein Schema eines beispielhaften Prozesses zum Verwalten von Störungszuständen autonomer Fahrzeuge.
BESCHREIBUNG
EINLEITUNG
Ein System 10 zum Verwalten von Störungszuständen in einem autonomen Fahrzeug 12 mit einem entfernten Server 14 wird in 1 gezeigt. Das System 10 schließt das Fahrzeug 12, den Server 14 und eine oder mehrere Datenquellen 16 ein. Das Netzwerk 18 stellt Kommunikationen zwischen dem Fahrzeug 12, dem Server 14 den Datenquellen 16 bereit.
Das Fahrzeug 12 kann ein autonomes oder halbautonomes Fahrzeug 12 sein und schließt einen Computer 20 ein. Der Computer 20 ist im Allgemeinen programmiert, um das Fahrzeug 12 zu steuern, und auch, um dem Fahrzeug 12 über das Netzwerk 18 hierin zugeschriebene Kommunikation bereitzustellen. Der Computer 20 bestimmt eine Route für das Fahrzeug 12 auf Grundlage von Zielinformationen und erzeugt Anweisungen zum Fahren des Fahrzeugs 12 entlang der Route unter Verwendung von Methoden zum Steuern von autonomen Fahrzeugen, die bekannt sind.
Der Computer 20 des Fahrzeugs 12 ist programmiert, um vor, während und/oder nach dem Betrieb ein oder mehrere betriebene Teilsysteme des Fahrzeugs 12 zu überwachen und das Auftreten von einem oder mehreren Störungszuständen zu bestimmen. Das Überwachen kann fahrzeugeigene Diagnoseeinrichtungen (OBD) des Fahrzeugs einschließen, die bekannt sind.
Für den Fall, dass das Fahrzeug 12 bestimmt, dass ein Störungszustand aufgetreten ist, kann der Computer 20 des Fahrzeugs 12 den Störungszustand und Daten in Bezug auf den Betrieb des Fahrzeugs 12 drahtlos zu dem entfernten Server 14 übertragen. Die Daten für den Störungszustand können einen Diagnose-Fehlercode (DTC) für das Fahrzeug 12 einschließen, der bekannt ist. Der DTC kann spezifische Informationen darüber bereitstellen, welche betriebenen Teilsysteme in dem Fahrzeug 12 den Störungszustand zeigten und unter welchen Bedingungen. Der Computer 20 des Fahrzeugs 12 kann ferner ein Risiko bestimmen, das mit dem Störungszustand verknüpft ist und das bestimmte Risiko des Störungscodes zu dem entfernten Server 14 übertragen. Das Risiko, das mit einem Störungszustand verknüpft ist, wie hierin verwendet, steht für eine Wahrscheinlichkeit dafür, dass der Störungszustand zu einer Kollision oder einer Fahrzeugpanne führen kann.
Der Server 14 empfängt den Störungszustand und Betriebsdaten von dem Computer 20 des Fahrzeugs 12. Zusätzlich kann der Server 14 Daten in Bezug auf Betriebsbedingungen des Fahrzeugs 12 erfassen. In einigen Fällen kann der Server 14 die zusätzlichen Daten von Quellen erfassen, die sich von dem Computer 20 des Fahrzeugs 12 unterscheiden, zum Beispiel von einem Speicher, der mit dem Server 14 verknüpft ist oder den Datenquellen 16.
Der Server 14 schließt eine HMI 36 ein, die der HMI 26 ähnelt, die in Bezug auf das Fahrzeug 12 beschrieben wird. Die HMI 36 des Servers 14 ist programmiert, um Daten von einem Benutzer bereitzustellen und von diesem zu empfangen. Der Benutzer kann ein Bediener des Servers 14 sein.
Die Datenquellen 16 können zum Beispiel Dienste, wie etwa Dienste zur Datenerfassung und -analyse, Wetterberichtsdienste, Verkehrsmeldungsdienste, Kartendienste, ein Datendienst, der mit dem Hersteller des Fahrzeugs 12 verknüpft ist usw., sein. Die zusätzlichen Daten können zum Beispiel Daten in Bezug auf den bestimmten Störungszustand für den bestimmten Typ des Fahrzeugs 12 einschließen. Die zusätzlichen Informationen können ferner Verkehrsbedingungen, Wetterbedingungen usw. entlang der geplanten Route sein. Die zusätzlichen Daten können ferner alternative Routen zu dem Ziel und Verkehrs- und Wetterbedingungen entlang der alternativen Routen einschließen.
Zum Beispiel können die Daten entsprechende Häufigkeiten von einem oder mehreren Störungszuständen für einen Typ (z. B. Marke, Modell, Jahr) des Fahrzeugs 12 einschließen. Zum Beispiel kann eine Häufigkeit eines Störungszustands für einen bestimmten Störungszustand für einen bestimmten Typ eines Fahrzeugs 1 Störung aller 300.000 gefahrenen Meilen (ca. 482.803 km) entsprechen.
Ferner können die Daten Gewichtungsfaktoren einschließen, die Abhängigkeiten von Störungszuständen in Bezug auf Umgebungsbedingungen, wie etwa Niederschläge, die Umgebungstemperatur, die Verkehrsdichte, das Alter von Komponenten in einem Back-up-System usw., anzeigen. Zum Beispiel kann eine Wahrscheinlichkeit für eine Störung einer bestimmten Komponente zunehmen, wenn die Umgebungstemperatur hoch ist und kann ferner zunehmen, wenn das Verkehrsaufkommen hoch ist, was dazu führt, dass das Fahrzeug für längere Zeiträume bei großer Wärme stillsteht.
Auf Grundlage der Daten, die von dem Fahrzeug 12 empfangen werden und der zusätzlichen Daten, kann der Server 14 ein Risiko bestimmen, das mit dem Fortfahren zu dem Ziel verknüpft ist. Zum Beispiel auf Grundlage des Risikos, das innerhalb eines Risikobereichs liegt, überträgt der Server 14 drahtlos eine Anweisung zu dem Fahrzeug 12, um zu dem Ziel fortzufahren. Der Bereich kann als ein Risiko unterhalb eines Schwellenwerts definiert sein. Ferner kann der Server 14 bestimmen, dass durch das Einhalten einer alternativen Route das Risiko verringert werden kann und das Fahrzeug 12 anweisen, zu dem Ziel entlang der alternativen Route fortzufahren.
In einigen Fällen kann der Computer 20 des Fahrzeugs 12 vor dem Übertragen des Störungszustands und von Betriebsdaten zu dem entfernten Server 14 den Störungszustand beurteilen und eine anfängliche Bestimmung des Risikos treffen, das mit dem Störungszustand verknüpft ist. In einem Fall dafür, dass das Risiko, das mit dem Störungszustand verknüpft ist, unter einem ersten Schwellenwert liegt, kann der Computer 20 den Störungszustand zusammen mit dem Risiko, das mit den Daten für den Störungszustand verknüpft ist, zu dem Server 14 übertragen. Der Computer 20 kann ferner eine Autorisierung von dem Server 14 anfordern, um zu dem Ziel fortzufahren.
Für den Fall, dass das Risiko, das mit dem Störungszustand verknüpft ist, z. B. größer als der Schwellenwert ist oder diesem entspricht, kann der Computer 20 des Fahrzeugs 12 das Fahrzeug 12 stoppen. Der Computer 20 kann ferner den Störungszustand und das Risiko, das mit dem Störungszustand verknüpft ist, zu dem Server 14 übertragen und kann Anweisungen für weitere Abhilfemaßnahmen anfordern.
Der Schwellenwert zum Beurteilen des Risikos, das mit dem Störungszustand verknüpft ist, kann durch den Server 14 auf Grundlage einer großen Anzahl von Faktoren bestimmt werden. Einige Störungszustände, wie etwa eine Bremse, die nicht funktioniert, eine Lenksteuerung, die nicht funktioniert usw., können bestimmt werden, um den Schwellenwert für das Risikoniveau unabhängig von anderen Faktoren zu überschreiten.
In einigen Fällen kann der Schwellenwert von mehreren Faktoren abhängen. Zum Beispiel kann der Computer 20, wenn bestimmt wird, dass ein Sensor in dem Fahrzeug 12 nicht funktioniert, bestimmen, ob Daten von anderen Sensoren verwendet werden können, um den nicht funktionierenden Sensor zu kompensieren. Für den Fall, dass Sensordaten von anderen Sensoren verfügbar sind, kann der Computer 20 z. B. bestimmen, dass bestimmte Wetterfaktoren die Daten von den anderen Sensoren weniger zuverlässig oder weniger genau werden lassen. In einem solchen Fall kann der Computer 20 z. B. ferner aktuelle Wetterbedingungen beurteilen, um ein Risikoniveau zu bestimmen, das mit dem Störungszustand verknüpft ist.
Für den Fall, dass das Risiko, das mit dem Störungszustand verknüpft ist, über dem Schwellenwert liegt, kann der Computer 20 des Fahrzeugs 12 drahtlos die Daten für den Störungszustand zu dem Server 14 übertragen. Der Server 14 kann Abhilfemaßnahmen bestimmen und zum Beispiel anfordern, dass ein Dienstfahrzeug zu der Stelle des Fahrzeugs 12 fortfährt.
Der Server 14 kann programmiert sein, um vor dem Übertragen einer Anweisung zu dem Fahrzeug 12 ein Dienstfahrzeug zu der Stelle des Fahrzeugs 12 zu schicken oder andere Maßnahmen zu ergreifen, um eine Autorisierung von einem Benutzer anzufordern. Zum Beispiel kann der Server 14 über die HMI 36 des Servers 14 eine Autorisierung von einem Benutzer des Servers 14 anfordern. Als ein anderes Beispiel kann der Server 14 über die HMI 26 des Fahrzeugs 12 eine Autorisierung von einem Benutzer des Fahrzeugs 12 anfordern. Als noch ein anderes Beispiel kann der Server 14 eine Anfrage zu einer entfernten Vorrichtung, wie etwa einer mobilen Vorrichtung, senden, um eine Autorisierung zu empfangen.
Nach dem Empfangen einer Autorisierung von einem Benutzer kann der Server 14 mit dem Übertragen der Anweisung zu dem Computer 20 des Fahrzeugs 12 fortfahren, das Dienstfahrzeug auffordern, zu der Stelle des Fahrzeugs 12 fortzufahren usw.
SYSTEMELEMENTE
Das Fahrzeug 12 ist im Allgemeinen ein landbasiertes Fahrzeug 12, das drei oder mehr Räder aufweist, z. B. ein Personenkraftwagen, ein Leicht-LKW usw. Das Fahrzeug schließt einen Computer 20, einen oder mehrere Sensoren 22, eine oder mehrere Steuerungen 24 und eine Mensch-Maschine-Schnittstelle (HMI) 26 ein. Der eine oder die mehreren Sensoren 22, die eine oder die mehreren Steuerungen 24 und die HMI 26 sind kommunikativ an den Computer 20 gekoppelt, wie nachfolgend beschrieben.
Der Computer 20 schließt einen Prozessor und einen Speicher ein. Der Speicher schließt eine oder mehrere Arten von computerlesbaren Medien und das Speichern von Anweisungen ein, die durch den Prozessor ausführbar sind, um verschiedene Vorgänge durchzuführen, einschließend die hierin offenbarten. Ferner kann der Computer 20 einen oder mehrere andere Computer einschließen und/oder kommunikativ daran gekoppelt sein, einschließend Fahrzeugkomponenten, wie etwa die Sensoren 22, die Steuerungen 24 und die HMI 26, die ebenso, wie bekannt ist, entsprechende Prozessoren und Speicher einschließen können. Kommunikationen können über einen Controller-Area-Network(CAN)-Bus oder Local-Interconnect-Network(LIN)-Bus, ein verdrahtetes und/oder drahtloses fahrzeuginternes Local Area Network (LAN) durchgeführt werden, z. B. unter Verwendung verdrahteter oder drahtloser Technologien, wie etwa Wi-Fi^®, Bluetooth^® usw., wie bekannt ist.
Die Sensoren 22 können programmiert sein, um Daten in Bezug auf das Fahrzeug 12 und die Umgebung zu erfassen, in der das erste Fahrzeug 12 betrieben wird. Beispielhalber und nicht einschränkend können die Sensoren 22 Höhenmesser, Kameras, LiDAR, Radar, Ultraschallsensoren, Infrarotsensoren, Drucksensoren, Beschleunigungsmesser, Gyroskope, Temperatursensoren, Drucksensoren, Hallsensoren, optische Sensoren, Spannungssensoren, Stromsensoren, mechanische Sensoren, wie etwa Schalter, usw. einschließen. Die Sensoren 22 können verwendet werden, um die Umgebung abzutasten, in der das Fahrzeug 12 betrieben wird, wie etwa Wetterbedingungen, die Neigung einer Straße, den Standort einer Straße, benachbarte Fahrzeuge usw. Die Sensoren 22 können ferner verwendet werden, um dynamische Daten des Fahrzeugs 12 zu erfassen, die sich auf den Betrieb des Fahrzeugs 12 beziehen, wie etwa die Geschwindigkeit, die Giergeschwindigkeit, der Lenkwinkel, die Motordrehzahl, der Bremsdruck, der Öldruck, das auf die Steuerungen 24 im Fahrzeug 12 angewandte Leistungsniveau, die Konnektivität zwischen Komponenten usw. Die Sensoren 22 können die Daten für den Computer 20 des Fahrzeugs 12 bereitstellen, welcher die Daten verwenden kann, um zu bestimmen, ob die Teilsysteme des Fahrzeugs 12 innerhalb vorher festgelegter Bereiche betrieben werden oder ob eines oder mehrere der Teilsysteme des Fahrzeugs 12 einen Störungszustand zeigen.
In einigen Fällen können die Sensoren 22 von dem Computer 20 verwendet werden, um diagnostische Tests, wie etwa fahrzeugeigene Diagnoseeinrichtungen (OBD), durchzuführen. Der Computer 20 kann zum Beispiel Anweisungen zu einer Steuerung 24 senden, um einen bestimmten Vorgang durchzuführen. Der Computer 20 kann dann die Sensoren 22 abfragen, die mit der Steuerung 24 verknüpft sind, um zu bestimmen, ob die Steuerung 24, die Anweisung ausgeführt hat und ob das erwartete Ergebnis eingetreten ist. Für den Fall, dass ein Störungszustand detektiert wird, kann der Computer 20 einen Diagnose-Fehlercode (DTC) erzeugen, der Informationen über den Störungszustand bereitstellt, wie etwa welches Teilsystem des Fahrzeugs 12 eine Störung aufweist und unter welchen Bedingungen.
Zum Beispiel kann der Computer 20 eine Bremssteuerung 24 anweisen, einen Bremsdruck in einer Bremsleitung um einen bekannten Betrag zu erhöhen. Ein Drucksensor 22 in der Bremsleitung kann den Druck in der Bremsleitung messen und den Druck dem Computer 20 melden. Der Computer 20 kann dann auf Grundlage des gemessenen Drucks bestimmen, ob z. B. der Druck in der Bremsleitung auf Grundlage der Anweisung zu der Steuerung 24 erhöht wurde.
Die eine oder die mehreren Steuerungen 24 für das Fahrzeug 12 können bekannte elektronische Steuereinheiten (ECUs) oder dergleichen einschließen, einschließend, als nicht einschränkende Beispiele, eine Motorsteuerung, eine Ventilsteuerung, eine Sitzsteuerung, eine Servolenkungssteuerung, eine Türverriegelungssteuerung, eine Türriegelsteuerung, eine Klimatisierung, eine Steuerung zum Verstellen der Spiegel, eine Sicherheitsgurtsteuerung, eine Bremssteuerung usw. Jede der Steuerungen 24 kann entsprechende Prozessoren und Speicher und ein oder mehrere Betätigungselemente einschließen. Die Steuerungen 24 können mit einem Kommunikationsbus eines Fahrzeugs 12 programmiert und verbunden sein, wie etwa einem Controller-Area-Network(CAN)-Bus oder Local-Interconnect-Network(LIN)-Bus, um Anweisungen von dem Computer 20 zu empfangen und Betätigungselemente auf Grundlage der Anweisungen zu steuern.
Zusätzlich können die Steuerungen 24 programmiert sein, um bei Bedarf diagnostische Tests (z. B. fahrzeugeigene Diagnoseeinrichtungen) durchzuführen, um Daten im Hinblick auf den Betrieb des Fahrzeugs 12 zu erfassen. Der Computer 20 des Fahrzeugs 12 kann die Daten verwenden, um zum Beispiel zu bestimmen, ob ein Störungszustand in dem Fahrzeug 12 vorliegt.
Die Mensch-Maschine-Schnittstelle (HMI) 26 des Fahrzeugs 12 ist, wie vorstehend beschrieben, auf bekannte Weise kommunikativ mit dem Computer 20 gekoppelt und schließt eine oder mehrere Ausgabevorrichtungen, wie etwa eine Anzeige, Lampen, Lautsprecher usw. ein, um einem Benutzer Daten zu kommunizieren. Die HMI 26 schließt ferner eine oder mehrere Eingabevorrichtungen, wie etwa eine Touchscreen-Anzeige, Schaltflächen, eine Maus, eine Tastatur, ein Mikrofon, eine Gestenerkennungsvorrichtung, Schalter usw. ein, um Eingaben vom Benutzer zu empfangen.
Die HMI 26 des Fahrzeugs 12 kann z. B. verwendet werden, um Eingaben von dem Benutzer zu empfangen, um ein Ziel für das Fahrzeug 12 auszuwählen oder Informationen im Hinblick auf eine Fahrt bereitzustellen, wie etwa die geplante Fahrtzeit, die Anzahl und Identität der Insassen usw.
Der Server 14 ist ein Computer, einschließend einen Prozessor und einen Speicher, wobei der Speicher Anweisungen speichert, die von dem Prozessor ausgeführt werden können. Der Server 14 kann über das Netzwerk 18 zu dem Computer 20 des Fahrzeugs 12 kommunizieren und kann ferner mit der einen oder den mehreren Datenquellen 16 kommunizieren.
Der Server 14 ist programmiert, um Daten für den Störungszustand und Daten für den Betriebszustand von dem Computer 20 des Fahrzeugs 12 zu empfangen. Der Server 14 kann zusätzlich Daten in Bezug auf das Fahrzeug 12 und/oder eine Fahrt für das Fahrzeug 12 von anderen Quellen, wie etwa den Datenquellen 16, erfassen.
Zum Beispiel kann der Server 14 Daten in Bezug auf den Störungszustand für das Fahrzeug 12 erfassen. Als ein Beispiel kann der Störungszustand eine Störung eines Raddrehzahlsensors sein. Der Server 14 kann bestimmen, dass alternative Verfahren zum Bestimmen der Raddrehzahl in dem Fahrzeug 12 verfügbar sind und dass das Risiko für eine Störung der alternativen Verfahren unter einem Schwellenwert liegt und demnach akzeptabel ist. Auf Grundlage dieser Bestimmung kann der Server 14 programmiert sein, um das Fahrzeug 12 zu autorisieren, um zu dem Ziel fortzufahren.
Als ein anderes Beispiel kann der Server 14 programmiert sein, um Zieldaten in Bezug auf das Fahrzeug 12 zu empfangen. Auf Grundlage des Ziels des Fahrzeugs 12 kann der Server 14 Kartendaten für den Bereich erfassen, durch den sich das Fahrzeug 12 bewegen wird. Der Server 14 kann auf Grundlage der Daten programmiert sein, um eine oder mehrere alternative Routen für das Fahrzeug 12 zu identifizieren.
Der Server 14 kann ferner programmiert sein, um Wetterdaten entlang der ursprünglichen Route und der einen oder den mehreren alternativen Routen zu erfassen.
Im Anschluss an das oben stehende Beispiel kann der Server 14 z. B. bestimmen, dass feuchte Bedingungen, die Daten von alternativen Quellen für Raddrehzahldaten herabsetzen können. Der Server 14 kann ferner bestimmen, dass während einer Fahrt des Fahrzeugs 12 Regen entlang der ursprünglichen Route zu erwarten ist und kein Regen entlang einer alternativen Route zu erwarten ist. Auf Grundlage des Störungszustands und der erwarteten Wetterbedingungen kann der Server 14 das Fahrzeug 12 autorisieren, um zu dem Ziel fortzufahren und das Fahrzeug 12 anweisen, entlang der alternativen Route fortzufahren, wo kein Regen zu erwarten ist.
Die eine oder die mehreren Datenquellen 16 sind Computer, die dem Server 14 ähneln. Die Datenquellen 16 sind kommunikativ mit dem Server 14 gekoppelt und können ferner mit dem Computer 20 des Fahrzeugs 12 kommunikativ gekoppelt sein. Jede der Datenquellen 16 ist programmiert, um Daten, wie etwa Kartendaten, Wetterdaten, Verkehrsdaten, Daten für den Störungszustand usw. für den Server 14 bereitzustellen. In einigen Fällen kann die Datenquelle 16 zusätzlich Daten für den Computer 20 des Fahrzeugs 12 bereitstellen.
Die Datenquellen 16 können die Sensoren 42 einschließen und/oder damit verknüpft sein. Als eine nicht einschränkende Liste von Beispielen können die Sensoren 42 Thermometer, Barometer, Windgeschwindigkeitssensoren, Regenmesser, Strahlungsdetektoren, Kameras, Radar, LiDAR, Ultraschallsensoren, Infrarotsensoren, Lichtsensoren, Funkfrequenzmessvorrichtungen, Mikrofone usw. einschließen. Die Sensoren 42 können Daten in Bezug auf die Umgebung des Fahrzeugs 12 erfassen und die Daten für die Datenquellen 16 bereitstellen. Die Datenquellen 16 können die erfassten Daten oder Daten, die aus den erfassten Daten erzeugt wurden, für den Server 14 und/oder das Fahrzeug 12 bereitstellen.
Zum Beispiel kann eine Datenquelle 16 die Sensoren 42 einschließen und Wetterdaten, wie etwa die derzeitige Lufttemperatur, Feuchtigkeit usw. erfassen. Die Datenquelle 16 kann ferner auf Grundlage der erfassten Daten, zukünftige Wetterbedingungen, zum Beispiel entlang einer geplanten Route, vorhersagen. Die Datenquelle 16 kann sowohl die derzeitigen Wetterbedingungen als auch vorhergesagte Wetterbedingungen für den Server 14 bereitstellen.
Das Netzwerk 18 stellt einen oder mehrere Mechanismen dar, durch die das eine oder die mehreren Fahrzeuge 12, der Server 14 und die Datenquellen 16 miteinander kommunizieren können, und kann einer oder mehrere von verschiedenen verdrahteten oder drahtlosen Kommunikationsmechanismen sein, einschließend eine beliebige gewünschte Kombination aus verdrahteten (z. B. Kabel und Faser) und/oder drahtlosen (z. B. Mobilfunk, drahtlos, Satellit, Mikrowelle und Funkfrequenz) Kommunikationsmechanismen und eine beliebige gewünschte Netzwerktopologie (oder Topologien, wenn mehrere Kommunikationsmechanismen verwendet werden). Beispielhafte Kommunikationsnetzwerke schließen drahtlose Kommunikationsnetzwerke (z. B. unter Verwendung von einem oder mehreren von Mobilfunk, Bluetooth, IEEE 802.11 usw.), Local Area Networks (LAN) und/oder Wide Area Networks (WAN), einschließend das Internet, ein, die Datenkommunikationsdienste bereitstellen.
Die Arten der drahtlosen Kommunikation können eines oder mehrere von Mobilfunk, Bluetooth, IEEE 802.11 (typischerweise WLAN), dezidierten Nahbereichskommunikationen (DSRC), Zweiwegesatellit (z. B. Notfalldienste), Einwegesatellit (z. B. Empfang von digitalen Audiofunkübertragungen), AM/FM Radio usw. einschließen.
BEISPIELHAFTE PROZESSABLÄUFE
2A und 2B sind jeweils Schemata eines ersten Abschnitts und eines zweiten Abschnitts eines beispielhaften Prozesses 200 zum Verwalten von Störungszuständen autonomer Fahrzeuge. Der Prozess 200 beginnt in einem Block 205.
Im Block 205 initiiert der Computer 20 des Fahrzeugs 12 eine Fahrt. Die Fahrt kann auf Grundlage einer Eingabe von einem Benutzer oder einer anderen Rechenvorrichtung initiiert werden. Als ein Beispiel kann die Eingabe von einem Benutzer stammen, der Zieldaten bereitstellt und anfordert, dass sich das Fahrzeug 12 zu dem Ziel bewegt. Als ein anderes Beispiel kann die Eingabe von einer Rechenvorrichtung, wie etwa dem Server 14, stammen, der Zieldaten bereitstellt und anfordert, dass sich das Fahrzeug 12 zu dem Ziel bewegt.
In einigen Fällen kann der Computer 20 des Fahrzeugs 12 eine Fahrt mit Benutzereingaben initiieren, zum Beispiel um zum Auftanken zu einer Tankstelle fortzufahren. In diesem Fall kann der Computer 20 Zieldaten z. B. aus einer Datenbank von verfügbaren Tankstellen bestimmen.
Auf Grundlage der Zieldaten bestimmt der Computer 20 eine Route und beginnt einen Betrieb entlang der Route. Der Computer 20 des Fahrzeugs 12 kann das Fahrzeug 12 unter Verwendung von Methoden zum Steuern autonomer Fahrzeuge betreiben, die bekannt sind. Nach Beginn einer Bewegung entlang der Route, fährt der Prozess 200 in einem Block 207 fort.
Im Block 207 empfängt der Computer 20 des Fahrzeugs 12 Daten, die Betriebsbedingungen des Fahrzeugs 12 melden. Der Computer 20 kann die Daten von Sensoren 22 des Fahrzeugs 12 und zusätzlich von den Steuerungen 24 empfangen. Die Daten können Betriebsbedingungen, wie etwa die Drehzahl, Richtung, Beschleunigung usw. des Fahrzeugs 12 anzeigen. Die Daten können ferner Umgebungsbedingungen, wie etwa die Temperatur, Feuchtigkeit, Straßensteigung, Straßenbedingung, Windgeschwindigkeit, Menge an Licht usw., entlang der Straße anzeigen. Die Daten können darüber hinaus Betriebsbedingungen von internen Systemen des Fahrzeugs 12, wie etwa die Motortemperatur, die Kühlmitteltemperatur, den Bremsdruck, den Reifendruck, den Batteriezustand usw., anzeigen.
Der Computer 20 kann einige der Daten als Teil der Ausführung der Methoden zum Steuern autonomer Fahrzeuge erfassen. Zusätzlich oder alternativ kann der Computer 20 während des Betriebs des Fahrzeugs 12 diagnostische Tests ausführen, um zusätzliche Daten zu erfassen.
Nach Empfang der Daten wird der Prozess 200 in einem Block 210 fortgesetzt.
In dem Block 210 bestimmt der Computer 20, ob ein Störungszustand vorliegt.
Der Computer 20 kann die Daten analysieren und bestimmen, ob ein Störungszustand vorliegt. Für den Fall, dass kein Störungszustand bestimmt wird, wird der Prozess in dem Block 207 fortgesetzt. Für den Fall, dass ein oder mehrere Störungszustände bestimmt werden, wird der Prozess 200 in einem Block 215 fortgesetzt.
Im Block 215 überträgt der Computer 20 des Fahrzeugs 12 drahtlos Daten zu dem Server 14. Die Daten schließen den Störungszustand ein und können einen Diagnose-Fehlercode einschließen. Wie zuvor beschrieben, kann der Diagnose-Fehlercode spezifische Informationen darüber bereitstellen, welche Teilsysteme in dem Fahrzeug 12 den Störungszustand zeigten und unter welchen Bedingungen.
Zusätzlich können die Daten, die von dem Computer 20 des Fahrzeugs 12 zu dem Server 14 übertragen werden, Daten einschließen, die Betriebsbedingungen des Fahrzeugs 12 anzeigen, wie zuvor beschrieben.
Der Computer 20 des Fahrzeugs 12 kann eine Autorisierung von dem Server 14 anfordern, um zu dem Ziel fortzufahren.
In einigen Fällen kann der Computer 20 des Fahrzeugs 12 vor dem Senden der Daten ein Risiko bestimmen, das mit dem Störungszustand verknüpft ist.
Störungszuständen kann ein numerisches Risikoniveau zugewiesen werden, z. B. auf einer Skala von 0 bis 1. Das Risikoniveau ist eine numerische Anzeige des Risikos eines Störungszustands, der zu einer Kollision oder einer Fahrzeugpanne führt. Der Computer 20 des Fahrzeugs 12 kann eine erste Tabelle von Störungszuständen einschließen, welche jede Art eines Störungszustands identifiziert und dem Störungszustand ein numerisches Risikoniveau zuweist. Zum Beispiel kann einem Sensor mit Funktionsstörung, der die Warnung „Motor prüfen“ fälschlicherweise aktiviert, ein Risikoniveau von 0,01 zugewiesen werden. Einer Bremsleitung, die nicht genug Druck aufweist, kann ein Risikoniveau von 0,95 zugewiesen werden.
Risikoniveaus, wie in der Risikoniveautabelle gespeichert, können auf ein Fahrtniveau von 100 Meilen (ca. 161 km) normiert werden. Das Risikoniveau kann auf Grundlage der Tabelle gemäß einer Länge einer geplanten Fahrt gewichtet werden. Zum Beispiel kann für eine geplante Fahrt von 250 Meilen (ca. 402 km) eine Gewichtung für die Fahrtlänge 2,5 entsprechen.
Der Computer 20 des Fahrzeugs 12 kann eine oder mehrere zusätzliche Tabellen einschließen. Die zusätzlichen Tabellen können Gewichtungsfaktoren bereitstellen, um ein gewichtetes Risikoniveau eines Störungszustands auf Grundlage von Umgebungsbedingungen zu bestimmen. Zum Beispiel kann ein Reifen mit geringem Druck ein Risikoniveau von 0,2 aufweisen. Für eine Fahrt, die bei Regen stattfindet, kann das Risikoniveau jedoch mit einem Faktor von 1,5 gewichtet werden, woraus sich ein gewichtetes Risikoniveau von 0,3 ergibt, das mit dem geringen Reifendruck für die Fahrt im Regen verknüpft ist.
In einem Fall dafür, dass bestimmt wird, dass das Risikoniveau, das mit einem Störungszustand verknüpft ist, einem Schwellenwert entspricht oder darüber liegt, kann der Computer 20 des Fahrzeugs 12 autonom eine Abhilfemaßnahme, wie etwa das Betreiben des Fahrzeugs zu einer sicheren Stelle und das Stoppen des Fahrzeugs 12, das Stoppen des Fahrzeugs 12 an Ort und Stelle usw., ergreifen. Für den Fall, wie zuvor beschrieben, dass Risikoniveaus Störungszuständen zugewiesen und auf Grundlage von Umgebungsfaktoren gewichtet werden, kann der Schwellenwert zum Beispiel ein Fixwert, wie etwa 0,7, sein. Störungszustände mit einem Risikoniveau von 0,7 oder mehr können dazu führen, dass das Fahrzeug sofortige Abhilfemaßnahmen ergreift.
Der Computer 20 des Fahrzeugs 12 kann die Daten, einschließend den Störungszustand und das bestimmte Risikoniveau des Störungszustands, zu dem Server 14 übertragen, was anzeigt, dass das Fahrzeug 12 den Betrieb gestoppt hat.
Nach dem Übertragen der Daten zu dem Server 14 wird der Prozess 200 in einem Block 220 fortgesetzt.
In dem Block 220 fordert der Server 14 zusätzliche Informationen an und/oder ruft diese ab.
Zum Beispiel kann der Server 14 Daten aus einem Speicher abrufen, der kommunikativ mit dem Server 14 gekoppelt ist. Als ein anderes Beispiel kann der Server 14 Daten von einer oder mehreren Datenquellen 16 abrufen.
Die erfassten/abgerufenen Daten können zum Beispiel Daten in Bezug auf den Störungszustand einschließen, der von dem Fahrzeug 12 identifiziert wird. Zum Beispiel kann das Fahrzeug 12 ein Back-up-System aufweisen, das einen Teil der Funktionalität einer identifizierten Komponente mit einer Störung ersetzen kann. Die Daten können eine Wahrscheinlichkeit für eine Störung des Back-up-Systems anzeigen. Die Daten können eine Häufigkeit einer Störung, wie etwa 1 Störung aller 300.000 Meilen (ca. 482.803 km) des Betriebs, anzeigen und auf Grundlage der Häufigkeit einer Störung die Wahrscheinlichkeit einer Störung während der geplanten Fahrt bestimmen. Die Daten können von dem Alter des Back-up-Systems abhängig sein. Zum Beispiel kann die Wahrscheinlichkeit einer Störung eines 15 Jahre alten Back-up-Systems während der Fahrt höher sein als die Wahrscheinlichkeit einer Störung eines 5 Jahre alten Back-up-Systems während der Fahrt.
Die erfassten/abgerufenen Daten können ferner Daten, wie etwa das derzeitige und erwartete Wetter entlang einer Route, das derzeitige und erwartete Wetter entlang einer oder mehrerer alternativer Routen, den derzeitigen und erwarteten Verkehr entlang einer Route, den derzeitigen und erwarteten Verkehr entlang einer oder mehrerer alternativer Routen usw., einschließen.
Die erfassten Daten können ferner Daten in Bezug auf die Ladung und/oder die Insassen des Fahrzeugs 12 einschließen. Zum Beispiel können die Daten die Information einschließen, dass ein Insasse in dem Fahrzeug 12 dringend ärztliche Hilfe benötigt.
Nach dem Erfassen der zusätzlichen Daten wird der Prozess 200 in einem Block 225 fortgesetzt.
In dem Block 225 analysiert der Server 14 die von dem Computer 20 des Fahrzeugs 12 empfangenen Daten und zusätzliche erfasste Daten, um eine Maßnahme auf Grundlage des Störungszustands zu bestimmen.
Der Server 14 kann programmiert sein, um im Hinblick auf die Daten eine Vielzahl von Analysen durchzuführen. Eine nicht einschränkende Liste von Beispielen schließt Folgendes ein: (1) das Identifizieren möglicher Back-up-Teilsysteme des Fahrzeugs 12 für eine Komponente oder ein Teilsystem mit einer Störung, (2) das Identifizieren einer Zuverlässigkeit der Back-up-Teilsysteme für die Komponente oder das Teilsystem mit einer Störung, (3) das Identifizieren von Umgebungsbedingungen, wie etwa Wetter- oder Straßenbedingungen, die das Risiko erhöhen oder verringern, welches der Störungszustand oder die Verwendung des Back-up-Teilsystems darstellt, (4) das Analysieren einer potenziellen Auswirkung auf die Ladung und/oder Insassen des Fahrzeugs 12 (z. B. kann, wenn sich ein Insasse an Bord befindet, der für eine dringende medizinische Behandlung in ein Krankenhaus fährt, eine Wahrscheinlichkeit für negative Konsequenzen für den Insassen durch das Stoppen des Fahrzeugs erhöht werden), (5) Daten von anderen Fahrzeugen 12 des gleichen oder eines ähnlichen Typs, die diesen Störungszustand aufwiesen (zum Beispiel dass es üblicherweise eine Störung eines unkritischen Sensors war und üblicherweise kein Risiko für eine Kollision oder Fahrzeugpanne während der Fahrt darstellte), wobei die Wahrscheinlichkeit negativer Konsequenzen des Stoppens des Fahrzeugs 12 an einer Stelle (ist bekannt, dass die Stelle gefährlich ist, werden die Wetterbedingungen zunehmend schlechter) eingeschätzt wird usw.
Als eine beispielhafte Analyse kann der Server 14 Daten von dem Computer 20 des Fahrzeugs 12 darüber empfangen, dass ein Raddrehzahlsensor eine Störung aufweist. Der Server 14 kann bestimmen, dass die Daten von dem Sensor, der eine Störung aufweist, durch Daten von anderen Sensoren, zum Beispiel Raddrehzahlsensoren an anderen Rädern, ersetzt werden können. Einer individuellen Störung eines Raddrehzahlsensors kann ein Risikoniveau von 0,4 zugewiesen werden, bevor Gewichtungsfaktoren berücksichtigt werden. Dieser Wert kann zum Beispiel in einer Tabelle von Störungszuständen gespeichert werden, wobei jedem Störungszustand ein Risikoniveau zugewiesen wird.
Wie zuvor beschrieben, kann das Risikoniveau, auf eine Fahrtlänge von 100 Meilen (ca. 161 km) normiert werden. Der Server 14 kann das Risikoniveau durch einen Fahrtlängenfaktor auf Grundlage der geplanten Länge der Fahrt einstellen. Zum Beispiel kann die geplante Länge für diese Fahrt 90 Meilen (ca. 145 km) entsprechen, woraus sich ein Fahrtlängenfaktor von 90/100 = 0,9 ergibt.

Zusätzlich kann der Server 14 für jeden Störungszustand eine Vielzahl von Gewichtungstabellen einschließen, wobei jede Gewichtungstabelle Gewichtungsfaktoren einschließt, die beim Bestimmen eines gewichteten Risikoniveaus für den Störungszustand angewendet werden können. Zum Beispiel kann der Server 14 für den Raddrehzahlsensor eine Gewichtungstabelle für Regenbedingungen, eine für Verkehrsbedingungen und eine für das Alter des Fahrzeugs für den bestimmten Typ des Fahrzeugs 12 einschließen. Teile der Tabellen können, wie folgt, erscheinen:

Gewichtungstabelle für Regenbedingungen für einen Störungszustand eines Raddrehzahlsensors
Bedingung	Gewichtungsfaktor
Dauerregen	2
Zeitweise Regen	1,2
Trocken	1

Tabelle 1

Gewichtungstabelle für Verkehrsbedingungen für einen Störungszustand eines Raddrehzahlsensors
Bedingung	Gewichtungsfaktor
Starker Verkehr	1,1
Mäßiger Verkehr	1
Wenig Verkehr	1

Tabelle 2

Gewichtungstabelle für das Alter des Fahrzeugs für einen Störungszustand eines Raddrehzahlsensors (für einen bestimmten Typ eines Fahrzeugs)
Bedingung	Gewichtungsfaktor
0–8 Jahre	1
8–12 Jahre	1,1
> 12 Jahre	1,25

Tabelle 3

Als ein erstes Beispiel kann der Server 14 ferner Daten empfangen, die anzeigen, dass erwartet wird, dass das Wetter entlang der geplanten Route klar und sonnig ist. Auf Grundlage der oben stehenden Tabelle 1 ist der Gewichtungsfaktor des Störungszustands für Regen 1.
Empfangene Daten können ferner anzeigen, dass die Verkehrsbedingungen entlang der geplanten Route mäßig sind. Auf Grundlage der oben stehenden Tabelle 2, ist der Gewichtungsfaktor für Verkehr ebenfalls 1.
Ferner kann der Server 14 Daten empfangen, die anzeigen, dass das Alter des Fahrzeugs 12 14 Jahren entspricht. Auf Grundlage der oben stehenden Tabelle 3, ist der Gewichtungsfaktor für das Alter des Fahrzeugs 12 1,25.
Nachdem jeder der Gewichtungsfaktoren bestimmt wurde, kann ein gewichtetes Risikoniveau des Störungszustands des Raddrehzahlsensors gemäß der folgenden Gleichung bestimmt werden. gewichtetes Risiko = Risikoniveau·Fahrtlängenfaktor·Regenfaktor· Verkehrsfaktor·Altersfaktor (Gl. 1)
Für das oben stehende Beispiel wäre das gewichtete Risikoniveau 0,4·0,9·1·1·1,25 = 0,45.
Das gewichtete Risikoniveau kann zum Beispiel mit einem Schwellenwert des Risikoniveaus verglichen werden, um einen kontinuierlichen Betrieb zu ermöglichen. Der Schwellenwert des Risikoniveaus kann zum Beispiel ein Fixwert von 0,7 sein. In diesem Fall liegt das gewichtete Risikoniveau 0,5 unter dem Schwellenwert von 0.7. Der Server 14 bestimmt, dass das Fahrzeug 12 zu dem Ziel fortfahren kann.
Alternativ kann der Server 14 im Anschluss an das gleiche Beispiel bestimmen, dass erwartet wird, dass das Wetter entlang einer ursprünglich geplanten Route regnerisch ist. Durch regnerisches Wetter werden die Raddrehzahldaten von den anderen Rädern aufgrund eines möglichen Rutschens der Räder unzuverlässig. Wie zuvor können Daten anzeigen, dass Verkehrsbedingungen entlang der geplanten Route mäßig sind und das Alter des Fahrzeugs bei 14 Jahren liegt. In diesem Fall kann der Server 14 bestimmen, dass das gewichtete Risikoniveau = 0,4·0,9·2·1·1,25 = 0,9.
Jedoch können zusätzliche Daten, die für den Server 14 verfügbar sind, anzeigen, dass das Wetter entlang einer alternativen Route trocken ist und das Verkehrsaufkommen niedrig ist. Die alternative Route kann ebenso 90 Meilen (ca. 145 km) lang sein. Für die alternative Route kann bestimmt werden, dass das gewichtete Risikoniveau 0,4·0,9·1·1·1 = 0,36 entspricht.
Das gewichtete Risikoniveau für die alternative Route (0,36) ist kleiner als das gewichtete Risikoniveau entlang der ursprünglich geplanten Route (0,9). Ferner ist die gewichtete Schwere entlang der alternativen Route (0,0,36) kleiner als der Schwellenwert des Risikoniveaus (0,7). Auf Grundlage dieser Bestimmungen bestimmt der Server 14, dass das Fahrzeug 12 entlang der alternativen Route zu dem Ziel fortfahren kann.
Nach dem Abschluss der Analyse des Blocks 225 wird der Prozess 200 in einem Block 230 fortgesetzt.
In dem Block 230 sendet der Server 14 auf Grundlage der Analyse, die in dem Block 225 durchgeführt wurde, eine oder mehrere Anweisungen zu dem Computer 12 des Fahrzeugs 20. Als nicht einschränkende Beispiele kann der Server 14 den Computer 20 anweisen, das Fahrzeug 12 entlang der ursprünglichen Route zu betreiben, das Fahrzeug 12 entlang einer alternativen Route zu betreiben oder das Fahrzeug 12 anweisen, eine oder mehrere andere Abhilfemaßnahmen zu ergreifen. Zusätzlich kann der Server 14 Anweisungen zu Dienstanbietern, wie etwa Reparaturdienstanbietern, Fahrzeuganbietern, Transportanbietern usw., senden.
Wie zuvor beschrieben, kann der Server 14 in einigen Fällen vor dem Übertragen einer Anweisung zu dem Fahrzeug 12 oder dem Ergreifen einer anderen Maßnahme programmiert sein, um eine Autorisierung von einem Benutzer anzufordern. Beim Empfangen einer Autorisierung von dem Benutzer fährt der Server 14 dann mit dem Übertragen der Anweisung zu dem Fahrzeug 12 oder dem Ergreifen der anderen Maßnahme fort.
Ferner gelingt es dem Server 14 in einigen Fällen möglicherweise nicht, innerhalb eines Zeitraums für eine Antwort eine Antwort zu dem Computer 20 des Fahrzeugs 12 zu senden. Der Zeitraum für eine Antwort kann z. B. ein festgelegter Zeitraum, wie etwa 30 Sekunden, sein.
Nach dem Senden von Anweisungen zu dem Computer 20 des Fahrzeugs 12 und anderen Dienstanbietern oder dem Ablauf des Zeitraums für die Antwort bevor der Server 14 eine Antwort sendet, wird der Prozess 200 in einem Block 235 fortgesetzt.
In dem Block 235 bestimmt der Computer 20 des Fahrzeugs 12 auf Grundlage einer Anweisung, die von dem Server 14 empfangen wurde, ob das Fahrzeug 12 zu dem Ziel fortfahren oder die Fahrt abbrechen und Abhilfemaßnahmen ergreifen soll. Für den Fall, dass der Computer 20 des Fahrzeugs 12 angewiesen wird, die Fahrt zu unterbrechen und Abhilfemaßnahmen zu ergreifen oder für den Fall, dass keine Antwort von dem Server 14 empfangen wird, wird der Prozess 200 in einem Block 240 fortgesetzt. Für den Fall, dass der Computer 20 des Fahrzeugs 12 angewiesen wird, zu dem Ziel fortzufahren, wird der Prozess 200 in einem Block 245 fortgesetzt.
In dem Block 240 ergreift der Computer 20 des Fahrzeugs 12 für den Fall, dass der Computer 20 des Fahrzeugs 12 eine Antwort von dem Server 14 empfängt, eine Abhilfemaßnahme auf Grundlage von Anweisungen von dem Server 14. Nicht einschränkende Beispiele für Abhilfemaßnahmen, die der Computer 20 des Fahrzeugs 12 ergreifen kann, schließen Folgendes ein: (1) das Stoppen des Fahrzeugs 12 an Ort und Stelle und das Warten darauf, dass ein Dienstanbieter, wie etwa ein Reparaturdienst, ein Abschleppdienst, ein Transportdienst usw., zu der Stelle kommt, (2) das Betreiben des Fahrzeugs 12 zu einer sicheren Stelle, wie etwa einem Parkplatz und das Warten auf einen Dienstanbieter, (3) das Betreiben des Fahrzeugs 12 zu einer Reparaturstation usw. Für den Fall, dass der Computer 20 des Fahrzeugs 12 innerhalb des Zeitraums für eine Antwort keine Antwort von dem Server 14 empfangen hat, stoppt der Computer 20 des Fahrzeugs 12 das Fahrzeug. Nach dem Ergreifen der Abhilfemaßnahme und/oder Stoppen des Fahrzeugs endet der Prozess 200.
In dem Block 245, welcher auf den Block 235 folgt, bestimmt der Computer 20 des Fahrzeugs 12 auf Grundlage der empfangenen Anweisungen, ob das Fahrzeug 12 entlang der ursprünglichen Route oder entlang einer neuen Route fortfährt. Für den Fall, dass der Computer 20 angewiesen wird, entlang der ursprünglichen Route fortzufahren, wird der Prozess 200 in einem Block 250 fortgesetzt. Für den Fall, dass der Computer 20 angewiesen wird, über eine neue Route fortzufahren, wird der Prozess 200 in einem Block 255 fortgesetzt.
In dem Block 250 betreibt der Computer 20 das Fahrzeug 12 entlang der ursprünglichen Route zu dem Ziel. Der Prozess 200 endet.
In dem Block 255 betreibt der Computer 20 das Fahrzeug 12 entlang einer neuen Route zu dem Ziel, die von dem Server 14 bestimmt wird. Der Prozess 200 endet.
SCHLUSSFOLGERUNG
Rechenvorrichtungen, wie etwa die hierin besprochenen, schließen im Allgemeinen jeweils Anweisungen ein, die durch eine oder mehrere Rechenvorrichtungen, wie etwa die oben identifizierten, ausgeführt werden können, und zum Ausführen von oben beschriebenen Blöcken oder Schritten von Prozessen. Zum Beispiel können die vorstehend besprochenen Prozessblöcke als computerausführbare Anweisungen ausgeführt sein.
Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt wurden, einschließend unter anderem, entweder allein oder in Kombination, Java^TM, C, C++, Visual Basic, Java Script, Perl, HTML usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch er einen oder mehrere Prozesse durchführt, einschließend einen oder mehrere der hierin beschriebenen Prozesse. Derartige Anweisungen und sonstige Daten können unter Verwendung einer Vielzahl computerlesbarer Medien in Dateien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist im Allgemeinen eine Sammlung von Daten, die auf einem computerlesbaren Medium, wie etwa einem Speichermedium, einem Direktzugriffsspeicher usw., gespeichert werden.
Ein computerlesbares Medium schließt jedes Medium ein, das am Bereitstellen von Daten (z. B. Anweisungen), die durch einen Computer gelesen werden können, beteiligt ist. Ein solches Medium kann viele Formen annehmen, einschließend unter anderem nichtflüchtige Medien, flüchtige Medien usw. Nichtflüchtige Medien schließen zum Beispiel optische oder magnetische Platten und andere Dauerspeicher ein. Flüchtige Medien schließen dynamischen Direktzugriffsspeicher (Dynamic Random Access Memory – DRAM) ein, welcher in der Regel einen Hauptspeicher darstellt. Gängige Formen computerlesbarer Medien schließen zum Beispiel eine Diskette, eine Folienspeicherplatte, 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, einen beliebigen anderen Speicherchip oder eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium ein, das von einem Computer gelesen werden kann.
Allen in den Ansprüchen verwendeten Begriffen sollen deren einfache und allgemeine Bedeutung zugeordnet werden, wie sie Fachleuten bekannt sind, sofern hier kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „eine“, „der“, „die“, „das“ usw. dahingehend auszulegen, dass ein oder mehrere der aufgeführten Elemente genannt werden, sofern ein Anspruch nicht eine ausdrückliche gegenteilige Einschränkung enthält.
Der Begriff „beispielhaft“ wird hierin in dem Sinne verwendet, dass er ein Beispiel angibt, z. B. sollte ein Verweis auf ein „beispielhaftes Gerät“ einfach als Bezugnahme auf ein Beispiel für ein Gerät gelesen werden.
Das einen Wert oder ein Ergebnis modifizierende Adverb „ungefähr“ bedeutet, dass eine Form, eine Struktur, ein Maß, ein Wert, eine Bestimmung, eine Berechnung usw. von einer/einem genau beschriebenen Geometrie, Entfernung, Maß, Wert, Bestimmung, Berechnung usw. durch Mängel hinsichtlich der Materialien, Bearbeitung, Herstellung, Sensormessungen, Berechnungen, Bearbeitungszeit, Kommunikationszeit usw. abweichen kann.
In den Zeichnungen kennzeichnen gleiche Bezugszeichen ähnliche Elemente. Ferner könnten manche oder alle dieser Elemente geändert werden. Hinsichtlich der hierin beschriebenen Medien, Prozesse, Systeme, Verfahren usw. ist davon auszugehen, dass, wenngleich die Schritte derartiger Prozesse usw. als in einer bestimmten Reihenfolge erfolgend beschrieben wurden, derartige Prozesse durchgeführt werden können, wobei die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, welche von der hierin beschriebenen Reihenfolge abweicht. Es versteht sich zudem, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte hier beschriebene Schritte weggelassen werden könnten. Anders gesagt, werden die vorliegenden Beschreibungen von Prozessen zum Zwecke der Veranschaulichung bestimmter Ausführungsformen bereitgestellt und sollten keinesfalls dahingehend ausgelegt werden, dass sie die beanspruchte Erfindung einschränken.
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 Nicht-Patentliteratur

IEEE 802.11 [0039]
IEEE 802.11 [0040]

Claims

Verfahren, umfassend: Empfangen einer Anzeige eines Störungszustands in einem Fahrzeug durch einen Prozessor; drahtloses Übertragen der Anzeige des Störungszustands zu einem entfernten Server; Empfangen einer überarbeiteten Route zu einem Ziel, zumindest teilweise auf Grundlage des Störungszustands, von dem entfernten Server; und Betreiben des Fahrzeugs entlang der überarbeiteten Route.
Verfahren nach Anspruch 1, ferner umfassend: Bestimmen, dass ein Risikoniveau des Störungszustands innerhalb eines Risikobereichs liegt; und Übertragen des Störungszustands und des bestimmten Risikoniveaus des Störungszustands zu dem entfernten Server auf Grundlage der Bestimmung, dass das Risikoniveau des Störungszustands innerhalb des Risikobereichs liegt.
Verfahren nach Anspruch 1, ferner umfassend: Bestimmen eines Risikoniveaus des Störungszustands; und Übertragen einer Anfrage zu dem entfernten Server auf Grundlage des Risikoniveaus des Störungszustands für eine Autorisierung, um zu dem Ziel fortzufahren.
Verfahren nach Anspruch 1, wobei der Prozessor ferner programmiert ist, um: eine Anweisung zu empfangen, um das Fahrzeug zu stoppen; eine Stelle zum Stoppen des Fahrzeugs zu identifizieren; und das Fahrzeug an der Stelle zu stoppen.
Verfahren nach Anspruch 1, ferner umfassend: Empfangen der Anzeige des Störungszustands in einem Fahrzeug von dem Prozessor durch einen zweiten Prozessor; Beurteilen eines Risikoniveaus des Störungszustands, zumindest teilweise auf Grundlage zusätzlicher Daten, durch den zweiten Prozessor; Bestimmen, dass das Risikoniveau des Störungszustands durch die überarbeitete Route zu dem Ziel in Bezug auf eine ursprüngliche Route zu dem Ziel verringert ist, durch den zweiten Prozessor; und Übertragen der überarbeiteten Route zu dem Prozessor durch den zweiten Prozessor.
Verfahren nach Anspruch 5, wobei die zusätzlichen Daten erste Wetterdaten entlang der ursprünglichen Route und zweite Wetterdaten entlang der überarbeiteten Route einschließen.
Verfahren nach Anspruch 5, wobei die zusätzlichen Daten von einer Quelle empfangen werden, die sich von dem Prozessor unterscheidet.
Verfahren nach Anspruch 5, ferner umfassend: Empfangen von Daten, die einen Zustand eines Insassen in dem Fahrzeug anzeigen; und Beurteilen des Risikoniveaus des Störungszustands zumindest teilweise auf Grundlage des Zustands des Insassen.
Verfahren nach Anspruch 1, ferner umfassend: Bestimmen, dass der Prozessor innerhalb eines Zeitraums des Übertragens des Störungszustands zu dem entfernten Server keine Antwort von dem entfernten Server empfangen hat; und Stoppen des Fahrzeugs auf der Grundlage der Bestimmung, dass der Prozessor die Antwort nicht empfangen hat.
Computer, welcher programmiert ist, um das Verfahren nach einem der Ansprüche 1–9 auszuführen.
Fahrzeug, umfassend einen Computer, welcher programmiert ist, um das Verfahren nach einem der Ansprüche 1–9 auszuführen.