-
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Hinweisen eines Fahrers auf Warnzustände.
-
Der Zusatz von Fahrzeuginformations- und Infotainment-Systemen zu Fahrzeugen stellt eine Vielfalt von Unterhaltungs- und Informationsablieferungsoptionen für Fahrzeuginsassen zur Verfügung. Durch Onboard-Ressourcen und Fernverbindungen können Insassen Musik und Spielfilme streamen, die neuesten Nachrichten empfangen, auf entfernte Datenbanken zugreifen, Navigationsinformationen erhalten und zahlreiche andere Aufgaben ausführen, die früher ein sekundäres Datenverarbeitungssystem, wie etwa ein Smartphone oder einen PC mit einer drahtlosen Netzwerkkarte, erforderten.
-
Unter Verwendung des Onboard-Systems können Fahrer mit Offboard-Ressourcen auf Cloud-Basis kommunizieren und auf praktisch beliebige Informationen zugreifen, die für das Fahren oder Reisen nützlich sind. Bestimmte Software-Addons erlauben es Benutzern, intelligent zu empfohlenen Haltepunkten geleitet zu werden, auf Benutzer zugeschnittene Coupons oder Deals zu erhalten und sogar Notdienste und/oder Ärzte des Benutzers im Fall eines medizinischen Notfalls zu benachrichtigen.
-
In den meisten Systemen ist der Prozess jedoch ein Prozess des „Pull“-Typs. Eine bestimmte Offboard-Ressource reagiert auf eine Benutzeranforderung von Informationen oder ein Benutzerbedürfnis. Diese Bedürfnisse werden oft von einem Onboard-System zu dem entfernten System übermittelt und das entfernte System reagiert auf die Einzelheiten einer Anforderung.
-
„Pull“-Systeme sind sehr nützlich, um den Bedürfnissen eines Benutzers nachzukommen, wenn der Benutzer weiß, dass ein bestimmtes Bedürfnis besteht. Sie können jedoch nicht immer den Bedürfnissen eines Benutzers entsprechen, dem nicht bewusst ist, dass eine bestimmte verfügbare Lösung oder Option in einer bestimmten Situation nützlich sein könne.
-
Bei einer ersten beispielhaften Ausführungsform umfasst ein computerimplementiertes Verfahren das Empfangen von Routendaten von einem fahrzeuginternen Prozess. Das beispielhafte Verfahren umfasst ferner das Setzen eines oder mehrerer Raumgrenzen entsprechend bekannten Bedingungen auf einer durch die Routendaten definierten Route. Das Verfahren umfasst zusätzlich das Senden der Raumgrenzen zu dem fahrzeuginternen Prozess zur Überwachung.
-
In einem zweiten Anschauungsbeispiel speichert ein maschinenlesbares Speichermedium Anweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor das Verfahren ausführt, das das Empfangen von Routendaten von einem fahrzeuginternen Prozess umfasst. Das beispielhafte Verfahren umfasst ferner das Setzen eines oder mehrerer Raumgrenzen entsprechend bekannten Bedingungen auf einer durch die Routendaten definierten Route. Das beispielhafte Verfahren umfasst zusätzlich das Senden der Raumgrenzen zu dem fahrzeuginternen Prozess zur Überwachung.
-
Bei einer dritten beispielhaften Ausführungsform umfasst ein computerimplementiertes Verfahren das Senden von Routendaten zu einem entfernten Server zur Verarbeitung. Das Verfahren umfasst ferner als Reaktion das Empfangen eines oder mehrerer Raumgrenzen, die mit Zuständen auf einer durch die Routendaten definierten Route assoziiert sind. Das Verfahren umfasst zusätzlich das Überwachen des Fortschritts eines Fahrzeugs, bis eine Grenze eines der Raumgrenzen erreicht wird. Außerdem umfasst das beispielhafte Verfahren das Benachrichtigen des entfernten Servers, dass die Grenze erreicht wurde, einschließlich Senden von Fahrzeugkoordinatendaten.
-
Bei einer vierten beispielhaften Ausführungsform umfasst ein computerimplementiertes Verfahren das Empfangen von Routendaten in einem Offboard-System, die von einem Fahrzeug gesendet werden. Das Verfahren umfasst außerdem das Vergleichen von Routendaten mit bekannten Gefahren, um Gefahrenzustände auf einer Route zu bestimmen. Das nichteinschränkende Verfahren umfasst ferner das Schätzen eines Fahrzeugorts auf einer Route, während das Fahrzeug fährt. Außerdem umfasst das Verfahren das Senden von Gefahrenwarnungen, wenn ein geschätzter Fahrzeugort in einer vordefinierten Nähe zu einem bekannten gefährlichen Zustand liegt.
-
1 zeigt ein beispielhaftes Fahrzeugdatenverarbeitungssystem;
-
2 zeigt einen beispielhaften Prozess zum Überwachen der Fahrzeugfahrt;
-
3 zeigt einen beispielhaften Prozess zur Onboard-Tracking-Einleitung;
-
4 zeigt einen beispielhaften Prozess zur Fernsystemkommunikation;
-
5 zeigt einen beispielhaften Prozess zum Fernsenden von Aktualisierungen zu einem Fahrzeug;
-
6 zeigt einen beispielhaften Prozess zum Aktualisieren von mit einem fahrenden Fahrzeug assoziierten Parametern; und
-
7 zeigt einen weiteren beispielhaften Prozess zur Routengefahrenüberwachung.
-
Wie erforderlich werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen realisiert werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; bestimmte Merkmale können übertrieben oder minimiert werden, um Einzelheiten bestimmter Komponenten zu zeigen. Die spezifischen hier offenbarten strukturellen und Funktionsdetails sind deshalb nicht als Beschränkung aufzufassen, sondern lediglich als repräsentative Grundlage, um es Fachleuten zu lehren, die vorliegende Erfindung verschiedenartig einzusetzen.
-
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 der 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, automatische 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 mit nicht persistentem 5 und persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nicht persistente Speicher Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher.
-
Der Prozessor ist auch mit einer Anzahl von verschiedenen Eingängen ausgestattet, die es dem Benutzer erlauben, sich mit dem Prozessor anzuschalten. 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 und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist ein Eingangsselektor 51 vorgesehen, um es einem Benutzer zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Eingaben sowohl in den Mikrofon- als auch in den Zusatzverbinder werden durch einen Umsetzer 27 von analog in digital umgesetzt, bevor sie zu dem Prozessor geleitet werden. Obwohl es nicht gezeigt ist, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie etwa, aber ohne Beschränkung darauf, einen CAN-Bus) verwenden, um Daten zu und von dem VCS (oder Komponenten davon) weiterzuleiten.
-
Ausgaben des Systems können, aber ohne Beschränkung darauf, ein visuelles Display 4 und einen Lautsprecher 13 oder Stereoanlagenausgang umfassen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Umsetzer 9 von dem Prozessor 3. Ausgaben können auch an eine entfernte BLUETOOTH-Einrichtung erfolgen, wie etwa die PND 54 oder eine USB-Einrichtung, wie etwa die Fahrzeugnavigationseinrichtung 60, entlang der bei 19 bzw. 21 gezeigten bidirektionalen Datenströme.
-
Bei einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Sender/Empfänger 15 zum Kommunizieren 17 mit der nomadischen Einrichtung 53 (z.B. Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Einrichtung mit Konnektivität zu einem drahtlosen entfernten Netzwerk) eines Benutzers. Die nomadische Einrichtung kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Zellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
-
Beispielhafte Kommunikation zwischen der nomadischen Einrichtung und dem BLUETOOTH-Sender/Empfänger wird durch das Signal 14 repräsentiert.
-
Die Paarung einer nomadischen Einrichtung 53 und des BLUETOOTH-Sender/Empfängers 15 kann durch eine Taste 52 oder ähnliche Eingabe befohlen werden. Dementsprechend wird der CPU mitgeteilt, dass der Onboard-BLUETOOTH-Sender/Empfänger mit einem BLUETOOTH-Sender/Empfänger in einer nomadischen Einrichtung 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 Onboard-Modem 63 vorzusehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übermitteln 16. Die nomadische Einrichtung 53 kann dann dazu verwendet werden, zum Beispiel durch Kommunikation 55 mit einem Zellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. 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 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 nomadischen Einrichtung anzutreffenden) herzustellen. BLUETOOTH ist eine Teilmenge der Protokolle IEEE 802 PAN (Personal Area Network). Die Protokolle IEEE 802 LAN (Lokales Netzwerk) umfassen WiFi und besitzen beträchtliche Kreuzfunktionalität mit IEEE 802 PAN. 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 nicht standardisierte Verbraucher-IR-Protokolle.
-
Bei einer anderen Ausführungsform umfasst die nomadische Einrichtung 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. Bei der Data-Over-Voice-Ausführungsform kann eine als Frequenzmultiplexen bekannte Technik implementiert werden, wenn der Eigentümer der nomadischen Einrichtung über die Einrichtung sprechen kann, während Daten transferiert werden. Zu anderen Zeiten, wenn der Eigentümer die Einrichtung 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 nunmehr durch IMT-Advanced (4G) ersetzt, das für Benutzer in einem Fahrzeug 100 mbs und für stationäre Benutzer 1 gbs bietet. Wenn der Benutzer über einen mit der nomadischen Einrichtung assoziierten Datenplan verfügt, ist es möglich, dass der Datenplan Breitband-Übertragung ermöglicht und das System eine viel größere Bandbreite verwenden könnte (wodurch der Datentransfer beschleunigt wird). Bei einer weiteren Ausführungsform wird die nomadische Einrichtung 53 durch eine (nicht gezeigte) zellulare Kommunikationseinrichtung ersetzt, die in das Fahrzeug 31 installiert ist. Bei einer weiteren Ausführungsform kann die ND 53 eine Einrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, die zum Beispiel (und ohne Beschränkung) über ein 802.11g-Netzwerk (d.h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
-
Bei einer Ausführungsform können ankommende Daten durch die nomadische Einrichtung ü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 an das Fahrzeug angeschaltet werden können, gehören eine persönliche Navigationseinrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationseinrichtung 60 mit einem USB 62 oder einer anderen Verbindung, eine Onboard-GPS-Einrichtung 24 oder ein (nicht gezeigtes) Fernnavigationssystem, das Konnektivität mit dem Netzwerk 61 aufweist. USB ist eines einer Klasse von Serienvernetzungsprotokollen. IEEE 1394 (Firewire), serielle Protokolle der EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards von Einrichtung zu Einrichtung. Die meisten der Protokolle können entweder für elektrische oder optische Kommunikation implementiert werden.
-
Ferner könnte sich die CPU in Kommunikation mit vielfältigen anderen Hilfseinrichtungen 65 befinden. Diese Einrichtungen können durch eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden sein. Die Hilfseinrichtung 65 kann, aber ohne Beschränkung darauf, persönliche Medien-Player, drahtlose Gesundheitseinrichtungen, tragbare Computer und dergleichen umfassen.
-
Außerdem oder als Alternative könnte die CPU zum Beispiel unter Verwendung eines Senders/Empfängers für WiFi 71 mit einem fahrzeuggestützten drahtlosen Router 73 verbunden werden. Dadurch könnte die CPU sich mit entfernten Netzwerken in der Reichweite des lokalen Routers 73 verbinden.
-
Zusätzlich dazu, dass beispielhafte Prozesse durch ein Fahrzeugdatenverarbeitungssystem ausgeführt werden, das sich in einem Fahrzeug befindet, können bei bestimmten Ausführungsformen die beispielhaften Prozesse durch ein Datenverarbeitungssystem in Kommunikation mit einem Fahrzeugdatenverarbeitungssystem ausgeführt werden. Ein solches System kann eine drahtlose Einrichtung (zum Beispiel, 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, einschließen, aber ohne Beschränkung darauf. Kollektiv können solche Systeme als ein fahrzeugassoziiertes Datenverarbeitungssystem (VACS) bezeichnet werden. Bei bestimmten Ausführungsformen können bestimmte Komponenten des VACS abhängig von der bestimmten Implementierung des Systems bestimmte Teile eines Prozesses ausführen. Zum Beispiel und ohne Beschränkung ist es, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gepaarten drahtlosen Einrichtung aufweist, dann wahrscheinlich, dass die drahtlose Einrichtung den Prozess nicht ausführt, da die drahtlose Einrichtung nicht Informationen mit sich selbst "senden und empfangen" würde. Für Durchschnittsfachleute ist verständlich, wann es nicht angemessen ist, ein bestimmtes VACS auf eine gegebene Lösung anzuwenden. Bei allen Lösungen wird in Betracht gezogen, dass mindestens das Fahrzeugdatenverarbeitungssystem (VCS), das sich in dem Fahrzeug selbst befindet, in der Lage ist, die beispielhaften Prozesse auszuführen.
-
Bei den beispielhaften Ausführungsformen werden Systeme in Betracht gezogen, die Daten so, wie sie von einem Fahrer benötigt werden, zu einem Fahrzeug „pushen“. Statt auf spezifische Anforderungen von einem Fahrer zu warten und dann auf die Anforderungen zu reagieren, bestimmen die beispielhaften Ausführungsformen, welche Informationen benötigt werden oder einem Fahrer nützlich sein können, und senden diese Informationen dann dynamisch zu dem Fahrzeug. Die hier aufgeführten Prozesse arbeiten zum Beispiel mit einer bekannten Fahrzeugroute und bestimmen potentielle Bereiche mit Gefahr oder Fahrerbedenklichkeit auf diesen Routen. Zu diesen gehören, aber ohne Beschränkung darauf, Wetterzustände, Allergiezustände, gefährliches Material oder Notfallzustände usw.
-
Obwohl ein Fahrer am Anfang einer Route Informationen über diese Zustände anfordern könnte, vergessen viele Fahrer dies zu tun. Wenn es zum Beispiel sonnig ist, wenn ein Fahrer das Haus verlässt, denkt der Fahrer möglicherweise nicht an die Möglichkeit von gefährlichem Wetter auf einer Route. Oder der Fahrer könnte in einem anderen Beispiel nach einem Wetterbericht fragen und einen Alles-Klar-Bericht empfangen. Der Fahrer kann dann das Dach eines Kabrioletts herabnehmen und auf eine Tour losfahren. Unter der Annahme, dass das Wetter schön sein wird, könnte der Fahrer weiter auf einer Route fahren, und dann könnte ein Gewittersystem, das sich plötzlich entwickelt hat, auf den Fahrer treffen. Unter Verwendung der beispielhaften Ausführungsformen können Fahrer dynamisch vor rauen Situationen gewarnt werden, bevor sie auf diese treffen, auch wenn die Informationen nicht spezifisch angefordert werden.
-
2 zeigt einen beispielhaften Prozess zum Überwachen der Fahrzeugfahrt. In diesem Beispiel tritt ein entferntes System mit einem Onboard-System (fahrzeuginternen System, Anwendung auf einem drahtlosen Gerät in dem Fahrzeug usw.) in Interaktion. Die Interaktion erlaubt es dem entfernten System, potentielle Problembereiche auf einer Route hervorzuheben, und das Fahrzeug kann dann das entfernte System automatisch benachrichtigen, wenn sich das Fahrzeug einem gekennzeichneten Bereich nähert. Diese Bereiche können in einem Beispiel als Raumgrenzen bezeichnet werden und können durch Koordinatengrenzen, Koordinatenlinien, Straßenkreuzungen oder Übergänge oder beliebige andere geeignete Mittel zum Bestimmen eines geographischen Punkts, an dem eine Aktualisierung erforderlich sein kann, gekennzeichnet sein.
-
Bei dieser beispielhaften Ausführungsform beginnt der entfernte Prozess mit dem Überwachen, wenn er eine Benachrichtigung empfängt, dass ein Fahrzeug eine Route begonnen hat 201. Dieses Einleitungsprogramm kann dauernd laufen und für jedes Fahrzeug, das mit ihm in Interaktion tritt, eingerichtet werden. Oder es können gegebenenfalls für einzelne Fahrzeuge, Fahrzeuge in einer bestimmten Region usw. separate Instanzen laufen gelassen werden.
-
Zusätzlich zu dem Empfangen einer Benachrichtigung von dem Fahrzeug empfängt der Prozess außerdem die aktuellen GPS-Koordinaten des Fahrzeugs 203. Mit diesen Informationen kann man es dem entfernten System erlauben, zu bestimmen, wo sich das Fahrzeug gerade befindet, wo eine Route anfängt und beliebige Informationen dynamisch über potentielle Gefahren oder unerwünschte Zustände in der Nähe der aktuellen Position des Fahrzeugs bereitzustellen.
-
Nach dem Empfang der Fahrzeugkoordinaten empfängt der Prozess außerdem eine Fahrzeugroute (wenn verfügbar). In mindestens einem Fall kann eine Route unter Verwendung von bekannten Techniken prädiktiv bestimmt werden oder die Route könnte durch den Fahrer eingegeben werden. Die Route kann dann mit Fällen von gefährlichen und unerwünschten Situationen, die dem entfernten System bekannt sind, verglichen werden 211. Diese Informationen können dem System Punkte auf der Route bereitstellen, an denen diese Zustände vorliegen können.
-
Da es vorzuziehen sein kann, einen Fahrer über einen rauen Zustand zu benachrichtigen, bevor der Fahrer an dem tatsächlichen Punkt ankommt, an dem der Zustand auftritt, kann der Prozess einen „Zaun“ um den Zustand bzw. die Zustände setzen 207. Wenn es zum Beispiel am Ort X regnet, könnte ein Zaun in geeigneter Distanz um X herum gesetzt werden, so dass der Fahrer wahrscheinlich den Zaun überquert, bevor er tatsächlichen Regen antrifft. Der Zaun kann fest sein oder kann dafür eingestellt werden, sich gemäß einem bestimmten Plan zu bewegen, wie etwa, aber ohne Beschränkung darauf, in der bekannten Bewegungsrichtung eines Wettersystems. Obwohl in diesem Beispiel zur Veranschaulichung Wettersysteme verwendet werden, sind die Anwendungen der Erfindung nicht darauf beschränkt.
-
In einem anderen Beispiel kann der Ort des Zauns zu Beginn fest sein, kann aber mit der Zeit aktualisiert werden, während ein Fahrzeug auf einer Route voranschreitet. Zum Beispiel kann sich das System auf unvorhersehbare Weise bewegen oder dynamische, sich bewegende Einzäunung kann nicht erwünscht sein. In diesem Fall kann der Prozess periodisch die Bedingungen erneut mit der Route vergleichen und die Zäune gemäß bekannten Positionen potentieller Gefahren neu setzen.
-
Da Vorkommnisse, die für bestimmte Individuen besorgniserregend sein könnten, andere nicht kümmern, kann das System auch gespeicherte Fahrer-/Insasseninformationen verwenden, um zu bestimmen, welche Zustände zu melden sind. Der Fahrer kann diese Informationen voreinstellen, oder die Informationen könnten aus anderen eingegebenen Informationen erhalten werden, die durch das Fahrzeugsystem gesendet werden. Wenn zum Beispiel ein Fahrer Allergien hätte, wäre es nützlich, diesen Fahrer über raue Pollenzustände auf einer Route zu benachrichtigen. Ein Fahrer ohne Allergien kann jedoch diese Benachrichtigungen nicht benötigen oder sogar wünschen. Die Verwendung von Informationen, die für einen Fahrer/Insassen spezifisch sind, kann eine genauere Ablieferung von wünschenswerten nützlichen Informationen erlauben.
-
Nachdem die geeigneten Zäune bestimmt und gesetzt wurden, können die Informationen an das Fahrzeug zurückgegeben werden 209. Bei einer beispielhaften Ausführungsform verfolgt das Fahrzeug, wann es einen gesetzten Zaun überquert hat. Bei einer anderen beispielhaften Ausführungsform empfängt das Offboard-System periodisch Informationen von einem Fahrzeug, einschließlich des Orts dieses Fahrzeugs, und kann bestimmen, ob ein offboard gespeicherter Zaun überschritten wurde. Bei dem Offboard-Modell kann das System Zäune leichter aktualisieren, wenn sich Informationen ändern, bei dem Onboard-Modell kann das Fahrzeug aber das entfernte System benachrichtigen, sobald ein Zaun überschritten wurde. Außerdem ist es möglich, beide Modelle zum Überwachen zu benutzen, wenn es erwünscht ist.
-
3 zeigt einen beispielhaften Prozess zur Onboard-Tracking-Einleitung. Bei dieser beispielhaften Ausführungsform ist der Prozess ein Onboard-Prozess oder läuft auf einem Mobilgerät in dem Fahrzeug. Die Daten von dem entfernten Server werden je nach Bedarf zu dem Prozess “gepusht”, sobald der Prozess eingeleitet wurde und das Tracking begonnen hat.
-
In diesem Anschauungsbeispiel leitet der Prozess einen Tracking-Schritt ein 301, der potentiell einen Ruf des entfernten Servers umfassen kann, um einen Überwachungsschritt auf der Serverseite einzuleiten. Nachdem der serverseitige Prozess eingeleitet wurde, sendet der Prozess dann gegebenenfalls aktuelle Fahrzeugkoordinaten und/oder eine Route, wenn sie verfügbar sind 303. Bei mindestens einer nichtgezeigten Ausführungsform kann, wenn eine Route unbekannt ist, der Prozess den Benutzer bitten, eine Route einzugeben, oder versuchen, auf der Basis bekannter Techniken eine Route vorherzusagen.
-
Nachdem die gesendeten Daten serverseitig empfangen werden, werden sie durch einen serverseitigen Prozess verarbeitet und geben etwaige Warndaten und/oder Einzäunungsdaten aus. Diese Daten werden durch den fahrzeugseitigen Prozess empfangen 305. Etwaige Zaundaten werden dann fahrzeugseitig gespeichert, und während das Fahrzeug fährt, bestimmt der Prozess periodisch oder kontinuierlich, ob irgendwelche Raumgrenzen überschritten wurden 307.
-
4 zeigt einen beispielhaften Prozess zur Fernsystemkommunikation. Bei diesem beispielhaften Prozess wurde ein fahrzeugseitiger Überwachungsprozess aktiviert. Wie zuvor erwähnt, kann die Zaunüberwachung auch auf der Serverseite stattfinden, und das Fahrzeug kann lediglich die Koordinaten zu Tracking-Zwecken zu dem Server weiterleiten.
-
In diesem nichteinschränkenden Beispiel verfolgt der fahrzeugseitige Prozess die Position des Fahrzeugs 401. Dies kann zum Beispiel unter Verwendung von GPS-Koordinaten oder anderen geeigneten Tracking-Verfahren erfolgen, die Orte bereitstellen können, die mit den Zaunkoordinaten verglichen werden können. Zusätzlich zu dem Tracking des Fahrzeugs, um Zaunüberquerungen zu bestimmen, verfolgt der Prozess außerdem die allgemeine Fahrzeugposition, um periodisch sicherzustellen, dass keine neue, zuvor unbekannte Warnsituation entstanden ist.
-
Wenn in diesem Beispiel eine vorbestimmte Zeit/Distanz/usw. abgelaufen ist 403, sendet das System die aktuellen Koordinaten des Fahrzeugs zu einem entfernten System zur Verarbeitung. In diesem Beispiel wird, da keinerlei potentielle Warnung empfangen wird, wenn die Koordinaten in der Nähe eines Warnzustands sind, die Zaunprüfung nicht durchgeführt, falls Koordinaten als Teil der periodischen Sendung gesendet werden. Wenn jedoch keine periodische Sendung ansteht, prüft der Prozess dann jedoch, ob eine Raumgrenze überquert wurde 405.
-
Wenn der Zaun nicht überquert wurde und keine periodischen Sendungen zu senden sind, bleibt der Prozess in einer Schleife und überwacht weiter auf Koordinatenänderungen oder Zaunüberquerungen. Wenn ein Zaun überquert wurde, sendet der Prozess jedoch Daten in Bezug auf den Zaun, der überquert wurde 407, zusätzlich zu den Koordinatendaten 409.
-
Obwohl es auch möglich ist, einfach Koordinatendaten zu senden, wenn ein Zaun überquert wird, erlaubt in diesem Beispiel das Senden von Daten (wie etwa eines Zaunnamens oder zugeordneter Zaunattribute) dem entfernten Prozess, die gesendeten Zaundaten zum Beispiel, aber ohne Beschränkung, mit einem diesem Zaun zugeordneten Ereignis oder Zustand zu vergleichen. Wenn sich das Ereignis oder der Zustand geändert hat, können eine dynamische Aktualisierung des Zauns sowie etwaige notwendige Warnungen zu dem Fahrzeug gepusht werden. Dies kann dabei helfen, den Zaun adaptiv zu ändern, wenn neue Daten verfügbar werden, während gleichzeitig das Tracking von mit dem Zaun assoziierten Zuständen gewährleistet wird.
-
Etwaige von dem entfernten Server gesendete Antworten, wie etwa, aber ohne Beschränkung darauf, Warnungen, neue Zäune, Zaunaktualisierungen usw., werden durch das fahrzeuginterne System empfangen 411. Wenn irgendwelche neuen Warnungen abzuliefern sind 413, liefert der Prozess die Warnungen an die Insassen ab 415. Wenn neue oder aktualisierte Zaundaten als Reaktion von dem Server gepusht werden 417, kann der Prozess die Zaundaten zu dem Überwachungsprozess hinzufügen 419, so dass Vergleiche mit den neuen oder aktualisierten Grenzen stattfinden können.
-
5 zeigt einen beispielhaften Prozess zum Fernsenden von Aktualisierungen zu einem Fahrzeug. In diesem Anschauungsbeispiel empfängt der entfernte Server Koordinatendaten von dem Fahrzeug, sowie Daten in Bezug auf Zaunüberquerungen. In anderen Beispielen kann der entfernte Server einfach Koordinatendaten oder andere geeignete Tracking-Daten empfangen und auf dem Server gespeicherte Zauninformationen verwenden, um Warnzustände zu verfolgen.
-
Bei dieser nichteinschränkenden Ausführungsform überwacht der entfernte Prozess eine oder mehrere Routen je nach Wunsch 501. Koordinaten- oder ähnliche Daten werden von einem fahrzeuginternen Prozess gemäß einem Senden dieser Daten von dem fahrzeuginternen Prozess empfangen 503. Die Koordinatendaten werden dann untersucht, um zu sehen, ob ein Warnzustand den gesendeten Koordinatendaten entspricht 504.
-
Wenn es eine Warnung gibt, die abgeliefert werden muss 505, sendet der Prozess die Warnung zur Ablieferung an die Fahrzeuginsassen zu dem fahrzeuginternen Prozess 507. Wenn keine Warnung zu senden ist oder nachdem die Warnung gesendet wurde, kann der Prozess bei dieser Ausführungsform dann auch Zaunüberquerungsdaten empfangen 509, die angeben, dass eine vorbestimmte Raumgrenze durch das Fahrzeug erreicht oder überquert wurde.
-
Die empfangenen Zaundaten können mit dem mit diesem bestimmten Zaun oder diesen bestimmten Zäunen assoziierten System, Zustand usw. verglichen werden 511. Wenn sich der Zustand geändert, zu existieren aufgehört, bewegt usw. hat, kann es nicht notwendig sein, eine Warnung abzuliefern, aber wenn eine Warnung notwendig ist 513, kann eine mit dem bestimmten Zustand assoziierte Warnung an das fahrzeuginterne System abgeliefert werden 515.
-
Zusätzlich zu dem Abliefern einer Warnung kann der Prozess bestimmen, dass ein neuer Zaun oder eine Abänderung des existierenden Zauns notwendig ist 517. Dieser neue Zaun könnte einem neuen Zaun entsprechen, der einem beliebigen Punkt auf der Route zugeordnet ist, einem neuen Zaun, der empfangenen Koordinatendaten zugeordnet ist, der Löschung eines existierenden Zauns, der Abänderung eines existierenden Zauns (wofür entweder Daten empfangen wurden oder an einer anderen Stelle auf einer Route), oder einer beliebigen anderen geeigneten Zaunabänderung/-erzeugung. Bei mindestens einer Ausführungsform könnten die „empfangenen“ Zaundaten einfach NULL-Daten sein, aber der Prozess könnte weiter sehen, ob die Erzeugung von neuen Zäunen oder Abänderung von existierenden Zäunen notwendig ist.
-
Wenn ein oder mehrere neue Zäune zu erzeugen sind oder wenn irgendwelche existierenden Zäune abgeändert werden müssen, kennzeichnet der Prozess neue Grenzen für die Zäune 519. Diese Grenzdaten können dann an den fahrzeuginternen Prozess abgeliefert werden 521. An diesem Punkt kann das System das Überwachen des Fortschritts des Fahrzeugs wiederaufnehmen und je nach Bedarf zusätzliche Aktualisierungen in der Zukunft empfangen.
-
6 zeigt einen beispielhaften Prozess zum Aktualisieren von Parametern, die mit einem fahrenden Fahrzeug assoziiert sind. In diesem Beispiel ist das entfernte System mit zusätzlicher Funktionalität zum Erzeugen und Abändern von Zäunen gezeigt. Wie bei allen Prozessen in der vorliegenden Anmeldung ist dieser Prozess beispielhaft und soll mögliche Schritte zeigen, die von einem entfernten System unternommen werden können. Es ist nicht beabsichtigt, den Schutzumfang der Erfindung darauf zu beschränken.
-
In diesem Beispiel werden Fahrzeuginformationen empfangen 601. Wenn zum Beispiel der entfernte Server eine Aufzeichnung aktueller Zaundaten für fahrende Fahrzeuge speichert, könnten die Fahrzeuginformationen dazu verwendet werden, existierende gespeicherte Daten nachzuschlagen. Zusätzlich oder als Alternative könnten Routendaten in das Fahrzeuginformationspaket aufgenommen werden, so dass der entfernte Server Überwachungsdaten für eine neue Route setzen und/oder die empfangene Route mit einer gespeicherten bekannten Route für ein bestimmtes Fahrzeug vergleichen kann.
-
In mindestens einem Fall kann es wünschenswert sein, zumindest vorübergehend Routendaten für jedes Fahrzeug zu speichern. Zusätzlich zu der Bereitstellung von Metrik- und Tracking-Daten zum Fahrzeugfahrt-Tracking, zum Fahrzeugbenutzungs-Tracking, für prädiktive Routing-Routinen usw. können die gespeicherten Daten auch dann editiert werden, wenn ein fahrzeuginterner Prozess gerade keine Informationen sendet, so dass die Einzäunung in Echtzeit oder nahezu Echtzeit auf dem neuesten Stand gehalten werden kann. Auf diese Weise kann, auch wenn das System stark beschäftigt ist, wenn Koordinatendaten für ein bestimmtes Fahrzeug empfangen werden, ein einfacher Nachschlag von zuvor aktualisierten und gespeicherten Daten die zu einem bestimmten Fahrzeug zu pushenden Informationen bereitstellen. Dadurch könnte der entfernte Server bzw. könnten die entfernten Server zahlreiche Fahrzeugrouten mit neuen Daten aktualisieren, während Zyklen niedrig sind und Serverlasten gering sind.
-
Zusätzlich oder als Alternative könnte der Prozess, wenn die Daten entfernt gespeichert werden, immer dann, wenn eine Raumgrenze abgeändert wird, die abgeänderten Raumgrenzendaten zu einem gegebenen Fahrzeug weiterzuleiten
-
In diesem Anschauungsbeispiel vergleicht der Prozess eine empfangene Route mit einer existierenden Route (die eine NULL-Route sein kann), um zu sehen, ob eine neue Route empfangen wurde 603. Wenn eine neue Route empfangen wurde, kann der Prozess zum Beispiel zu Schritt 205 von 2 übergehen und verarbeitet die neuen Routendaten für ein neues Tracking-/Zaunsystem.
-
Wenn die Routendaten einer bereits bekannten Route entsprechen und keine neue Route sind oder wenn die empfangenen Routendaten NULL sind (z.B. keine Route eingegeben), kann der Prozess zwischen den beiden eine Bestimmung treffen 605. Wenn eine Route NULL oder unbekannt ist, kann der Prozess eine Route von einem fahrzeuginternen Prozess anfordern 615. Die zu dem fahrzeuginternen Prozess gesendete Anforderung kann zu einem Fahrer übermittelt werden und/oder kann Einbindung eines prädiktiven Algorithmus verursachen, um auf der Basis von bekannten Techniken eine Route zu „raten“.
-
Wenn eine ansprechende neue Route empfangen wird 617 kann das System nach dem Senden der Anforderung der Route zum Beispiel und ohne Beschränkung wieder zu einem Prozess wie Schritt 205 von 2 übergehen, um mit der neuen Route umzugehen. Wenn die neue Route noch nicht empfangen wurde, kann der entfernte Prozess immer noch mit etwaigen empfangenen Koordinaten umgehen 619, so dass ein Fahrer über etwaige lokale Zustände benachrichtigt werden kann, die existieren oder bevorstehen, wenn Koordinaten empfangen werden.
-
Wenn eine empfangene Route einer zuvor bekannten Route entspricht 605, kann der Prozess dann existierende Zäune auf dieser Route prüfen, um zu sehen, ob Änderungen an diesen Zäunen zu dem fahrzeuginternen Prozess gepusht werden müssen 607. Wie zuvor erwähnt, können die mit einer gegebenen Route assoziierten Zäune entfernt in einem Repositorium gespeichert und mit einem bestimmten Fahrzeug assoziiert werden. Wenn die Zäune geändert wurden oder neue Zäune hinzugefügt wurden bzw. werden müssen, können etwaige nichtabgespeicherte Änderungen in dem Repositorium gespeichert werden 611, und die neuen/abgeänderten Daten können zu dem Fahrzeug gepusht werden.
-
7 zeigt einen weiteren beispielhaften Prozess zur Routengefahrenüberwachung. In diesem Anschauungsbeispiel wird die Kommunikation zwischen dem Fahrzeug und dem entfernten System auf einem Minimum gehalten. Am Beginn des Prozesses empfängt das entfernte System Routendaten, die zum Beispiel von dem Fahrzeug transferiert werden 701. Die Daten werden mit existierenden bekannten Zuständen verglichen 703, und etwaige relevante Warnungen werden zu einem Fahrzeugbenutzer gesendet 705.
-
In bestimmten Fällen kann die völlige Vermeidung einer Gefahr wünschenswert sein, so dass der Prozess eine oder mehrere Neuroutungen empfehlen kann 707. Die Vermeidung von Gefahren kann, aber ohne Beschränkung darauf, Unwetter, Bereiche mit hohen Allergiezählwerten für Fahrer mit Allergien usw. umfassen. Wenn es irgendwelche empfohlenen Neuroutungen gibt, kann der entfernte Prozess Vermeidungsrouten bestimmen und die Route(n) zu dem Fahrzeug senden 709. Wenn der Fahrer reagiert, indem er die neuen Routen annimmt 711, kann die neue Route als die „aktuelle“ Route angenommen werden 713.
-
Der Prozess speichert dann zumindest vorübergehend die Route in einem assoziierten Speicherbereich 715. Diese Route kann in Verbindung mit Geschwindigkeitsdaten, Verkehrsdaten, Wetterdaten, Fahrerverhaltensdaten usw. verwendet werden, um zu einem beliebigen Zeitpunkt eine Fahrzeugposition zu schätzen 717. Während das Fahrzeug fährt kann der Prozess, wenn eine neue Route eingegeben wird oder das Fahrzeug wesentlich von der Route abweicht, eine Anzeige „neue Route“ empfangen 719. Dies kann bewirken, dass der gesamte Prozess in eine Schleife eintritt, wobei die neue Route als die aktuelle Route behandelt wird und die entsprechenden Schritte ausgeführt werden.
-
Wenn es keine neue Route gibt, vergleicht das System eine geschätzte Fahrzeugposition mit Gefahrenzuständen, um zu sehen, ob eine Warnung (oder Neuroutung) notwendig ist 721. Wenn eine Warnung oder Neuroutung notwendig ist, weist der Prozess den Fahrer hin 723 und nimmt dann die Fahrtüberwachung wieder auf. Zusätzlich kann, obwohl es nicht gezeigt ist, wenn die Kommunikation mit dem Fahrzeug zum Zwecke der Warnungsübertragung geöffnet wird, die Fahrzeugposition auch unter Verwendung von bidirektionaler Kommunikation aktualisiert werden, so dass die geschätzte Position so dicht wie möglich bei der tatsächlichen Position gehalten werden kann.
-
Unter Verwendung der beispielhaften Ausführungsformen kann ein Fahrer/Insasse dynamisch Daten (oder etwaige andere Daten) über gefährliche Zustände empfangen, ohne die bestimmten Daten explizit anfordern zu müssen. Auf diese Weise können die beispielhaften Ausführungsformen dazu dienen, die Bedürfnisse des Fahrers zu „antizipieren“ und ein besseres Fahrerlebnis bereitzustellen.
-
Unter Verwendung von Gefahrendaten und Routeninformationen können Ausführungsformen Zäune und Unfälle auf einer Route vorhersagen. Das heißt, wenn eine Route eingeleitet wird, kann der Prozess bereits über potentielle Problembereiche auf der Route, die einige Distanz/Zeit entfernt sind, Bescheid wissen. Diese Informationen können bei der Bereitstellung von Neuroutung verwendet werden und/oder beim Hinweisen eines Fahrers, lange bevor ein bedenklicher Bereich erreicht wird.
-
Obwohl oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Stattdessen sind die in der Beschreibung verwendeten Wörter nicht Wörter der Beschränkung, sondern der Beschreibung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener Implementierungsausfü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
-
- Protokolle IEEE 802 PAN [0026]
- Protokolle IEEE 802 LAN [0026]
- IEEE 802 PAN [0026]
- IEEE 1394 [0029]
- IEEE 1284 [0029]
