DE102016115965A1

DE102016115965A1 - Verfahren und Vorrichtung zum Empfehlen von energiesparenden Fahrzeugnutzungsänderungen

Info

Publication number: DE102016115965A1
Application number: DE102016115965.4A
Authority: DE
Inventors: Oliver Lei; Allen R. MURRAY
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-09-08
Filing date: 2016-08-26
Publication date: 2017-03-23
Also published as: CN107009904B; CN107009904A; US20170067746A1; US10488209B2

Abstract

Ein System weist einen Prozessor auf, der konfiguriert, ist, eine gewünschte Abfahrtszeit und Route für eine bevorstehende Fahrt von einem Fahrzeugcomputersystem zu empfangen. Der Prozessor ist auch konfiguriert, ein Verkehrsaufkommen basierend auf der empfangenen Zeit für die empfangene Route zu bestimmen. Der Prozessor ist ferner konfiguriert, einen Fahrzeugladezustand zu bestimmen und eine neue Route oder Abfahrtszeit zu empfehlen, falls vorhergesagt wird, dass der Fahrzeugladezustand ausreichend ist, um eine Fahrtvollendung basierend auf der neuen Route oder Abfahrtszeit gemäß der Empfehlung zu erzielen.

Description

TECHNISCHES GEBIET
Die Ausführungsbeispiele betreffen im Allgemeinen ein Verfahren und eine Vorrichtung zum Empfehlen von energiesparenden Fahrzeugnutzungsänderungen.
HINTERGRUND
Typischerweise werden Elektrofahrzeuge in regelmäßigen Abständen innerhalb ungefähr wöchentlicher Zeiträume aufgeladen, während sich das Fahrzeug an einem Heimatstandort (oder anderen Langzeitaufenthaltsstandorten wie an einem Büro) befindet. Ladezeitpläne, insbesondere wenn der Benutzer für den Strom zahlt, können basierend auf festgestellten Energieversorgungskosten variiert werden, sodass ein bevorzugter Ladevorgang oftmals dann stattfindet, wenn die Kosten am niedrigsten sind. Die Zeiträume mit niedrigen Kosten können variieren, wobei ein Fahrzeug zuweilen mehr Ladung benötigt, als während der Zeiträume mit den niedrigsten Preisen erhalten werden kann. Zur Unterstützung von Ladeentscheidungen haben Automobil-OEM eine webbasierte Ladekonfiguration und/oder automatisierte Systeme bereitgestellt, die einen Ladevorgang basierend auf gegenwärtigen Niedrigpreis-Zeiträumen anweisen können, die in Verbindung mit einem voraussichtlichen Energiebedarf (zum Beispiel basierend auf definierten Routen und oder einer festgestellten Nutzung) berücksichtigt werden. Unter solchen Umständen laden Fahrzeuge typischerweise eine „Losfahr“-Zeit basierend darauf hoch, wann eine voraussichtliche Route beginnen wird. Ferner bereiten Fahrzeuge normalerweise die Innentemperatur basierend darauf vor, wann eine voraussichtliche Route beginnen wird. Selbst wenn ein Durchführungszeitplan an dem Fahrzeug eingestellt wird, kann dieser von einem Backend-Server zurückverfolgt oder verwaltet werden und die gewünschte/voraussichtliche Startzeit kann folglich ebenfalls hochgeladen werden.
KURZDARSTELLUNG
In einem Ausführungsbeispiel weist ein System einen Prozessor auf, der konfiguriert, ist, eine gewünschte Abfahrtszeit und Route für eine bevorstehende Fahrt von einem Fahrzeugcomputersystem zu empfangen. Der Prozessor ist auch konfiguriert, ein Verkehrsaufkommen basierend auf der empfangenen Zeit für die empfangene Route zu bestimmen. Der Prozessor ist ferner konfiguriert, einen Fahrzeugladezustand zu bestimmen und eine neue Route oder Abfahrtszeit zu empfehlen, falls vorhergesagt wird, dass der Fahrzeugladezustand ausreichend ist, um eine Fahrtvollendung basierend auf der neuen Route oder Abfahrtszeit gemäß der Empfehlung zu erzielen.
In einem zweiten Ausführungsbeispiel beinhaltet ein computerimplementiertes Verfahren das Bestimmen einer neuen Abfahrtszeit oder Fahrtroute, die voraussichtlich dazu führt, auf weniger Verkehr zu treffen als bei einer Fahrt über eine empfangene bevorzugte Route, die zu einer empfangenen bevorzugten Abfahrtszeit beginnt, und das Senden der neuen Abfahrtszeit oder Fahrtroute an eine Benutzervorrichtung zwecks Bestätigung.
Ein System umfasst einen Prozessor, der zum Bestimmen einer vorhergesagten Fahrtzeit basierend auf einem vorhergesagten Verkehrsaufkommen über eine bevorzugte Route konfiguriert ist, die zu einer bevorzugten Abfahrtszeit beginnt, die von einem Fahrzeugcomputer empfangen wird. Der Prozessor ist ferner zum Empfehlen einer alternativen Abfahrtszeit oder einer alternativen Route konfiguriert, die zu einer geringeren vorhergesagten Fahrtzeit führt, falls vorhergesagt wird, dass ein gegenwärtiger Fahrzeugladezustand, der von dem Fahrzeugcomputer empfangen wird, zur Vollendung der Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route ausreichend ist.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein veranschaulichendes Fahrzeugcomputersystem;
2 zeigt ein beispielhaftes System zum Abgeben von Fahrzeugnutzungsempfehlungen;
3 zeigt einen beispielhaften Prozess für die Implementierung von Fahrzeugnutzungsänderungen;
4 zeigt einen beispielhaften Prozess für die Bestimmung einer empfohlenen Fahrzeugnutzungsänderung; und
5 zeigt einen beispielhaften Prozess für den Empfang und die Bestätigung einer Fahrzeugnutzungsänderung.
AUSFÜHRLICHE BESCHREIBUNG
Wie erforderlich, werden hierin ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Details besonderer Komponenten zu zeigen. Die speziellen strukturellen und funktionalen Details, die hier offenbart werden, sollen deshalb nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einen Fachmann zu lehren, wie die vorliegende Erfindung auf verschiedene Weise einzusetzen ist.
1 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem 1 (VCS) für ein Fahrzeug 31. Ein Beispiel für ein solches fahrzeuggestütztes Datenverarbeitungssystem 1 ist das von THE FORD MOTOR COMPANY hergestellte System SYNC. Ein mit einem fahrzeuggestützten Datenverarbeitungssystem befähigtes Fahrzeug kann eine im Fahrzeug befindliche visuelle Frontend-Schnittstelle 4 enthalten. Der Benutzer kann auch in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm ausgestattet ist. Bei einer anderen beispielhaften Ausführungsform erfolgt die Interaktion durch Tastenbetätigungen, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der Prozessor ist in dem Fahrzeug vorgesehen und erlaubt Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nichtpersistentem 5 als auch mit persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nichtpersistente Speicher ein Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Allgemein kann persistenter (nichtflüchtiger) Speicher alle Arten von Speicher beinhalten, die Daten halten, wenn ein Computer oder eine andere Einrichtung ausgeschaltet wird. Dazu gehören, jedoch ohne Beschränkung darauf, HDDs, CDs, DVDs, Magnetbänder, Halbleiterlaufwerke, tragbare USB-Laufwerke und jegliche andere geeignete Form von persistentem Speicher.
Der Prozessor ist außerdem mit einer Anzahl von unterschiedlichen Eingängen versehen, die es dem Nutzer ermöglichen, mit dem Prozessor in Verbindung zu treten. Bei dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Zusatzeingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, welcher ein Berührungsbildschirm sein kann, und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist ein Eingangsselektor 51 vorgesehen, um es einem Benutzer zu erlauben, zwischen verschiedenen Eingängen zu wählen. Eingaben sowohl in das Mikrofon als auch in den Hilfsstecker werden von einem Wandler 27 von analog in digital umgewandelt, bevor sie zu dem Prozessor geleitet werden. Wenngleich nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS verbunden sind, ein Fahrzeugnetzwerk (wie beispielsweise, jedoch ohne Beschränkung auf einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) zu leiten.
Zu Ausgängen des Systems können, unter anderem, eine visuelle Anzeige 4 und ein Lautsprecher 13 oder ein Stereo-Systemausgang zählen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Wandler 9 von dem Prozessor 3. Die Ausgabe kann auch an ein rechnerfernes BLUETOOTH-Gerät wie PND 54 oder ein USB-Gerät wie ein Fahrzeugnavigationsgerät 60 entlang der bidirektionalen Datenströme erfolgen, die bei 19 bzw. 21 dargestellt sind.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den Bluetooth-Transceiver 15, um mit einer nomadischen Vorrichtung 53 des Nutzers zu kommunizieren 17 (z. B. einem Mobiltelefon, Smartphone, PDA oder irgendeiner anderen Vorrichtung, die drahtlose Konnektivität zu entfernten Netzwerken aufweist). Die nomadische Vorrichtung kann dann zur Kommunikation 59 mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 verwendet werden. Bei einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Beispielhafte Kommunikation zwischen der nomadischen Vorrichtung und dem BLUETOOTH-Transceiver wird durch das Signal 14 dargestellt.
Das Paaren einer nomadischen Vorrichtung 53 und des BLUETOOTH-Sendeempfängers 15 kann mittels einer Taste 52 oder ähnlichen Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der Bord-BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einer nomadischen Vorrichtung gepaart wird.
Daten können zum Beispiel unter Verwendung eines Datenplans, von Data-over-Voice oder von DTMF-Tönen, die mit der nomadischen Einrichtung 53 assoziiert sind, zwischen der CPU 3 und dem Netzwerk 61 übermittelt werden. Als Alternative kann es wünschenswert sein, ein bordseitiges Modem 63 mit Antenne 18 aufzunehmen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übertragen 16. Die nomadische Vorrichtung 53 kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, zum Beispiel über die Verbindung 55 mit einem Mobilfunkmast 57. Bei bestimmten Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Mast 57 zur Kommunikation mit dem Netzwerk 61 herstellen. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Zellularmodem sein und die Kommunikation 20 kann Zellularkommunikation sein.
Bei einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API (Application Program Interface) zur Kommunikation mit Modem-Anwendungssoftware umfasst. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Sender/Empfänger zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sender/Empfänger (wie etwa dem in einer mobilen Vorrichtung anzutreffenden) herzustellen. BLUETOOTH ist eine Teilmenge der IEEE 802 PAN(Personal Area Network)-Protokolle. IEEE 802 LAN(Local Area Network)-Protokolle beinhalten WiFi und weisen beträchtliche übergreifende Funktionalitäten mit IEEE 802 PAN auf. Beide eignen sich für drahtlose Kommunikation in einem Fahrzeug. Ein anderes Kommunikationsmittel, das in diesem Bereich verwendet werden kann, sind optische Freiraumkommunikation (wie etwa IrDA) und nichtstandardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform umfasst die nomadische Vorrichtung 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. In der Ausführungsform Data Over Voice wird möglicherweise eine als Frequenzmultiplexen bekannte Technik umgesetzt, wenn der Besitzer der nomadischen Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Eigentümer die Vorrichtung nicht benutzt, kann der Datentransfer die gesamte Bandbreite verwenden (in einem Beispiel 300 Hz bis 3,4 kHz). Obwohl Frequenzmultiplexen für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und weiterhin verwendet wird, wurde es zum großen Teil durch Hybride von CDMA (Code Domain Multiple Access), TDMA (Time Domain Multiple Access), SDMA (Space-Domain Multiple Access) für digitale zellulare Kommunikation ersetzt. Diese sind alle ITU IMT-2000 (3G) genügende Standards und bieten Datenraten bis zu 2 mbs für stationäre oder gehende Benutzer und 385 kbs für Benutzer in einem sich bewegenden Fahrzeug. 3G-Standards werden nun durch IMT-Advanced (4G) ersetzt, der 100 mbs oder eine höhere Downlink-Geschwindigkeit bieten kann. Falls der Nutzer über einen mit der nomadischen Vorrichtung verknüpften Datentarif verfügt, ist es möglich, dass der Datentarif Breitband-Übertragung gestattet und dass das System eine viel größere Bandbreite verwenden könnte (was die Datenübertragung beschleunigt). Bei einer weiteren Ausführungsform wird die mobile Vorrichtung 53 durch eine zellulare Kommunikationseinrichtung (nicht gezeigt) ersetzt, die in dem Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann die ND 53 eine Vorrichtung mit Wireless Local Area Network (LAN) sein, das zum Beispiel (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
In einer Ausführungsform können ankommende Daten durch die mobile Vorrichtung über Data-over-Voice oder Datenplan geleitet werden, durch den Onboard-BLUETOOTH-Sender/Empfänger und in den internen Prozessor 3 des Fahrzeugs. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf der HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zu zusätzlichen Quellen, die möglicherweise mit dem Fahrzeug in Verbindung stehen, zählen eine persönliche Navigationsvorrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeug-Navigationsvorrichtung 60, die eine USB-Verbindung 62 oder eine andere Verbindung aufweist, eine Bord-GPS-Vorrichtung 24 oder ein entferntes Navigationssystem (nicht dargestellt), das Konnektivität zum Netz 61 aufweist. USB ist eines einer Klasse von Serienvernetzungsprotokollen. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), EIA (Electronics Industry Association) serielle Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der Standards für serielle Kommunikation von Vorrichtung zu Vorrichtung. Die meisten der Protokolle können entweder für elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielzahl anderer Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Einrichtungen können durch eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden sein. Die Zusatzeinrichtung 65 kann, aber ohne Beschränkung darauf, persönliche Medien-Player, drahtlose Gesundheitseinrichtungen, tragbare Computer und dergleichen umfassen.
Ebenso oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 zum Beispiel unter Verwendung eines WiFi-Transceivers (IEEE 803.11) 71 verbunden werden. Dies könnte es der CPU gestatten, sich mit in Reichweite des lokalen Routers 73 befindlichen entfernten Netzen zu verbinden.
Zusätzlich dazu, dass repräsentative Prozesse von einem Fahrzeugcomputersystem, das sich in einem Fahrzeug befindet, ausgeführt werden, können die repräsentativen Prozesse in gewissen Ausführungsformen von einem Computersystem ausgeführt werden, das in Kommunikation mit einem Fahrzeugcomputersystem steht. Ein solches System kann, ohne Beschränkung darauf, eine drahtlose Vorrichtung (z.B., aber ohne Beschränkung darauf, ein Mobiltelefon) oder ein entferntes Datenverarbeitungssystem (zum Beispiel, aber ohne Beschränkung darauf, ein Server), das durch die drahtlose Einrichtung verbunden ist, aufweisen. Kollektiv können solche Systeme als ein fahrzeugassoziiertes Datenverarbeitungssystem (VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS abhängig von der jeweiligen Implementierung des Systems bestimmte Teile eines Prozesses durchführen. Beispielhaft und ohne Beschränkung ist es, falls ein Prozess einen Schritt aufweist, in dem er Informationen an eine bzw. von einer gekoppelten drahtlosen Vorrichtung sendet oder empfängt, dann wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, weil die drahtlose Vorrichtung Informationen nicht an sich selbst „senden“ und nicht von sich selbst "empfangen" würde. Ein Durchschnittsfachmann weiß, wann es ungeeignet ist, ein bestimmtes Computersystem auf eine gegebene Lösung anzuwenden.
In jeder der hier erörterten Ausführungsbeispiele wird ein erläuterndes, nicht einschränkendes Beispiel für einen Prozess, der von einem Computersystem durchführbar ist, gezeigt. Bezüglich jedes Prozesses ist es dem Computersystem, das den Prozess ausführt, möglich, für den begrenzten Zweck des Ausführens des Prozesses, als ein Sonderzweck-Prozessor konfiguriert zu werden, um den Prozess durchzuführen. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Typen von Prozessen, die durchgeführt werden können, um Elemente der Erfindung zu erreichen, zu verstehen. Zusätzliche Schritte können auf Wunsch hinzugefügt oder aus den beispielhaften Prozessen entfernt werden.
In derzeitigen Telematiksystemen laden die Elektrofahrzeuge wie Batterieelektrofahrzeuge (BEV) und Plug-In-Hybridfahrzeuge (PHEV) nach Einstellen ihres Ladezeitplans normalerweise ihre „Losfahr“-Zeit auf den Backend-Server hoch. Jedoch verfügt das gegenwärtige System nicht über die Möglichkeit, die Fahrzeugbesitzer daran zu erinnern, ob die „Losfahr“-Zeit oder die bevorzugte Route mit einem bekannten oder vorhergesagten hohen Verkehrsaufkommen in Konflikt steht. Durch Empfehlen einer Änderung der Route und/oder der Startzeit kann zusätzliche Energie eingespart werden, und eine zeiteffizientere Reise an einen Zielort erzielt werden.
2 zeigt ein beispielhaftes System zum Abgeben von Fahrzeugnutzungsempfehlungen. In diesem erläuternden Beispiel steht ein Fahrzeug 201 mit der Cloud 207 durch eine Telematiksteuereinheit (TCU) 203 in drahtloser Kommunikation 205. Das Fahrzeug kann diese Verbindung (die schließlich zur Verbindung mit einem Backend-Server 209 führt) benutzen, um vorhergesagte Nutzungsdaten hochzuladen, die eine vorhergesagte „Losfahr“-Zeit, eine bevorzugte Route/einen bevorzugten Zielort und einen Stromladeprozentanteil einschließen, jedoch nicht darauf beschränkt sind.
Der Backend-Server kann nach Empfang der Daten für ein bestimmtes Fahrzeug Verkehrsinformationen 211 (gegebenenfalls sowohl tatsächliche als auch vorhergesagte Informationen) nutzen, um zu bestimmen, ob eine bessere Route oder Startzeit für die gewünschte Reise vorhanden ist. Interessanterweise kann dies einem höheren Verkehrsaufkommen entsprechen, das den Windwiderstand reduzieren und die regenerative Bremsung erhöhen kann, falls für den Fahrer die Energieeinsparung wichtiger ist als die Fahrtzeit. Natürlich können Bedingungen von weniger Verkehr in Betracht gezogen werden, falls für den Fahrer die Fahrtzeit wichtig ist. Diese Überlegung kann auch einen Batterieladeprozentsatz beinhalten. Falls beispielsweise ein Benutzer um 7:30 Uhr morgens 80 Meilen zu einem vordefinierten Zielort fahren möchte, kann das System bestimmen, dass die Route viel weniger Verkehr hätte, wenn das Fahrzeug um 6:30 Uhr morgens aufbrechen würde. Falls jedoch die gegenwärtige Fahrzeugladung nur eine 20-Meilen-Fahrt unterstützt, kann das System auch berücksichtigen, ob genügend Zeit zwischen der gegenwärtigen Uhrzeit und 6:30 Uhr morgens verbleibt, um das Fahrzeug für die Fahrt aufzuladen. Solche Überlegungen können zum Beispiel die Ladung, die zur Rückfahrt nach Hause benötigt wird, und/oder die Ladung beinhalteten, die zum Erreichen einer bekannten alternativen Aufladestelle benötigt wird.
Falls eine „bessere“ Route oder Startzeit empfohlen wird und angemessen ist, kann der Prozess ein Mobilfunknetz 213 benutzen, um die Empfehlung an ein Benutzertelefon 215 zu senden. Der Benutzer kann dann die Änderung (die auch eine Erhöhung in Bezug auf eine Ladestartzeit, basierend auf einer gegenwärtigen Ladung und einer benötigten Ladung, erforderlich machen kann) bestätigen oder ablehnen.
3 zeigt einen veranschaulichenden Prozess für die Implementierung von Fahrzeugnutzungsänderungen. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweckprozessor umfunktioniert werden, und zwar bis zu dem Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweckprozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
In dem veranschaulichenden Beispiel aus 3 lädt das Fahrzeug Daten im Zusammenhang mit einer geplanten Nutzung (über einen bevorstehenden Zeitraum) auf einen Fernserver zwecks Verarbeitung und Empfehlung alternativer Nutzungspläne 301 hoch. Falls Änderungen einer Abfahrtszeit, Routenänderungen und/oder Änderungen von Ladezeitplänen aus den Empfehlungen resultieren, empfängt der Prozess die empfohlenen Veränderungen 303. In diesem Beispiel kommuniziert dann der fahrzeuggestützte Prozess mit dem Benutzer direkt 305, um eine Implementierung 307 der vorgeschlagenen Änderungen zu bestätigen (oder eine Auswahl aus einer Liste möglicher Änderungen zu empfangen). Falls der Benutzer eine Änderung akzeptiert oder auswählt, dann implementiert das Fahrzeug die Änderungen, zum Beispiel an einem Routenplanungsprozess und/oder einem Ladezeitplan. Eine beliebige Vorkonditionierung basierend auf der vorhergesagten Startzeit kann gemäß der Empfehlung ebenfalls geändert werden.
In einem anderen Beispiel verwaltet der Backend-Server die Bestätigung mit dem Benutzer und kann etwaige benötigte Änderungen an dem Fahrzeug wie von dem Benutzer bestätigt übermitteln. Ein beliebiges Kommunikationsmodell, das dazu führt, dass das Fahrzeug bestätigte/ausgewählte Änderungen implementiert, ist geeignet.
4 zeigt einen veranschaulichenden Prozess für die Bestimmung von Fahrzeugnutzungsänderungen. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweckprozessor umfunktioniert werden, und zwar bis zu dem Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweckprozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel empfängt der Backendserver (der die Instanz ist, die in diesem Beispiel die Empfehlungsberechnung ausführt) die relevanten Daten im Zusammenhang mit der geplanten Nutzung von dem Fahrzeug 401. Diese Daten könnten auch von zum Beispiel einer Zeitplaneingabe in ein Benutzertelefon empfangen werden und/oder das Telefon selbst könnte als die eine Empfehlung bereitstellende Instanz fungieren (falls sie mit dem Fahrzeug direkt oder indirekt in Verbindung steht). In noch einem anderen Beispiel könnte das Fahrzeug selbst die Empfehlungsverarbeitung ausführen, falls eine geeignete Verarbeitungsleistung und Ressourcen zur Verwendung von einem Fahrzeugcomputersystem verfügbar sind.
In diesem Beispiel greift der Prozess dann auf Verkehrsdaten 403 zu. Diese können gegenwärtige Verkehrsdaten (für vor Ort gemachte Empfehlungen) und vorhergesagte Verkehrsdaten beinhalten, die auf beobachteten Verkehrsmustern für einen bestimmten Wochentag, eine bestimmte Uhrzeit und/oder ein bestimmtes Datum basieren. Falls ein hohes (oder ein Schwellenwert-)Verkehrsaufkommen nicht über eine bevorzugte Route vorhergesehen wird (oder auf einer in naher Zukunft zu nehmenden Route beobachtet wird), kann der Prozess eine Bestätigung an das Fahrzeug senden, dass die vorgeschlagene Nutzung angemessen ist 407. Es ist auch möglich, keine Maßnahme zu ergreifen, wobei der Prozess später eine Empfehlung basierend auf einer Änderung hinsichtlich der beobachteten oder vorhergesagten Verkehrsmuster (z. B. falls ein Unfall stattfindet) aktualisieren kann.
Falls ein hohes Verkehrsaufkommen (oder ein hoher Verkehrsschwellenwert) beobachtet oder vorhergesagt wird, kann der Prozess bestimmen, ob eine Fahrzeugladung basierend auf einer bevorzugten Ladestartzeit ausreichend ist, um die bevorzugte Route zur bevorzugten Startzeit zu vollenden. Falls die Ladung nicht ausreichend ist, kann eine Empfehlung zum Ändern der Ladestartzeit an den Benutzer 411 gesendet werden. In anderen Beispielen kann die Empfehlung zu einer Liste möglicher Empfehlungen hinzugefügt werden, die zu einem Zeitpunkt zur Benutzerauswahl gesendet werden soll (sodass der Benutzer keine Ladestartzeitänderung bestätigt und danach wenige Sekunden später eine Empfehlung empfängt, eine andere Route zu nehmen oder eine andere Abfahrtszeit zu verwenden).
Falls bestimmt wird, dass eine bessere Abfahrtszeit vorhanden ist 413, (d. h. eine Abfahrtszeit, die basierend auf einem gegenwärtigen oder vorhergesagten Verkehr über eine Route, die zur empfohlenen Startzeit beginnt, zu einer schnelleren Fahrt führen wird), dann kann der Prozess bestimmen, ob ein ausreichender Ladezustand basierend beispielsweise auf einer gegenwärtigen Aufladestartzeit und einem gegenwärtigen Ladezustand vorhanden sein wird, um die Route zurückzulegen (und/oder nach Hause zurückzukehren oder eine andere Aufladestelle zu erreichen) 415. Falls der Ladezustand nicht ausreichend sein wird oder nicht bereits ausreichend ist, kann der Prozess eine neue Ladestartzeit empfehlen 417. In diesem Fall, oder falls der Ladezustand ausreichend ist oder sein wird, kann der Prozess auch die neue Abfahrtszeit empfehlen 419. Wieder kann diese Empfehlung Teil einer Liste möglicher Handlungen basierend auf verschiedenen Empfehlungen sein.
Für ein diesbezügliches Beispiel, falls ein Benutzer typischerweise um 7:30 Uhr morgens losfährt, jedoch eine Abfahrt von 6:30 Uhr morgens empfohlen wird, kann sich eines der folgenden Szenarien ergeben: a) Das Fahrzeug kann bereits eine angemessene Ladungsmenge für einen beliebigen vorhergesagten Nutzungsbedarf haben, selbst wenn die Route früher beginnt; b) das Fahrzeug kann die angemessene Ladungsmenge basierend auf einer gegenwärtigen Ladestartzeit zu der Zeit erzielen, zu der die neue Abfahrt stattfindet (dies ist oft der Fall, wenn eine spätere Abfahrt empfohlen wird); c) das Fahrzeug kann die geeignete Ladungsmenge basierend auf einer neuen Ladestartzeit zu der Zeit erzielen, zu der die neue Abfahrt stattfindet; oder d) es verbleibt nicht mehr genug Zeit vor der neuen Abfahrtszeit, damit das Fahrzeug die geeignete Ladungsmenge erzielen kann.
In einem veranschaulichenden Beispiel können die obigen Fälle a) und b) lediglich zu einer Empfehlung zur Änderung einer Abfahrtszeit führen. Fall c) kann zu einer Empfehlung zur Änderung einer Abfahrtszeit und einer Empfehlung zur Änderung einer Ladestartzeit führen. Fall d) kann zu einer Entscheidung zum Verzicht auf eine Empfehlung der neuen Abfahrtszeit führen, da sie den Benutzer wahrscheinlich festsitzen lassen wird. In Fall d) kann die neue Abfahrtszeit auch empfohlen werden, jedoch kann es auch ratsam sein, den Benutzer über ein vorhergesagtes Ladungsdefizit zu informieren, sodass der Benutzer weiß, dass eine Aufladung im Laufe des Tages benötigt werden kann.
Danach wird in dem veranschaulichenden Prozess bestimmt, ob eine oder mehrere bessere Routen (d. h. schnellere Routen und/oder Routen mit weniger Verkehr oder einer geringeren Verkehrswahrscheinlichkeit) vorhanden ist 421. Falls keine besseren Routen vorhanden sind, kann der Prozess die gegenwärtigen Einstellungen beibehalten 429 und/oder Empfehlungen im Zusammenhang mit noch nicht gesendeten empfohlenen Änderungen an den Benutzer senden. Eine Bestätigung gemäß Benutzerauswahlen (falls vorhanden) kann auch zu diesem Zeitpunkt 431 nach Empfang einer Benutzerauswahl und/oder Bestätigung gesendet werden.
Falls bessere Routen oder eine einzige bessere Route vorhanden ist, bestimmt der Prozess erneut, ob ein Ladezustand zur Vollendung der Fahrt über die neue(n) Route(n) ausreichend ist oder sein wird. Wie oben kann diese Überlegung einen gegenwärtigen Ladezustand, einen vorhergesagten Ladezustand und eine Ladung beinhalten, von der bestimmt wird, dass sie benötigt wird, um nach Hause zurückzukehren und/oder um eine Aufladestelle zu erreichen. Falls die Ladung unzureichend ist oder sein wird, kann der Prozess wie oben eine neue Ladestartzeit empfehlen 425. Falls die Ladung ausreichend ist oder sein wird oder in Verbindung mit der Änderungsempfehlung der Ladestartzeit kann der Prozess dann eine oder mehrere neue Routen empfehlen.
In jedem der obigen Fälle können eine oder mehrere Empfehlungen bereitgestellt werden. Zum Beispiel kann ein ganzer Satz von Empfehlungen Folgendes beinhalten:
1) Eine Mitteilung, dass das Verkehrsaufkommen hoch sein wird, und falls eine gewünschte Startzeit beibehalten werden soll, die Aufladung eine Stunde früher beginnen muss, um ein Energiedefizit aufgrund von Verzögerungen zu vermeiden; 2) eine Empfehlung zum Ändern einer Abfahrtszeit von 7:30 Uhr in 8:30 Uhr, einschließlich, falls gewünscht, einer vorhergesagten Fahrtzeitdifferenz und/oder Energienutzungsdifferenz; 3) eine Empfehlung zum Ändern einer Abfahrtszeit von 7:30 Uhr in 6:30 Uhr und eine Empfehlung zum Beginn der Aufladung 30 Minuten früher, einschließlich etwaiger Änderungen gegebenenfalls an Fahrtzeit und Energieverbrauch; 4) eine Empfehlung zur Verwendung einer alternativen Route A, einschließlich etwaiger Änderungen gegebenenfalls an Fahrtzeit und Energieverbrauch; 5) eine Empfehlung zur Verwendung einer alternativen Route B und eine Empfehlung zum Beginn der Aufladung 45 Minuten früher, einschließlich etwaiger Änderungen gegebenenfalls an Fahrtzeit und Energieverbrauch; und 6) eine Empfehlung zur Abfahrt um 7:10 Uhr, zur Verwendung einer alternativen Route B und eine Empfehlung zum Beginn der Aufladung 25 Minuten früher, einschließlich etwaiger Änderungen gegebenenfalls an Fahrtzeit und Energieverbrauch.
Wie aus dem obigen Beispiel zu sehen ist, stellt Empfehlung 6) eine Abfahrtszeit bereit, die sich am nächsten an die gewünschte Abfahrtszeit annähert, verwendet jedoch auch eine alternative Route, um eine schnellere Ankunft und/oder weniger Energieverbrauch sicherzustellen. In diesem Fall kann Route B etwas länger sein und eine geringfügige Einstellung an der Aufladezeit erforderlich machen, was auch auf der früheren Startzeit basieren könnte. Der Benutzer könnte eine beliebige erwünschte empfohlene Änderung auswählen und der Prozess könnte dann Anweisungen an das Fahrzeug senden, die entsprechenden Änderungen beispielsweise an Abfahrtszeit, Routendaten und/oder Vorkonditionierungsstartzeit vorzunehmen.
5 zeigt einen veranschaulichenden Prozess für den Empfang und die Bestätigung einer Fahrzeugnutzungsänderung. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweckprozessor umfunktioniert werden, und war bis zu dem Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweckprozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel repräsentiert der Prozess einen Benutzerbestätigungsprozess, der beispielsweise auf einer Benutzervorrichtung ausgeführt wird. Hier empfängt der Benutzer eine Benachrichtigung einer empfohlenen Änderung 501, einschließlich einer oder mehrerer Empfehlungen für Änderungen an Abfahrtszeit, Route und/oder Aufladestartzeit. Der Prozess empfängt eine Benutzerauswahl der entsprechenden Empfehlung und prüft dann in diesem Fall gegen, um sicherzustellen, dass auch eine neue Aufladestartzeit gewählt wurde und geeignet ist, eine ausreichende Ladung vor der Reise zu erhalten 505. Falls die Ladung ausreichend sein wird, sendet der Prozess die neuen Einstellungen an das Fahrzeug 511 (dies kann indirekt durch den Server erfolgen, je nach dem verwendeten Kommunikationssystem). Falls der Benutzer eine neue Abfahrt oder Route auswählt, jedoch keine Änderungen an der Ladestartzeit vornehmen möchte, kann der Prozess den Fahrer warnen, dass eine unzureichende Ladung für die vorhergesagte Nutzung wahrscheinlich ist 507. Falls der Fahrer bestätigt, dass dies ok ist (zum Beispiel falls der Fahrer weiß, dass er das Fahrzeug an seiner Arbeitsstelle aufladen kann, wobei dem Prozess diese Tatsache möglicherweise nicht bekannt ist); dann kann der Prozess die Änderungen an das Fahrzeug senden. Anderenfalls kann der Fahrer die Änderung basierend auf einem Wunsch, die Ladestartzeit nicht zu ändern, ablehnen und der Prozess kann beendet werden, ohne die Änderungen zu senden.
Wenngleich oben Ausführungsbeispiele beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Spezifikation verwendeten Begriffe beschreibende und keine einschränkende Begriffe, und es versteht sich, dass diverse Änderungen vorgenommen werden können, ohne vom Sinn und vom Schutzbereich der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener implementierender Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE 1394 [0023]
IEEE 1284 [0023]
IEEE 803.11 [0025]

