-
Die beispielhaften Ausführungsformen betreffen allgemein ein Verfahren und eine Vorrichtung zur Erleichterung von Pannenhilfe.
-
Die US-Anmeldung, Publikation 2009/0233572, offenbart „Ein System zum Bereitstellen von Pannen- und Notfallhilfe für ein Fahrzeug umfasst eine Fahrzeugeinheit mit mehreren Konnektivitätsoptionen. Eine Benutzeroberflächeneinheit gestattet es einem Benutzer, Hilfe anzufordern und mit einem Notdienstentsender und/oder Dienstanbieter zu kommunizieren. Ein Server empfängt Anforderungen von Hilfe von der Fahrzeugeinheit und leitet Informationen zwischen der Fahrzeugeinheit und einem Entsender oder Dienstanbieter weiter, um Kommunikation zwischen dem Fahrer des Fahrzeugs und dem Entsender oder Dienstanbieter bereitzustellen. Als Alternative, wie etwa in einer Notfall-(z.B. Unfall-)situation fordert der Server direkt an, dass Hilfe zu dem Fahrzeug gesendet wird.“
-
Das
US-Patent 6,028,537 offenbart „Das Fahrzeugkommunikations- und Steuersystem der vorliegenden Erfindung umfasst einen Sender/Empfänger zum Senden und Empfangen von HF-Signalen, einen mit dem Sender/Empfänger gekoppelten Prozessor, einen mit dem Prozessor gekoppelten Ortsidentifizierungssensor zum Liefern von Fahrzeugortsdaten, eine mit dem Prozessor gekoppelte Benutzeroberfläche, um einem Benutzer Informationen bereitzustellen, und um es einem Benutzer zu ermöglichen, durch den Prozessor auszuführende Befehle einzugeben, und eine Fahrzeughilfseinrichtungsschnittstelle zum Koppeln des Prozessors mit einer Fahrzeughilfseinrichtungs-Steuerschaltung, um es dem Prozessor zu ermöglichen, Befehle an eine Fahrzeughilfseinrichtung auszugeben. Der Prozessor ist vorzugsweise dafür ausgelegt, als Reaktion auf Benutzereingabebefehle, empfangene HF-Signale und andere von anderen Fahrzeughilfseinrichtungen und Komponenten, die durch den Fahrzeugsystembus mit dem System der vorliegenden Erfindung gekoppelt sind, empfangene Befehle vielfältige Funktionen auszuführen. Zu bestimmten dieser Funktionen gehören das Herstellen einer bidirektionalen Kommunikationsverbindung, das Anfordern und Bereitstellen von ortsspezifischen Informationen, das Ermöglichen von Fernverfolgung des Fahrzeugs, Ausgeben einer Notfallanforderung oder Anforderung von Pannenhilfe, Anfordern und Empfangen von Navigationsinformationen, Fernbedienung von Fahrzeugfunktionen, Ermöglichen von Ferndiagnostik des Fahrzeugs und Ermöglichung einer Umprogrammierung von verschiedenen Fahrzeughilfseinrichtungen und -komponenten.“
-
Obwohl über die Jahre hinweg verschiedene Ansätze mit Bezug auf Pannenhilfe und Fahrzeuge unternommen wurden, sind durch aufkommende Technologie- und Kommunikationsoptionen Möglichkeiten für schnellere, effizientere und umfassendere Hilfslösungen entstanden.
-
Bei einer ersten beispielhaften Ausführungsform umfasst ein Pannenhilfesystem ein Fahrzeugdatenverarbeitungssystem (VCS), das betreibbar ist, um durch eine mit einer drahtlosen Vorrichtung hergestellte drahtlose Verbindung mit einem oder mehreren entfernten Systemen zu kommunizieren. Das System umfasst außerdem ein zwischengeschaltetes System, das betreibbar ist, um mit dem VCS und mindestens einem Backend-System zu kommunizieren. Das System umfasst ferner ein Backend-Pannenhilfe-Verarbeitungssystem, das betreibbar ist, um durch eine Datenverbindung Daten von dem zwischengeschalteten System zu empfangen, und betreibbar ist, um Telefonanrufe von dem VCS zu empfangen.
-
Das VCS ist betreibbar, um als Reaktion auf eine Pannenhilfeanforderung Kommunikation mit dem zwischengeschalteten System herzustellen. Das VCS ist ferner betreibbar, um Fahrzeug- und Kundendaten zu dem zwischengeschalteten System zu übermitteln. Das VCS ist ferner betreibbar, um einen Telefonanruf an das Backend-Pannenhilfe-Verarbeitungssystem einzuleiten. Das VCS ist ferner betreibbar, um mindestens eine Mobilidentifikationsnummer zu dem Backend-Pannenhilfe-Verarbeitungssystem weiterzuleiten.
-
Das zwischengeschaltete System ist betreibbar, um übermittelte Daten zu verarbeiten und übermittelte Daten zu dem Backend-Pannenhilfesystem weiterzuleiten. Das Backend-Pannenhilfesystem ist betreibbar, um die von dem VCS weitergeleitete Mobilidentifikationsnummer mit aus dem zwischengeschalteten System empfangenen Daten zu vergleichen, um eine Entsendungsreihenfolge zu formulieren. Das Backend-Pannenhilfesystem ist ferner betreibbar, um Pannenhilfe gemäß der Entsendungsreihenfolge zu entsenden.
-
Bei einer zweiten beispielhaften Ausführungsform umfasst ein computerimplementiertes Verfahren das Empfangen einer Anforderung von Pannenhilfe in einem Fahrzeugdatenverarbeitungssystem (VCS). Das Verfahren umfasst außerdem das Herstellen einer ersten Kommunikation mit einem zwischengeschalteten System und das Weiterleiten von Fahrzeugdaten von dem VCS zu dem zwischengeschalteten System zur Verarbeitung. Das Verfahren umfasst ferner das Herstellen einer zweiten Kommunikation mit einer Pannenhilfezentrale. Das Verfahren umfasst das Weiterleiten von Kundendaten zu der Pannenhilfezentrale zur Verarbeitung. Außerdem umfasst das Verfahren das Bereitstellen einer offenen Leitung für Kommunikation zwischen dem Kunden und der Pannenhilfezentrale.
-
Bei einer dritten beispielhaften Ausführungsform umfasst ein computerimplementiertes Verfahren das Empfangen eines Anrufs von einem Fahrzeugdatenverarbeitungssystem (VCS), der eine Anforderung von Pannenhilfe weiterleitet. Das Verfahren umfasst ferner das Empfangen von Daten von einer zwischengeschalteten Quelle, wobei die Daten durch das VCS zu der zwischengeschalteten Quelle gesendet wurden. Außerdem umfasst das Verfahren das Korrelieren des empfangenen Telefonanrufs und empfangener Daten. Das Verfahren umfasst ferner das Verifizieren von Kundenhilfeberechtigung mindestens teilweise auf der Basis der Daten. Außerdem umfasst das Verfahren automatisches Entsenden von Pannenhilfe, um einem Kunden zu helfen, abhängig von Kundenhilfeberechtigung.
-
1 zeigt ein beispielhaftes Fahrzeugdatenverarbeitungssystem;
-
2A zeigt ein Anschauungsbeispiel für Pannenhilfe-Anforderungsfluss in einem Fahrzeugdatenverarbeitungssystem;
-
2B zeigt ein Anschauungsbeispiel für einen Pannenhilfe-Backend-Fluss;
-
2C–2E zeigen Anschauungsbeispiele für Pannenhilfe-Anforderungsverarbeitungsflüsse;
-
3A–3C zeigen Anschauungsbeispiele für Pannenhilfe-Anforderungshandhabungsprozesse;
-
4 zeigt ein Anschauungsbeispiel für einen Pannenhilfe-Anforderungsverarbeitungsprozess; und
-
5 zeigt ein Anschauungsbeispiel für einen Pannenhilfe-Aktualisierungsprozess.
-
Es 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 THE FORD MOTOR COMPANY hergestellte System SYNC. Ein mit einem fahrzeuggestützten Datenverarbeitungssystem befähigtes Fahrzeug kann eine im Fahrzeug befindliche visuelle Frontend-Schnittstelle 4 enthalten. Der Benutzer kann auch in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm ausgestattet ist. Bei einer anderen beispielhaften Ausführungsform erfolgt die Interaktion durch Tastenbetätigungen, ein interaktives Sprachsystem mit automatischer Spracherkennung und Sprachsynthese.
-
Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der Prozessor ist in dem Fahrzeug vorgesehen und erlaubt Onboard-Verarbeitung von Befehlen und Routinen. Ferner kann der Prozessor mit nicht persistentem 5 und persistentem Speicher 7 verbunden sein. 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-Senders/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 Daten-über-Sprache 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, ist 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 Daten-über-Sprache-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 Daten-über-Sprache 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, einen 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 vielen Fahrzeugen sind eine oder mehrere Arten von Pannenhilfe-Verträgen für Kauf oder Aktivierung durch den Kunden verfügbar. Optionen für Pannenhilfe reichen von dem Verbinden eines Kunden mit einem Techniker, der Fahrzeugrat geben kann, mit Abschleppdiensten, bis zu umfassenden ortsgebundenen Verträgen, und sind oft zahlreich und unterschiedlich.
-
Aufgrund der enormen Anzahl von von Herstellern/Händlern verkauften Fahrzeugen, da bestimmte Verträge übertragbar sind und andere möglicherweise nicht, und da die einem bestimmten Vertrag zugeordneten Optionen von Fahrzeug zu Fahrzeug unterschiedlich sein können, ist es nützlich, in der Lage zu sein, Informationen in Bezug auf einen bestimmten Kunden und/oder ihren Vertrag schnell und leicht wieder aufzurufen. In verschiedenen Fällen ist dabei ein komplizierter Nachschlageprozess beteiligt, der von einer Bedienungsperson ausgeführt wird.
-
Es können Fahrzeugwartungsinformationen, Berechtigungsinformationen, Kundeninformationen, Fahrzeugdiagnostikinformationen (wenn verfügbar), Händlerort/-informationen und sehr viele andere Informationen erwünscht sein, um einen Pannenhilferuf erfolgreich zu verarbeiten. Wenn bestimmte dieser Informationen nicht verfügbar sind, kann ein Hilfeanbieter jedoch wählen, trotz der Nichtverfügbarkeit fortzufahren oder die Anforderung im Hinblick auf die Nichtverfügbarkeit zu verweigern.
-
Im ersteren Fall wird möglicherweise ineffektive oder ungeeignete Hilfe bereitgestellt, wodurch entweder ein Kunde irritiert wird oder einem Hersteller/Händler/Anbieter Geldkosten bei der Bereitstellung von Dienst, für den ein Kunde nicht berechtigt ist, entstehen. Im letzteren Fall kann eine Dienstverweigerung, bei der der Kunde weiß/glaubt, dass er berechtigt ist, einen möglicherweise bereits irritierten Kunden weiter irritieren. In jedem Fall sind unerwünschte Ergebnisse möglich und/oder wahrscheinlich, und ein umfassendes, leicht zugängliches und schnelles System würde größere Zufriedenheit für alle Beteiligten ermöglichen.
-
2A zeigt ein Anschauungsbeispiel für Pannenhilfe-Anforderungsfluss in einem Fahrzeugdatenverarbeitungssystem. Bei mindestens einer Ausführungsform ist ein Fahrzeugdatenverarbeitungssystem entweder automatisch oder auf Anforderung eines Kunden hin in der Lage, eine Pannenhilfeanforderung durchzuführen. Die Aktivierung von Pannenhilfe 201 bewirkt die Verarbeitung eines Pannenhilfebefehls 203.
-
In diesem Anschauungsbeispiel bewirkt die Verarbeitung des Pannenhilfebefehls, dass vielfältige wünschenswerte Daten zu einer oder mehreren entfernten Quellen gesendet werden 205. Diese Daten werden zum Beispiel, aber ohne Beschränkung, Fahrzeugbetriebsdaten 207 entnommen, die in Fahrzeugnetzwerken (wie etwa, aber ohne Beschränkung darauf, einem CAN-Bus) verfügbar sind. Die Daten können, aber ohne Beschränkung darauf Fahrzeugsensordaten, Onboard-Diagnostikdaten, Kraftstoffstände, Kilometerzählerstände, Reifendrücke, Rückhaltesteuermodulsignale und beliebige andere relevante oder erwünschte fahrzeug- oder fahrgastbezogene Daten umfassen. In bestimmten Fahrzeugen können Daten über die spezifischen Fahrgäste bekannt sein, darunter, aber ohne Beschränkung darauf, medizinische Daten, Notfallkontaktdaten usw.
-
2B zeigt ein Anschauungsbeispiel für einen Pannenhilfe-Backend-Fluss. In diesem Anschauungsbeispiel ist ein Backend-System/-Fluss für umfassende Datenbereitstellung für einen Pannenhilfeanbieter gezeigt. Daten 215 eines erweiterten Servicevertrags, Händlerort/-Daten 217 und Verkaufs- und Kundeninformationen 219 sind nur einige wenige der möglichen „entfernten“ Datenelemente, die durch den Pannenhilfeanbieter automatisch zugänglich sind. Zusätzlich erlaubt dieses beispielhafte System das Aktualisieren von Kunden- und Fahrzeugdaten 213 (zum Beispiel aus Kundenanrufen, Pannenhilfeanrufen, Händlerbesuchen usw.).
-
Die Kunden- und Fahrzeugdaten werden im Vergleich zu einem existierenden Kundendatensatz zum Beispiel unter Verwendung einer VIN (um sicherzustellen, dass das richtige Fahrzeug mit den gemeldeten Daten korreliert ist) verifiziert. Zusammen mit existierenden Kundendaten 223 werden jegliche neuen Sorgen oder Probleme zu einem Kundeninformations-Datenspeicher übermittelt 221, aus dem sie später im Fall eines zukünftigen Pannenhilfeanrufs zugänglich sind. Dieser „Sorge-Meldeprozess“ kann auch unmittelbar Daten in Bezug auf irgendeinen ablaufenden Pannenhilfeanruf verarbeiten, um sie zu einem Kundendatensatz hinzuzufügen.
-
Die gespeicherten Daten 215, 217 und 219 können zusammen mit beliebigen anderen betreffenden Daten im Detail 227 zu einem Pannenhilfe-Verarbeitungspunkt gesendet werden, um einen Kunden-/Fahrzeugdatensatz 229 zur Verwendung beim Verarbeiten einer Pannenhilfeanforderung zusammenzustellen. Ein Anruf bzw. eine Kommunikation, der bzw. die in die Pannenhilfezentral 231 hereinkommt, kann bestimmte eigene Daten 233 umfassen, und diese Daten und dieser Anruf können auf aggregierte Weise mit allen wünschenswerten existierenden Kundendaten gehandhabt werden, so dass ein Kunde leicht nachgeschlagen, verifiziert und Hilfe entsendet werden kann 237. Zusätzlich kann der Nachschlage-/Entsendeprozess zusätzliche fahrzeugbezogene Daten 235 über einen aktuellen Status des Fahrzeugs umfassen, die in diesem Fall durch einen Anforderungsverarbeitungsfluss zu dem Prozess weitergeleitet wurden (im Gegensatz zu direkter Übermittlung mit dem Anruf).
-
Vor der Ablieferung an die Pannenhilfezentrale wurden die fahrzeugbezogenen Daten in diesem Beispiel in leicht lesbares und verständliches klares Englisch 239 transformiert, so dass der Bearbeiter/Entsender verstehen kann, welche potentiellen Probleme von Dienstpersonal behandelt werden müssen. Diese Daten 243 wurden aus einem zwischengeschalteten Verarbeitungssystem weitergeleitet, das u.a. einem Händler oder Hersteller (OEM) erlauben kann, ferner Daten in Bezug auf gewartete Fahrzeuge zu empfangen und potentiell zum Beispiel häufig auftretende Probleme zu diagnostizieren und zu behandeln.
-
2C–2E zeigen Anschauungsbeispiele für Pannenhilfe-Anforderungsverarbeitungsflüsse. In 2C befindet sich ein zwischengeschalteter menügesteuerter Dienstanbieter (umrahmt mit gestrichelter Linie) in Kommunikation mit dem VCS. In diesem Fall wird im VCS ein Sprachanruf 251 verwendet, um Daten 252 zu übermitteln, wobei die Datenübermittlung in einem Daten-über-Sprache-Verfahren ermöglicht wird.
-
Der Prozess beim Dienstanbieter empfängt einen Anruf 253, der einen internen Pannenhilfebefehl 254 einleitet, der dann eine Anfrage einer Brücke 255 als Brückenanforderung 260 mit einem zwischengeschalteten System 263 bewirken kann. Die Brücke kann zum Beispiel geöffnet werden, um Übermittlung 256 von ankommenden Fahrzeugdaten zu dem zwischengeschalteten System 263 zu ermöglichen. Nachdem die Brückenanforderung 260 gesendet/durch das zwischengeschaltete System verarbeitet wurde und eine Brücke offen ist, können zu dem Dienstanbieter gesendete Daten 252 durch den Dienstanbieter im Schritt 256 weitergeleitet werden in Form eines oder mehrerer Datenpakete 261 zu dem zwischengeschalteten System 263.
-
Nachdem alle Daten weitergeleitet wurden, kann der Dienstanbieter anfordern 257, dass die Brücke geschlossen wird, und ein Brückenschließungsbefehl 262 kann durch das zwischengeschaltete System verarbeitet werden, wodurch die Datenverbindung beendet wird.
-
Zusätzlich zu der Handhabung des anfänglichen Anforderungsanrufs 251 und der Datenübermittlung 252 kann der Dienstanbieter auch erkennen, dass Verarbeitung eines Pannenhilfebefehls 258 erfordern kann, dass eine Verbindung mit einer Pannenhilfezentrale hergestellt wird 259. Ein Sprachanruf (und etwaige zugeordnete Daten) 212 können verarbeitet werden, wodurch der Fahrzeug-Fahrgast Informationen über verfügbare Dienste und spezifische Entsendungen empfangen kann.
-
Gleichzeitig kann das zwischengeschaltete System die Daten für Meldezwecke benutzen sowie die Daten 265 weiterleiten und etwaige Diagnostik in ein benutzbares Format 243 z.B. eines Pannenhilfeanbieter transformieren 216.
-
In den in 2C–2E gezeigten Beispielen sind mehrere verschiedene zwischengeschaltete Systeme 263, 268, 281 gezeigt. Zusätzlich zu der Bereitstellung von Datenweiterleitungsfähigkeit können diese Systeme von OEM verwendet werden, um Pannenhilfeanrufe und übermittelte Fahrzeugdiagnostikdaten aufzuzeichnen. Der bei Pannenhilfeanrufen gemeldete Kilometerstand kann überwacht werden, die allgemeine Pannenhilfsbenutzung kann überwacht werden, Diagnostikinformationen können überwacht werden. In bestimmten Fällen können Fahrzeuggarantiedaten aktualisiert, Fahrzeugbetriebsdaten aufgezeichnet und Pannenhilfemeldungen zur Begutachtung durch OEM-Produktmanager zusammengestellt werden. Es können auch je nach Wunsch andere Meldungen/Daten erfolgen. Obwohl es zum Verarbeiten einer Pannenhilfeanforderung nicht erforderlich ist, erlaubt all dieses Melden und Aufzeichnen von Daten OEM, erweiterte Grade von Fahrzeugservice und Kundenzufriedenheit zu gewährleisten, und kann allgemein zu einem glücklicheren, zufriedeneren Kunden führen.
-
2D zeigt ein Anschauungsbeispiel, bei dem Fahrzeugdaten 265 auf vielfältige Weisen zu einem zwischengeschalteten System übermittelt und von diesem in einem Schritt 264 weitergegeben werden können. Es kann der Fall sein, dass für schnellere und vielleicht sogar umfassendere Datenübermittlung eine bestimmte Weise, die höhere Bandbreite bereitstellt, ausgewählt wird, wenn sie verfügbar ist, wohingegen ein sekundäres System verwendet werden kann, wenn das schnellere System nicht verfügbar ist.
-
Wenn zum Beispiel eine WiFi-Verbindung 272 zur Verwendung durch ein Fahrzeugdatenverarbeitungssystem verfügbar ist, können die Daten 273 unter Verwendung einer WiFi-Verbindung zu dem zwischengeschalteten System 268 übermittelt werden. Oder wenn zum Beispiel eine drahtlose Vorrichtung mit einem Datenplan in Kommunikation mit dem VCS detektiert wird, kann ein Befehl zum Weiterleiten von Fahrzeugdaten 266 von der drahtlosen Vorrichtung durch die drahtlose Vorrichtung verarbeitet/zu dieser gesendet werden, und ein Vorrichtungs-Datenplan 270 kann zum Weiterleiten von Fahrzeugdaten 271 verwendet werden.
-
Oder wenn eine Übermittlung von Daten-über-Sprache DOV 267 erwünscht/verfügbar ist, können die Betriebsdaten 265 zu einer DOV-Verarbeitungsmaschine 275 gesendet werden, die den Daten-über-Sprache-Kanal empfängt und dann die Daten 269 zu dem zwischengeschalteten System 268 weiterleitet.
-
Nachdem die Daten zur Verarbeitung und Weiterleitung durchgeleitet wurden, kann das System auch einen Sprachanruf 212 verbinden, so dass der Fahrgast des Fahrzeugs und das VCS mit einer Hilfeentsendung bzw. -backend zum Senden und Empfangen von Informationen in Bezug auf eine Hilfeanforderung kommunizieren kann.
-
2E zeigt ein anderes Anschauungsbeispiel für ein System, bei dem DOV die einzige Option zur Fahrzeugdatenweiterleitung ist. In diesem Anschauungsbeispiel wird ein Fahrzeugdatenpaket 280 im DOV-Format zu einer DOV-Verarbeitungsmaschine 283 gesendet, die in der Lage ist, über einen Sprachkanal gesendete Daten zu empfangen. Die Datenverarbeitungsmaschine 283 wickelt das Datenpaket ab und leitet die Daten 282 dann zu einem zwischengeschalteten System 281 weiter. Wie zuvor erwähnt, kann das zwischengeschaltete System bzw. können die zwischengeschalteten Systeme die Daten an einen OEM 299 (oder Händler usw.) melden sowie die Daten 284 zur weiteren Weiterleitung 243 zu einem Pannenhilfeanbieter transformieren. Transformierte Daten können auch einem OEM-Meldesystem 299 gemeldet werden.
-
Zusätzlich zu der Verarbeitung der Daten bewirkt dieses System, dass ein Sprachanruf 212 an einen Backend-Pannenhilfeanbieter eingeleitet wird, so dass Informationen zwischen dem Dienstanbieter und einem Kunden/Fahrzeug ausgetauscht werden können.
-
3A–3C zeigen Anschauungsbeispiele für Pannenhilfe-Anforderungsabwicklungsprozesse.
-
Zum Beispiel zeigt 3A eine beispielhafte Ausführungsform eines Prozesses für ein VCS (oder ein ähnliches Datenverarbeitungssystem, etwa auf einer drahtlosen Vorrichtung oder entfernt, das als Reaktion auf eine Anforderung von dem VCS handelt), das eine Pannenhilfeanforderung abwickelt. In diesem beispielhaften Prozess detektiert das Datenverarbeitungssystem 301 eine Aktivierung (manuell oder automatisch) einer Pannenhilfeanforderung 301.
-
Als Reaktion auf die Aktivierung kontaktiert das System zuerst ein zwischengeschaltetes System 303 und sammelt Fahrzeugdaten 305 zur Weiterleitung zu dem zwischengeschalteten System. Wie mit Bezug auf 2A–2E zu sehen war, können die zu dem zwischengeschalteten System weitergeleiteten Daten danach zu einem entfernten Dienstanbieter gesendet werden, der die Pannenhilfsanforderung entsendet.
-
Die relevanten gesammelten Fahrzeugdaten werden dann zu dem zwischengeschalteten System 307 gesendet und es wird eine zweite Verbindung mit dem entfernten Pannenhilfe-Dienstanbieter 309 hergestellt. Diese Verbindung kann verwendet werden, um Informationen zwischen einem Kunden/Fahrzeug und einem Pannenhilfeanbieter zu übermitteln. In diesem Beispiel wird eine Mobilidentifikationsnummer (MIN) zu dem Pannenhilfeanbieter 311 gesendet. Diese MIN wurde auch zuvor zu dem zwischengeschalteten System gesendet und wird zusammen mit den durch den Pannenhilfeanbieter empfangenen Fahrzeugdaten weitergeleitet. Auf diese Weise kann der Anrufer mit den ankommenden Fahrzeugdiagnostikdaten korreliert werden und die MIN und eine VIN (die mit den Diagnostikdaten assoziiert ist), können verwendet werden, um kundenbezogene Daten-Dateien nachzuschlagen, um Dienstgrad, Berechtigung und Fahrzeugwartung und Status zu bestimmen.
-
Dann kann der Kunde relevante Fahrzeughilfsdaten empfangen. Diese Daten könnten einfach nur darin bestehen, dass ein Betreiber den Kunden über eine Entsendung informiert, und könnten auch, aber ohne Beschränkung darauf, Daten zur Verarbeitung durch das VCS, Berechtigungs-/Unberechtigungsinformationen, vorhergesagte Fahrzeugprobleme/Diagnostikanalyse usw. umfassen.
-
Wenn Daten zur Verarbeitung durch das VCS empfangen werden, kann ein Fahrzeugdisplay dann einen oder mehrere Aspekte der vorhergesagten Fahrzeughilfe 315 anzeigen. Zum Beispiel und ohne Beschränkung könnte das Display eine geschätzte Dienstankunftszeit oder einen Timer anzeigen. Dieser Timer könnte sogar aktualisiert werden, wenn ein Techniker näher kommt, um einen Kunden wissen zu lassen, sich nicht von dem Fahrzeug zu entfernen (wenn das Fahrzeug zum Beispiel in der Nähe eines Restaurants oder einer gewissen anderen „Ablenkung“ angehalten hat). Zusätzlich oder als Alternative könnte das Display verwendet werden, um Informationen zu zeigen, die beim Lösen von „einfachen“ Fahrzeugproblemen benutzbar sind.
-
Wenn zum Beispiel ein Kunde an einem unbekannten Ort gefahren ist und ihm das Benzin ausgegangen ist, kann das Fahrzeug in der Nähe einer Tankstelle, aber außerhalb ihrer Sicht, angehalten haben. Sobald die Pannenhilfe entsendet wurde oder zumindest das Problem diagnostiziert wurde, können Informationen in Bezug auf eine in der Nähe befindliche Tankstelle gezeigt werden. Dadurch kann der Benutzer die Option erhalten, einfach zu laufen, um Benzin zu holen, statt auf Hilfe zu warten. Oder der Benutzer könnte wählen, für Essen/Unterbringung (was durch das Display gezeigt werden kann) zu einem nahegelegenen Ort zu laufen und die Verbindung oder das Display verwenden, um das Pannenhilfepersonal zu informieren, dass der Benutzer an diesem Ort getroffen werden möchte.
-
3B zeigt ein Anschauungsbeispiel für einen Pannenhilfe-Anrufbearbeitungsprozess (der auch mindestens teilweise durch ein zwischengeschaltetes System ausgeführt werden kann). In diesem Beispiel wird ein Anruf von einem Fahrzeug/Fahrzeugdatenverarbeitungssystem empfangen und der Anruf umfasst eine Kennung (in diesem Fall eine MIN). Zusätzlich empfängt die Verarbeitungszentrale Fahrzeugdaten von einem zwischengeschalteten System 323, wobei die Daten von dem zwischengeschalteten System weitergeleitet wurde, nachdem das System die Daten von dem Fahrzeug empfangen hat. Unter Verwendung von aus dem Anruf und/oder von dem zwischengeschalteten System weitergeleiteten Daten empfangenen Daten wird die Berechtigung eines Benutzers für Hilfe bestimmt 325.
-
Wenn der Benutzer nicht für Dienst berechtigt ist, kann eine Verweigerungsnachricht zurückgegeben werden 329. Wenn der Benutzer dagegen berechtigt ist 327, kann eine Diagnose etwaiger wahrscheinlicher Probleme durchgeführt werden 331 (wenn die Diagnose nicht bereits durchgeführt wurde oder die Diagnose bestätigt werden kann). Relevante Daten, die durch den Prozess als Reaktion auf den ankommenden Hilfeanruf entweder empfangen oder gesammelt wurden, können dann zu einem Servicetechniker weitergeleitet werden, der dem Fahrzeug hilft 335.
-
3C zeigt ein Anschauungsbeispiel für einen anderen Backend-Prozess. In diesem Beispiel wurde die Berechtigung des Kunden bereits bestätigt, zum Beispiel durch ein zwischengeschaltetes System. Der Prozess empfängt hier eine Pannenhilfeanforderung 341. Zusammen mit der Anforderung wird zur Verwendung als Kundenkennung auch eine MIN empfangen 343. Wie erwähnt, kann dies verwendet werden, um die Anforderung 345 mit existierenden entfernten Daten und mit von einem zwischengeschalteten System empfangenen Daten zu vergleichen. Nachdem der Kunde identifiziert ist, können relevante Fahrzeugdaten, die mit dem Kunden und/oder der Anforderung korrelieren, zur Analyse/Weiterleitung abgerufen werden 347. Dann kann geeignetes Personal zu dem Kunden entsendet werden 249, und hilfebezogene Daten können gegebenenfalls zu Personal und/oder einem Kundenfahrzeug/Kunden 351 gesendet werden.
-
4 zeigt ein Anschauungsbeispiel für einen Pannenhilfeanforderungs-Verarbeitungsprozess. In diesem Anschauungsbeispiel leitet ein Fahrzeugdatenverarbeitungssystem nicht automatisch einen Anruf an eine Pannenhilfezentrale ein, nachdem Daten zu einem zwischengeschalteten System weitergeleitet wurden. Stattdessen kann zuerst durch das zwischengeschaltete System als Reaktion auf eine empfangene Hilfeübermittlung Berechtigung bestimmt werden 401 (was sowohl Fahrzeugdaten als auch Anrufweiterleitungsdaten umfassen kann). Wenn bestimmt wird, dass das Fahrzeug für Service berechtigt ist, kann das zwischengeschaltete System anweisen, dass ein sekundärer Anruf an eine Pannenhilfezentrale eingeleitet wird 403. Ein solcher Prozess kann dabei helfen, die ankommende Anruflast einer Pannenhilfezentrale zu vermindern, oder erlaubt das Einleiten von Anrufen an Zentralen, denen Verifikationsfähigkeit fehlt.
-
5 zeigt ein Anschauungsbeispiel für einen Pannenhilfe-Aktualisierungsprozess. In diesem Anschauungsbeispiel ist ein Fahrzeug in der Lage, Daten in Bezug auf eine ablaufende Anforderung zu empfangen 501. Lediglich für die Zwecke des Beispiels umfassen die Daten eine hilfebezogene Telefonnummer (wie etwa eine Telefonnummer von Hilfspersonal) und eine geschätzte Ankunftszeit. Die relevante Telefonnummer 503 und Ankunftszeit (oder Timer) 505 werden zum Beispiel auf einem Fahrzeug-Infotainment-System angezeigt. Dies kann dem Kunden dabei helfen, zu bestimmen, wann Hilfe ankommen sollte, und kann dem Kunden ein Mittel zum Kontaktieren des Hilfepersonals geben, wenn sich eine Situation ändert.
-
Wenn die Zeit vergangen ist oder ein Timer abläuft 507, kann der Prozess einen automatischen Anruf 509 entweder an ein Dienstpersonal oder eine Pannenhilfezentrale einleiten 509. Zusätzlich oder als Alternative kann eine automatisierte Erinnerung (Text, Datenpaket, Email usw.) zu einer oder mehreren dienstbezogenen Quellen gesendet werden 511. Als Reaktion auf die Erinnerung und/oder den Anruf können aktualisierte Hilfedaten 501 empfangen werden, und der Prozess kann von Neuem beginnen.
-
Wenn zum Beispiel Hilfepersonal im Verkehr feststeckt, könnte dieser Prozess dazu dienen, hilfebezogene Daten an einen Kunden automatisch weiterzuleiten und zu aktualisieren, ohne zu verursachen, dass der Kunde Anrufe tätigen, in einer Schleife warten muss usw.
-
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 Patentliteratur
-
-
Zitierte Nicht-Patentliteratur
-
- IEEE 802 PAN [0021]
- IEEE 802 LAN [0021]
- IEEE 802 PAN [0021]
- IEEE 1394 (Firewire), serielle Protokolle der EIA (Electronics Industry Association) [0024]
- IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) [0024]
