DE102017126167A1

DE102017126167A1 - Verfahren und vorrichtung zur fahrzeugfahrunterstützung

Info

Publication number: DE102017126167A1
Application number: DE102017126167.2A
Authority: DE
Inventors: William Paul Perkins; Kenneth James Miller; David B. Kelley; Jimmy KAPADIA
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-11-11
Filing date: 2017-11-08
Publication date: 2018-05-17
Also published as: US10006778B2; CN108074412B; US20180136003A1; CN108074412A

Abstract

Ein System beinhaltet einen Prozessor, der dazu programmiert ist, eine erste und eine zweite empfohlene Route an eine drahtlose Vorrichtung als Reaktion auf das Empfangen eines gegenwärtigen Fahrzeugstandortes, der beim Parken des Fahrzeugs gespeichert wurde, und auch eines empfangenen Zielortes und einer Abfahrtszeit zu senden. Die erste empfohlene Route basiert auf Fahrzeitfaktoren, die dem Zielort und der Abfahrtszeit und spezifizierten Routenfindungs- und Zeitplanungspräferenzen entsprechen. Die zweite empfohlene Route basiert auf einer berechneten alternativen Abfahrtszeit unter Verwendung der spezifizierten Präferenzen.

Description

TECHNISCHES GEBIET
Die Ausführungsbeispiele betreffen im Allgemeinen ein Verfahren und eine Vorrichtung für die Fahrzeugfahrunterstützung.
ALLGEMEINER STAND DER TECHNIK
Viele Quellen für aktuelle Wetter- und Verkehrsinformationen stehen Fahrern zur Verwendung bei der Planung von Routen zur Verfügung, um Staus oder andere Verzögerungen zu vermeiden. Allerdings denken Fahrer möglicherweise erst dann daran, mögliche Verzögerungen in Betracht zu ziehen, wenn sie bereits unterwegs sind. Die Planung im Vorfeld kann zur Minderung von Verzögerungen beitragen, jedoch kann die Zusammenstellung von Verkehrs- und Wetterinformationen eine komplizierte Aufgabe sein. Außerdem können sich vorhergesagte Verkehrs- und Wettersituationen vor einer geplanten Abfahrt verändern, wodurch die Nützlichkeit einer Planung im Vorfeld verringert wird.
Eine andere Überlegung ist die Zeit und der Aufwand, die eine detaillierte Routenplanung mit sich bringen. Fahrer verfügen typischerweise nicht über einen ganzen Nachmittag, um Verkehrsmuster zu verfolgen, Wetterfronten zu verfolgen und geplante Routen zu einem Zielort zu modifizieren. Fahrer sind möglicherweise noch nicht einmal dazu in der Lage, alle Ressourcen, die für eine Planung von Routen auf diese Weise benötigt werden, zu finden und/oder Zugriff zu diesen zu haben. Falls Fahrer Zugriff zu all diesen Ressourcen haben können, ist es ein relativ unrealistisches Vorhaben, zu erwarten, dass man jeden Tag einige Stunden mit der Planung der optimalen Version eines zwanzig- oder dreißigminütigen Arbeitsweges verbringt.
Vor einigen Jahrzehnten hätte ein Fahrer eine Straßenkarte in Papierform zur Hand genommen, eine Route zu einem Zielort bestimmt und gegebenenfalls lokales Wissen und Wetterberichte für die Optimierung der Route genutzt. Änderungen hinsichtlich des Wetters und Verkehrs auf der Route hätte man einfach und ohne große Mühe Rechnung getragen. Heutzutage können Navigationssysteme zur Identifizierung von Routen, Straßenschließungen und Verkehrsstockungen beitragen. Allerdings weist der Verkehr eine historische Komponente auf und unterliegt auch momentanen Veränderungen. In ähnlicher Weise sind Wetterberichte zuweilen unzuverlässig, wobei ihre prognostizierte Wirkung auf einer Route im Laufe des Tages und aufgrund von Änderungen von Wettermustern variieren kann. Wenngleich zur Optimierung von Routen viel mehr Informationen verfügbar sind, stellt die unverbundene und dynamische Natur der Daten neue Probleme bezüglich Zugriff bzw. Wirkungsbestimmung dar.
KURZDARSTELLUNG
In einem ersten Ausführungsbeispiel beinhaltet ein System einen Prozessor, der dazu programmiert ist, eine erste und eine zweite empfohlene Route an eine drahtlose Vorrichtung als Reaktion auf das Empfangen eines gegenwärtigen Fahrzeugstandortes, der beim Parken des Fahrzeugs gespeichert wurde, und auch eines empfangenen Zielortes und einer Abfahrtszeit zu senden. Die erste empfohlene Route basiert auf Fahrzeitfaktoren, die dem Zielort und der Abfahrtszeit und spezifizierten Routenfindungs- und Zeitplanungspräferenzen entsprechen. Die zweite empfohlene Route basiert auf einer berechneten alternativen Abfahrtszeit unter Verwendung der spezifizierten Präferenzen.
In einem zweiten Ausführungsbeispiel beinhaltet ein computerimplementiertes Verfahren das Berechnen einer prognostizierten Fahrzeit für eine vom Fahrer ausgewählte Route zu einem Zielort als Reaktion auf eine Definition des Zielortes und einer bevorzugten Abfahrtszeit. Das Verfahren beinhaltet das Berechnen in vordefinierten Zeitintervallen zwischen einer gegenwärtigen Zeit und der bevorzugten Abfahrtszeit. Das Verfahren beinhaltet auch das Empfehlen einer alternativen Abfahrtszeit, die berechnet wird, um zu einer kürzeren Fahrzeit zum Zielort zu führen, als Reaktion darauf, dass die berechnete prognostizierte Fahrzeit um mehr als einen vorbestimmten Schwellenwert gegenüber einer anfänglichen prognostizierten Fahrzeit zunimmt.
In einem dritten Ausführungsbeispiel beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, von einem Fahrzeug drahtlos eine Mehrzahl von empfohlenen Abfahrtszeiten und entsprechende prognostizierte Fahrzeiten zu einem Zielort zu empfangen, der von einem Benutzer bestätigt wird. Der Prozessor ist auch dazu konfiguriert, die empfohlenen Abfahrtszeiten und entsprechenden prognostizierten Fahrzeiten auf eine vom Benutzer auswählbare Weise anzuzeigen. Der Prozessor ist ferner dazu konfiguriert, eine Auswahl von empfohlenen Abfahrtszeiten als eine bevorzugte Abfahrtszeit zu empfangen und die ausgewählte empfohlene Abfahrtszeit an das Fahrzeug zu übermitteln.
Figurenliste

1 veranschaulicht ein repräsentatives Fahrzeugrechensystem;
2 veranschaulicht einen repräsentativen Prozess zur Zielortbestimmung und Abfahrtsunterstützung;
3 veranschaulicht einen repräsentativen Prozess zur Routen- und Abfahrtszeitverbesserung;
4 veranschaulicht einen repräsentativen Prozess zur Routen- und Abfahrtszeitauswertung;
5 veranschaulicht einen repräsentativen Prozess zur Routen- und Abfahrtszeitüberwachung;
6 veranschaulicht repräsentative Routenempfehlungsanzeigen; und
7 veranschaulicht ein vom Benutzer einstellbares Schaubild der Fahrzeit gegenüber der Abfahrtszeit.

