-
ALLGEMEINER STAND DER TECHNIK
-
Die Society of Automotive Engineers (SAE) hat mehrere Stufen eines autonomen Fahrzeugbetriebs definiert. Bei den Stufen 0-2 überwacht oder steuert ein menschlicher Fahrer den Großteil der Fahraufgaben, häufig ohne Hilfe des Fahrzeugs. Bei Stufe 0 beispielsweise („keine Automation“) ist ein menschlicher Fahrer verantwortlich für alle Fahrzeugbetriebsvorgänge. Bei Stufe 1 („Assistenzsysteme“) hilft das Fahrzeug bisweilen mit Lenken, Beschleunigung oder Bremsen, der Fahrer ist jedoch nach wie vor verantwortlich für den überwiegenden Großteil der Fahrzeugsteuerung. Bei Stufe 2 („Teilautomatisierung“) kann das Fahrzeug Lenkung, Beschleunigung und Bremsen unter bestimmten Umständen ohne menschliche Interaktion steuern. Bei den Stufen 3-5 übernimmt das Fahrzeug weitere fahrbezogene Aufgaben. Bei Stufe 3 („bedingte Automatisierung“) kann das Fahrzeug Lenkung, Beschleunigung und Bremsen unter bestimmten Umständen handhaben sowie die Fahrumgebung überwachen. Stufe 3 erfordert jedoch ein gelegentliches Eingreifen des Fahrers. Bei Stufe 4 („Hochautomatisierung“) kann das Fahrzeug dieselben Aufgaben wie bei Stufe 3 handhaben, erfordert jedoch kein Eingreifen des Fahrers in bestimmten Fahrmodi. Bei Stufe 5 („Vollautomatisierung“) kann das Fahrzeug nahezu alle Aufgaben ohne jegliches Eingreifen des Fahrers handhaben.
-
Figurenliste
-
- 1 veranschaulicht ein beispielhaftes Trägerfahrzeug mit einem Steuersystem, das einen Selbstdiagnosetest nach einem Aufprall mit Beteiligung des Trägerfahrzeugs in Kommunikation mit einem Fernserver durchführt.
- 2 ist ein Blockdiagramm, das Beispielkomponenten des Steuersystems veranschaulicht.
- 3 ist ein Flussdiagramm eines Beispielprozesses, der vom Steuersystem ausgeführt werden kann.
-
DETAILLIERTE BESCHREIBUNG
-
Höhere Automatisierungsstufen (beispielsweise die SAE Stufen 3-5) gestatten einen autonomen Fahrzeugbetrieb mit wenig bis gar keinem menschlichen Eingreifen. Wenn ein autonomes Fahrzeug, das mit einer hohen autonomen Betriebsstufe arbeitet, an einem Unfall beteiligt ist, kann eventuell kein Mensch anwesend sein, um das Ausmaß des Schadens am Fahrzeug zu beurteilen, einen Abschleppwagen zu rufen, die Notfalldienste anzurufen, das Fahrzeug aus der Fahrbahn zu bewegen usw. Somit kann das autonome Fahrzeug nach dem Unfall eventuell auf der Fahrbahn stehenbleiben, selbst wenn es ansonsten durchaus in der Lage ist wegzufahren. Alternativ dazu kann das autonome Fahrzeug eventuell versuchen, von einem Unfallort wegzufahren, obwohl wichtige Teilsysteme des Fahrzeugs aufgrund des Unfalls beschädigt sind.
-
Eine Möglichkeit, derartige Situationen zu meistern, ist durch ein autonomes Fahrzeug mit einem Prozessor, der einen Selbstdiagnosetest durchführt und abhängig vom Ergebnis des Selbstdiagnosetests Hilfe aus der Ferne anfordert. Insbesondere beinhaltet eine Lösung ein Fahrzeugsystem mit einem Prozessor, der dazu programmiert ist, einen Selbstdiagnosetest des Prozessors als Reaktion auf das Empfangen eines Aufprallsignals durchzuführen. Das Aufprallsignal stellt einen Aufprall mit Beteiligung des Trägerfahrzeugs dar. Der Prozessor ist ferner dazu programmiert, eine Fernverarbeitung mindestens einer autonomen Fahrzeugbetriebsfunktion als Reaktion darauf anzufordern, dass der Prozessor den Selbstdiagnosetest nicht besteht. Dieses Fahrzeugsystem kann es dem Trägerfahrzeug gestatten, in einem Notbetriebsmodus zu funktionieren, sogar unter Bedingungen, bei denen der Prozessor selbst bei dem Unfall beschädigt wurde.
-
Die gezeigten Elemente können viele verschiedene Formen annehmen und mehrere und/oder alternative Komponenten und Einrichtungen beinhalten. Die dargestellten Beispielkomponenten sind nicht als einschränkend zu verstehen. Vielmehr können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden. Außerdem sind die gezeigten Elemente nicht notwendigerweise maßstabsgetreu dargestellt, sofern dies nicht ausdrücklich angegeben ist.
-
Wie in 1 veranschaulicht, beinhaltet ein Trägerfahrzeug 100 ein Steuersystem 105, das über ein Kommunikationsnetz 115 in Kommunikation mit einem Fernserver 110 steht. Das Steuersystem 105 führt nach einem Aufprall mit Beteiligung des Trägerfahrzeugs 100 einen Selbstdiagnosetest durch. Wenn das Steuersystem 105 den Selbstdiagnosetest nicht besteht, was bedeuten könnte, dass das Steuersystem 105 nicht in der Lage ist, bestimmte autonome Fahrzeugbetriebsfunktionen richtig zu steuern, so fordert das Steuersystem 105 eine Fernverarbeitung einer oder mehrerer autonomer Fahrzeugbetriebsfunktionen an. In solchen Fällen kann der Fernserver 110 vom Steuersystem 105 übermittelte Signale aus der Ferne verarbeiten und Steuersignale zurück an das Steuersystem 105 übermitteln, sodass die autonomen Fahrzeugbetriebsfunktionen gesteuert werden können, zumindest, um das Trägerfahrzeug 100 in einem Notbetriebsmodus zu betreiben.
-
Der Notbetriebsmodus kann einen Modus bezeichnen, in dem eine Reihe von autonomen Fahrzeugbetriebsfunktionen ausgeführt werden können, um das Trägerfahrzeug 100 autonom zu steuern, um das Trägerfahrzeug 100 nach einem Unfall aus der Fahrbahn, zu einem Servicecenter oder beidem zu bewegen. Der Notbetriebsmodus kann ferner bestimmte autonome Fahrzeugbetriebsfunktionen definieren, die nicht verfügbar sind, selbst wenn die mit jenen Betriebsfunktionen verbundenen Teilsysteme richtig funktionieren. Ferner kann der Notbetriebsmodus bestimmten autonomen Fahrzeugbetriebsfunktionen Einschränkungen auferlegen. Zum Beispiel kann es dem Trägerfahrzeug 100 beim Betrieb im Notbetriebsmodus ggf. nicht gestattet sein, schneller als eine Maximalgeschwindigkeit wie beispielsweise 13 km/h zu fahren.
-
Der Fernserver 110 ist durch Schaltkreise, Chips oder andere elektronische Komponenten umgesetzt, die Signale, die über das Kommunikationsnetz 115 vom Steuersystem 105 an den Fernserver 110 übermittelt werden, empfangen und verarbeiten können. Der Fernserver 110 kann daher über eine cloudbasierte Computervorrichtung umgesetzt sein. Der Fernserver 110 kann dazu programmiert sein, Signale über eine beliebige Zahl von Kommunikationsprotokollen, wie beispielsweise paketvermittelte Netzwerkprotokolle, Satellitenkommunikationsprotokolle, Zellularkommunikationsprotokolle oder ähnliches, zu empfangen und zu übermitteln.
-
Das Kommunikationsnetz 115 ist über Hardwarekomponenten, wie beispielsweise Netzwerkknoten (Gateways, Terminals, Mobilfunkmasten, Satelliten, Satellitenschüsseln usw.), Schaltkreise, Chips oder andere elektronische Komponenten umgesetzt, die die Kommunikation von Daten zwischen dem Trägerfahrzeug 100 und dem Fernserver 110 ermöglichen. Das Kommunikationsnetz 115 kann Kommunikationen über eine beliebige Zahl von Kommunikationsprotokollen, wie beispielsweise paketvermittelte Netzwerkprotokolle, Satellitenkommunikationsprotokolle, Zellularkommunikationsprotokolle oder ähnliches, übermitteln.
-
Das Steuersystem 105 kann in verschiedenen elektronischen Systemen des Trägerfahrzeugs 100 integriert sein. Ferner kann ein einzelnes Trägerfahrzeug 100 mehrere Steuersysteme 105 aufweisen. Beispielsweise kann das Steuersystem 105 in einer Motorsteuereinheit, einer Getriebesteuereinheit, einem Antriebsstrangsteuermodul, einem Rückhaltesteuermodul, einem Karosseriesteuermodul usw. integriert sein.
-
Obwohl es als eine Limousine dargestellt ist, kann das Trägerfahrzeug 100 ein beliebiges Personen- oder Nutzfahrzeug, wie beispielsweise einen Pkw, einen Lkw, ein SUV, ein Crossover-Fahrzeug, einen Transporter, einen Kleintransporter, ein Taxi, einen Bus usw., beinhalten. Das Trägerfahrzeug 100 kann ein autonomes Fahrzeug sein, das in einem autonomen (z. B. fahrerlosen) Modus, einem teilautonomen Modus oder einem nichtautonomen Modus arbeiten kann.
-
Nun bezugnehmend auf 2, beinhaltet oder arbeitet das Steuersystem 105 gemäß mindestens einem Aufprallsensor 120, einer Kommunikationsschnittstelle 125, einem Speicher 130 und einem Prozessor 135 in Kommunikation über ein Fahrzeugnetz 140. Das Fahrzeugnetz 140 ist durch Schaltkreise, Chips, Netzhardware oder andere elektronische Komponenten umgesetzt, die eine drahtgebundene oder drahtlose Netzkommunikation über z. B. einen CAN (Controller Area Network)-Bus, Ethernet, Bluetooth®, Bluetooth® Low Energy ermöglichen können.
-
Die Aufprallsensoren 120 sind durch Schaltkreise, Chips oder andere elektronische Komponenten, wie beispielsweise einen Beschleunigungsmesser oder Näherungssensor, umgesetzt, die einen Aufprall mit Beteiligung des Trägerfahrzeugs 100 erkennen können. Der Aufprall kann von einem Aufprall auf ein anderes Fahrzeug (motorisiert oder mit Muskelkraft angetrieben), einen Fußgänger oder ein Objekt, wie beispielsweise einen Baum, ein Verkehrsschild, einen Hydranten, ein Geländer, eine Böschung usw. herrühren, oder irgendetwas anderes, das ausreicht, um einen Schaden am Trägerfahrzeug 100 oder an einem oder mehreren Teilsystemen 145 des Trägerfahrzeugs 100 zu verursachen. Als Reaktion auf das Erkennen des Aufpralls kann der Aufprallsensor 120 ein Aufprallsignal ausgeben, das anzeigen kann, dass das Trägerfahrzeug 100 an einem Aufprall beteiligt war. Das Aufprallsignal kann ferner die Schwere des Aufpralls anzeigen. Beispielsweise kann ein „starkes “Aufprallsignal eine schwere Kollision anzeigen, während ein „schwaches“ Aufprallsignal eine weniger schwere Kollision (z. B. einen „Blechschaden“) anzeigen kann. Das Aufprallsignal kann über das Fahrzeugnetz 140 an den Prozessor 135 ausgegeben werden.
-
Die Kommunikationsschnittstelle 125 ist durch eine Antenne, Schaltkreise, Chips oder andere elektronische Komponenten umgesetzt, die eine drahtgebundene oder drahtlose Kommunikation außerhalb des Trägerfahrzeugs 100 ermöglichen können. Beispielsweise kann die Kommunikationsschnittstelle 125 dazu programmiert sein, Signale über das Kommunikationsnetz 115 gemäß einer beliebigen Zahl von drahtgebundenen oder drahtlosen Kommunikationsprotokollen zu übermitteln, einschließlich paketvermittelten Netzwerkprotokollen, Zellularkommunikationsprotokollen, Satellitenkommunikationsprotokollen, Fahrzeug-an-Fahrzeug- oder Fahrzeug-an-Infrastruktur-Kommunikationsprotokollen, wie beispielsweise des Dedicated Short Range Communication (DSRC)-Protokolls, oder ähnlichem. Die Kommunikationsschnittstelle 125 kann ferner dazu programmiert sein, Signale zu empfangen, die gemäß derartigen Protokollen über das Kommunikationsnetz 115 an das Trägerfahrzeug 100 übermittelt werden. Die Kommunikationsschnittstelle 125 kann dazu programmiert sein, über das Fahrzeugnetz 140 Signale an z. B. den Prozessor 135 oder andere Komponenten des Trägerfahrzeugs 100 auszugeben und Signale von dem Prozessor 135 oder anderen Komponenten des Trägerfahrzeugs 100 zu empfangen.
-
Der Speicher 130 ist durch Schaltkreise, Chips oder andere elektronische Komponenten umgesetzt, die elektronisch Daten, einschließlich von dem Prozessor 135 ausführbare Anweisungen, speichern können, um eine oder mehrere der autonomen Fahrzeugbetriebsfunktionen zu steuern. Mit Speicher 130 kann Nur-Lese-Speicher (ROM), Schreib-Lese-Speicher (RAM) oder ähnliches gemeint sein. Obwohl er als separate Komponente gezeigt wird, kann der Speicher 130 im Prozessor 135 integriert sein. Somit kann mit Aussagen, dass der Prozessor 135 einen Selbstdiagnosetest durchführt, gemeint sein, dass der Prozessor 135 eine Diagnose des Speichers 130 durchführt.
-
Der Prozessor 135 ist durch Schaltkreise, Chips oder andere elektronische Komponenten umgesetzt, die die von den Aufprallsensoren 120 ausgegebenen Signale verarbeiten und feststellen können, inwieweit das Trägerfahrzeug 100 in einem Notbetriebsmodus arbeiten kann. In einigen Fällen ist der Prozessor 135 ein Mehrkernprozessor 135 (z. B. durch mehrere Kerne 150 umgesetzt). Vor Ausführen des Notbetriebsmodus ist der Prozessor 135 dazu programmiert, einen Selbstdiagnosetest durchzuführen, um festzustellen, ob er richtig funktioniert. Falls nicht, ist der Prozessor 135 dazu programmiert, eine Femverarbeitung bestimmter autonomer Fahrzeugbetriebsfunktionen anzufordern, wie beispielsweise jener, die mit dem Notbetriebsmodus verbunden sind (wie nachfolgend eingehender erörtert), ein Flashen des Speichers 130 anzufordern, oder ähnliches.
-
Der Prozessor 135 kann dazu programmiert sein, den Selbstdiagnosetest durchzuführen, der als ein Satz von vom Prozessor 135 ausgeführten Anweisungen definiert ist, um festzustellen, ob der Prozessor 135 (insbesondere jeder Kern 150 des Prozessors 135), der Speicher 130 oder beide richtig funktionieren. Der Prozessor 135 kann dazu programmiert sein, den Selbstdiagnosetest als Reaktion auf das Empfangen des Aufprallsignals durchzuführen. Das Durchführen des Selbstdiagnosetests kann das Feststellen beinhalten, ob der Speicher 130 fehlerhaft ist, ob einer der Kerne 150 des Prozessors 135 ausgefallen ist, usw. Das Feststellen, ob der Speicher 130 fehlerhaft ist, kann das Schreiben einer Abfolge von Bits an den Speicher 130 und das Zurücklesen dieser Abfolge von Bits beinhalten, um festzustellen, ob der Speicher 130 in der Lage war, die korrekte Abfolge von Bits präzise zu speichern. Das Feststellen, ob einer oder mehrere der Kerne 150 ausgefallen sind, kann beinhalten, dass jeder der Kerne 150 veranlasst wird, verschiedene Operationen oder Berechnungen durchzuführen. Falls einer oder mehrere der Kerne 150 nicht in der Lage sind, die Operation oder Berechnung durchzuführen, kann der Selbstdiagnosetest anzeigen, dass der Kern 150, der nicht in der Lage war, die Operation oder Berechnung durchzuführen, ausgefallen ist.
-
Unter bestimmten Umständen, wie beispielsweise, wenn der Prozessor 135 den Selbstdiagnosetest nicht besteht, weil einer oder mehrere der Kerne 150 oder der Speicher 130 ausgefallen ist, kann der Prozessor 135 dazu programmiert sein, ein Kern-Flash von dem Fernserver 110 anzufordern. Mit Kern-Flash kann ein Prozess gemeint sein, bei dem die im Kern 150 gespeicherten oder diesem zugänglichen Daten gelöscht und neue Daten, wie beispielsweise neue vom Kern 150 ausführbare Anweisungen, in den Kern 150 oder den dem Kern 150 zugänglichen Speicher 130 hochgeladen werden. Somit kann der Begriff „Kern-Flash“ das Hochladen von Anweisungen in den Kern 150, in den Speicher 130 oder beide bezeichnen. Der Fernserver 110 kann die neuen Daten über das Kommunikationsnetz 115 an das Steuersystem 105 übermitteln. Die Kommunikationsschnittstelle 125 kann die neuen Anweisungen empfangen und sie auf Befehl des Prozessors 135 in den Kern 150 hochladen.
-
Während er darauf wartet, dass der Kern-Flash abgeschlossen wird, kann der Prozessor 135 anfordern, dass der Fernserver 110 das Verarbeiten von einer oder mehreren autonomen Fahrzeugbetriebsfunktionen, die ansonsten von dem Kern 150 gehandhabt würden, aus der Ferne handhabt, zumindest bis der Kern-Flash abgeschlossen ist. Wenn der Kern-Flash abgeschlossen ist, kann der Prozessor 135 dazu programmiert sein, einen anschließenden Selbstdiagnosetest durchzuführen, um z. B. festzustellen, ob der Kern-Flash erfolgreich abgeschlossen wurde. Der anschließende Selbstdiagnosetest kann beinhalten, dass der Prozessor 135 den Kern 150 anweist, bestimmte Operationen oder Berechnungen durchzuführen. Zumindest teilweise basierend darauf, ob der Kern 150 die Operationen oder Berechnungen während des anschließenden Selbstdiagnosetests durchführen kann, kann der Prozessor 135 feststellen, ob der Kern-Flash erfolgreich war.
-
Der Prozessor 135 kann ferner dazu programmiert sein, festzustellen, ob andere autonome Fahrzeugteilsysteme 145, die mit dem Betreiben des Trägerfahrzeugs 100 im Notbetriebsmodus verbunden sind, nach dem Empfangen des Aufprallsignals betriebsfähig bleiben. Zum Beispiel kann der Prozessor 135 feststellen, ob eine(r/s) oder mehrere der Kraftstoffpumpe, des Kraftstoffverteilers, der Zündspulen, der Batterie, des Anlassers, der Krafstoffeinspritzdüsen, der Zündkerzen, der beheizten Abgas- (Heated Exhaust Gas Oxygen -HEGO)-Sonden, der Schaltung, der Navigationssensoren, des Rückhaltesteuermoduls, der Aktoren zum Beschleunigen, Bremsen und Lenken des Fahrzeugs usw., richtig funktionieren. Vorausgesetzt, dass zumindest ein bestimmter Teilsatz jener oder eventuell anderer autonomer Fahrzeugbetriebsfunktionen trotz des Aufpralls funktionstüchtig sind, kann der Prozessor 135 feststellen, dass das Trägerfahrzeug 100 im Notbetriebsmodus arbeiten kann. In einigen Fällen kann der Prozessor 135 feststellen, dass das Trägerfahrzeug 100 im Notbetriebsmodus arbeiten kann, auch wenn bestimmte Teilsysteme 145, wie beispielsweise ein Abgasrückführungs-(AGR)-System, ein Katalysator, das System zur Verminderung der Verdunstungsemissionen (EVAP) usw., nach dem Aufprall nicht richtig funktionieren. Darüber hinaus können bestimmte Probleme, wie beispielsweise ein Vakuumleck, das Trägerfahrzeug 100 eventuell nicht daran hindern, im Notbetriebsmodus zu arbeiten. Derartige ausgefallene Teilsysteme 145 können das Trägerfahrzeug 100 eventuell nicht daran hindern, im Notbetriebsmodus zu arbeiten, da das Trägerfahrzeug 100 nur mit niedriger Geschwindigkeit oder eine kurze Strecke oder beides fahren wird.
-
Der Prozessor 135 kann dazu programmiert sein, zusätzliche Vorsichtsmaßnahmen zu ergreifen, bevor er dem Trägerfahrzeug 100 gestattet, im Notbetriebsmodus zu arbeiten, auch wenn bestimmte Teilsysteme 145 richtig zu funktionieren scheinen. Beispielsweise kann der Prozessor 135 dazu programmiert sein, den Motor einige Minuten laufen zu lassen bevor er ein Schalten aus dem Parkgang in einen Fahrgang zulässt, um sicherzustellen, dass der Motor ohne erhebliche Probleme arbeiten kann. Nach dem Sicherstellen, dass der Motor arbeiten kann, kann der Prozessor 135 dazu programmiert sein, dem Trägerfahrzeug 100 ein Schalten aus dem Parkgang in einen Fahrgang zu gestatten, indem er z. B. ein Steuersignal an eine Autonomiemodussteuerung, eine Getriebesteuereinheit usw. ausgibt. Der Prozessor 135 kann ferner dazu programmiert sein, die Geschwindigkeit und Richtung des Fahrzeugs zu beobachten und die Geschwindigkeit und Richtung des Fahrzeugs mit Daten zu vergleichen, die es von einem bordeigenen Navigationssystem empfangen hat. Der Prozessor 135 kann derartige Informationen nutzen, um festzustellen, ob das Trägerfahrzeug 100 richtig im Notbetriebsmodus arbeitet. Wenn nicht, kann der Prozessor 135 dazu programmiert sein, den Notbetriebsmodus, die lokale Verarbeitung der autonomen Fahrzeugbetriebsfunktionen oder beides abzubrechen. Weitere Vorsichtsmaßnahmen beinhalten, dass der Prozessor 135 Steuersignale ausgibt, um die Warnblinker einzuschalten, über eine Fahrzeug-an-Fahrzeug-Kommunikation mitzuteilen, dass das Trägerfahrzeug 100 im Notbetriebsmodus arbeitet, oder beides. Ferner kann der Prozessor 135 ein Signal an das Rückhaltesteuermodul (Restraint Control Module -RCM) ausgeben und das Rückhaltesteuermodul anweisen, die Kraftstoffleitungen trotz des Aufpralls offen zu lassen.
-
Wenn der Prozessor 135 feststellt, dass das Trägerfahrzeug 100 nicht in der Lage ist im Notbetriebsmodus zu arbeiten, kann der Prozessor 135 dazu programmiert sein, die Notfalldienste, den Fahrzeugeigentümer oder beide zu kontaktieren. Beispielsweise kann der Prozessor 135 dazu programmiert sein, der Kommunikationsschnittstelle 125 zu befehlen, über das Kommunikationsnetz 115 eine Nachricht an die Notfalldienste, wie beispielsweise einen Abschleppwagen, Polizei, Feuerwehr, Krankenwagen usw., oder an den Fahrzeugeigentümer zu übermitteln. Die Nachricht kann den Standort des Trägerfahrzeugs 100 sowie weitere Informationen, wie beispielsweise den Zustand des Trägerfahrzeugs 100 (z. B. das Ausmaß des Schadens am Trägerfahrzeug 100 aufgrund des Aufpralls), beinhalten.
-
Wenn der Prozessor 135 feststellt, dass das Trägerfahrzeug 100 im Notbetriebsmodus arbeiten kann, der Prozessor 135 jedoch den Selbstdiagnosetest nicht bestanden hat, weil ein mit einem der Fahrzeugteilsysteme 145 verbundener Kern 150, der verwendet wird während das Trägerfahrzeug 100 im Notbetriebsmodus arbeitet, ausgefallen ist, so kann der Prozessor 135 eine Fernverarbeitung der autonomen Fahrzeugbetriebsfunktionen anfordern, die normalerweise von dem ausgefallenen Kern 150 gehandhabt würden. Der Prozessor 135 kann über die Kommunikationsschnittstelle 125 eine Anforderung an den Fernserver 110 übermitteln. Die Anforderung kann über das Kommunikationsnetz 115 an den Fernserver 110 übermittelt werden. Nachdem ein Handshake abgeschlossen ist, kann der Prozessor 135 Signale mit Daten, die mit dem Betrieb des Trägerfahrzeugs 100 im Notbetriebsmodus verbunden sind, an der Fernserver 110 übermitteln. Die Daten können z.B. von Autonomiesensoren, wie beispielsweise einem Lidarsensor, einem Radarsensor, einer Kamera, einem Ultraschallsensor usw., erzeugt werden. Weitere an den Fernserver 110 übermittelte Daten können die Geschwindigkeit des Trägerfahrzeugs 100, die Stellung des Lenkrads, die Stellung des Gaspedals, die Stellung des Bremspedals usw. beinhalten.
-
Der Fernserver 110 verarbeitet die empfangenen Daten und kann Steuersignals erzeugen und über das Kommunikationsnetz 115 an das Steuersystem 105 übermitteln. Die Kommunikationsschnittstelle 125 kann die Steuersignale über das Fahrzeugnetz 140 an den Prozessor 135 oder die entsprechenden Teilsysteme 145 weiterleiten. Zum Beispiel können Steuersignale für das Lenkrad an den Lenkaktor übermittelt werden, können Steuersignale für das Gaspedal an den Gaspedalaktor übermittelt werden, können Steuersignale für das Bremspedal an den Bremspedalaktor übermittelt werden, oder ähnliches. Somit können die am Ausführen des Notbetriebsmodus beteiligten Teilsysteme 145 weiter arbeiten, obwohl der mit diesen Betriebsfunktionen verbundene Kern 150 ausgefallen ist.
-
3 ist ein Flussdiagramm eines Beispielprozesses 300, der vom Steuersystem 105 ausgeführt werden kann. Der Prozess 300 kann jederzeit bei Betrieb des Trägerfahrzeugs 100 ausgeführt werden und kann weiter ausgeführt werden, bis das Trägerfahrzeug 100 z. B. ausgeschaltet wird.
-
Bei Entscheidungsblock 305 stellt das Steuersystem 105 fest, ob ein Aufprallsignal empfangen wurde. Das Aufprallsignal kann anzeigen, dass das Trägerfahrzeug 100 an einem Aufprall beteiligt war. Der Prozessor 135 kann die Aufprallsignalausgabe von einem oder mehreren der Aufprallsensoren 120 empfangen. Wenn das Aufprallsignal empfangen wird, geht der Prozess 300 zu Block 310 über. Andernfalls kann der Prozess 300 damit fortfahren, Block 305 auszuführen, bis das Aufprallsignal empfangen wird.
-
Bei Entscheidungsblock 310 stellt das Steuersystem 105 fest, ob das Trägerfahrzeug 100 im Notbetriebsmodus arbeiten kann. Zum Beispiel kann der Prozessor 135 feststellen, ob bestimmte autonome Fahrzeugteilsysteme 145 nach dem Aufprall betriebsfähig bleiben. Zum Beispiel kann der Prozessor 135 feststellen, ob eine(r/s) oder mehrere der Kraftstoffpumpe, des Kraftstoffverteilers, der Zündspulen, der Batterie, des Anlassers, der Krafstoffeinspritzdüsen, der Zündkerzen, der beheizten Abgas- (Heated Exhaust Gas Oxygen -HEGO)-Sonden, der Schaltung, der Navigationssensoren, des Rückhaltesteuermoduls, der Aktoren zum Beschleunigen, Bremsen und Lenken des Fahrzeugs usw., richtig funktionieren. Wenn der Prozessor 135 feststellt, dass zumindest ein bestimmter Teilsatz jener oder eventuell anderer autonomer Fahrzeugbetriebsfunktionen trotz des Aufpralls funktionstüchtig sind, kann der Prozessor 135 feststellen, dass das Trägerfahrzeug 100 im Notbetriebsmodus arbeiten kann. In diesem Fall kann der Prozess 300 zu Block 320 übergehen. Wenn der Prozessor 135 feststellt, dass das Trägerfahrzeug 100 nach dem Aufprall nicht im Notbetriebsmodus arbeiten kann, kann der Prozess 300 zu Block 315 übergehen.
-
Bei Block 315 fordert das Steuersystem 105 Hilfe an. Beispielsweise kann der Prozessor 135 der Kommunikationsschnittstelle 125 befehlen, eine Nachricht an einen Notfalldienstleister, den Fahrzeugeigentümer oder beide zu übermitteln. Der Notfalldienstleister kann ein Abschleppdienst, die Polizei, die Feuerwehr, ein Krankenwagen usw. sein. Die Nachricht kann über das Kommunikationsnetz 115 an den Notfalldienstleister übermittelt werden. Die Nachricht kann den Standort des Trägerfahrzeugs 100 sowie weitere Informationen, wie beispielsweise den Zustand des Trägerfahrzeugs 100 (z. B. das Ausmaß des Schadens am Trägerfahrzeug 100 aufgrund des Aufpralls), beinhalten. Der Prozess 300 kann nach Block 315 enden.
-
Bei Block 320 führt das Steuersystem 105 einen Selbstdiagnosetest durch. Der Selbstdiagnosetest ist ein Satz von vom Prozessor 135 ausgeführten Anweisungen, um festzustellen, ob der Prozessor 135 (insbesondere jeder Kern 150 des Prozessors 135), der Speicher 130 oder beide richtig funktionieren. Der Prozessor 135 führt den Selbstdiagnosetest durch, indem er z. B. feststellt, ob der Speicher 130 fehlerhaft ist, ob einer der Kerne 150 des Prozessors 135 ausgefallen ist, usw. Das Feststellen, ob der Speicher 130 fehlerhaft ist, kann das Schreiben einer Abfolge von Bits an den Speicher 130 und das Zurücklesen dieser Abfolge von Bits durch den Prozessor 135 beinhalten, um festzustellen, ob der Speicher 130 in der Lage war, die korrekte Abfolge von Bits präzise zu speichern. Das Feststellen, ob einer oder mehrere der Kerne 150 ausgefallen sind, kann beinhalten, dass jeder der Kerne 150 durch den Prozessor 135 veranlasst wird, verschiedene Operationen oder Berechnungen durchzuführen. Falls einer oder mehrere der Kerne 150 nicht in der Lage sind, die Operation oder Berechnung durchzuführen, kann der Selbstdiagnosetest anzeigen, dass der Kern 150, der nicht in der Lage war, die Operation oder Berechnung durchzuführen, ausgefallen ist.
-
Bei Entscheidungsblock 325 stellt das Steuersystem 105 fest, ob der Prozessor 135 den Selbstdiagnosetest bestanden hat. Zum Beispiel kann der Prozessor 135 feststellen, ob der Speicher 130 die richtige Abfolge von Bits geschrieben hat, ob die Kerne 150 in der Lage waren, die verschiedenen Operationen oder Berechnungen durchzuführen usw. Wenn dies der Fall ist, kann der Prozessor 135 feststellen, dass der Selbstdiagnosetest bestanden wurde und der Prozess 300 kann zu Block 330 übergehen. Wenn der Prozessor 135 den Selbstdiagnosetest nicht besteht, kann der Prozess 300 zu Block 335 übergehen.
-
Bei Block 330 gibt das Steuersystem 105 Steuersignale aus, um verschiedene Fahrzeugteilsysteme 145 im Notbetriebsmodus zu steuern. Das heißt der Prozessor 135 gibt Steuersignale aus, um verschiedene autonome Fahrzeugbetriebsfunktionen, die mit dem Betreiben des Trägerfahrzeugs 100 im Notbetriebsmodus verbunden sind, zu starten. Die Steuersignale können Steuersignale zum Betreiben von Lenkung, Beschleunigung und Bremsen des Trägerfahrzeugs 100 gemäß z. B. von Sensoren, wie beispielsweise einem Lidarsensor, einem Radarsensor, einer Kamera oder einem Ultraschallsensor, empfangenen Signalen beinhalten. Die Steuersignale können auch gemäß einem Navigationssystem, wie beispielsweise einem GPS (Global Positioning System), erzeugt und ausgegeben werden, das den aktuellen Standort des Trägerfahrzeugs 100, den Zielort des Trägerfahrzeugs 100 und eine Route vom aktuellen Standort zum Zielort feststellen kann.
-
Bei Entscheidungsblock 335 stellt das Steuersystem 105 fest, ob ein Kern-Flash anzufordern ist. Der Prozessor 135 kann basierend auf den Ergebnissen des Selbstdiagnosetests feststellen, dass ein Kern-Flash angefordert werden sollte. Beispielsweise kann der Prozessor 135 den Kern-Flash anfordern, wenn z. B. der Speicher 130 in der Lage ist, Daten zu speichern, und der mit einem oder mehreren Kernen 150 verbundene Ausfall durch ein Flashen des Kerns 150 behoben werden kann. Der Prozessor 135 kann den Kern-Flash eventuell nicht anfordern, wenn z. B. der Speicher 130 zu fehlerhaft ist, um Daten richtig zu speichern, oder ein vorheriges Flashen versucht wurde, der Kern 150 jedoch den Selbstdiagnosetest immer noch nicht bestanden hat. Der Prozess 300 kann zu Block 340 übergehen, um den Flash vom Fernserver 110 anzufordern. Der Prozess 300 kann zu Block 345 übergehen, wenn der Prozessor 135 entscheidet, keinen Flash vom Fernserver 110 anzufordern, was geschehen kann, wenn Block 340 bereits von einem vorherigen Durchgang des Prozesses 300 ausgeführt wurde.
-
Bei Block 340 fordert das Steuersystem 105 den Kern-Flash vom Fernserver 110 an. Das heißt der Prozessor 135 kann der Kommunikationsschnittstelle 125 befehlen, eine Nachricht an den Fernserver 110 mit Anforderung des Kern-Flashs zu übermitteln. Die den Kern-Flash anfordernde Nachricht kann über das Kommunikationsnetz 115 an den Fernserver 110 übermittelt werden. Als Reaktion darauf kann der Fernserver 110 den Kern 150, den Speicher 130 oder beide flashen, indem er über das Kommunikationsnetz 115 neue Anweisungen an das Trägerfahrzeug 100 übermittelt. Die Kommunikationsschnittstelle 125 kann die neuen Anweisungen an den Prozessor 135 weiterleiten, der die neuen Anweisungen in den Kern 150, den Speicher 130 oder beide hochladen kann. Der Prozess 300 kann zu Block 320 übergehen, sodass der Prozessor 135 einen anschließenden Selbstdiagnosetest durchführen kann; das heißt, sodass der Prozessor 135 feststellen kann, ob die Probleme, die dazu geführt haben, dass der Prozessor 135 den Selbstdiagnosetest nicht bestand, durch den Kern-Flash gelöst wurden. Während er darauf wartet, dass der Kern-Flash abgeschlossen wird, kann der Prozessor 135 anfordern, dass der Fernserver 110 das Verarbeiten von einer oder mehreren autonomen Fahrzeugbetriebsfunktionen, die ansonsten von dem Kern 150 gehandhabt würden, aus der Ferne handhabt, zumindest bis der Kern-Flash abgeschlossen ist.
-
Bei Block 345 fordert das Steuersystem 105 eine Femverarbeitung des Trägerfahrzeugs 100 an, um im Notbetriebsmodus zu arbeiten. Der Prozessor 135 kann der Kommunikationsschnittstelle 125 befehlen, über das Kommunikationsnetz 115 eine Anforderung zur Femverarbeitung an den Fernserver 110 zu übermitteln. Der Prozessor 135 kann der Kommunikationsschnittstelle 125 auch befehlen, Signale mit Daten, die mit dem Betrieb des Trägerfahrzeugs 100 im Notbetriebsmodus verbunden sind, an der Fernserver 110 zu übermitteln. Die Daten können z. B. von Autonomiesensoren, wie beispielsweise einem Lidarsensor, einem Radarsensor, einer Kamera, einem Ultraschallsensor usw., erzeugt werden. Weitere an den Fernserver 110 übermittelte Daten können die Geschwindigkeit des Trägerfahrzeugs 100, die Stellung des Lenkrads, die Stellung des Gaspedals, die Stellung des Bremspedals usw. beinhalten.
-
Bei Block 350 empfängt das Steuersystem 105 Steuersignale vom Fernserver 110 und steuert das Trägerfahrzeug 100 entsprechend. Wie oben erörtert, verarbeitet der Fernserver 110 die vom Trägerfahrzeug 100 empfangenen Daten und erzeugt und übermittelt als Reaktion darauf über das Kommunikationsnetz 115 Steuersignale an das Steuersystem 105. Die Kommunikationsschnittstelle 125 kann die Steuersignale über das Fahrzeugnetz 140 an den Prozessor 135 oder die entsprechenden Teilsysteme 145 weiterleiten. Zum Beispiel können Steuersignale für das Lenkrad an den Lenkaktor übermittelt werden, können Steuersignale für das Gaspedal an den Gaspedalaktor übermittelt werden, können Steuersignale für das Bremspedal an den Bremspedalaktor übermittelt werden, oder ähnliches. Somit können die am Ausführen des Notbetriebsmodus beteiligten Teilsysteme 145 weiter arbeiten, obwohl der mit diesen Betriebsfunktionen verbundene Kern 150 ausgefallen ist. Der Prozess 400 kann damit fortfahren, Block 335 und 340 auszuführen, bis das Trägerfahrzeug 100 an seinem Zielort ankommt.
-
Im Allgemeinen können die beschriebenen Rechensysteme und/oder -vorrichtungen eine beliebige Zahl von Computerbetriebssystemen einsetzen, einschließlich, jedoch in keiner Weise beschränkt auf, Versionen und/oder Abwandlungen der Anwendung Ford Sync®, AppLink/Smart Device Link Middleware, des Betriebssystems Microsoft Automotive®, des Betriebssystems Microsoft Windows®, des Betriebssystems Unix (z. B. des von Oracle Corporation aus Redwood Shores, Kalifornien, vetriebenen Betriebssystems Solaris®), des von International Business Machines aus Armonk, New York, vertriebenen Betriebssystems AIX UNIX, des Betriebssystems Linux, der von Apple Inc. aus Cupertino, Kalifornien, vertriebenen Betriebssysteme Mac OSX und iOS, des von Blackberry, Ltd. aus Waterloo, Kanada, vertriebenen BlackBerry OS, und des von Google, Inc. und der Open Handset Alliance entwickelten Betriebssystems Android, oder der von QNX Software Systems angebotenen QNX® CAR Platform for Infotainment. Beispiele von Rechenvorrichtungen beinhalten, ohne darauf beschränkt zu sein, einen bordeigenen Fahrzeugcomputer, eine Computer-Workstation, einen Server, einen Desktop-, Notebook-, Laptop- oder tragbaren Computer, oder irgendein anderes Rechensysteme und/oder irgendeine andere Rechenvorrichtung.
-
Rechenvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen von einer oder mehreren Rechenvorrichtungen, wie den oben aufgeführten, ausführbar sein können. Computer-ausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die mithilfe einer Vielzahl von Programmiersprachen und/oder Technologien erstellt wurden, einschließlich unter anderem und entweder allein 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 Dalvik Virtual Machine oder ähnlichen, kompiliert und ausgeführt werden. 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, wobei er einen oder mehrere Prozesse durchführt, einschließlich einen oder mehrere der hierin beschriebenen Prozesse. Derartige Anweisungen und andere Daten können mithilfe einer Vielzahl von computerlesbaren Medien gespeichert und übermittelt werden.
-
Ein computerlesbares Medium (auch als ein prozessorlesbares Medium bezeichnet) beinhaltet jedes beliebige permanente (z. B. materielle) Medium, das am Bereitstellen von Daten (z. B. Anweisungen) teilnimmt, die von einem Computer (z. B. einem Prozessor eines Computers) gelesen werden können. Ein derartiges Medium kann viele Formen annehmen, einschließlich unter anderem nichtflüchtige Medien und flüchtige Medien. Zu nichtflüchtigen Medien können zum Beispiel optische oder Magnetplatten und andere dauerhafte Speicher gehören. Zu flüchtigen Medien kann zum Beispiel Dynamic Random Access Memory (DRAM) gehören, der in der Regel einen Hauptspeicher darstellt. Derartige Anweisungen können von einem oder mehreren Übermittlungsmedien übermittelt werden, einschließlich Koaxialkabeln, Kupferkabeln und Glasfaser, einschließlich der Kabel, die einen mit einem Prozessor eines Computers gekoppelten Systembus umfassen. Zu den üblichen Formen von computerlesbaren Medien gehören beispielsweise eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband, jedes beliebige andere magnetische Medium, eine CD-ROM, eine DVD, jedes beliebige andere optische Medium, Lochkarten, Lochstreifen, jedes beliebige andere physische Medium mit Mustern oder Löchern, ein RAM, ein PROM, ein EPROM, ein FLASH, ein EEPROM, jeder beliebige andere Speicherchip oder jede beliebige andere Speicherkassette, oder jedes beliebige andere Medium, das ein Computer ablesen kann.
-
Datenbanken, Datenbestände oder andere hierin beschriebene Datenspeicher können verschiedene Arten von Mechanismen zum Zugreifen auf, Speichern und Abrufen verschiedener Arten von Daten beinhalten, einschließlich einer hierarchischen Datenbank, einem Satz von Dateien in einem Dateisystem, eine Anwendungsdatenbank in einem proprietären Format, ein relationales Datenbankmanagementsystem (RDBMS) usw. Jeder derartige Datenspeicher ist im Allgemeinen in einer Rechenvorrichtung enthalten, die ein Computerbetriebssystem, wie eines der oben genannten, einsetzt, und es wird über ein Netzwerk auf eine beliebige oder mehrere einer Vielzahl von Weisen darauf zugegriffen. Auf ein Dateisystem kann von einem Computerbetriebssystem aus zugegriffen werden und kann in verschiedenen Formaten gespeicherte Dateien beinhalten. Ein RDBMS setzt im Allgemeinen die Structured Query Language (SQL) ein, zusätzlich zu einer Sprache zum Erzeugen, Speichern, Bearbeiten und Ausführen von gespeicherten Prozeduren, wie beispielsweise die oben genannte PL/SQL-Sprache.
-
Bei einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Servern, Personal Computern usw.) umgesetzt sein, die auf damit verbundenen computerlesbaren Medien (z. B. Platten, Speichern usw.) gespeichert sind. Ein Computerprogrammprodukt kann derartige Anweisungen umfassen, die auf computerlesbaren Medien zum Ausführen der hierin beschriebenen Funktionen gespeichert sind.
-
In Bezug auf die hierin beschriebenen Prozesse, Systeme, Heuristiken usw. versteht sich, dass obwohl die Schritte derartiger Prozesse usw. als gemäß einer bestimmten geordneten Abfolge erfolgend beschrieben wurden, derartige Prozesse mit den beschriebenen Schritten in einer anderen Reihenfolge als der hierin beschriebenen Reihenfolge umgesetzt werden könnten. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten, oder dass bestimmte hierin beschriebene Schritte weggelassen werden könnten. Mit anderen Worten, die Beschreibungen der hierin angegebenen Prozesse werden zum Zwecke der Veranschaulichung bestimmter Ausführungsformen bereitgestellt und sind in keiner Weise als die Patentansprüche einschränkend auszulegen.
-
Demgemäß versteht sich, dass die obige Beschreibung veranschaulichend und nicht einschränkend gedacht ist. Viele Ausführungsformen und Anwendungen neben den bereitgestellten Beispielen erschließen sich aus der obigen Beschreibung. Der Geltungsumfang sollte nicht bezugnehmend auf die obige Beschreibung, sondern vielmehr bezugnehmend auf die beigefügten Patentansprüche zusammen mit dem vollen Umfang von Äquivalenten, zu denen diese Patentansprüche berechtigt sind, festgestellt werden. Es wird vorweggenommen und beabsichtigt, dass zukünftige Weiterentwicklungen an den hierin erörterten Technologien stattfinden werden und dass die offenbarten Systeme und Verfahren in solche zukünftigen Ausführungsformen mit aufgenommen werden. Zusammenfassend versteht sich, dass die Anwendung zu Modifikationen und Abwandlungen fähig ist.
-
Bei allen in den Patentansprüchen verwendeten Begriffen wird davon ausgegangen, dass ihre übliche Bedeutungen von Fachleuten der hierin beschriebenen Technologien verstanden werden, sofern nichts Gegenteiliges hierin ausdrücklich genannt wird. Insbesondere gilt die Verwendung der Artikel in der Einzahl, wie „ein(er/s) “und „der/die/das “usw. sowie all ihrer grammatikalischen Formen, als eines oder mehrere der genannten Elemente bezeichnend, sofern in einem Patentanspruch keine gegenteilige Einschränkung genannt wird.
-
Die Zusammenfassung wird bereitgestellt, um es dem Leser zu ermöglichen, die Natur der technischen Offenbarung rasch zu erfassen. Sie wird unter der Maßgabe geliefert, dass sie nicht dazu verwendet wird, den Umfang oder die Bedeutung der Patentansprüche zu interpretieren oder einzuschränken. Außerdem wird in der vorstehenden detaillierten Beschreibung ersichtlich, dass verschiedene Merkmale in verschiedenen Ausführungsformen zusammen gruppiert sind, um die Offenbarung übersichtlicher zu machen. Dieses Offenbarungsverfahren ist nicht als eine Absicht enthaltend zu interpretieren, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als die ausdrücklich in jedem Patentanspruch genannten. Vielmehr liegt der erfindungsgemäße Gegenstand in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Patentansprüche zeigen. Daher werden die folgenden Patentansprüche in die detaillierte Beschreibung mit aufgenommen, wobei jeder Anspruch alleine für sich als ein separat beanspruchter Gegenstand steht.