Claims

System, das Folgendes umfasst: einen Prozessor, der für Folgendes konfiguriert ist: Empfangen einer gewünschten Abfahrtszeit für eine bevorstehende Fahrt von einem Fahrzeugcomputersystem; Bestimmen eines Verkehrsaufkommens basierend auf der empfangenen Abfahrtszeit und Route; Bestimmen eines Fahrzeugladezustands; und Empfehlen einer neuen Route oder Abfahrtszeit, falls vorhergesagt wird, dass der Fahrzeugladezustand ausreichend ist, um eine Fahrtvollendung basierend auf der neuen Route und Abfahrtszeit zu erzielen.
System nach Anspruch 1, wobei das Verkehrsaufkommen ein gegenwärtiges Verkehrsaufkommen ist.
System nach Anspruch 1, wobei das Verkehrsaufkommen ein vorhergesagtes Verkehrsaufkommen ist.
System nach Anspruch 1, wobei der Fahrzeugladezustand ein gegenwärtiger Fahrzeugladezustand ist.
System nach Anspruch 1, wobei der Fahrzeugladezustand ein vorhergesagter Fahrzeugladezustand basierend auf einer bevorzugten Ladestartzeit ist.
System nach Anspruch 5, wobei der Prozessor ferner konfiguriert ist, eine neue Ladestartzeit zu empfehlen, falls vorhergesagt wird, dass der vorhergesagte Fahrzeugladezustand unzureichend ist, um eine Fahrtvollendung basierend auf der neuen Route oder Abfahrtszeit zu erzielen.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist, die neue Route oder Abfahrtszeit in einer Nachricht an eine Benutzervorrichtung zu empfehlen.
System nach Anspruch 7, wobei der Prozessor konfiguriert ist, eine Annahmebestätigung der neuen Route oder Abfahrtszeit von der Benutzervorrichtung zu empfangen.
System nach Anspruch 8, wobei der Prozessor konfiguriert ist, nach Bestätigen des Empfangs Anweisungen an das Fahrzeugcomputersystem zu senden, die das Fahrzeugcomputersystem über die angenommene neue Route oder Abfahrtszeit informieren.
Computerimplementiertes Verfahren, das Folgendes umfasst: Bestimmen einer neuen Abfahrtszeit oder Fahrtroute, die voraussichtlich dazu führt, dass auf weniger Verkehr als bei der Fahrt über eine empfangene bevorzugte Route getroffen wird, die zu einer empfangenen bevorzugten Abfahrtszeit beginnt; und Senden der neuen Abfahrtszeit oder Fahrtroute an eine Benutzervorrichtung zwecks Bestätigung.
Verfahren nach Anspruch 10, wobei eine Verkehrsvorhersage für die Fahrt über die empfangene Route und eine Verkehrsvorhersage für eine Fahrt, die zur neuen Abfahrtszeit oder über die neue Fahrtroute beginnt, auf historischen Verkehrsdaten basiert.
Verfahren nach Anspruch 10, wobei eine Verkehrsvorhersage für eine Fahrt über die empfangene Route und eine Verkehrsvorhersage für eine Fahrt, die zur neuen Abfahrtszeit oder über die neue Fahrtroute beginnt, auf gegenwärtigen Verkehrsdaten basiert.
Verfahren nach Anspruch 10, ferner umfassend das Senden der neuen Abfahrtszeit oder Fahrtroute in Abhängigkeit davon, dass eine vorhergesagte Fahrzeugladung ausreichend ist, um die Fahrt beginnend zur neuen Abfahrtszeit oder über die neue Fahrtroute zu vollenden.
Verfahren nach Anspruch 13, ferner umfassend das Senden einer neuen empfohlenen Ladestartzeit an die Benutzervorrichtung in Verbindung mit der neuen Abfahrtszeit oder Fahrtroute, falls eine vorhergesagte Fahrzeugladung unzureichend ist, um die Fahrt beginnend zur neuen Abfahrtszeit oder über die neue Fahrtroute zu vollenden.
Verfahren nach Anspruch 14, ferner umfassend das Senden von Anweisungen an ein Fahrzeug, um mit einer Ladung zur neuen empfohlenen Ladestartzeit nach einer Empfangsbestätigung der neuen empfohlenen Ladestartzeit von der Benutzervorrichtung zu beginnen.
Verfahren nach Anspruch 10, ferner umfassend das Senden eines aktualisierten Fahrplans an ein Fahrzeug nach Empfangsbestätigung der neuen Abfahrtszeit oder der neuen Fahrtroute von der Benutzervorrichtung.
System, das Folgendes umfasst: einen Prozessor, der für Folgendes konfiguriert ist: Bestimmen einer vorhergesagten Fahrtzeit basierend auf einem vorhergesagten Verkehrsaufkommen über eine bevorzugte Route, die zu einer bevorzugten Abfahrtszeit beginnt, die von einem Fahrzeugcomputer empfangen wird; und Empfehlen einer alternativen Abfahrtszeit oder einer alternativen Route, die zu einer geringeren vorhergesagten Fahrtzeit führt, falls vorhergesagt wird, dass ein gegenwärtiger Fahrzeugladezustand, der von dem Fahrzeugcomputer empfangen wird, zur Vollendung der Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route ausreichend ist.
System nach Anspruch 17, wobei der Prozessor ferner konfiguriert ist, eine Fahrzeugladestartzeit zu empfehlen, die voraussichtlich zu einem Ladezeitraum führt, der einen ausreichenden Fahrzeugladezustand bereitstellt, um die Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route zu vollenden, falls vorhergesagt wird, dass der gegenwärtige Fahrzeugladezustand zur Vollendung der Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route unzureichend ist.
System nach Anspruch 17, wobei der Prozessor ferner konfiguriert ist, die alternative Abfahrtszeit oder die alternative Route zu empfehlen, falls vorhergesagt wird, dass ein vorhergesagter Fahrzeugladezustand basierend auf einer gegenwärtigen Ladestartzeit, die von dem Fahrzeugcomputer empfangen wird, zur Vollendung der Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route ausreichend ist.
System nach Anspruch 19, wobei der Prozessor ferner konfiguriert ist, eine neue Fahrzeugladestartzeit zu empfehlen, die voraussichtlich zu einem Ladezeitraum führt, der einen ausreichenden Fahrzeugladezustand bereitstellt, um die Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route zu vollenden, falls vorhergesagt wird, dass der vorhergesagte Fahrzeugladezustand zur Vollendung der Fahrt unter Verwendung der alternativen Abfahrtszeit oder der alternativen Route unzureichend ist.