DETAILLIERTE BESCHREIBUNG
Wie erfordert, sind hierin detaillierte Ausführungsformen offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein veranschaulichend sind und in verschiedenen und alternativen Formen ausgeführt werden können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder minimiert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Daher sollen hierin offenbarte spezielle strukturelle und funktionale Einzelheiten nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einen Fachmann zu lehren, wie der beanspruchte Gegenstand auf verschiedene Art und Weise einzusetzen ist.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechensystem 1 (Vehicle-based Computing System - VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines solchen fahrzeugbasierten Rechensystems 1 ist das SYNC-System, das von THE FORD MOTOR COMPANY hergestellt wird. Ein Fahrzeug, das mit einem fahrzeugbasierten Rechensystem ausgerüstet ist, kann eine visuelle Front-End-Schnittstelle 4 enthalten, die sich im Fahrzeug befindet. Der Benutzer kann auch mit der Schnittstelle interagieren, falls diese zum Beispiel mit einem berührungsempfindlichen Bildschirm bereitgestellt ist. In einer anderen veranschaulichenden Ausführungsform findet die Interaktion durch das Drücken von Knöpfen, ein gesprochenes Dialogsystem mit automatischer Spracherkennung und Sprachsynthese statt.
In der veranschaulichenden Ausführungsform 1, die in 1 dargestellt ist, steuert ein Prozessor 3 mindestens einen Abschnitt des Betriebs des fahrzeugbasierten Rechensystems. Im Fahrzeug bereitstellt, ermöglicht der Prozessor eine Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nicht persistentem 5 als auch persistentem Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nicht persistente Speicher ein wahlfreier Zugriffsspeicher (RAM) und der persistente Speicher ist ein Festplattenspeicher (HDD) oder ein Flashspeicher. Im Allgemeinen kann der persistente (nicht flüchtige) Speicher alle Formen von Speicher beinhalten, die Daten beibehalten, wenn ein Computer oder eine andere Vorrichtung abgeschaltet wird. Dazu gehören unter anderem HDDs, CDs, DVDs, magnetische Bänder, Solid-State-Laufwerke, tragbare USB-Laufwerke und jede beliebige andere geeignete Form von persistentem Speicher.
Der Prozessor ist auch mit einer Anzahl verschiedener Eingaben versehen, die es dem Benutzer ermöglichen, sich mit dem Prozessor zu verbinden. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, eine Hilfseingabe 25 (für die Eingabe 33), eine USB-Eingabe 23, eine GPS-Eingabe 24, ein Bildschirm 4, der eine Berührungsbildschirm-Anzeige sein kann, und eine BLUETOOTH-Eingabe 15 bereitgestellt. Ein Eingabewähler 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingaben wechseln kann. Die Eingabe sowohl für das Mikrofon als auch den Hilfsverbinder wird von einem Wandler 27 von analog in digital umgewandelt, bevor sie an den Prozessor geleitet wird. Wenngleich nicht dargestellt, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS kommunizieren, ein Fahrzeugnetzwerk (wie beispielsweise einen CAN-Bus, ohne darauf beschränkt zu sein) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) zu übertragen.
Ausgaben des Systems können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder eine Stereosystemausgabe beinhalten, ohne darauf beschränkt zu sein. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Wandler 9. Eine Ausgabe kann auch an eine rechnerferne BLUETOOTH-Vorrichtung wie ein PND 54 oder eine USB-Vorrichtung wie eine Fahrzeugnavigationsvorrichtung 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 tragbaren Vorrichtung 53 eines Benutzers (z. B. Mobiltelefon, Smartphone, PDA oder eine beliebige andere Vorrichtung, die eine drahtlose rechnerferne Netzwerkkonnektivität aufweist) zu kommunizieren 17. Die tragbare Vorrichtung kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch beispielsweise Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann ein Mast 57 ein WLAN-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen der tragbaren Vorrichtung und dem BLUETOOTH-Transceiver wird von dem Signal 14 dargestellt.
Die Kopplung einer tragbaren Vorrichtung 53 und des BLUETOOTH-Transceivers 15 kann durch einen Knopf 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einer tragbaren Vorrichtung gekoppelt wird.
Daten können zwischen der CPU 3 und dem Netzwerk 61 unter Verwendung zum Beispiel eines Datenplans, Data-Over-Voice oder DTMF-Tönen, die der tragbaren Vorrichtung 53 zugeordnet sind, kommuniziert werden. Als Alternative kann es wünschenswert sein, ein Onboard-Modem 63 mit einer Antenne 18 aufzunehmen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Die tragbare Vorrichtung 53 kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch beispielsweise Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein zelluläres USB-Modem sein und die Kommunikation 20 kann eine zelluläre Kommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem bereitgestellt, das einen API beinhaltet, um mit einer Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Transceiver zugreifen, um eine drahtlose Kommunikation mit einem rechnerfernen BLUETOOTH-Transceiver (wie demjenigen in einer tragbaren Vorrichtung) zu vollenden. Bluetooth ist ein Teilsatz der IEEE 802 PAN (Personal Area Network)-Protokolle. IEEE 802 LAN (Local Area Network)-Protokolle schließen WLAN ein und haben eine erhebliche übergreifende Funktionalität mit IEEE 802 PAN. Beide sind zur drahtlosen Kommunikation innerhalb eines Fahrzeugs geeignet. Ein anderes Kommunikationsmittel, das in diesem Bereich verwendet werden kann, ist die optische Freiraumkommunikation (wie IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet die tragbare Vorrichtung 53 ein Modem zur Sprachband- oder Breitband-Datenkommunikation. In der Ausführungsform mit Data-Over-Voice kann eine Technik implementiert werden, die als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der tragbaren Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Benutzer die Vorrichtung nicht nutzt, kann die Datenübertragung die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) nutzen. Wenngleich das Frequenzmultiplexverfahren zur analogen zellulären Kommunikation zwischen dem Fahrzeug und dem Internet üblich ist und noch immer angewendet wird, wurde es größtenteils durch Mischformen von Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) zur digitalen zellulären Kommunikation ersetzt. Falls der Benutzer einen Datenplan hat, welcher der tragbaren Vorrichtung zugeordnet ist, ist es möglich, dass der Datenplan eine Breitbandübertragung ermöglicht und das System eine viel breitere Bandbreite nutzen könnte (was die Datenübertragung beschleunigt). In noch einer anderen Ausführungsform wird die tragbare Vorrichtung 53 durch eine zelluläre Kommunikationsvorrichtung (nicht dargestellt) ersetzt, die im Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann die ND (Nomadic Device = tragbare Vorrichtung) 53 eine drahtlose Local Area Network-(LAN)-Vorrichtung sein, die zur Kommunikation über beispielsweise (und ohne Einschränkung) ein 802.11g-Netzwerk (d. h. WLAN) oder ein WiMax-Netzwerk fähig ist.
In einer Ausführungsform können ankommende Daten durch die tragbare Vorrichtung über Data-Over-Voice oder einen Datenplan, durch den Onboard-BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs übertragen werden. Im Falle bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder anderen Speichermedien 7 so lange gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die mit dem Fahrzeug verbunden sein können, schließen eine persönliche Navigationsvorrichtung 54 ein, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60, die eine USB 62 oder eine andere Verbindung aufweist, eine Onboard-GPS-Vorrichtung 24 oder ein rechnerfernes Navigationssystem (nicht dargestellt), das Konnektivität zum Netzwerk 61 aufweist. USB ist eines einer Klasse von seriellen Netzwerkprotokollen. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Grundgerüst der seriellen Standards von Vorrichtung zu Vorrichtung. Die meisten Protokolle können entweder zur elektrischen oder zur optischen Kommunikation verwendet werden.
Ferner könnte die CPU mit verschiedenen anderen Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können durch eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden sein. Die Hilfsvorrichtung 65 kann persönliche Mediaplayer, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten, ohne darauf beschränkt zu sein.
Ferner oder als Alternative könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, der zum Beispiel einen WLAN (IEEE 803.11) 71-Transceiver verwendet. Dadurch kann die CPU mit rechnerfernen Netzwerken innerhalb der Reichweite des lokalen Routers 73 verbunden werden.
Neben beispielhaften Prozessen, die von einem Fahrzeugrechensystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die beispielhaften Prozesse in bestimmten Ausführungsformen von einem Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein solches System kann eine drahtlose Vorrichtung (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein rechnerfernes Rechensystem (z. B. und ohne Einschränkung einen Server), das durch die drahtlose Vorrichtung verbunden ist, beinhalten, ohne darauf beschränkt zu sein. Insgesamt können solche Systeme als fahrzeugassoziierte Rechensysteme (Vehicle Associated Computing Systems - VACS) bezeichnet werden. In gewissen Ausführungsformen können bestimmte Komponenten der VACS in Abhängigkeit der jeweiligen Implementierung des Systems bestimmte Abschnitte eines Prozesses ausführen. Falls zum Beispiel und ohne Einschränkung ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Abschnitt des Prozesses nicht ausführt, da die drahtlose Vorrichtung keine Informationen mit sich selbst „sendet und empfängt“. Ein Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine jeweilige Lösung anzuwenden.
In jeder der hierin erläuterten veranschaulichenden Ausführungsformen ist ein beispielhaftes, nicht einschränkendes Beispiel eines Prozesses dargestellt, der von einem Rechensystem ausführbar ist. Unter Bezugnahme auf jeden Prozess kann das Rechensystem, das den Prozess ausführt, für den begrenzten Zweck der Ausführung des Prozesses als ein Spezialprozessor konfiguriert werden, um den Prozess auszuführen. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Typen von Prozessen zu verstehen, die zur Erzielung von Elementen der Erfindung ausgeführt werden können. Zusätzliche Schritte können je nach Wunsch zu den beispielhaften Prozessen hinzugefügt oder aus diesen entfernt werden.
Unter Bezugnahme auf die in dieser Figur beschriebenen veranschaulichenden Ausführungsformen, welche veranschaulichende Prozessflüsse darstellen, sei klargestellt, dass ein Universalprozessor vorübergehend als ein Spezialprozessor aktiviert werden kann, um einige oder alle der hierin dargestellten beispielhaften Verfahren auszuführen. Beim Ausführen von Code, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend zu einem Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, soweit angemessen, Firmware, die gemäß einem vorkonfigurierten Prozessor agiert, veranlassen, dass der Prozessor als ein Spezialprozessor agiert, der zur Ausführung des Verfahrens oder einer geeigneten Variation davon bereitgestellt ist.
Nach Einsteigen in ein Fahrzeug nutzt ein Fahrer oftmals ein Smartphone oder eine andere drahtlose Vorrichtung, um eine Anwendung zu starten, um den Verkehr auf Verkehrsstauungen zu überprüfen und zu versuchen, die beste Route zu einem Zielort zu finden. Ein solcher Vorgang kann detaillierte gegenwärtige Verkehrsinformationen und eine gegenwärtige optimale Route basierend auf spezifizierten Kriterien bereitstellen, die von einem Benutzer auswählbar sein können und/oder sich basierend auf der jeweiligen Anwendung und Implementierung ändern können. Da sich der Fahrer bereits im Fahrzeug befindet, falls keine geeigneten Routen vorhanden sind, um den Fahrer zufrieden zu stellen, bleibt dem Fahrer leider nur die Wahl, entweder das Fahrzeug zu verlassen und zu einem späteren Zeitpunkt abzufahren oder eine stark verstopfte Route zu einem Zielort zu nehmen. Hätte der Fahrer gewusst, dass die Abfahrtszeit basierend auf den Routenkriterien des Fahrers suboptimal ist, hätte der Fahrer beispielsweise eine frühere oder spätere Abfahrt planen können.
Der Fahrer hätte versuchen können, vor der Abfahrt bessere Abfahrtszeitinformationen zu bestimmen, was jedoch einen Recherchezeitaufwand erfordert hätte, um Zeit auf dem Arbeitsweg zu sparen. Eine vom Fahrer durchgeführte Recherche wäre auch aufgrund der Verzögerung und Änderung der Bedingungen zwischen der Überprüfung der Informationen und dem tatsächlichen Einsteigen in das Fahrzeug für den Beginn der Reise wenig sinnvoll.
Die veranschaulichenden Ausführungsformen stellen Verfahren und Systeme dar, die Routen und Verzögerungen aktiv überwachen und die einen Fahrer vor einer geplanten Abfahrt auf optimale Abfahrtszeiten und empfohlene Routenfindung aufmerksam machen können. Wenngleich diese Verfahren und Systeme aufgrund unerwarteter Veränderungen der Bedingungen einem gewissen Grad an Unvollkommenheit unterliegen können, ermöglicht die Fähigkeit der veranschaulichenden Ausführungsformen, historische und sich aktuell verändernde Bedingungen fortlaufend zu integrieren, eine weit genauere und einfachere Analyse einer bevorstehenden Reise, als wenn der Fahrer versuchte, eine solche Abwägung manuell durchzuführen.
In den veranschaulichenden Beispielen interagieren ein Fahrzeugroutenplanungscomputer und/oder ein cloudbasiertes System mit der intelligenten Vorrichtung des Fahrers (Telefon, iPad, Uhr usw.), um Fahrer und Fahrzeug auf eine kurz bevorstehende Reise vorzubereiten.
Das Fahrzeug kann Cloud-Kommunikation verwenden, um mit der intelligenten Vorrichtung des Fahrers zu interagieren und relevante reisebezogene Informationen (Abfahrtszeiten, Verkehr, Routen usw.) weiterzuleiten. Durch kontinuierliche Datenverarbeitung kann das Fahrzeug zu jeder Tageszeit weiter Daten verarbeiten und mit dem Fahrer interagieren, selbst wenn andere Fahrzeugsysteme eventuell abgeschaltet sind. Durch Deep-Learning-Algorithmen kann der Bordcomputer des Fahrzeugs (alleine oder in Verbindung mit Cloud-basierten Systemen) Fahrdaten analysieren und sich an Nutzungsmuster anpassen, um Abfahrtszeiten und Zielorte vorherzusagen, auch wenn keine explizit spezifizierten Informationen vorliegen.
Diese und ähnliche Prozesse ermöglichen es einem Fahrzeug, einen Routenanalyseprozess zu initiieren, der beispielsweise auf der Anzeige eines Fahrers basiert, dass der Fahrer bald das Auto benutzen muss, oder auf einer abgeleiteten Wahrscheinlichkeit basiert, dass der Fahrer das Auto basierend auf vorherigen Nutzungsmustern (Deep Learning über Nutzungszeiten/- tage, Zielorte usw.) bald benutzen wird.
Im ersten Szenario kann der Fahrer einen Zielort spezifizieren oder nicht. Falls der Zielort nicht spezifiziert wird oder bei dem obigen Szenario mit vorhergesagter Nutzung, kann das Fahrzeug basierend auf der vorherigen Nutzung einen Zielort mit hoher Wahrscheinlichkeit bestimmen.
Mit einem Zielort kann das Fahrzeug Verkehrsstaus und andere Faktoren (Wetter, Ereignisse usw.) auswerten, um die optimalen Routen in Abhängigkeit von Abfahrtszeiten zu finden und diese Information an den Fahrer zu kommunizieren.
Das Fahrzeug kann in ähnlicher Weise auch eine Abfahrtszeit für eine Reise zu einem Zielort basierend auf spezifizierten oder Standardkriterien bestimmen und dem Fahrer die prognostizierte(n) Reisedauer(n), Verzögerungen, empfohlene Abfahrtszeiten und andere relevante Informationen übermitteln. Der Fahrer, der möglicherweise noch nicht abgefahren ist, kann die auf einer drahtlosen Vorrichtung angezeigten Informationen sehen, den Zielort bestätigen, eine Abfahrtszeit wählen und möglicherweise andere damit zusammenhängende Optionen auswählen, sodass sich das Fahrzeug auf die Reise vorbereiten kann (z. B. Vorkonditionierung vor erwarteter Abfahrt). Das Fahrzeug kann dann weiterhin die gewählte Route und Abfahrtszeit überwachen, falls unerwartete Verzögerungen oder Auflösungen von Verkehrsstauungen zu einer Route oder einer empfohlenen Abfahrtszeit führen, die besser mit den angegebenen Kriterien übereinstimmt.
Zum Beispiel kann ein Fahrer, der seinen Arbeitsplatz typischerweise um 17:00 Uhr verlässt, eine Fahrzeit von ungefähr 40 Minuten zu seinem Zielort benötigen. Falls der Fahrer seinen Arbeitsplatz um 17:30 Uhr verlässt, kann die Dauer der Fahrt auf 25 Minuten sinken. Somit kommt der Fahrer bei Abfahrt um 17:00 Uhr um 17:40 Uhr zu Hause an, während der Fahrer bei Abfahrt um 17:30 Uhr nur 15 Minuten später, nämlich um 17:55 Uhr zu Hause ankommt. Der Fahrer kann dieses verallgemeinerte Wissen durch Erfahrung lernen, wenngleich die Fahrzeiten an einem bestimmten Tag einer beliebigen Anzahl von Variationen unterliegen. Persönliche Erfahrungen stellen somit nur eine grobe Annäherung von Fahrbedingungen und Fahrzeit bereit.
Unter Verwendung der veranschaulichenden Ausführungsformen könnte der Fahrer um 15:00 Uhr über vorhergesagte Verkehrsverzögerungen (aufgrund von Baustellen oder großen Unfällen), vorhergesagte Wetterverzögerungen und beliebige andere historische oder gegenwärtige Informationen, welche die prognostizierte Fahrzeit beeinflussen können, informiert werden. Dem Fahrer könnten bei einer Anzahl von zusätzlichen Abfahrtszeiten auch vorhergesagte Fahrzeiten zur Verfügung gestellt werden. Diese zusätzlichen Abfahrtszeiten können dazu dienen, den Fahrer über eine bessere Abfahrtszeit (z. B. 16:45 Uhr) zu informieren, die der Fahrer zuvor noch nicht einmal in Betracht gezogen hatte oder für die der Fahrer nur sehr begrenzte persönliche Kenntnisse über historische Bedingungen hatte.
Aus den dargelegten Optionen kann der Fahrer eine bevorzugte Abfahrtszeit und Route oder eine spezifizierte Ankunftszeit oder Routenvermeidung, Wettervermeidung usw. auswählen (oder modifizieren), und das Fahrzeug kann weiterhin die Parameter überwachen, die sich auf die spezifizierten Kriterien wie die Route und die Abfahrtszeit auswirken können, falls unerwartete oder unvorhergesehene Änderungen der Bedingungen die Abfahrtszeit oder die Route suboptimal machen. Dies ermöglicht dem Fahrer, das Verhalten durch einige wenige Vorrichtungsinteraktionen an gewünschte Fahrerkriterien anzupassen, sodass der Fahrer nicht mehr täglich umfangreiche Recherchen und Vermutungen anstellen muss.
2 veranschaulicht einen repräsentativen Prozess zur Zielortbestimmung und Abfahrtsunterstützung. Wenngleich viele der veranschaulichenden Prozesse derart dargestellt sind, dass sie vom Fahrzeugcomputer ausgeführt werden, ist es auch möglich, dass ein cloudbasiertes System oder eine andere Rechenvorrichtung (z. B. eine drahtlose Fahrervorrichtung) einige oder alle Prozesse oder Unterroutinen ausführen kann. In mindestens einem Beispiel kann das Fahrzeug Daten anfordern, die sich auf Reisebestimmungen aus der Cloud beziehen, und die Cloud kann auf die Anforderung entweder durch Bereitstellen der Daten oder Ausführen der Berechnungen reagieren, wenn ausreichende Rechenzyklen in der Cloud verfügbar sind, sodass die Cloud die Bestimmung einfach verarbeitet. Dieses System mit alternativen Optionen zur Bereitstellung von Lösungen kann Zeiten mit hohem Anforderungsaufkommen Rechnung tragen, indem das Fahrzeug wirksam eingesetzt wird, wenn die Cloud überlastet ist (z. B. während der Hauptverkehrszeit), und die Cloud wirksam eingesetzt wird, wenn eine begrenzte Anzahl von eingehenden Anforderungen vorliegt. Demgemäß können, falls ein solches adaptives System implementiert ist, die Zielort- und Abfahrtszeitdaten (falls diese dem Fahrzeug bekannt sind) einer beliebigen Datenanfrage an die Cloud beigefügt sein, sodass die Cloud einfach die Abfahrtszeit- und Zielortdaten nutzen kann, um stattdessen und gegebenenfalls die Bestimmung zu vollenden.
Die Kommunikation zwischen dem Fahrzeug/der Cloud und der Fahrervorrichtung kann in Abhängigkeit von den Kosten und anderen Überlegungen in ähnlicher Weise verwaltet werden. In einigen Fällen kann das Fahrzeug die Daten empfangen und relevante Informationen direkt (z. B. über eine Mobilfunkverbindung) an die Fahrervorrichtung übermitteln. In anderen Fällen kann die Cloud als Vermittler fungieren. Im vorstehenden Beispiel, wenn die Cloud als Vermittler fungiert, überträgt ein Cloudsystem Informationen direkt ohne explizite Fahreranweisung an die Fahrervorrichtung (d. h. es ist eine Quelle der Informationen und nicht eine bloße Zwischenstation für die Informationen vom Fahrzeug).
In dem in 2 dargestellten Beispiel beginnt der Prozess, wenn eine erste Fahrzeugfahrt beginnt, markiert durch den Start eines Fahrzeugs 201. Der Prozess bestimmt, ob ein gegenwärtiger Zielort (für die gegenwärtige Fahrt) bekannt ist 203, da diese Informationen für eine Bestimmung eines zukünftigen Zielortes relevant sein können. Falls das Fahrzeug den Zielort für die gegenwärtige Fahrt nicht kennt, kann das Fahrzeug versuchen, den Zielort 205 basierend auf der Tageszeit, dem Abfahrtsort und anderen Faktoren, die für Zielortvorhersagen nützlich sind, basierend auf dem zuvor beobachteten Fahrerverhalten vorherzusagen.
Auch in diesem Beispiel versucht das Fahrzeug, den vorhergesagten Zielort 207 zu bestätigen, und falls das Fahrzeug falsch liegt, kann das Fahrzeug stattdessen die Zielorteingabe 209 von einem Insassen empfangen. Falls der Insasse zu beschäftigt ist, um den Zielort einzugeben, oder anderweitig den Zielort nicht eingeben möchte, wartet der Prozess, bis sich das Fahrzeug in der Parkposition 211 befindet, um den Zielort 213 zu bestimmen. An diesem Punkt wird davon ausgegangen, dass der Zielort der Ort ist, an dem das Fahrzeug in die Parkposition versetzt wurde.
Sobald das Fahrzeug den Zielort der gegenwärtigen Fahrt kennt, kann das Fahrzeug beginnen, Vorhersagen über eine nächste Etappe einer Fahrt 215 (beispielsweise wann und wohin) zu bestimmen. Das Fahrzeug kann diese Vorhersagen auf historisch beobachtetes Verhalten und andere relevante Faktoren (Tageszeit, Wochentag usw.) stützen.
Als Beispiel für den ersten Teil dieses Prozesses kann das Fahrzeug, wenn der Fahrer an einem Montagmorgen nach Hause fährt, entweder informiert werden (durch Eingabe) oder erraten (basierend auf historischem Verhalten), dass ein Fahrer zur Arbeit fahren möchte. Der Arbeitszielort kann bekannt sein, und falls der Fahrer diesen Zielort nicht eingibt oder bestätigt, dann kennt das Fahrzeug diesen Zielort spätestens dann, wenn der Fahrer bei der Arbeit ankommt (d. h. am Zielort). Sobald der Fahrzeugzielort „Arbeit“ bekannt ist, kann das Fahrzeug vorhersagen, dass der Fahrer um 17:00 Uhr (basierend auf historischem Verhalten) die Arbeit verlässt und nach Hause fährt (der Zielort der nächsten Etappe, ebenfalls basierend auf historischem Verhalten). Unterschiedliche Startorte, aktuelle Reiseziele, Tageszeiten und Wochentage können unter anderem zu unterschiedlichen Vorhersagen führen, die darauf basieren, was das Fahrzeug aus historischen Beobachtungen über das Fahrerverhalten gelernt hat.
Wenn als Nächstes in dem veranschaulichenden Prozess die Mensch-Maschinen-Schnittstelle (Human-Machine Interface - HMI) des Fahrzeugs noch aktiv ist 217 (d. h., wenn das Fahrzeug nicht abgeschaltet wurde und die Schnittstelle nicht deaktiviert wurde), zeigt der Prozess den vorhergesagte Zielort 221 für die nächste Etappe zusammen mit der vorhergesagten Abfahrtszeit an. Dies ermöglicht dem Fahrer, die bevorstehende Reise und die Zeit zu bestätigen und bestimmten Veränderungen für einen bestimmten Tag (z. B. wenn der Fahrer früher abfährt, länger bleibt oder nach der Arbeit an einen anderen Ort fährt) Rechnung zu tragen.
Falls die HMI inaktiv ist, befindet sich der Fahrer möglicherweise noch nicht im Fahrzeug, daher kann das Fahrzeug stattdessen die Bestätigungsinformationen an eine drahtlose Fahrervorrichtung 219 senden. Sobald der Fahrer die Abfahrtszeit und den Zielort 223 eingestellt und/oder bestätigt hat, kann der Routen-/Abfahrtsverbesserungsabschnitt des Prozesses beginnen. Falls der Fahrer die Informationen ändern möchte, kann der Fahrer eine neue Abfahrtszeit und/oder einen neuen Zielort 225 eingeben, mit dem das Fahrzeug sowohl die Route/Abfahrtszeit verbessern als auch das historisch beobachtete Verhalten (zur Verwendung bei zukünftigen Vorhersagen) aktualisieren kann.
Basierend auf dem angestrebten Zielort und der Abfahrtszeit, die beide nun dem Fahrzeug bekannt sind, kann das Fahrzeug basierend auf vorhergesagten Verkehrs- und Wetterverzögerungen (und einem beliebigen anderen Faktor, der sich auf die Reisezeit basierend auf der gegenwärtigen Reiseplanung oder Routenfindungskriterien auswirken kann) eine beste Route 227 bestimmen. Es kann viele andere Faktoren geben. Falls der Fahrer zum Beispiel eine Fähre auf einem Arbeitsweg benutzt, können die Abfahrtszeiten der Fähren und die Ankunftszeiten am Fährenstandort die gesamte Reisezeit erheblich beeinflussen (beispielsweise, wenn der Fahrer kurz nach Ablegen der Fähre angekommen ist). In einem solchen Beispiel kann das System eine Ankunft an den Docks vor Ablegen der Fähre anvisieren, um die Fahrzeit zu optimieren und/oder die Auswirkungen der Verfügbarkeit der Fähre bei der Bestimmung der Abfahrts- und Fahrzeiten zu berücksichtigen.
Das Fahrzeug kann auch eine beste Abfahrtszeit bestimmen. Diese kann teilweise auf vorkonfigurierten Fahrerpräferenzen basieren. Ein Fahrer kann bevorzugen, so früh wie möglich zu Hause anzukommen, ein anderer Fahrer kann bevorzugen, Fahrverzögerungen zu minimieren. Das Fahrzeug kann auch Fahrzeugkraftstoff-/Energiebedingungen berücksichtigen, da für bestimmte Routen oder Fahrtdauern eventuell nicht genügend Kraftstoff/Energie zur Verfügung stehen kann. Das Fahrzeug kann eine Abfahrtszeit entsprechend Fahrerpräferenzen 229 oder anderen voreingestellten Bedingungen bestimmen.
Das Fahrzeug kann dann die empfohlene Route und Abfahrtszeit an eine drahtlose Fahrervorrichtung 231 senden. Falls der Fahrer einer neuen Abfahrtszeit und der Route zustimmt oder irgendwelche Änderungen vornehmen möchte 233, empfängt das Fahrzeug die Antwort zur Nutzung bei der Überwachung der erwarteten Route und Abfahrtszeit. In diesem Beispiel, falls die Abfahrtszeit noch nicht erreicht ist 235, stellt der Prozess die Überwachung 237 für die erwartete Route und Zeit ein und überwacht die Route weiterhin in Bezug auf nützliche Informationsänderungen (unerwartete Verkehrsänderungen, Wetteränderungen, Straßensperrungen usw.).
Sobald die Abfahrtszeit weniger als eine Schwellenzeit bevorsteht, kann das Fahrzeug ebenfalls eine Vorkonditionierung durchführen. Dies beinhaltet beispielsweise das Aufwärmen eines Motors, Ändern der Klimasteuerungen, Voreinstellen von Radiosendern und Vornehmen anderer vordefinierter Anpassungen, um das Fahrerlebnis zu verbessern und/oder den Betrieb oder die Effizienz des Fahrzeugs zu erleichtern.
3 veranschaulicht einen repräsentativen Prozess zur Routen- und Abfahrtszeitverbesserung. In diesem Beispiel empfängt das Fahrzeug einen bestätigen Zielort 301 und eine Abfahrtszeit 303. Dies stellt einen Zielort und eine Zeit dar, die das Fahrzeug hätte vorhersagen können und bestätigt hatte oder die der Fahrer hätte explizit eingeben können.
Dieses Beispiel zeigt die Fähigkeit der Systeme, in Abhängigkeit einer Verfügbarkeit adaptiv eine rechnerferne Rechenleistung zu nutzen. In diesem Beispiel sendet das Fahrzeug eine Anfrage an die Cloud, um zu bestimmen, ob die Cloud über genügend Rechenzyklen verfügt, um die Routenfindungs-Verbesserungsüberlegung zu verarbeiten. Falls die Cloud verfügbar ist 305, sendet das Fahrzeug die Zielort- und Abfahrtszeitdaten (und andere nützliche Daten) zur Verarbeitung an die Cloud 307. Die Cloud führt dann die Optimierungsüberlegungen aus und sendet in diesem Beispiel die Daten an das Fahrzeug zurück 309. In einem alternativen Beispiel könnte die Cloud die verarbeiteten Daten direkt an den Fahrer senden.
Falls die Cloud nicht verfügbar ist (was zum Beispiel während der Hauptverkehrszeit der Fall sein kann), fordert das Fahrzeug historische und aktuelle (sofern relevante) Daten zu Verkehr 313 und Wetter 315 an. Beliebige andere Daten, die sich auf die Fahrzeit auswirken, könnten zu diesem Zeitpunkt ebenfalls angefordert werden. Das Fahrzeug kann diese Daten lokal speichern und die Daten für künftige Routenüberlegungen verwenden, wobei die Daten regelmäßig aktualisiert werden, um Änderungen historischer Beobachtungen Rechnung zu tragen. Falls das Fahrzeug die Bestimmungen in Bezug auf Fahrzeit und Verzögerungen im Vorfeld einer Fahrt (z. B. acht Stunden im Voraus) vornimmt, sind die gegenwärtigen Verkehrs- und Wetterdaten möglicherweise nicht besonders nützlich. Andererseits werden diese Daten für die Bestimmungen immer nützlicher, wenn sich die Abfahrtszeit nähert. Das Fahrzeug kann die bestimmten Arten von Daten basierend auf einer vordefinierten Relevanz anfordern, sodass das Fahrzeug aufgrund der zeitlichen Nähe zur Abfahrt verschiedene Daten anfordern kann.
Sobald das Fahrzeug die relevanten Daten empfängt, sagt das Fahrzeug geschätzte Verzögerungen für eine Reise zu einem bestimmten Zielort vorher. Dies kann unter anderem die Auswertung einer Vielzahl von Routen zu einer Vielzahl von Abfahrtszeiten beinhalten, die sowohl für den historischen als auch für den gegenwärtigen Verkehr und aktuelle Wetter- und Wetterberichte geeignet sind. Die Daten können in vielen Formen kompiliert werden, und das Fahrzeug sendet einen oder mehrere Momentaufnahmen der bestimmten Daten an eine drahtlose Vorrichtung des Fahrers.
In einem Beispiel werden die Daten in einer Weise kompiliert, die Wetter-in-Bewegungs-Karten ähnlich ist, die üblicherweise auf Websites wie WEATHER.COM erhältlich sind. Anstatt jedoch Wettermuster anzuzeigen, zeigen diese Momentaufnahmen vorhergesagte Verkehrsänderungen und empfohlene Routen in festen Intervallen. Falls also beispielsweise eine geplante Abfahrtszeit 17:00 Uhr war, könnten die Momentaufnahmen 15-Minuten-Intervallen für eine Stunde vor und nach 17:00 Uhr Rechnung tragen. Dadurch kann der Fahrer die den wechselnden Bedingungen entsprechenden Bildschirme schnell durchblättern und die vorhergesagten Änderungen von Fahrzeiten, Verkehrs- und Ankunftszeiten visuell interpretieren. In anderen Beispielen kann das System Daten einfach als eine Bestätigung der Abfahrtszeit und/oder Route oder eine Empfehlung einer neuen Route oder Abfahrtszeit senden. Ein Beispiel einer Anzeige mit variierten Landkarten ist in Bezug auf 6 dargestellt.
Falls der Fahrer Empfehlungen akzeptiert oder Änderungen an der geplanten Route oder Abfahrtszeit vornimmt, empfängt das Fahrzeug diese Änderungen von der drahtlosen Fahrervorrichtung 319. Das Fahrzeug kann eine beliebige geänderte Route oder Zeit als die neue Route und/oder Zeit 321 speichern, und die Überwachung kann dann für die neue oder bestehende Route/Zeit 323 fortgesetzt werden.
4 zeigt einen veranschaulichenden Prozess zur Routen- und Abfahrtszeitauswertung. In diesem Beispiel berücksichtigt der Prozess verschiedene veranschaulichende Informationen basierend darauf, wie zeitlich nahe die Abfahrtszeit ist. Die berücksichtigten bestimmten Informationen sind nur zu Veranschaulichungszwecken dargestellt, wobei zusätzliche oder andere Informationen, welche die Fahrzeit beeinflussen, ebenfalls in Betracht gezogen werden können.
Das Fahrzeug kennt die Abfahrtszeit und den Zielort in diesem Beispiel und bestimmt zuerst eine oder mehrere Routen zu einem Zielort. Zum Beispiel kann das Fahrzeug zuerst verzögerungsbeeinflussende Bestimmungen in Bezug auf eine derzeit geplante Route durchführen. Falls keine unerwarteten Verzögerungen gefunden werden, kann das System nur eine oder zwei (oder keine anderen) zusätzlichen Routen berücksichtigen. Falls sich die erwartete Fahrzeit jedoch über einen Schwellenwert hinaus geändert hat, kann das System mehrere alternative Routen berücksichtigen, um der unerwarteten Verzögerung Rechnung zu tragen.
Falls in diesem Beispiel die zeitliche Nähe der Abfahrtszeit mehr als zwei Stunden beträgt 403 (spezifische Zeitfenster, die nur als veranschaulichende Beispiele angegeben sind), ist der Prozess in diesem Beispiel stark auf historische Daten angewiesen. Dies ist darauf zurückzuführen, dass die gegenwärtigen Wetter- und Verkehrsdaten wahrscheinlich zu einem so weit vor der erwarteten Abfahrt liegenden Zeitpunkt weniger nützlich sind. Die Zeit, die das Fahrzeug für die „Abfahrtszeit“ nutzt, kann auch als die erste Instanz der Momentaufnahmenfenster (die vor der Abfahrtszeit liegen können) behandelt werden, wenn die Momentaufnahme oder ähnliche Verfahren angewendet werden.
Das Fahrzeug sammelt historische Verkehrsdaten für die Route 409 sowie aktuelle Verkehrsmuster 411 (oder greift auf diese zu, falls sie bereits gespeichert sind). Somit kann das Fahrzeug zwei unterschiedliche Sätze von Verkehrsdaten aufweisen, wobei eines einige Monate oder Jahre von Fahrdaten darstellt und ein anderes die letzte Woche von Fahrdaten darstellt. Instanzen wie Baustellen und dergleichen können nur zeitlich neu sein und werden eher in einer zeitnahen Ansicht von Daten reflektiert, im Gegensatz zu einer längeren historischen Ansicht. Das Fahrzeug sammelt auch einen Wetterbericht für das relevante Zeitfenster 413. Historische Wetterdaten können weniger nützlich sein, sofern das Klima des Gebiets nicht überaus beständig ist. In diesem Beispiel verwendet das Fahrzeug einen Wetterbericht anstelle von historischen Wetterdaten, um bevorstehende Bedingungen vorherzusagen.
Ferner gewichtet das Fahrzeug die Daten 415, wobei die Gewichtung basierend auf der zeitlichen Nähe zur Abfahrt variieren kann. Falls das Fahrzeug beispielsweise während dieser Bestimmung gegenwärtige Verkehrsbedingungen berücksichtigt (mehr als zwei Stunden nach der Abfahrt), kann das Fahrzeug diese Daten aufgrund der Wahrscheinlichkeit einer Änderung sehr gering gewichten. Andererseits kann das Fahrzeug fünfzehn Minuten vor der Abfahrt die gegenwärtigen Verkehrsdaten viel höher als die historischen Daten gewichten, da die gegenwärtigen Daten in fünfzehn Minuten sehr viel wahrscheinlicher genaue gegenwärtige Bedingungen bereitstellen. Sobald das Fahrzeug die berücksichtigten Daten gewichtet hat, bestimmt das Fahrzeug alle wahrscheinlichen Verzögerungen, die mit einer Route 417 verbunden sind.
Falls die Abfahrtszeit innerhalb weniger als einer Stunde stattfindet (jedoch nicht mehr als zwei Stunden) 405, sammelt das Fahrzeug erneut historische Verkehrsdaten 419 und 421 sowie einen Wetterbericht 423. Erneut wird eine spezifische Zeitplanung nur für Veranschaulichungszwecken bereitgestellt. Da die Abfahrt in dieser Instanz kürzer bevorsteht, sammelt das Fahrzeug auch gegenwärtige Wetterbedingungen 425 und gegenwärtige Verkehrsbedingungen 427. Wenngleich diese durch die weitere Bestimmung verwendet worden sein könnten, erhöht sich, falls gewünscht, die Relevanz dieser Daten, wenn sich die Abfahrtszeit nähert. Dementsprechend kann das Fahrzeug die Gewichtung 429 basierend auf dem Zwischenzeitfenster vor Zuweisung von Gewichtungen zu den Daten einstellen.
Ein ähnlicher Prozess findet immer dann statt, wenn das Zeitfenster schrumpft, wobei das Beispiel einer Abfahrt, die innerhalb von weniger als eine Stunde stattfindet, gezeigt wird. Das Fahrzeug kann die Datengewichtung 407 einstellen, um der bevorstehenden Abfahrt Rechnung zu tragen, und das Fahrzeug kann diese Einstellung so oft wie nötig vornehmen, wenn sich die Abfahrt nähert. Das Fahrzeug kann auch zusätzliche relevante Daten berücksichtigen, deren Relevanz sich mit der Nähe zur Abfahrtszeit in immer näheren Fenstern zur Abfahrt erhöht.
Ein beliebiger der fahrzeugbasierten Prozesse, die stattfinden, wenn eine Berechnung durch oder eine Kommunikation mit dem Fahrzeug erfolgt, kann selbst dann stattfinden, wenn das Fahrzeug nicht anderweitig mit Leistung versorgt wird. Das heißt, selbst wenn kein Schlüssel vorhanden ist und die Zündung nicht eingeschaltet ist, kann das Fahrzeug die hier beschriebenen routenbezogenen Prozesse aufwecken oder anderweitig ausführen. Dies ermöglicht einen wirksamen Einsatz der Fahrzeugrechenleistung, selbst wenn das Fahrzeug nicht explizit von einem Insassen im Fahrzeug mit Leistung versorgt wird.
5 zeigt einen veranschaulichenden Prozess zur Routen- und Abfahrtszeitüberwachung. Dieser Prozess ermöglicht dem Fahrzeug, die ausgewählte Route und Abfahrtszeit zu überwachen und den Benutzer über etwaige Änderungen zu informieren, die eine andere Route oder Abfahrtszeit zu einer besseren Wahl machen könnten.
Der Fahrzeugprozess erwacht 501, möglicherweise in vordefinierten Intervallen, selbst wenn das Fahrzeug im Allgemeinen nicht mit Leistung versorgt ist. Das Fahrzeug kommuniziert mit der Cloud, um alle Daten aufzufrischen 503, die für die neue Überlegung aktualisiert werden müssen. Das Fahrzeug kann bereits historische Verkehrsdaten für die Route gespeichert haben, jedoch muss das Fahrzeug beispielsweise einen Wetterbericht oder aktuelle Verkehrsbedingungen auffrischen. Das Fahrzeug berechnet dann basierend auf den gespeicherten und neu empfangenen Daten alle Verzögerungen, die mit der gewählten Route und Abfahrtszeit 505 verbunden sind. Das Fahrzeug berücksichtigt auch eine oder mehrere alternative Routen basierend auf den erhaltenen Daten, um zu bestimmen, ob eine bessere Route existiert.
Falls eine bessere Route existiert (schnellere oder andere relevante Änderungen basierend auf Fahreroptimierungspräferenzen) 507, zeichnet das Fahrzeug eine Empfehlung für die bessere Route 509 auf. Das Fahrzeug sendet in diesem Beispiel die Route noch nicht, da das Fahrzeug andere Überlegungen, welche die Fahrzeit beeinflussen, vor Senden der Empfehlungen berücksichtigt. In anderen Beispielen können die Empfehlungen iterativ gesendet werden und die Bestimmung kann fortgesetzt werden, sobald der Benutzer die aktualisierten Empfehlungen angenommen oder abgelehnt hat.
Falls es eine bessere Abfahrtszeit basierend auf den Fahrkriterien und zugehörigen Parametern für die ausgewählte oder empfohlene Route 511 gibt, beinhaltet der Prozess eine Empfehlung für eine neue Abfahrtszeit 513. Die bessere Zeit kann auf vermindertem Verkehr, verbessertem Wetter, verbesserter Gesamtfahrzeit, verbesserter Ankunftszeit usw. basieren. Die bessere Abfahrtszeit kann auch zu einer geänderten Routenempfehlung führen, wobei die neue Route Eigenschaften aufweist, die auf den Fahrerpräferenzen basieren (kürzere Entfernung, kürzere Zeit, weniger Kraftstoff usw.).
Wenn außerdem in diesem Beispiel eine Verzögerung bei einer zuvor ausgewählten Route einen Schwellenwert 515 überschreitet, fügt das Fahrzeug eine Benachrichtigung über die unerwartete Verzögerung 517 zu einer Nachricht hinzu. Die Route und die Abfahrtszeit sind möglicherweise immer noch optimal, aber der Fahrer möchte die Verzögerung möglicherweise im Voraus wissen, damit der Fahrer etwaige Pläne entsprechend ändern kann. Dies trägt zur Vermeidung von unerwarteten Überraschungen bei, wenn der Fahrer tatsächlich abfährt.
Das Fahrzeug berichtet dann der drahtlosen Fahrervorrichtung etwaige Beobachtungen. Diese können empfohlene Änderungen hinsichtlich der Route oder Abfahrtszeit, unerwartete Verzögerungen oder sogar nur eine Aktualisierung beinhalten, ohne darauf beschränkt zu sein, um mitzuteilen, dass alle Bedingungen wie im Vorfeld vorhergesagt bestehen bleiben. Falls das Fahrzeug Empfehlungen ausspricht, die der Fahrer annimmt, oder falls der Fahrer freiwillige Änderungen an der Route oder Abfahrtszeit 521 vornimmt, empfängt und speichert der Prozess die neuen Änderungen 525. Dann kehrt der Prozess bis zum nächsten Überwachungsfenster in einen Ruhezustand 527 zurück.
6 veranschaulicht zwei veranschaulichende Routenempfehlungsanzeigen. Dies ist ein Beispiel für eine Momentaufnahme der vorhergesagten Routenfahrzeit und des Verkehrs in Zeitintervallen vor und nach einer ausgewählten oder empfohlenen Abfahrtszeit. Dies stellt eine visuell verständliche Darstellung der vorhergesagten Bedingungen bereit und kann einigen Fahrern bei der Entscheidung helfen, welche Route oder Abfahrtszeit ausgewählt werden soll.
Bild 601 zeigt eine Darstellung der bevorzugten Route 615 und beinhaltet jegliche identifizierten wahrscheinlichen Gebiete mit hohem Verkehrsaufkommen 617. Das Bild beinhaltet auch mindestens eine alternative Route sowie Hinweise zur Zeitdifferenz 619 und Gebiete mit hohem Verkehrsaufkommen 621. Somit kann der Fahrer Gebiete mit vorhergesagtem Verkehr entlang einer bevorzugten Route und alternative Routen leicht sehen. Wetter und andere die Fahrzeit beeinflussende Daten können, falls gewünscht, auch visuell angezeigt werden. In einem Beispiel kann der Fahrer verschiedene Filter aktivieren/deaktivieren, um unterschiedliche Daten in jeder Kartendarstellung zu sehen.
Die Anzeige beinhaltet auch eine Bestätigungsschaltfläche 605, die es dem Fahrer ermöglicht, die ausgewählte Route und Zeit ohne jegliche Änderungen zu bestätigen. Falls der Fahrer eine Route oder Zeit ändern möchte, kann der Fahrer auf die Zeit-Ändern-Schaltfläche 607 klicken und/oder die alternative Route auswählen, die auf der Vorrichtung angezeigt wird.
Die Anzeige beinhaltet Informationsdaten, welche die gegenwärtige Abfahrtszeit 609, die durch das Schaubild dargestellt ist, sowie eine erwartete Fahrzeit 611 und eine erwartete Ankunftszeit 613 zeigen. Ein Schieber 623 ermöglicht dem Fahrer, sich unter Verwendung der angezeigten Pfeile 625 zeitlich vorwärts oder rückwärts zu bewegen, wobei in diesem Beispiel ein vergrößerter Kreis 627 anzeigt, „wann“ der Fahrer innerhalb der sichtbaren Auswahlmöglichkeiten 629 nachschaut. In diesem Fall ist ein Zeitfenster früher als die gegenwärtige Anzeige sichtbar und vier Zeitfenster später als die gegenwärtige Anzeige sichtbar. Für Informationszwecke weist die Anzeige auch eine Batterielebensdauer- oder Kraftstoffdarstellung 631 zusammen mit einer Übersetzung der Kraftstoffdaten in einen Prozentsatz 633 und der äquivalenten möglichen Fahrt basierend auf dem verbleibenden Kraftstoff 635 auf.
Das zweite Bild zeigt ein nächstes Zeitfenster mit einer Abfahrt 641 um 17:15 Uhr. Wie aus 6 zu sehen ist, hat sich das Gebiet mit hohem Verkehrsaufkommen 647 auf der zuvor vorgeschlagenen Route 615 im Zeitverlauf stark vergrößert. Dies führt zu einer erhöhten Fahrzeit 643 und einer viel späteren Ankunftszeit 645. Die alternative Route ist nun 10 Minuten schneller 649 dargestellt, falls die Abfahrt um 17:15 Uhr erwartet wird, wobei sich das vorherige Gebiet mit hohem Verkehrsaufkommen 621 vollkommen aufgelöst hat. Der angezeigte vergrößerte Kreis hat sich um eine Position nach links 653 bewegt, um den Vorwärtsverlauf der Zeit visuell darzustellen.
In diesem Beispiel weist die Anzeige auch mehrere Alarme 651 auf, die dazu dienen können, besonders relevante Informationen hervorzuheben. Insbesondere weisen die Alarme darauf hin, dass eine bessere Route vorhanden ist und dass eine alternative Abfahrtszeit empfohlen wird. Diese Alarme könnten auch in Bezug auf ihre Natur auswählbar sein, sodass das Anklicken eines Alarms dazu führen würde, eine dem Alarm zugeordnete Aktion auszuführen (z. B. in diesem Fall Auswählen einer neuen Route oder Auswählen einer neuen Abfahrtszeit). Durch diese und ähnliche visuelle Darstellungen kann es für einen Fahrer leicht sein, die prognostizierten Unterschiede hinsichtlich der Verkehrs- und Fahrzeit zu sehen und die Pläne entsprechend anzupassen. Falls die Anzeige interaktiv ist, kann der Fahrer auch schnell und einfach Änderungen an einer Route oder Abfahrtszeit vornehmen.
7 veranschaulicht eine Darstellung eines vom Benutzer einstellbaren Schaubildes der Fahrzeit gegenüber der Abfahrtszeit. Dies ist ein veranschaulichendes Beispiel, das zeigt, wie ein Benutzer sich verschiedene Abfahrtszeitmöglichkeiten und die prognostizierten Auswirkungen jeder Abfahrtszeit auf die Fahr- und/oder Ankunftszeit anzeigen lassen kann. Die auf diesem Schaubild angezeigten Daten könnten wie hierin beschrieben durch das Fahrzeug oder die Cloud berechnet werden und könnten zur Anzeige an eine Benutzervorrichtung übertragen werden.
Schaubild 701 zeigt ein veranschaulichendes Beispiel eines Schaubildes, das verschiedene prognostizierte Fahrtdauern 705 (Fahrzeiten) basierend auf verschiedenen bevorstehenden Abfahrtszeiten 703 zeigt. In diesem Beispiel sind die Abfahrtszeiten von der unmittelbar gegenwärtigen Zeit vorwärts gerichtet, jedoch könnte die „Start“-Zeit (bei 0 Minuten) auch einer angeforderten Abfahrtszeit entsprechen, und das Schaubild könnte auch über diese Zeit hinaus und nach dieser Zeit schauen. Wenn der Benutzer zum Beispiel die Abfahrt um 16:00 Uhr angefordert hat und die gegenwärtige Zeit 14:00 Uhr war, könnte die Startzeit 16:00 Uhr sein und das Schaubild könnte 30 Minuten vor und 30 Minuten nach 16:00 Uhr prognostizierte Abfahrtseffekte anzeigen.
Der Bereich unter dem Schaubild 707 zeigt eine leicht verständliche Anzeige, die der Benutzer schnell verarbeiten kann. Im Allgemeinen ist zum Beispiel ersichtlich, dass der Verkehr oder andere Faktoren, welche die Fahrzeit beeinflussen, dazu tendieren ab dem gegenwärtigen Zeitpunkt um 20 Minuten abzunehmen und sich kurz danach wieder neu etablieren. Somit kann der Benutzer schnell feststellen, dass etwa 20 Minuten ab dem gegenwärtigen Zeitpunkt der wahrscheinlich beste Zeitpunkt zur Abfahrt ist.
Ein Schieber 709 könnte ebenfalls enthalten sein, wobei Werte für eine exakte Abfahrtszeit (z. B. 21 Minuten ab dem gegenwärtigen Zeitpunkt) und eine prognostizierte Fahrzeit (beispielsweise 29 Minuten) angezeigt werden könnten, wenn der Schieber zu einem bestimmten Punkt verschoben wird. Der Schieber könnte auch das Scrollen über einen größeren Satz von Werten ermöglichen, als in einem Schaubild auf einer einzelnen Bildschirmanzeige angezeigt werden könnte.
Das andere Schaubild zeigt die Ankunftszeit gegenüber der Abfahrtszeit 711. Die in diesem Schaubild gezeigten Werte sind diejenigen der prognostizierten Ankunftszeiten 713 für gegebene Abfahrtszeiten 707. Wie bei dem anderen Schaubild kann ein Schieber 709 enthalten sein, der die Bestimmung einer bestimmten Abfahrtszeit und der resultierenden Ankunftszeit ermöglicht. Wieder zeigt der Schaubildbereich 715 eine schnelle visuelle Anleitung zum Analysieren von guten Abfahrtszeiten. Wenn somit beispielsweise ein Benutzer wüsste, dass der Benutzer beispielsweise um 18:00 Uhr zu Hause sein muss, könnte der Benutzer zu jeder beliebigen Zeit abfahren, die prognostiziert gezeigt wird, um den Benutzer vor 18:00 Uhr nach Hause zu bringen.
Durch Anwendung der veranschaulichenden Beispiele und dergleichen können Benutzer verbesserte Fahrzeiten und Ankunftszeiten erfahren und unerwarteten Verkehr und Verzögerungen vermeiden. Mit einem schnellen Blick auf Daten und einigen Bildschirmauswahlen kann ein Benutzer eine Route oder Fahrzeit aktualisieren und das Fahrzeug die neue Route und die Zeit für vorhergesagte Verzögerungen überwachen lassen. Dies kann bis zur Abfahrt mit minimalen Auswirkungen auf die Zeit und die Ressourcen des Benutzers fortgesetzt werden.
Wenngleich vorstehend Ausführungsbeispiele beschrieben wurden, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die Begriffe, die in der Patentschrift verwendet werden, beschreibende und keine einschränkenden Begriffe, wobei es sich versteht, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Schutzumfang der Erfindung abzuweichen. Außerdem können die Merkmale verschiedener implementierender Ausführungsformen auf logische Art und Weise kombiniert werden, um situationsbedingt geeignete Variationen von hierin beschriebenen Ausführungsformen hervorzubringen.

Claims

System, das Folgendes umfasst: einen Prozessor, der zu Folgendem programmiert ist: Senden einer ersten und einer zweiten empfohlenen Route an eine drahtlose Vorrichtung als Reaktion auf das Empfangen eines gegenwärtigen Fahrzeugstandortes, der beim Parken eines Fahrzeugs gespeichert wurde, und eines empfangenen Zielortes und einer Abfahrtszeit, wobei die erste empfohlene Route auf Fahrzeitfaktoren basiert, die dem Zielort und der Abfahrtszeit und spezifizierten Routenfindungs- und Zeitplanungspräferenzen entsprechen, und die zweite empfohlene Route auf einer berechneten alternativen Abfahrtszeit unter Verwendung der spezifizierten Präferenzen basiert.
System nach Anspruch 1, wobei die Fahrzeitfaktoren das Wetter einschließen.
System nach Anspruch 2, wobei der Prozessor dazu konfiguriert ist, auf einen Wetterbericht zuzugreifen, um Wettervorhersagen für die empfangene Abfahrtszeit und die alternative Abfahrtszeit zu erhalten.
System nach Anspruch 1, wobei die Fahrzeitfaktoren den Verkehr einschließen.
System nach Anspruch 4, wobei der Prozessor dazu konfiguriert ist, auf eine Verkehrsdatenbank zuzugreifen, die historische Verkehrsbedingungen beinhaltet, um Verkehrsbedingungen zu der empfangenen Abfahrtszeit und der berechneten alternativen Abfahrtszeit vorherzusagen.
System nach Anspruch 1, wobei sich der Prozessor in einem Fahrzeug befindet und dazu konfiguriert ist, die erste und die zweite empfohlene Route zu senden, selbst wenn das Fahrzeug nicht anderweitig eingeschaltet ist.
System nach Anspruch 1, wobei sich der Prozessor von einem Fahrzeug entfernt befindet und wobei der Prozessor den Zielort und die Abfahrtszeit von einem Fahrzeug empfängt.
System nach Anspruch 1, wobei der Prozessor ferner dazu konfiguriert ist, eine bevorzugte Route und/oder die Abfahrtszeit von der drahtlosen Vorrichtung zu empfangen.
System nach Anspruch 8, wobei der Prozessor dazu konfiguriert ist, unter Verwendung der empfangenen Abfahrtszeit und der Fahrzeitfaktoren eine Ankunftszeit oder Fahrzeit an die drahtlose Vorrichtung für die bevorzugte Route zu senden.
System nach Anspruch 9, wobei der Prozessor dazu konfiguriert ist, wiederholt die Fahrzeit basierend auf der empfangenen Abfahrtszeit und zuletzt empfangenen Fahrzeitfaktoren in vordefinierten Intervallen nach dem Senden der ersten und der zweiten empfohlenen Route zu berechnen.
System nach Anspruch 10, wobei der Prozessor zu Folgendem konfiguriert ist: als Reaktion darauf, dass die Fahrzeit um mehr als einen Schwellenwert ansteigt, Berechnen einer neuen alternativen Abfahrtszeit und einer dritten empfohlenen Route basierend auf den spezifizierten Präferenzen; und Senden der neuen alternativen Abfahrtszeit und der dritten Route an die drahtlose Vorrichtung.
System nach Anspruch 1, wobei die spezifizierten Präferenzen eine kürzeste Entfernung bezeichnen.
System nach Anspruch 1, wobei die spezifizierten Präferenzen eine kürzeste Fahrzeit bezeichnen.
System nach Anspruch 1, wobei die spezifizierten Präferenzen eine Route mit dem geringsten Kraftstoffverbrauch bezeichnen.