DE102022126408A1

DE102022126408A1 - Fahrdienstunterstützung für elektrische autonome fahrzeuge

Info

Publication number: DE102022126408A1
Application number: DE102022126408.4A
Authority: DE
Inventors: Oliver Lei; Arpita Chand; Somak Datta Gupta; Vladyslav Slyusar; Jayanthi Rao
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2021-10-12
Filing date: 2022-10-11
Publication date: 2023-04-13
Also published as: US20230110300A1; CN115958995A; US12037021B2

Abstract

Ein autonomes Fahrzeug kann bestimmen, dass es einen verbleibenden Leistungsbetrag aufweist, der der Vorhersage nach benötigt wird, um einen Aufladepunkt durch autonomes Fortbewegen mit deaktivierten vordefinierten Systemen zu erreichen. Das Fahrzeug kann die vordefinierten Systeme deaktivieren und sich zu dem Aufladepunkt fortbewegen. Im Anschluss an das Deaktivieren kann das autonome Fahrzeug bestimmen, dass es nicht mehr den verbleibenden Leistungsbetrag aufweist, der der Vorhersage nach benötigt wird, um den Aufladepunkt zu erreichen. Das Fahrzeug kann dann mit einem Server kommunizieren und Unterstützung anfordern. Das Fahrzeug kann sich dann zu einem angewiesenen Treffpunkt mit einem zweiten autonomen Fahrzeug fortbewegen, wobei der Treffpunkt von dem Server empfangen wurde. Die zwei Fahrzeuge können dann als Reaktion darauf, dass sich das erste und das zweite autonome Fahrzeug innerhalb eines Kommunikationsbereichs befinden, kommunizieren, um es dem ersten Fahrzeug zu ermöglichen, eine Fähigkeit des zweiten autonomen Fahrzeugs zu Nutze zu machen, wobei es dem ersten Fahrzeug ermöglicht wird, den Aufladepunkt durch das Zunutzemachen zu erreichen.

Description

GEBIET DER TECHNIK
Die veranschaulichenden Ausführungsformen betreffen Fahrdienstunterstützung für elektrische autonome Fahrzeuge.
ALLGEMEINER STAND DER TECHNIK
Batterieelektrofahrzeuge (battery electric vehicles - BEVs) entwickeln sich als bevorzugte Transportquelle für die Zukunft, insbesondere in Bezug auf autonome Fahrzeuge. Sie haben das Potential, durch bordeigene Batterien eine große Menge an Energie zu speichern, die sowohl von den Rechensystemen als auch vom Fahrzeug selbst verwendet werden kann, um die Fortbewegung anzutreiben. Unter bestimmten Umständen kann jedoch die Tatsache, dass die bordeigenen Computer und Sensoren aus der gleichen Leistungsquelle wie das Fahrzeug beziehen, ein Problem darstellen, wenn die Leistungsreserven gering sind und sich das Fahrzeug nicht in der Nähe eines Betankungspunkts befindet.
BEVs und/oder batteriebetriebene autonome Fahrzeuge (battery electric electrical vehicles - BEAVs) erfahren erhebliche Fahrreichweiten bei ihrer internen Leistungsversorgung. Der einzige mögliche Nachteil besteht darin, dass Elektrizität im Gegensatz zu Benzin tendenziell weniger eine tragbare Betankungsoption ist. Dementsprechend ist es am besten, wenn ein BEV bei einem bestimmten Leistungsschwellenwert bleibt, um sicherzustellen, dass es nicht entfernt von einem Aufladepunkt liegenbleibt. Während es in dicht besiedelten Gebieten, in denen ein Aufladen besser verfügbar sein kann, weniger ein Problem darstellt, gibt es immer noch große Landflächen, in denen ein Aufladen begrenzt bis gar nicht verfügbar ist. Wenn das BEV ein BEAV ist, können die fahrzeuginternen Rechenressourcen, die das Fahrzeug antreiben, ebenfalls eine erhebliche Leistung verbrauchen, was die Reichweite verringern kann. Wenn sich zum Beispiel eine Person von einer Großstadt über eine lange Strecke von relativ unbewohntem Gelände zu einer anderen fortbewegt, muss eine Planung vorgenommen werden, um sicherzustellen, dass die Rechenressourcen plus die Fortbewegung das Fahrzeug nicht an einem Ort liegenbleiben lassen, an dem es möglicherweise sehr schwierig ist, zusätzliche Leistung zu erhalten.
Diese Fahrzeuge können innerhalb einer On-Demand-Flotte auch auf Grundlage von demografischen Merkmalen der Fortbewegung umfunktioniert werden, was eine Neupositionierung um einen breiten geografischen Ort herum im Laufe eines Tages oder einer Woche erfordert, je nachdem, wo sie benötigt werden. Selbst ohne einen Fahrgast würde ein Flottenbesitzer jedoch nicht wollen, dass das Fahrzeug liegenbleibt. Da die erneute Leistungsversorgung möglicherweise nicht jedes Mal sofort verfügbar ist, wenn ein Fahrzeug seinen Standort ändern oder eine lange Strecke zurücklegen muss, können Fahrzeuge damit beauftragt werden, ein Ziel zu erreichen, das einen Schwellenwert ihrer Reichweite überschreitet. Jegliche unerwartete Verzögerungen oder Umwege können dann dazu führen, dass das Fahrzeug eine Leistung verbraucht. Wenn sich ein Aufladepunkt in der Nähe einer Strecke befindet, wenn dies auftritt, kann das Fahrzeug eine andere Route planen. Wenn jedoch keine derartige Station vorhanden ist, kann es sein, dass das Fahrzeug nicht selbst zu einer weiter entfernten Station navigieren kann. Und wenn kein sachkundiger Fahrer anwesend ist, kann das Fahrzeug nicht auch manuell gefahren werden, sodass es das autonome Merkmal nicht einfach deaktivieren kann, um Leistung zu sparen, während eine Person das Fahrzeug zu dem weiteren Betankungspunkt fährt.
KURZDARSTELLUNG
In einem ersten veranschaulichenden Beispiel beinhaltet ein System einen Prozessor, der zum Empfangen einer Anforderung zur Fortbewegungsunterstützung von einem ersten autonomen Fahrzeug, die einen niedrigen Leistungszustand des ersten autonomen Fahrzeugs angibt, konfiguriert ist. Der Prozessor ist außerdem zum Bestimmen eines Aufladepunkts zur Verwendung durch das erste autonome Fahrzeug konfiguriert. Der Prozessor ist ferner konfiguriert zum Bestimmen der Leistung, die erforderlich ist, damit das erste autonome Fahrzeug den Aufladepunkt erreicht, und zwar unter einem oder mehreren Leistungserhaltungszuständen, die durch das erste autonome Fahrzeug aktivierbar sind, und Bestimmen eines zweiten autonomen Fahrzeugs für mindestens einen der Leistungserhaltungszustände, das Unterstützung für das erste autonome Fahrzeug auf eine für den mindestens einen Leistungserhaltungszustand vordefinierte Weise bereitstellen kann und das es dem ersten autonomen Fahrzeug ermöglicht, den Aufladepunkt zu erreichen. Der Prozessor ist zusätzlich konfiguriert zum Anweisen des zweiten autonomen Fahrzeugs, sich mit dem ersten autonomen Fahrzeug an einem bestimmten Treffpunkt zu treffen.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein erstes autonomes Fahrzeug einen Prozessor, der dazu konfiguriert ist, zu bestimmen, dass ein gegenwärtiger Leistungspegel geringer als ein prognostizierter Leistungspegel ist, der benötigt wird, um einen Aufladepunkt zu erreichen. Der Prozessor ist zudem dazu konfiguriert, Unterstützung von einem entfernten Server anzufordern. Ferner ist der Prozessor konfiguriert zum Empfangen von Treffanweisungen, einschließlich eines Treffpunkts für ein zweites autonomes Fahrzeug, als Reaktion auf die Anforderung und Ausführen einer Fortbewegung zum Treffpunkt. Der Prozessor ist konfiguriert zum direkten Kommunizieren mit dem zweiten autonomen Fahrzeug, wenn sich sowohl das erste als auch das zweite autonome Fahrzeug innerhalb einer kommunizierbaren Reichweite voneinander befinden, und Auslagern von mindestens einer von Rechen- oder Erfassungsaufgaben auf das zweite autonome Fahrzeug, wobei das zweite autonome Fahrzeug eine Antwort auf die ausgelagerte Aufgabe bereitstellt, die ermöglicht, dass das erste autonome Fahrzeug die autonome Fortbewegung unter Verwendung der Antwort fortsetzt. Zusätzlich ist der Prozessor konfiguriert zum Fortsetzen von Folgendem: Auslagern von mindestens einer von Rechen- oder Erfassungsaufgaben auf das zweite autonome Fahrzeug; Empfangen von Antworten auf die ausgelagerten Aufgaben; und autonomen Fortbewegen unter Verwendung der Antworten, bis das erste autonome Fahrzeug mindestens einen von dem Aufladepunkt oder einem Standort in der Nähe des Aufladepunkts erreicht, an dem das erste autonome Fahrzeug prognostiziert, dass der gegenwärtige Leistungspegel über dem prognostizierten Leistungspegel liegt, der benötigt wird, um den Aufladepunkt zu erreichen.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein Verfahren Bestimmen an Bord eines ersten autonomen Fahrzeugs, dass das erste autonome Fahrzeug einen verbleibenden Leistungsbetrag aufweist, der der Vorhersage nach benötigt wird, um einen Aufladepunkt durch Fortbewegen mit einem oder mehreren deaktivierten vordefinierten Systemen zu erreichen, die noch immer autonome Fortbewegung ermöglichen. Das Verfahren beinhaltet zudem Deaktivieren der vordefinierten Systeme und Fortbewegen in Richtung des Aufladepunkts. Ferner beinhaltet das Verfahren Bestimmen nach dem Deaktivieren, dass das erste autonome Fahrzeug nicht mehr den verbleibenden Leistungsbetrag aufweist, der der Vorhersage nach benötigt wird, um den Aufladepunkt zu erreichen, der von einem gegenwärtigen Standort des ersten autonomen Fahrzeugs erneut prognostiziert wird. Das Verfahren beinhaltet zusätzlich Kommunizieren mit einem Server und Anfordern von Unterstützung als Reaktion darauf, dass das erste autonome Fahrzeug nicht mehr den verbleibenden Leistungsbetrag aufweist. Ferner beinhaltet das Verfahren Empfangen von Treffanweisungen, einschließlich eines Treffpunkts, zum Zusammenkommen mit einem zweiten autonomen Fahrzeug als Reaktion auf das Anfordern. Außerdem beinhaltet das Verfahren Zunutzemachen, an dem ersten autonomen Fahrzeug, einer Fähigkeit des zweiten autonomen Fahrzeugs als Reaktion darauf, dass sich das erste und das zweite autonome Fahrzeug innerhalb des Kommunikationsbereichs befinden, wobei es dem ersten Fahrzeug ermöglicht wird, den Aufladepunkt durch das Zunutzemachen zu erreichen.
Figurenliste

1 zeigt ein veranschaulichendes Beispiel eines BEAV-Flottenverwaltungssystems für mehrere Fahrzeuge;
2 zeigt einen veranschaulichenden Prozess für einen Fahrzeugunterstützungsvorgang;
3 zeigt einen veranschaulichenden Warnungshandhabungsprozess; und
4 zeigt einen veranschaulichenden Assistenzwarteschlangenhandhabungsprozess.

DETAILLIERTE BESCHREIBUNG
In dieser Schrift werden Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale könnten vergrößert oder verkleinert dargestellt sein, um Details konkreter Komponenten zu zeigen. Daher sind in dieser Schrift offenbarte spezifische strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann den vielfältigen Einsatz der vorliegenden Erfindung zu lehren. Für den Durchschnittsfachmann versteht es sich, dass verschiedene Merkmale, die unter Bezugnahme auf eine beliebige der Figuren veranschaulicht und beschrieben sind, mit Merkmalen kombiniert werden können, die in einer oder mehreren anderen Figuren veranschaulicht sind, um Ausführungsformen zu produzieren, die nicht ausdrücklich veranschaulicht oder beschrieben sind. Die veranschaulichten Kombinationen von Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Verschiedene Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung vereinbar sind, könnten jedoch für konkrete Anwendungen oder Umsetzungen gewünscht sein.
Zusätzlich dazu, dass beispielhafte Prozesse durch ein Fahrzeugrechensystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die beispielhaften Prozesse in gewissen Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann eine drahtlose Vorrichtung (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein entferntes Rechensystem (z. B. und ohne Einschränkung einen Server), das durch die drahtlose Vorrichtung verbunden ist, beinhalten, ist aber nicht darauf beschränkt.Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (Vehicle Associated Computing Systems - VACS) bezeichnet werden.In bestimmten Ausführungsformen können bestimmte Komponenten des VACS abhängig von der konkreten Umsetzung des Systems konkrete Abschnitte eines Prozesses durchführen.Falls ein Prozess beispielsweise und ohne Beschränkung einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Abschnitt des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Der Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine bestimmte Lösung anzuwenden.
Die Ausführung von Prozessen kann durch die Verwendung eines oder mehrerer Prozessoren erleichtert werden, die allein oder in Verbindung miteinander arbeiten und Anweisungen ausführen, die auf verschiedenen nichttransitorischen Speichermedien gespeichert sind, wie etwa Flash-Speicher, programmierbarem Speicher, Festplattenlaufwerken usw., aber nicht darauf beschränkt. Die Kommunikation zwischen Systemen und Prozessen kann zum Beispiel die Verwendung von Bluetooth, Wi-Fi, Mobilfunkkommunikation und anderer geeigneter drahtloser und drahtgebundener Kommunikation beinhalten.
In jeder der in dieser Schrift erörterten veranschaulichenden Ausführungsformen ist ein beispielhaftes, nicht einschränkendes Beispiel für einen durch ein Rechensystem durchführbaren Prozess gezeigt. In Bezug auf jeden Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, für den begrenzten Zweck des Ausführens des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert wird. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden, sondern sind als Beispiele für Arten von Prozessen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu erzielen. Je nach Wunsch können zusätzliche Schritte zu den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
In Bezug auf die veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind, die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor vorübergehend als Spezialprozessor zum Zwecke des Ausführens einiger oder aller der beispielhaften Verfahren, die durch diese Figuren gezeigt sind, befähigt werden kann. Wenn er Code ausführt, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend so lange zum Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann in geeignetem Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor agiert, den Prozessor dazu veranlassen, als Spezialprozessor zu agieren, der zum Zwecke des Durchführens des Verfahrens oder einer sinnvollen Variation davon bereitgestellt wird.
Da Fahrzeugen die Leistung ausgehen kann, wenn sie lange Strecken von der verfügbaren Aufladung entfernt fahren, ist es nützlich, über Optionen zum Verhindern eines vollständigen Leistungsverlusts zu verfügen. Wenn das Elektrofahrzeug ein BEAV ist, kann es nicht besetzt sein oder es kann kein sachkundiger Fahrer (Minderjähriger oder Fahrgast ohne Führerschein) anwesend sein, weshalb eine einfache Lösung zum Abschalten der autonomen Funktionen und Ermöglichen, dass ein Fahrgast zu einem bestimmten Aufladepunkt fährt, womöglich nicht möglich ist. Gleichzeitig kann das Fahrzeug ohne Sensorführung und -berechnung typischerweise nicht selbst fahren, und somit kann es ohne einen Abschleppwagen begrenzte Optionen geben, wenn ein Fahrzeug unerwartet zu wenig Leistung aufweist.
Eine sorgfältige Planung kann viele dieser Situationen vermeiden, aber Verkehrsverzögerungen, unerwartete Verkürzung der Batterielebensdauer, unerwartete Umwege usw. können immer noch zu Situationen führen, in denen ein Fahrzeug nicht über ausreichend Leistung verfügt, um selbst zu einem Aufladepunkt zu fahren, wodurch mehr als der verbleibende Leistungsbetrag benötigt wird, um sowohl das Fahrzeug mit Leistung zu versorgen als auch das notwendige Erfassen und Berechnen durchzuführen.
Es ist wahrscheinlich, dass nicht alle Fahrzeuge konstant aufgeladen werden können, weshalb sich zwangsläufig Fahrzeuge in Zuständen mit mittlerer oder geringer Leistung auf der Straße befinden. Fahrgäste können Fahrzeuge auch auf unerwartete Weise umleiten, und die Bedingungen eines Reisevertrags können die Fähigkeit des Fahrzeugs zum Aufladen einschränken, während ein Insasse anwesend ist, da das Aufladen typischerweise eine relativ lange Dauer (im Verhältnis zur Fortbewegungszeit) in Anspruch nimmt.
Ein vorgeschlagenes Lösungskonzept, das in einem veranschaulichenden Beispiel über die Ausführungsformen in dieser Schrift gezeigt ist, ermöglicht es einem zweiten Fahrzeug, das eine höhere Leistung aufweist, das BEAV beim Erreichen eines Ziels zu unterstützen. Während es möglicherweise nicht immer möglich ist, zu Beginn einer Fahrt zu prognostizieren, dass ein Fahrzeug zu wenig Leistung aufweist, sind aktuelle Leistungsreserven ein bekanntes Gut, und es kann vernünftiger sein, zu wissen, wann einem Fahrzeug wahrscheinlich die Leistung ausgeht oder es einen kritischen Leistungszustand erreicht, bevor ein Aufladepunkt erreicht wird. Das heißt, sobald eine Fahrt im Gange ist, werden die Auswirkungen von unerwarteten Verspätungen und Umwegen beobachtet und der wahrscheinliche Leistungsbetrag, der benötigt wird, um eine Fahrt von einem beliebigen Punkt aus abzuschließen, ist bestimmbar. Die Variabilität dieser Zahl kann abnehmen, wenn sich ein Fahrzeug einem Ziel nähert, was die positive Wirkung einer genaueren Vorhersage haben kann, die jedoch auch aufzeigen kann, dass eine ursprüngliche Vorhersage in einer Weise falsch war, die das Fahrzeug liegenbleiben lassen kann.
Wenn die Wahrscheinlichkeit eines derartigen Vorkommnisses zunimmt (z. B. wenn das Fahrzeug sich weiter fortbewegt, aber die Leistungsnutzung über dem liegt, was erwartet wurde, und begrenzte Reserven zu verbleiben scheinen), kann ein zentrales Verwaltungssystem Abschwächungsmaßnahmen ergreifen, um einen vollständigen Leistungsverlust zu vermeiden, während sich das Fahrzeug noch immer fortbewegt. In diesem Beispiel beinhaltet dies das Beauftragen eines anderen Fahrzeugs, dem BEAV Unterstützung bereitzustellen, um es zu einem Ziel zu führen, indem es das beinahe entladene Fahrzeug führt und als Führung dient, was verteiltes Erfassen und Berechnen beinhalten kann (wobei das vorausfahrende Fahrzeug für das hinterherfahrende Fahrzeug erfasst und berechnet) und/oder indem das hinterherfahrende Fahrzeug das vorausfahrende Fahrzeug auf eine Weise verfolgt (die effektiv auf eine Weise wirkt, die einem Fahrzeug ähnlich ist, das ein anderes auf einem Anhänger zieht), wobei Erfassungs- und Rechenprozesse ausgeschaltet sind, um Energie zu sparen.
Im vorherigen Beispiel kann ein gewisser Betrag an Erfassung und Berechnung auf das vorausfahrende Fahrzeug ausgelagert werden und das vorausfahrende Fahrzeug kann überschüssige Leistung verwenden, um Erfassungs- und Rechenprozesse für das hinterherfahrende Fahrzeug durchzuführen, wobei Daten zurück an das hinterherfahrende Fahrzeug gesendet werden können, wo eingeschränktes autonomes Fahren unter der Führung des vorausfahrenden Fahrzeugs durchgeführt werden kann. In dem letzteren Beispiel kann das hinterherfahrende Fahrzeug dem vorausfahrenden Fahrzeug dicht folgen, was auf eine Weise erfolgen kann, die ein Trennen der beiden Fahrzeuge vermeidet (z. B. Minimieren von Spurwechsel, Beschleunigung usw.). Da beide Fahrzeuge autonom sein können, kann das hinterherfahrende Fahrzeug über alle Entscheidungen informiert werden, bevor das vorausfahrende Fahrzeug die nächste Bewegung vornimmt, sodass es die Bewegung des vorausfahrenden Fahrzeugs antizipieren kann, was die Wahrscheinlichkeit einer Trennung der Fahrzeuge begrenzen sollte.
Es kann auch möglich sein, dass autonome Fahrzeuge aufgrund der Fähigkeit, die Handlungen anderer Fahrzeuge zu antizipieren, und aufgrund der Reaktionszeit von Computern viel enger zusammenfahren, als dies für manuell gefahrene Fahrzeuge empfohlen würde. Somit können die Fahrzeuge in der Lage sein, nahezu aufeinander abgestimmt zu agieren und sich nahe genug aneinander zu bewegen, um eine intervenierende Fahrzeuginterferenz zu vermeiden. Das vorausfahrende Fahrzeug, das weiß, dass es in einem der Modi (oder einem anderen ähnlichen Führungsmodus) funktioniert, kann Entscheidungen treffen, die der Situation Rechnung tragen, und Bewegungen einschränken, die die Gruppe wahrscheinlich trennen lassen (z. B. Begrenzen von Spurwechsel, Vorsicht an Ampeln, um die Gruppe nicht zu trennen, Benachrichtigung anderer kreuzender Fahrzeuge an einem Stoppschild usw.).
Wenn die Fahrzeuge getrennt werden, kann das hinterherfahrende Fahrzeug immer selbst zurück zum vorausfahrenden Fahrzeug fahren, das sich verlangsamt oder angehalten hat, um auf das hinterherfahrende Fahrzeug zu warten, es sei denn, die Leistung befindet sich in einem absolut kritischen Zustand. Und in Situationen wie Spurwechseln kann jedem Fahrzeug aus Vorsicht die volle Kontrolle zurückgegeben werden. Für den Großteil der Fortbewegung sollte das vorausfahrende Fahrzeug jedoch in der Lage sein, eine gewisse Rechen- und/oder Fahrlast von dem zweiten Fahrzeug zu nehmen und es dem zweiten Fahrzeug zu ermöglichen, eine erhöhte Reichweite durch Begrenzen der Verwendung von Rechensystemen mit hohem Stromverbrauch zu erlangen.
1 zeigt ein veranschaulichendes Beispiel eines BEAV-Flottenverwaltungssystems für mehrere Fahrzeuge. In diesem Beispiel beinhaltet ein Fahrzeug 100 ein bordeigenes Rechensystem 101, das unter anderem eine Telematiksteuereinheit 105 beinhalten kann, die zur Mobilfunkkommunikation verwendet werden kann. Das Fahrzeug 100 kann zudem einen BLUETOOTH-Sendeempfänger 107 und einen Wi-Fi-Sendeempfänger 109 beinhalten, die zur Kommunikation mit jeweiligen BLUETOOTH- und Wi-Fi-Vorrichtungen in der Nähe des Fahrzeugs 100 und innerhalb der Reichweite der jeweiligen Sendeempfänger verwendet werden können.
Das Fahrzeug 100 kann zudem eine Vielfalt an von bordeigenen Rechenprozessen 111 und 113 oder Modulen, Sensoren oder anderen leistungsintensiven Elementen beinhalten. Speicher, die diese Prozesse speichern, sowie Sensoren und/oder Module können durch einen oder mehrere Fahrzeugbusse 115 mit der CPU 103 verbunden sein. Das Fahrzeug 100 kann ferner einen GNSS-Empfänger 117, wie etwa einen GPS-Empfänger, beinhalten.
Der bestimmte gesamte Satz von Elementen innerhalb des Fahrzeugs 100 ist nicht der Gegenstand von Interesse, außer um sicherzustellen, dass das Fahrzeug zu einer Form der Kommunikation mit einem anderen Fahrzeug 120 und/oder der Cloud 140 in der Lage ist. Die Kommunikation könnte in einer Vielfalt an Formen bereitgestellt werden und muss nicht unbedingt eine herkömmliche drahtlose Kommunikation beinhalten. Wäre das Fahrzeug 100 zum Beispiel mit einer Kamera ausgestattet und wäre das Fahrzeug 120 mit nach hinten gerichteten Leuchten einer LED-Anordnung versehen, könnte das Fahrzeug 120 Informationen an das Fahrzeug 100 übermitteln, indem es einfach Muster einer Lichtanordnung ändert, was für das Fahrzeug 100 leistungseffizienter sein kann als das Verwenden von drahtloser Kommunikation, um große Datenpakete auszutauschen.
In einer Ausführungsform kann, während ausreichend Leistung in dem Fahrzeug 100 verbleibt, eine fortschrittlichere Form der Kommunikation verwendet werden, aber wenn die Leistung schwindet und ein Ziel nicht erreicht wurde, kann die Kommunikation vereinfachter werden, um die Leistung für das Fahren zu maximieren. Aktuelle Fahrbedingungen können ebenfalls berücksichtigt werden - ob sich das Fahrzeug 100 in der Nähe eines Betankungspunkts befindet und ob eine aktuelle Straße/Route für weniger detaillierte Steuerfunktionen geeignet ist (z. B. wenn das Fahrzeug 100 eher wie ein von einem Anhänger gezogenes Fahrzeug als ein autonomen Fahrzeug arbeitet). Nichtsdestotrotz ist es möglich, Informationen unter Verwendung einer Vielfalt an Kommunikationsmedien auszutauschen, die Licht oder sogar Ton beinhalten könnten, wiederum abhängig davon, ob die Bedingungen dies zulassen.
Das Fahrzeug 120 ist ein ähnliches Fahrzeug wie 100, wenngleich nicht notwendigerweise die gleiche Marke und das gleiche Modell. Wenn das Fahrzeug 120 Sensorinformationen und/oder -verarbeitung für das Fahrzeug 100 bereitstellen soll, kann die Cloud 140 vor dem Entsenden bestätigen, dass das Fahrzeug 120 für derartige Aufgaben geeignet ist (unter anderem auf Grundlage von Systemen, Konfiguration und gegenwärtigem Leistungszustand).
Das Fahrzeug 120 weist ein bordeigenes Rechensystem 121 auf, das auch eine CPU 123 und eine Vielfalt an Kommunikationssendeempfängern beinhaltet. Diese können eine TCU 125 zur Kommunikation mit der Cloud über Mobilfunksendeempfänger, BLUETOOTH-Sendeempfänger 127 und Wi-Fi-Sendeempfänger 129 zur Kommunikation mit einem anderen Fahrzeug 100 oder anderen lokalen Vorrichtungen beinhalten. Dieses Fahrzeug 120 kann auch einen GNSS-Sendeempfänger 131 beinhalten.
Die Cloud 140 kann eine Reihe von entfernten Prozessen beinhalten, wie etwa einen Zeitplaner 141. Der Zeitplaner kann für das Kommunizieren von Entsendeanweisungen an das Fahrzeug 100, 120 verantwortlich sein und kann Kommunikation bezüglich aktiver Aufträge von diesen Fahrzeugen (sowie anderer Kommunikation) empfangen. So kann zum Beispiel das Fahrzeug 100, das einen Insassen an Bord haben kann oder nicht, den Zeitplaner benachrichtigen, dass es (auf Grundlage einer gegenwärtigen bordeigenen Bewertung von nahegelegenen Leistungsquellen und eines gegenwärtigen Leistungszustands) unwahrscheinlich ist oder unter einem vordefinierten Schwellenwert prognostiziert wird, dass das Fahrzeug 100 in der Lage ist, einen Aufladepunkt zu erreichen, bevor ihm die Leistung ausgeht.
Diese Informationen können an einen Anforderungshandhabungsprozess 143 weitergegeben werden, der auf einen Leistungsplanungsprozess 147 zugreifen kann, um zu bestimmen, wie das möglicherweise liegengebliebene Fahrzeug 100 am besten zu unterstützen ist. Dies sind lediglich beispielhafte Prozesse, die zeigen, welche Arten von Backend-Bestimmungen auftreten können. Der Leistungsplanungsprozess kann berücksichtigen, wie viel Leistung von dem Fahrzeug 100 als verbleibend gemeldet wird, was verwendet werden kann, um verschiedene wahrscheinliche Bereiche basierend auf dem Abschalten bestimmter Systeme und/oder dem Offboarding bestimmter Aufgaben zu bestimmen. Für eine oder mehrere dieser Rekonfigurationen kann der Prozess auch bestimmen, welche Art von Fahrzeug (Merkmale, Leistungspegel, Nähe usw.) zur Unterstützung gesendet werden sollte.
Bestimmte Rekonfigurationen von 100 können erfordern, dass das Fahrzeug 120 bestimmte Sensoren beinhaltet. Andere können erfordern, dass bestimmte entfernte Rechenfunktionen in dem Fahrzeug 120 möglich sind. Noch andere Rekonfigurationen können erfordern, dass das Fahrzeug 120 eine einfache Kommunikationsfähigkeit und eine bestimmte Leistungsreserve aufweist. Selbst wenn der gegenwärtige Standort eines gegebenen Fahrzeugs 120 noch nicht bekannt ist, ist es möglich, die Anforderungen zu bestimmen und für jedes in Frage kommende Fahrzeug, das die Anforderungen erfüllt, zu bestimmen, wie viel Leistung wahrscheinlich verbleibt, wenn sich das Fahrzeug mit dem Fahrzeug 100 an einem oder mehreren Treffpunkte trifft. Wie später erörtert, können diese gegenwärtige Standorte des Fahrzeugs 100 oder Punkte entlang einer gegenwärtigen Route des Fahrzeugs 100 beinhalten, wenn das Fahrzeug 100 dem Zeitplaner eine ausreichende Vorankündigung eines möglichen liegengebliebenen Zustands bereitstellt.
Die Leistungsplanung kann Anforderungen an die Anforderungshandhabungseinheit zurückgeben, die auf eine Datenbank mit aktuellen oder nahezu aktuellen Fahrzeugstatistiken 145 zugreifen kann, die Standorte, gegenwärtige Leistungszustände, gegenwärtige Aufgaben usw. beinhalten können. Wenn Fahrzeuge 120 häufig zur Unterstützung verwendet werden, kann eine gewisse Anzahl von Fahrzeugen 120 für einen gegebenen Ort auf Grundlage einer statistischen Wahrscheinlichkeit, dass eines benötigt wird, nicht bearbeitet werden. In anderen Beispielen findet der Prozess Fahrzeuge 120, die sich zwischen Aufgaben befinden oder die anderweitig vorhanden sein können. Selbst wenn ein gegebenes Fahrzeug 120 zu einem Benutzer geleitet wurde, kann es ein geeigneter Kandidat für eine Unterstützung sein, sodass es umgeleitet werden kann und ein anderes verfügbares Fahrzeug auf eine Weise zu dem Benutzer geleitet werden kann, die wenig oder keine Auswirkung auf die Benutzerenderfahrung hat (z. B. fährt ein alternatives Abholfahrzeug 10 Minuten, während das ursprüngliche Abholfahrzeug zur Unterstützung umgeleitet wird, während es ebenfalls 10 oder mehr Minuten vom Benutzer entfernt war).
Das Fahrzeug 120 kann bestätigen, dass es die geeigneten Fähigkeiten aufweist, um das Fahrzeug 100 zu unterstützen, und kann einen Treffpunkt von dem Zeitplaner empfangen. Das Fahrzeug 100 kann ebenfalls zu diesem Standort geleitet werden, und je nachdem, welches Fahrzeug 100, 120 zuerst ankommt, kann warten. Selbst wenn das Fahrzeug 100 einen Fahrgast beinhaltet, ist es wahrscheinlich, dass der Fahrgast damit einverstanden ist, eine kurze Zeitspanne zu warten, während die Unterstützung zu dem Fahrgast fährt.
2 zeigt einen veranschaulichenden Prozess für einen Fahrzeugunterstützungsvorgang. In diesem Beispiel wird der Prozess zum Beispiel an dem Fahrzeug 100 ausgeführt und ermöglicht es dem Fahrzeug 100, einen Zustand mit niedriger Leistung zu bestimmen, Unterstützung anzufordern und den Leistungszustand aktiv zu überwachen, um die Wahrscheinlichkeit des Erreichens eines Ladepunkts zu maximieren.
An einem bestimmten Punkt einer Fahrt bestimmt das Fahrzeug 100 bei 201, dass es sich in einem Zustand mit niedriger Leistung befindet. Dies kann einen durch den Benutzer oder Besitzer definierten Schwellenwert beinhalten oder kann ein dynamischer Schwellenwert sein, der an ein gegenwärtig aufrechterhaltenes Bewusstsein des wahrscheinlichen Betrags von Leistung gebunden ist, der benötigt wird, um einen Aufladepunkt zu erreichen. In dem letzteren Beispiel kann das Fahrzeug 100 kontinuierlich den wahrscheinlichen Leistungsbetrag bestimmen, der für einen nächsten erreichbaren Aufladepunkt (oder den gleichen Punkt, der praktisch gelegen ist, z. B. nicht der nächstgelegene, sondern in der richtigen Richtung) benötigt wird. Vermutlich hatte das Fahrzeug 100 zu Beginn einer Fahrt ausreichend Leistung oder sollte ausreichend Leistung aufweisen, um diesen Punkt zu erreichen, aber auf dem Weg dorthin kann sich die Leistungssituation wesentlich geändert haben. Alternativ kann eine geplante Aufladung durch einen Stromausfall abgeschaltet worden sein, wodurch das Fahrzeug 100 weiter fahren muss, und das Fahrzeug 100 kann ebenfalls über derartige Änderungen informiert werden. Wenn der Betrag an verbleibender Leistung zum Beispiel ohne Einschränkung die Leistung erreicht, die benötigt wird, um den Aufladepunkt plus 10 Prozent zu erreichen (z. B. beinhaltet dies einen Puffer), kann das Fahrzeug 100 bestimmen, dass es sich in einem Zustand mit niedriger Leistung befindet. Der Puffer und die Schwellenwerte können nach Bedarf eingeschlossen und/oder variiert werden.
Wenn das Fahrzeug 100 einen Ladepunkt nicht bereits kennt, findet es einen nächstgelegenen und/oder nächstgelegenen praktischen (in einer korrekten oder halbkorrekten Richtung) Leistungspunkt zum Aufladen. Zum Beispiel kann das Fahrzeug 100 ursprünglich einfach den Betrag an Leistung in Betracht gezogen haben, der benötigt wird, um ein Ziel zu erreichen, an dem ein bekanntes Laden vorhanden war. Wenn die verbleibende Leistung zu niedrig ist, um dieses Ziel zu erreichen, muss das Fahrzeug 100 möglicherweise nach lokalem Laden suchen. Es kann zuerst nach einem erreichbaren praktischen Aufladen Ausschau halten, und wenn dies nicht erreichbar ist, dann kann es nach einem „unpraktischen, aber erreichbaren“ Aufladen suchen (z. B. Backtracking). Da das Senden eines Unterstützungsfahrzeugs 120 die Verwendung von zwei Fahrzeugen für einen erheblichen Zeitraum erfordern kann, kann es ratsam sein, zu versuchen, sogar einen unpraktischen, aber erreichbaren Punkt für das Fahrzeug 100 zu finden. Andererseits kann es ein Abonnementmodell (wenn Insassen abgestufte Mitfahrgelegenheitsmodelle abonnieren) oder sogar die bloße Tatsache eines Insassen vernünftiger machen, das Fahrzeug 100 auf seiner aktuellen Route zu halten und einfach ein Unterstützungsfahrzeug 120 zu einem Treffen zu senden, sodass das besetzte Fahrzeug nicht zurückfährt.
Wenn das Fahrzeug 100 einen Aufladepunkt findet, der bei 205 erreichbar ist und bei 207 innerhalb eines Toleranzschwellenwerts liegt, kann das Fahrzeug 100 bei 219 einfach eine Route planen, ohne anfänglich den Server zu kontaktieren. Das heißt, wenn das Fahrzeug 100 bestimmt, dass die gegenwärtige Leistung gleich der Leistung zum Erreichen des Aufladens + 3 * einem „niedrigen“ Schwellenwert (z. B. 10 %) ist, besteht wahrscheinlich kein Bedarf an Unterstützung und das Fahrzeug 100 kann das Aufladen mit eigener Leistung fortsetzen.
Wenn der Punkt nicht innerhalb des Schwellenwerts liegt, zum Beispiel die gegenwärtige Leistung gleich der Leistung zum Erreichen des Aufladens + 0,5 * dem unteren Schwellenwert ist, muss möglicherweise bei 207 Unterstützung geplant werden. In dem ersten Beispiel beträgt die Leistung 130 % von dem, was der Vorhersage nach benötigt wird, mit einem Schwellenwert von 10 % (z. B. ist 110 % der Grenzwert). In dem zweiten Beispiel beträgt die verbleibende Leistung nur 105 % dessen, was benötigt wird, und somit kann (aber nicht notwendigerweise) Unterstützung erforderlich sein.
Wenn es unter dem Grenzschwellenwert liegt, alarmiert das Fahrzeug 100 den Server bei 209 und bestimmt bei 211, ob Unterstützung verfügbar ist, wie durch den Server als Reaktion auf die Warnung angegeben. Aus verschiedenen Gründen, z. B. erhalten Unterstützungsfahrzeuge Vorrang gegenüber besetzten Fahrzeugen, die Unterstützung benötigen, oder Fahrzeugen mit wirklich geringer Leistung (<100 % erforderlich), kann es sein, dass kein Unterstützungsfahrzeug verfügbar ist. Zum Beispiel können an einem gegebenen Ort drei Fahrzeuge, die Unterstützung benötigen, und ein Unterstützungsfahrzeug verfügbar sein. Es kann zuerst eines der drei Fahrzeuge unterstützen, das einen Fahrgast aufweist, wobei diesem Fahrzeug auf Grundlage der Anwesenheit des Fahrgasts Vorrang gegenüber den anderen zwei Fahrzeugen eingeräumt wird. Der nächste Vorrang der anderen zwei Fahrzeuge kann ein Fahrzeug mit einem Leistungszustand von <100 % sein, bei dem das Fahrzeug voraussichtlich nicht einmal über ausreichend Leistung verfügt, um das Aufladen zu erreichen. Wenn beide Fahrzeuge eine ausreichende prognostizierte Leistung aufweisen, ist es möglich, dass das Unterstützungsfahrzeug nur dasjenige der beiden unterstützt, das sich an einem praktischeren Ort befindet, oder dasjenige der beiden, das die niedrigste prognostizierte Leistung in Bezug auf die benötigte Leistung aufweist (z. B. 102 % gegenüber 104 %).
Wenn das Unterstützungsfahrzeug 120 nicht verfügbar ist, kann das Fahrzeug 100 bei 217 versuchen, die Leistung zu maximieren, und bei 219 eine Route zu dem Aufladepunkt planen. Das Fahrzeug 100 kann bei 207 auch die Leistung maximieren, wenn sich das Fahrzeug 100 innerhalb des Schwellenwerts (z. B. 130 %) befindet, da jedoch das Maximieren der Leistung zuerst das Deaktivieren von Dingen wie HLK und dann das Deaktivieren von nicht kritischen Sensoren, bordeigenen Internet-Hotspots usw. beinhalten kann, kann der Benutzer es vorziehen, dass der Maximierungsalgorithmus nicht aktiviert wird, es sei denn, die Leistung befindet sich in einem unter dem Schwellenwert liegenden Zustand (<110 % in diesem Beispiel).
Das Fahrzeug 100 überwacht sich auch kontinuierlich selbst während der Fortbewegung zum Aufladepunkt, sodass, wenn die 130 % des Bedarfs jemals <110 % des verbleibenden Bedarfs werden, der nächste Schritt unternommen werden kann (z. B. Kontaktieren des Servers, Maximieren der Leistung usw.). Gleichermaßen kann, wenn das, was 105 % des Bedarfs war, unter 100 % des Bedarfs fällt (z. B. das Fahrzeug 100 die Station im Modus mit maximierter Leistung nicht mehr erreichen kann), der Prozess bei 205 zu nicht erreichbar abzweigen. Wenn das Fahrzeug 100 bei 209 um Unterstützung oder mögliche Unterstützung gebeten hat und die Unterstützung bei 211 verfügbar ist, kann das Fahrzeug 100 Treffpunkte empfangen und plant bei 213 einen Schnittpunkt mit dem Fahrzeug 120. In allen Fällen kann das Fahrzeug 100 weiterhin einem Routenplan folgen und bei 231 kontinuierlich auf Erreichbarkeit prüfen, wobei es bei 205 zu unerreichbar abzweigt, wenn sich die prognostizierte Situation zu einer schlimmeren ändert.
Wenn zu einem beliebigen Zeitpunkt der Aufladepunkt auf Grundlage der gegenwärtigen Leistung im Vergleich zu der prognostizierten Leistung, die benötigt wird, um den Punkt zu erreichen (der einen Modus mit maximaler Leistung berücksichtigen kann, in dem alle nicht wesentlichen Systeme vorübergehend deaktiviert sind) nicht erreichbar zu sein scheint, kann das Fahrzeug 100 den Server bei 221 warnen.
Der Server kann bei 223 mit der Verfügbarkeit von Unterstützung antworten, was das Informieren des Fahrzeugs 100 beinhalten kann, dass das Fahrzeug 120 unterstützen kann und an einem Ort eintreffen sollte, der als ein Treffpunkt beinhaltet ist. Das Fahrzeug 100 plant bei 229 eine Route zu diesem Punkt und folgt dem Plan 215. Wenn der Treffpunkt bei 231 unerreichbar wird, kann der Prozess wiederholt werden, wobei der Treffpunkt näher an das Fahrzeug 100 zurückgesetzt wird, bis zu und einschließlich, dass das Fahrzeug 100 einfach anhält, parkt und wartet, wenn dies die einzige Möglichkeit ist, um ausreichend Leistung zu sparen, um den Aufladepunkt zu erreichen, selbst mit Unterstützung von dem Fahrzeug 120.
Wenn bei 223 kein Unterstützungsfahrzeug 120 verfügbar ist, kann sich das Fahrzeug 100 zur Unterstützung in die Warteschlange einreihen (ein Prozess, der auf dem Server erfolgen kann) und dann bei 227 entweder parken und warten oder eine angemessene Entfernung zu einem wahrscheinlichen Treffpunkt zurücklegen. In dem letzteren Beispiel ist es zum Beispiel, wenn sich das Fahrzeug 100 auf einer Autobahn 10 Meilen von der nächsten Ausfahrt, aber 100 Meilen von einer vorherigen Ausfahrt entfernt befindet, sehr wahrscheinlich, dass das Treffen an der nächsten Ausfahrt stattfinden wird, und daher ist es, ohne kritischen Leistungszustand, sinnvoll, dass das Fahrzeug 100 den Großteil oder die gesamten 10 Meilen zur nächsten Ausfahrt fährt, selbst wenn keine bestimmte Unterstützung bekannt ist. Das Parken und Warten kann dann an der nächsten Ausfahrt erfolgen, dies erzeugt jedoch eine Effizienz, wenn sich herausstellt, dass sich das Unterstützungsfahrzeug in unmittelbarer Nähe dieser Ausfahrt befindet.
3 zeigt einen veranschaulichenden Warnungshandhabungsprozess. Hierbei handelt es sich um einen serverseitigen Prozess, bei dem die Cloud 140 oder ein oder mehrere Backend-Server versuchen, ein Unterstützungsfahrzeug 120 zu finden, um ein liegengebliebenes oder möglicherweise liegengebliebenes Fahrzeug 100 zu unterstützen. Der Server empfängt die Warnung bei 301 und bestimmt bei 303, ob verwendbare Fahrzeuge 120 in der Nähe des anfordernden Fahrzeugs 100 vorhanden sind. Dies kann zum Beispiel das Bestimmen der in dem Fahrzeug 100 verbleibenden Leistung (gemeldet) sowie der Leistung beinhalten, die benötigt wird, um sich zu verschiedenen nahegelegenen Aufladepunkten unter gegenwärtigen Fortbewegungsbedingungen und unter verschiedenen Sensor- und Systemabschaltbedingungen fortzubewegen. Das Fahrzeug 100 kann den Server ferner darüber informieren, dass es besetzt ist (was die Auswahl von Aufladepunkten beeinflussen kann) und/oder das Fahrzeug 100 kann einen bevorzugten Aufladepunkt identifizieren, der bereits durch das Fahrzeug 100 identifiziert wurde.
Der Server kann bei 303 den Leistungsbedarf und/oder den Systembedarf eines Unterstützungsfahrzeugs 120 bestimmen und bestimmen, ob sich ein derartiges Fahrzeug 120 in erreichbarer Nähe befindet und verfügbar sein wird, was das Bestimmen beinhalten kann, ob es nach dem Fortbewegen zu einem beliebigen Treffpunkt ausreichend Leistung aufweisen wird.
Wenn es kein derartiges Fahrzeug 120 gibt, kann der Server eine oder mehrere Fahrzeuganweisungen (z. B. bevorzugtes Aufladen) ignorieren und bestimmen, ob es eine alternative Unterstützungslösung gibt, die zumindest zu sofortiger Unterstützung führt. Wenn keine Lösung gefunden werden kann, meldet der Server bei 305, dass keine gegenwärtige Unterstützung verfügbar ist. Der Server kann dann die ausstehende Fahrzeuganforderung bei 307 in eine Warteschlange einreihen.
Wenn es eine oder mehrere Lösungen gibt, die bei 303 ein mögliches Unterstützungsszenario aufzeigen, kann der Server bei 309 beliebige identifizierte Fahrzeuge 120 kontaktieren. Da die Fahrzeuge 120 möglicherweise nicht immer in der Lage sind, einen Server über unmittelbare Bedingungen (z. B. Strom oder lokaler Verkehr) auf dem Laufenden zu halten, kann dem Fahrzeug 120 die Möglichkeit gegeben werden, die Anforderung abzulehnen, selbst wenn der Server vermutlich für das Führen der Fahrzeuge 100, 120 verantwortlich ist.
Die Anforderung bei 309 kann auch bedingt sein, zum Beispiel kann sie Parameter zur Annahme beinhalten, die zum Beispiel die prognostizierte Zeit zum Bedienen der Anforderung (bei gegebenen Bedingungen, die nur dem Fahrzeug 120 bekannt sein können), die Kritikalität der Anforderung (z. B., ob es wahrscheinlich ist, dass das Fahrzeug 100 es bis zur Station schafft, und das Umleiten des Fahrzeugs 120 das Fahrzeug 120 in einen unsicheren Leistungszustand versetzen kann) usw. beinhalten. Somit kann das Fahrzeug 120 bestätigen, dass die Bedingungen alle erfüllt sind, und dann die Anforderung bestätigen, indem es sie ablehnt, wenn Bedingungen nicht erfüllt sind.
Wenn alle Fahrzeuge 120 die Unterstützungsanforderung ablehnen, meldet der Server bei 305 erneut, dass keine Fahrzeuge 120 verfügbar sind. Andernfalls kann es bei 313 einen angemessenen Schnittpunkt/Treffpunkt bestimmen. Dies kann den gegenwärtigen Standort des Fahrzeugs 100 sowie beliebige andere Einschränkungen berücksichtigen, wie etwa, ob das Fahrzeug 100 weiterfahren sollte oder kann („kann“ in dem Sinne, dass zu viel Leistung selbst bei einer AV-Fahrt mit eingeschränkter Funktion verbraucht würde), welche Fahrzeiten für jedes Fahrzeug den Punkt mit den wenigsten Wartezeiten durch eines der beiden Fahrzeuge vorgeben, ob das Fahrzeug 120 das Fahrzeug 100 an einem bestimmten Punkt auf einer Route des Fahrzeugs 100 treffen muss, um über ausreichend Leistung zum Unterstützen des Fahrzeugs 100 zu verfügen usw.
Primäre und/oder sekundäre Treffpunkte können bei 313 bestimmt und bei 315 verteilt werden. Zum Beispiel könnte ein primärer Punkt die meisten Variablen optimieren, aber sekundäre Punkte könnten mögliche Änderungen der Zustände des Fahrzeugs 100 oder 120 angehen. Diese sekundären Punkte müssen möglicherweise neu berechnet werden, aber wenn einer ausgelöst wird und beide Fahrzeuge 100 und 120 bestätigen, dass sie den sekundären Punkt verwenden können, ist keine Neuberechnung erforderlich und beide können fortfahren. Zum Beispiel kann ein sekundärer Punkt sein, wenn das Fahrzeug 100 in einem Modus mit maximaler Leistung unter einen Erreichbarkeitsschwellenwert fällt - z. B., wenn die gegenwärtigen 100+ % der benötigten Leistung unter 100 % fallen, was bedeutet, dass die AV-Fahrt ohne Unterstützung nicht möglich ist, wenn das Fahrzeug das Aufladen erreichen soll.
Dies bedeutet nicht, dass das Fahrzeug anhalten muss, da die Unterstützung zu einem Leistungsgewinn von 10 % (aufgrund von Prozessauslagerung) führen kann, und somit könnte das Fahrzeug 100 vermutlich eine gewisse Strecke (z. B. bis zu 95 %) zurücklegen, bevor es wartet. Wenn der Grenzwert 95 % beträgt, könnte das Fahrzeug 100 in jedem Fall sehr nahe an das ursprüngliche Treffen kommen, da die Anzahl anhand der verbleibenden Entfernung bestimmt wird, und somit verringert sich der Wert von 100 %, wenn das Fahrzeug 100 weiterfährt. Das heißt, dies legt nicht nahe, dass das Fahrzeug notwendigerweise nur 5 % der verbleibenden Entfernung zurücklegt, sondern dass das Fahrzeug 100 nach dem Zurücklegen von beispielsweise 5 % der Entfernung bestimmt, ob 95 % der benötigten Leistung, um die verbleibenden 95 % der Entfernung zurückzulegen, bleiben.
In einem anderen Beispiel kann das Unterstützungsfahrzeug 120 selbst einen Zustand mit niedriger Leistung erfahren und kann erfordern, dass das andere Fahrzeug 100 vor dem Treffen weiter fährt. Es ist nicht notwendig, sekundäre Zustände und Bedingungen zu senden, aber es kann Zeit und zukünftiges Aushandeln zwischen den Fahrzeugen 100 und 120 sparen, wenn sie sekundäre Bedingungen aufweisen, die unter bestimmten Umständen ausgelöst werden, und der Zeitplaner kann eine Nachricht von einem empfangen, dass eine Bedingung ausgelöst wurde, und mit dem anderen bestätigen, dass der sekundäre Punkt, der dieser Bedingung entspricht, ohne weitere Unterstützung (Umleitung oder Neubestimmung) von dem Backend erreicht werden kann.
4 zeigt einen veranschaulichenden Assistenzwarteschlangenhandhabungsprozess. Wenn kein Unterstützungsfahrzeug 120 für eine gegebene Anforderung verfügbar ist, kann das anfordernde Fahrzeug 100 angewiesen werden, zu parken und zu warten, bis ein Unterstützungsfahrzeug 120 geleitet werden kann. Ob sich das anfordernde Fahrzeug 100 weiter bewegt oder nicht, kann von seiner eigenen Leistung abhängig sein, aber zu diesem Zeitpunkt kann es keine Unterstützungszusicherungen aufweisen, sodass es die geeignete nächste Vorgehensweise selbst bestimmen kann.
Währenddessen kann der Server kontinuierlich oder periodisch eine Warteschlange mit Hilfeanforderungen überprüfen, wie etwa, wenn ein Fahrzeug 120 identifiziert, dass es eine Aufgabe abgeschlossen hat. Die Warteschlange kann auf eine beliebige Weise organisiert sein, aber ein Beispiel würde beinhalten, dass jedes Warteschlangenelement eine Warteschlangenzeit (wenn es in die Warteschlange eingereiht wurde) und einen Standort (wo es sich gegenwärtig befand) aufweist und dann kann basierend auf einer Kombination aus diesen und/oder anderen Informationen ein nun freies Fahrzeug 120 mit einem Fahrzeug in der Warteschlange korreliert werden.
Der Server kann auch prüfen, ob die Warteschlange mit Anforderungen von mehreren Fahrzeugen 100 gemeinsame Straßensegmente aufweist (oder mit möglichen Anpassungen). Falls ja, kann ein einzelnes Unterstützungsfahrzeug 120 in der Lage sein, diese Fahrzeuge 100 für die gemeinsamen Straßensegmente zusammenzuführen.
Die Bestimmung kann zum Beispiel bei 403 auch nächstgelegene Leistungsstandorte zu einem Standort eines gegenwärtig in der Warteschlange befindlichen Fahrzeugs 100 (der zusammen mit dem Fahrzeugstandort verfolgt werden kann) und/oder Reichweiten 405 des in der Warteschlange befindlichen Fahrzeugs auf Grundlage seines gegenwärtigen Leistungszustands bei verschiedenen Abschalt- und Unterstützungsbedingungen (wie zuvor beschrieben) beinhalten. Der Prozess kann dann für jedes in der Warteschlange befindliches Fahrzeug oder ein ausgewähltes in der Warteschlange befindliches Fahrzeug zu 303 abzweigen.
Zum Beispiel kann sich ein nun freies Fahrzeug 120 (mit abgeschlossener Aufgabe) der Identifizierung nach innerhalb von 20 Meilen von drei in der Warteschlange befindlichen Fahrzeugen 100 befinden, und zwar mit ausreichender Leistung, um diese Fahrzeuge 100 maximal (mit maximaler Unterstützung) weitere 10-15 Meilen zu führen, je nachdem, wie viel Leistung benötigt wird, um ein bestimmtes von ihnen zu erreichen. Eigenschaften der drei Fahrzeuge 100 (z. B. unter anderem Insassenanwesenheit, Dauer der Warteschlange, verbleibende Leistung, Nähe zum Fahrzeug 120 usw.) können untersucht werden. Ferner kann die relative Position dieser Fahrzeuge 100 verwendet werden, wenn das Fahrzeug 120 am einfachsten eines und dann ein nächstes in einer vernünftigen Reihenfolge unterstützen kann, unter der Annahme, dass keine anderen Unterstützungsfahrzeuge 120 gefunden werden können. Andere Faktoren können ebenfalls als angemessen in Betracht gezogen werden, sodass Fahrzeugen 100, die Unterstützung anfordern, für die keine unmittelbare Unterstützung besteht, dennoch in einer angemessenen rechtzeitigen Weise geholfen werden kann, wie es die Ressourcen zulassen.
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen beschreiben, die durch die Patentansprüche eingeschlossen sind. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale unterschiedlicher Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden, die möglicherweise nicht ausdrücklich beschrieben oder veranschaulicht sind. Wenngleich verschiedene Ausführungsformen gegenüber anderen Ausführungsformen oder Umsetzungen nach dem Stand der Technik in Bezug auf eine oder mehrere gewünschte Eigenschaften als vorteilhaft oder bevorzugt beschrieben worden sein könnten, erkennt der Durchschnittsfachmann, dass bei einem/einer oder mehreren Merkmalen oder Eigenschaften Kompromisse eingegangen werden können, um die gewünschten Gesamtattribute des Systems zu erzielen, die von der spezifischen Anwendung und Umsetzung abhängen. Diese Attribute können unter anderem Kosten, Festigkeit, Lebensdauer, Lebenszykluskosten, Marktfähigkeit, Erscheinungsbild, Bauraum, Größe, Wartungsfähigkeit, Gewicht, Herstellbarkeit, Einfachheit der Montage usw. beinhalten. Demnach liegen Ausführungsformen, die in Bezug auf eine oder mehrere Eigenschaften als weniger wünschenswert als andere Ausführungsformen oder Umsetzungen nach dem Stand der Technik beschrieben sind, nicht außerhalb des Umfangs der Offenbarung und können für konkrete Anwendungen wünschenswert sein.
Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das Folgendes aufweist: einen Prozessor, der konfiguriert ist zum: Empfangen einer Anforderung zur Fortbewegungsunterstützung von einem ersten autonomen Fahrzeug, die einen niedrigen Leistungszustand des ersten autonomen Fahrzeugs angibt; Bestimmen eines Aufladepunkts zur Verwendung durch das erste autonome Fahrzeug; Bestimmen der Leistung, die erforderlich ist, damit das erste autonome Fahrzeug den Aufladepunkt erreicht, und zwar unter einem oder mehreren Leistungserhaltungszuständen, die durch das erste autonome Fahrzeug aktivierbar sind; Bestimmen eines zweiten autonomen Fahrzeugs für mindestens einen der Leistungserhaltungszustände, das Unterstützung für das erste autonome Fahrzeug auf eine für den mindestens einen Leistungserhaltungszustand vordefinierte Weise bereitstellen kann und das es dem ersten autonomen Fahrzeug ermöglicht, den Aufladepunkt zu erreichen; und Anweisen des zweiten autonomen Fahrzeugs, sich mit dem ersten autonomen Fahrzeug an einem bestimmten Treffpunkt zu treffen.
Gemäß einer Ausführungsform wird der Aufladepunkt als Teil der Anforderung identifiziert.
Gemäß einer Ausführungsform wird der Aufladepunkt zumindest teilweise auf Grundlage dessen bestimmt, ob das erste autonome Fahrzeug besetzt ist.
Gemäß einer Ausführungsform beinhalten die Leistungserhaltungszustände Deaktivieren von Sensoren, die für das autonome Fahren nicht kritisch sind, wobei ermöglicht wird, das autonome Fahren fortzusetzen, und wobei die Weise beinhaltet, dass das zweite autonome Fahrzeug Daten von Sensoren bereitstellt, die mit den deaktivierten Sensoren vergleichbar sind.
Gemäß einer Ausführungsform beinhalten die Leistungserhaltungszustände Deaktivieren von Sensoren, die für das autonome Fahren kritisch sind, wobei autonomes Fahren ohne Unterstützung von dem zweiten autonomen Fahrzeug verhindert wird, und wobei die Weise beinhaltet, dass das zweite autonome Fahrzeug Daten von Sensoren bereitstellt, die mit den deaktivierten Sensoren vergleichbar sind.
Gemäß einer Ausführungsform beinhalten die Leistungserhaltungszustände gemeinsames Nutzen von Rechenzyklen mit dem zweiten autonomen Fahrzeug, die zumindest Veranlassen, dass das zweite autonome Fahrzeug eine oder mehrere rechenintensive Aufgaben durchführt, die der Vorhersage nach während des Rechnens Leistung über einem Schwellenwert verbrauchen, beinhalten.
Gemäß einer Ausführungsform basiert die Bestimmung des zweiten autonomen Fahrzeugs, das Unterstützung bereitstellen kann, zumindest auf Fähigkeiten des zweiten autonomen Fahrzeugs.
Gemäß einer Ausführungsform basiert die Bestimmung des zweiten autonomen Fahrzeugs, das Unterstützung bereitstellen kann, zumindest auf dem Standort des zweiten autonomen Fahrzeugs.
Gemäß einer Ausführungsform basiert die Bestimmung des zweiten autonomen Fahrzeugs, das Unterstützung bereitstellen kann, zumindest auf dem Leistungszustand des zweiten autonomen Fahrzeugs.
Gemäß einer Ausführungsform ist der Prozessor ferner dazu konfiguriert, die ersten autonomen Fahrzeuge anzuweisen, sich als Reaktion auf Empfangen einer Bestätigung von dem zweiten autonomen Fahrzeug, dass das zweite autonome Fahrzeug Unterstützung bereitstellen kann, mit dem zweiten autonomen Fahrzeug an dem bestimmten Treffpunkt zu treffen.
Gemäß der vorliegenden Erfindung ist ein erstes autonomes Fahrzeug bereitgestellt, das Folgendes aufweist: einen Prozessor, der zu Folgendem konfiguriert ist: Bestimmen, dass ein gegenwärtiger Leistungspegel geringer als ein prognostizierter Leistungspegel ist, der benötigt wird, um einen Aufladepunkt zu erreichen; Anfordern von Unterstützung von einem entfernten Server; als Reaktion auf die Anforderung Empfangen von Treffanweisungen, einschließlich eines Treffpunkts für ein zweites autonomes Fahrzeug; Ausführen einer Fortbewegung zum Treffpunkt; direktem Kommunizieren mit dem zweiten autonomen Fahrzeug, wenn sich sowohl das erste als auch das zweite autonome Fahrzeug innerhalb einer kommunizierbaren Reichweite voneinander befinden; Auslagern von mindestens einer von Rechen- oder Erfassungsaufgaben auf das zweite autonome Fahrzeug, wobei das zweite autonome Fahrzeug eine Antwort auf die ausgelagerte Aufgabe bereitstellt, die ermöglicht, dass das erste autonome Fahrzeug die autonome Fortbewegung unter Verwendung der Antwort fortsetzt; und Fortsetzen von Folgendem: Auslagern von mindestens einer von Rechen- oder Erfassungsaufgaben auf das zweite autonome Fahrzeug; Empfangen von Antworten auf die ausgelagerten Aufgaben; und autonomen Fortbewegen unter Verwendung der Antworten, bis das erste autonome Fahrzeug mindestens einen von dem Aufladepunkt oder einem Standort in der Nähe des Aufladepunkts erreicht, an dem das erste autonome Fahrzeug prognostiziert, dass der gegenwärtige Leistungspegel über dem prognostizierten Leistungspegel liegt, der benötigt wird, um den Aufladepunkt zu erreichen.
Gemäß einer Ausführungsform beinhaltet der prognostizierte Leistungspegel Fortbewegen mit deaktivierten Sensoren, die für autonomes Fahren nicht kritisch sind, wobei ermöglicht wird, das autonome Fahren fortzusetzen.
Gemäß einer Ausführungsform beinhaltet der prognostizierte Leistungspegel einen vordefinierten Puffer zusätzlich zu einem tatsächlichen Leistungsbetrag, der der Vorhersage nach benötigt wird, damit das Fahrzeug den Aufladepunkt erreicht.
Gemäß einer Ausführungsform beinhaltet der Treffpunkt den gegenwärtigen Standort des ersten autonomen Fahrzeugs.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, als Reaktion auf eine Benachrichtigung von dem Server, dass derzeit kein zweites autonomes Fahrzeug zur Verfügung steht, um das erste Fahrzeug zu unterstützen, das erste Fahrzeug parken und warten zu lassen.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren: Bestimmen an Bord eines ersten autonomen Fahrzeugs, dass das erste autonome Fahrzeug einen verbleibenden Leistungsbetrag aufweist, der der Vorhersage nach benötigt wird, um einen Aufladepunkt durch Fortbewegen mit einem oder mehreren deaktivierten vordefinierten Systemen zu erreichen, die noch immer autonome Fortbewegung ermöglichen; Deaktivieren der vordefinierten Systeme und Fortbewegen in Richtung des Aufladepunkts; Bestimmen nach dem Deaktivieren, dass das erste autonome Fahrzeug nicht mehr den verbleibenden Leistungsbetrag aufweist, der der Vorhersage nach benötigt wird, um den Aufladepunkt zu erreichen, der von einem gegenwärtigen Standort des ersten autonomen Fahrzeugs erneut prognostiziert wird; als Reaktion darauf, dass das erste autonome Fahrzeug den verbleibenden Leistungsbetrag nicht mehr aufweist, Kommunizieren mit einem Server und Anfordern von Unterstützung; als Reaktion auf das Anfordern Empfangen von Trennanweisungen, einschließlich eines Treffpunkts zum Treffen eines zweiten autonomen Fahrzeugs; und als Reaktion darauf, dass sich das ersten und das zweite autonome Fahrzeug innerhalb des Kommunikationsbereichs befinden, Zunutzemachen an dem ersten autonomen Fahrzeug einer Fähigkeit des zweiten autonomen Fahrzeugs, wobei ermöglich wird, dass das erste Fahrzeug den Aufladepunkt durch das Zunutzemachen erreicht.
In einem Aspekt der Erfindung beinhaltet die Fähigkeit eine Erfassungsfähigkeit und wobei das Zunutzemachen Senden von mindestens einer Sensordatenanforderung von dem ersten autonomen Fahrzeug an das zweite autonome Fahrzeug und Empfangen einer Antwort an dem ersten Fahrzeug beinhaltet, wobei dem ersten Fahrzeug auf Grundlage der Antwort ermöglicht wird, weiter autonom zu fahren.
In einem Aspekt der Erfindung beinhaltet die Fähigkeit eine Rechenfähigkeit und wobei das Zunutzemachen Senden von mindestens einer Rechenanforderung von dem ersten autonomen Fahrzeug an das zweite autonome Fahrzeug und Empfangen einer Antwort an dem ersten Fahrzeug beinhaltet, wobei dem ersten Fahrzeug auf Grundlage der Antwort ermöglicht wird, weiter autonom zu fahren.
In einem Aspekt der Erfindung beinhaltet die Fähigkeit eine Fortbewegungsfähigkeit und wobei das Zunutzemachen Verfolgen des zweiten autonomen Fahrzeugs unter Verwendung der Erfassungsfähigkeit des ersten autonomen Fahrzeugs beinhaltet, das in der Lage ist, die Bewegung des zweiten autonomen Fahrzeugs zu verfolgen.
In einem Aspekt der Erfindung beinhaltet die Fähigkeit eine Fortbewegungsfähigkeit und wobei das Zunutzemachen Verfolgen des zweiten autonomen Fahrzeugs unter Verwendung der Kommunikationsfähigkeit des ersten autonomen Fahrzeugs beinhaltet, um mit dem zweiten autonomen Fahrzeug zu kommunizieren und das zweite autonome Fahrzeug auf Grundlage des Empfangs von mindestens einer der beabsichtigten Handlungen des zweiten autonomen Fahrzeugs oder Fahranweisungen für das erste autonome Fahrzeug, die von dem zweiten autonomen Fahrzeug empfangen werden, zu verfolgen.

Claims

System, umfassend: einen Prozessor, der zu Folgendem konfiguriert ist: Empfangen einer Anforderung zur Fortbewegungsunterstützung von einem ersten autonomen Fahrzeug, die einen niedrigen Leistungszustand des ersten autonomen Fahrzeugs angibt; Bestimmen eines Aufladepunkts zur Verwendung durch das erste autonome Fahrzeug; Bestimmen von Leistung, die erforderlich ist, damit das erste autonome Fahrzeug den Aufladepunkt erreicht, unter einem oder mehreren Leistungserhaltungszuständen, die durch das erste autonome Fahrzeug aktivierbar sind; Bestimmen eines zweiten autonomen Fahrzeugs für mindestens einen der Leistungserhaltungszustände, das Unterstützung für das erste autonome Fahrzeug auf eine für den mindestens einen Leistungserhaltungszustand vordefinierte Weise bereitstellen kann und das es dem ersten autonomen Fahrzeug ermöglicht, den Aufladepunkt zu erreichen; und Anweisen des zweiten autonomen Fahrzeugs, sich mit dem ersten autonomen Fahrzeug an einem bestimmten Treffpunkt zu treffen.
System nach Anspruch 1, wobei der Aufladepunkt als Teil der Anforderung identifiziert wird.
System nach Anspruch 1, wobei der Aufladepunkt zumindest teilweise auf Grundlage dessen bestimmt wird, ob das erste autonome Fahrzeug besetzt ist.
System nach Anspruch 1, wobei die Leistungserhaltungszustände Deaktivieren von Sensoren beinhalten, die für das autonome Fahren nicht kritisch sind, wobei ermöglicht wird, das autonome Fahren fortzusetzen, und wobei die Weise beinhaltet, dass das zweite autonome Fahrzeug Daten von Sensoren bereitstellt, die mit den deaktivierten Sensoren vergleichbar sind.
System nach Anspruch 1, wobei die Leistungserhaltungszustände Deaktivieren von Sensoren beinhalten, die für das autonome Fahren kritisch sind, wobei autonomes Fahren ohne Unterstützung von dem zweiten autonomen Fahrzeug verhindert wird, und wobei die Weise beinhaltet, dass das zweite autonome Fahrzeug Daten von Sensoren bereitstellt, die mit den deaktivierten Sensoren vergleichbar sind.
System nach Anspruch 1, wobei die Leistungserhaltungszustände gemeinsames Nutzen von Rechenzyklen mit dem zweiten autonomen Fahrzeug beinhalten, die zumindest Veranlassen, dass das zweite autonome Fahrzeug eine oder mehrere rechenintensive Aufgaben durchführt, die der Vorhersage nach während des Rechnens Leistung über einem Schwellenwert verbrauchen, beinhalten.
System nach Anspruch 1, wobei die Bestimmung des zweiten autonomen Fahrzeugs, das Unterstützung bereitstellen kann, zumindest auf Fähigkeiten des zweiten autonomen Fahrzeugs basiert.
System nach Anspruch 1, wobei die Bestimmung des zweiten autonomen Fahrzeugs, das Unterstützung bereitstellen kann, zumindest auf dem Standort des zweiten autonomen Fahrzeugs basiert.
System nach Anspruch 1, wobei die Bestimmung des zweiten autonomen Fahrzeugs, das Unterstützung bereitstellen kann, zumindest auf einem Leistungszustand des zweiten autonomen Fahrzeugs basiert.
System nach Anspruch 1, wobei der Prozessor ferner dazu konfiguriert ist, die ersten autonomen Fahrzeuge anzuweisen, sich als Reaktion auf Empfangen einer Bestätigung von dem zweiten autonomen Fahrzeug, dass das zweite autonome Fahrzeug Unterstützung bereitstellen kann, mit dem zweiten autonomen Fahrzeug an dem bestimmten Treffpunkt zu treffen.
Erstes autonomes Fahrzeug, umfassend: einen Prozessor, der zu Folgendem konfiguriert ist: Bestimmen, dass ein gegenwärtiger Leistungspegel geringer als ein prognostizierter Leistungspegel ist, der benötigt wird, um einen Aufladepunkt zu erreichen; Anfordern von Unterstützung von einem entfernten Server; als Reaktion auf die Anforderung Empfangen von Treffanweisungen, einschließlich eines Treffpunkts für ein zweites autonomes Fahrzeug; Ausführen einer Fortbewegung zum Treffpunkt; direktem Kommunizieren mit dem zweiten autonomen Fahrzeug, wenn sich sowohl das erste als auch das zweite autonome Fahrzeug innerhalb einer kommunizierbaren Reichweite voneinander befinden, Auslagern von mindestens einer von Rechen- oder Erfassungsaufgaben auf das zweite autonome Fahrzeug, wobei das zweite autonome Fahrzeug eine Antwort auf die ausgelagerte Aufgabe bereitstellt, die ermöglicht, dass das erste autonome Fahrzeug die autonome Fortbewegung unter Verwendung der Antwort fortsetzt; und Fortsetzen von Folgendem: Auslagern von mindestens einer von Rechen- oder Erfassungsaufgaben auf das zweite autonome Fahrzeug; Empfangen von Antworten auf die ausgelagerten Aufgaben; und autonomes Fortbewegen unter Verwendung der Antworten, bis das erste autonome Fahrzeug mindestens einen von dem Aufladepunkt oder einem Standort in der Nähe des Aufladepunkts erreicht, an dem das erste autonome Fahrzeug prognostiziert, dass der gegenwärtige Leistungspegel über dem prognostizierten Leistungspegel liegt, der benötigt wird, um den Aufladepunkt zu erreichen.
Fahrzeug nach Anspruch 11, wobei der prognostizierte Leistungspegel Fortbewegen mit deaktivierten Sensoren beinhaltet, die für autonomes Fahren nicht kritisch sind, wobei ermöglicht wird, das autonome Fahren fortzusetzen.
Fahrzeug nach Anspruch 11, wobei der prognostizierte Leistungspegel einen vordefinierten Puffer zusätzlich zu einem tatsächlichen Leistungsbetrag beinhaltet, der der Vorhersage nach benötigt wird, damit das Fahrzeug den Aufladepunkt erreicht.
Fahrzeug nach Anspruch 11, wobei der Treffpunkt den gegenwärtigen Standort des ersten autonomen Fahrzeugs beinhaltet.
Fahrzeug nach Anspruch 11, wobei der Prozessor dazu konfiguriert ist, als Reaktion auf eine Benachrichtigung von dem Server, dass derzeit kein zweites autonomes Fahrzeug zur Verfügung steht, um das erste Fahrzeug zu unterstützen, das erste Fahrzeug parken und warten zu lassen.