DE102015104094A1

DE102015104094A1 - Telematik mit variabler Berichtsfrequenz

Info

Publication number: DE102015104094A1
Application number: DE102015104094.8A
Authority: DE
Inventors: David Chronowski; Kevin Michael Bullister
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-03-25
Filing date: 2015-03-19
Publication date: 2015-10-01
Also published as: CN104954420B; US20150279125A1; CN104954420A

Abstract

Ein Fahrzeugsteuergerät kann, gemäß von dem Steuergerät unterhaltenen Berichtseinstellungen, Fahrzeugdaten sammeln, die sich auf das Funktionieren mindestens eines Fahrzeugsystems beziehen; die Fahrzeugdaten gemäß einer Berichtsfrequenz, die durch die Berichtseinstellungen spezifiziert ist, an einen Server senden; und als Reaktion auf den Empfang eines Befehls, der dafür ausgelegt ist, das mindestens eine Steuergerät zum Anpassen der Berichtseinstellungen zu veranlassen, die Berichtseinstellungen aktualisieren. Ein System kann einen Server beinhalten, der dafür ausgelegt ist, Fahrzeugdaten von einem Fahrzeug zu erhalten; eine fahrzeugbezogene Triggerbedingung zu identifizieren; die Triggerbedingung gemäß den empfangenen Fahrzeugdaten auszuwerten; als Reaktion auf das Auftreten einer Triggerbedingung einen Befehl auszugeben, der dafür ausgelegt ist, Berichtseinstellungen, die von dem Fahrzeug zum Bereitstellen der Fahrzeugdaten für den Server verwendet werden, anzupassen; und den Befehl an das Fahrzeug zu senden.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen beziehen sich allgemein auf ein Verfahren und eine Vorrichtung zum Verwenden einer variablen Berichtsfrequenz zum Bereitstellen von Telematikinformationen.
HINTERGRUND
Fahrzeugtelematikeinheiten können dafür verwendet werden, es einem Benutzer zu ermöglichen, mit über ein Kommunikationsnetzwerk verfügbaren Diensten zu interagieren. Diese Dienste können Punkt-zu-Punkt-Wegbeschreibungen, Telefonkommunikation, Fahrzeugüberwachung und Pannenhilfe beinhalten. In manchen Fällen können die Telematikdienste durch den Fahrzeug- oder Telematikeinheithersteller bereitgestellt werden, während die Dienste in anderen Fällen durch einen Drittanbieter von Telematikdiensten bereitgestellt werden können.
KURZE DARSTELLUNG DER ERFINDUNG
Ein System beinhaltet in einer ersten veranschaulichenden Ausführungsform mindestens ein Steuergerät eines Fahrzeugs, das dafür ausgelegt ist, eine auslösende Triggerbedingung für eine erhöhte Fahrzeugdaten-Berichtsfrequenz zu einem entfernten Telematikdienstanbieter zu identifizieren; als Reaktion auf die auslösende Triggerbedingung eine Telematikberichtsfrequenz von einer Standardfrequenz auf eine höhere Frequenz zu aktualisieren; eine beendende Triggerbedingung zu identifizieren, bei der die erhöhte Berichtsfrequenz nicht länger benötigt wird, und die Telematikberichtsfrequenz zurück zur Standardfrequenz zu aktualisieren.
Ein System beinhaltet in einer zweiten veranschaulichenden Ausführungsform einen Server, der dafür ausgelegt ist, Fahrzeugdaten von einem Fahrzeug zu erhalten; eine fahrzeugbezogene Triggerbedingung zu identifizieren; die Triggerbedingung gemäß den empfangenen Fahrzeugdaten auszuwerten; als Reaktion auf das Auftreten einer Triggerbedingung einen Befehl auszugeben, der dafür ausgelegt ist, Berichtseinstellungen, die von dem Fahrzeug zum Bereitstellen der Fahrzeugdaten für den Server verwendet werden, anzupassen; und den Befehl an das Fahrzeug zu senden.
Ein System beinhaltet in einer dritten veranschaulichenden Ausführungsform ein Fahrzeugsteuergerät, das dafür ausgelegt ist, Fahrzeugdaten zu sammeln, die auf das Funktionieren eines Fahrzeugsystems gemäß von dem Steuergerät unterhaltenen Berichtseinstellungen bezogen sind; die Fahrzeugdaten gemäß einer berichtseinstellungsspezifizierten Berichtsfrequenz an einen Server zu senden; und als Reaktion auf den Empfang eines Befehls, der dafür ausgelegt ist, das Steuergerät zum Anpassen der Berichtseinstellungen zu veranlassen, die Berichtseinstellungen zu aktualisieren.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem für ein Fahrzeug;
2 veranschaulicht ein beispielhaftes Telematiksystem einschließlich eines entfernten Telematikdienstanbieters, der über ein Netzwerk mit dem fahrzeugbasierten Computersystem des Fahrzeugs in Kommunikation steht;
3 veranschaulicht einen beispielhaften Prozess zum Bereitstellen von Telematikaktualisierungsbefehlen mit variabler Frequenz für das fahrzeugbasierte Computersystem des Fahrzeugs; und
4 veranschaulicht einen beispielhaften Prozess zum Bereitstellen von Telematikfahrzeugdaten mit variabler Frequenz von dem fahrzeugbasierten Computersystem zu dem entfernten Telematikdienstanbieter.
AUSFÜHRLICHE BESCHREIBUNG
Wie erforderlich, werden hier detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgestaltet werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Details von bestimmten Komponenten zu zeigen. Die speziellen strukturellen und funktionalen Details, die hier offenbart werden, sollen daher nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einem Fachmann zu lehren, wie die vorliegende Erfindung auf verschiedene Weise auszuüben ist.
Ein fahrzeugbasiertes Computersystem (VCS), wie eine Fahrzeugtelematikeinheit, kann dafür ausgelegt sein, Fahrzeugdaten zu akkumulieren, die Fahrzeugdaten in einigen Fällen mittels Bordberechnungen zu verarbeiten, und die akkumulierten und verarbeiteten Daten periodisch bei einem entfernten Telematikdienstanbieter abzuladen. Die abgeladenen Fahrzeugdaten können ferner mit zusätzlichen Informationen, wie aktuellen Fahrzeugbedingungen und Standort, verbessert werden. Die Frequenz des Datenabladens sowie die einzuschließenden Elemente der Fahrzeugdaten können ausgelegt sein, um mit dem Abladen von Fahrzeugdaten assoziierte Kosten (wie Mobilfunkgebühren und Batterieverbrauch) mit dem Nutzen des Bereitstellens der Fahrzeugdaten mit erhöhter Detailgenauigkeit abzuwägen.
Unter einigen Fahrzeugbetriebsbedingungen oder -anwendungen kann es wünschenswert sein, mehr Einsicht in den Fahrzeugbetrieb zu liefern als während anderen Bedingungen. Als eine Möglichkeit kann eine erhöhte Frequenz von Fahrzeugdaten, die während einer Notfallverfolgung von einem Polizeifahrzeug an einen entfernten Telematikdienstanbieter geliefert werden, nützlich sein. Als eine weitere Möglichkeit kann eine erhöhte Frequenz von Fahrzeugdaten für ein Fahrzeug, für das ein Ereigniscode gesetzt wurde, nützlich sein. Als noch eine weitere Möglichkeit kann ein Flottenmanager zusätzliche Fahrzeuginformationen wünschen, wenn ein Fahrzeug außerhalb eines vorspezifizierten geographischen Gebiets oder einer vorspezifizierten Zeit betrieben wird. Zu dem Beispiel einer Polizeiverfolgung zurückkehrend kann eine Notfallkommandozentrale wünschen, über den entfernten Telematikdienstanbieter einen Videostream von einer Armaturenbrettkamera zu empfangen, während das Fahrzeug eine Verfolgung vornimmt.
Um, wenn benötigt, das Liefern zusätzlicher Fahrzeugdaten zu ermöglichen und auch Ressourcen zu sparen, kann das VCS dafür ausgelegt sein, Telematikfunktionalität mit variabler Berichtsfrequenz bereitzustellen. Basierend auf den Fahrzeugdaten können das VCS oder der entfernte Telematikdienstanbieter dafür ausgelegt sein, das Auftreten einer oder mehrerer Triggerbedingungen zu identifizieren. Als Reaktion auf das Auftreten der Triggerbedingungen können das VCS oder der entfernte Telematikdienstanbieter dafür ausgelegt sein, das VCS zu veranlassen, die von dem Fahrzeug verwendeten Berichtseinstellungen für das Liefern von Fahrzeugdaten an den entfernten Telematikdienstanbieter anzupassen. Als eine Möglichkeit kann der entfernte Telematikdienstanbieter ein Auftreten der Triggerbedingung identifizieren und kann die Fahrzeugberichtseinstellungen durch Ausgeben eines Befehls über eine Mobilfunkverbindung von dem entfernten Telematikdienstanbieter zu dem Fahrzeug anpassen. Als eine andere Möglichkeit kann das VCS das Auftreten von lokal gespeicherten Triggerbedingungen identifizieren und die Berichtseinstellungen lokal anpassen.
Eine auslösende Triggerbedingung kann Bedingungen beinhalten, die bei Erfüllen als Hinweis auf Fahrzeugsituationen dienen, für die erhöhte Berichterstattung wünschenswert sein kann. Das VCS kann dafür ausgelegt sein, bei Detektion einer auslösenden Triggerbedingung die Fahrzeugdatenberichtseinstellungen anzupassen, um eine Telematikberichtsfrequenz von einer ursprünglichen auf eine höhere Frequenz zu erhöhen, wodurch eine erhöhte Berichtsfrequenz zu dem Telematikdienstanbieter bereitgestellt wird. Als ein Beispiel kann eine auslösende Triggerbedingung Bedingungen beinhalten, die bei Erfüllen auf eine Notfallverfolgung hinweisen, wie Fahrzeugdynamikdaten und/oder entsprechende Werte für die Elemente, die auf eine Verfolgung hinweisen (zum Beispiel hohe g-Kräfte, Beschleunigung, Bremsen usw.). Als ein weiteres Beispiel kann eine auslösende Triggerbedingung Bedingungen beinhalten, die bei Erfüllen auf andere Fahrzeugsituationen hinweisen, für die erhöhtes Berichten wünschenswert sein kann, wie zum Beispiel bei Detektion von einer oder mehreren unüblichen Fahrzeugbetriebsbedingungen (zum Beispiel zu wenig Kraftstoff, eine Systemfehlfunktion usw.).
Eine beendende Triggerbedingung kann Bedingungen beinhalten, die bei Erfüllen als Hinweis auf Fahrzeugsituationen dienen, für die erhöhte Berichterstattung nicht mehr wünschenswert sein kann. Das VCS kann dafür ausgelegt sein, bei Detektion einer beendenden Triggerbedingung die Fahrzeugdatenberichtseinstellungen auf die Standardeinstellungen zurückzusetzen. Die beendenden Triggerbedingungen können als einige Beispiele (i) ein Timeout, (ii) einen Aufhebungsbefehl, der von einem Fahrzeuginsassen empfangen wurde, (iii) einen Aufhebungsbefehl, der automatisch durch das mindestens eine Steuergerät basierend auf vorbestimmten Bedingungen (zum Beispiel Fahrzeugschlüssel aus, Verstreichen eines Timeouts seit der auslösenden Triggerbedingung, verringerte Geschwindigkeit/Bremsen) erzeugt wurde, und (iv) einen Aufhebungsbefehl, der von dem entfernten Telematikdienstanbieter empfangen wurde, beinhalten.
Zusätzlich zu den Variationen der Berichtsfrequenz kann die Telematikeinheit dafür ausgelegt sein, während eines Modus erhöhter Berichtsfrequenz im Gegensatz zu dem Standardmodus der Berichtsfrequenz mehr oder weniger oder unterschiedliche Informationen bereitzustellen. Zum Beispiel kann die Telematikeinheit basierend auf gewissen Triggerkriterien dafür ausgelegt sein, damit zu beginnen, einen Videostream zu dem entfernten Telematikdienstanbieter zu liefern (zum Beispiel von einer Armaturenbrettkamera eines Fahrzeugs, während das Fahrzeug eine Verfolgung durchführt). Dementsprechend kann eine Telematikeinheit eine variable Berichtsfrequenzfunktionalität verwenden, um die Frequenz und den Inhalt einer Datenübertragung von der Telematikeinheit des Fahrzeugs zu dem entfernten Telematikdienstanbieter anzupassen, um mit dem Mobilfunk-Abladen von Fahrzeugdaten assoziierte Kosten mit dem Nutzen des Bereitstellens der Fahrzeugdaten mit erhöhter Detailgenauigkeit, während definierter Triggerbedingungen, abzuwägen.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (VCS für engl. vehicle-based computing system) für ein Fahrzeug 31. Ein Beispiel für solch ein fahrzeugbasiertes Computersystem 1 ist das von der FORD MOTOR COMPANY hergestellte SYNC-System. Ein mit einem fahrzeugbasierten Computersystem ausgestattetes Fahrzeug kann eine visuelle Front-End-Schnittstelle 4 enthalten, die sich im Fahrzeug 31 befindet. Der Benutzer ist möglicherweise außerdem in der Lage, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch Tastendrücke, Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der in 1 dargestellten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 oder eine zentrale Verarbeitungseinheit 3 (CPU, central processing unit) wenigstens einen Teil des Betriebs des fahrzeugbasierten Computersystems. Der Prozessor 3, der innerhalb des Fahrzeugs 31 vorgesehen ist, ermöglicht Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor 3 sowohl mit einem nicht-persistenten 5 als auch mit einem persistenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nicht-persistente Speicher 5 ein Direktzugriffspeicher (RAM, random access memory) und der persistente Speicher 7 ein Festplattenlaufwerk (HDD, hard disk drive) oder Flash-Speicher. Im Allgemeinen kann ein persistenter (nichtflüchtiger) Speicher 7 alle Arten von Speicher umfassen, welche Daten speichern, wenn ein Computer oder ein anderes Gerät ausgeschaltet wird. Diese umfassen, ohne darauf beschränkt zu sein, HDDs, CDs (compact disks), DVDs (digital versatile disks), Magnetbänder, Festkörperlaufwerke, tragbare USB(universal serial bus)-Laufwerke und andere geeignete Arten von persistentem Speicher 7.
Der Prozessor 3 ist außerdem mit einer Anzahl von unterschiedlichen Eingängen versehen, die es dem Benutzer ermöglichen, über eine Schnittstelle mit dem Prozessor 3 in Verbindung zu treten. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine berührungsempfindliche Anzeige sein kann, und ein BLUETOOTH-Eingang 15 vorgesehen. Es ist auch ein Eingangswähler 51 vorgesehen, der es einem Benutzer ermöglicht, zwischen verschiedenen Eingängen zu wechseln. Sowohl die Eingaben in das Mikrofon als auch in den Hilfsanschluss werden von einem Wandler 27 von analog in digital umgewandelt, bevor sie an den Prozessor 3 weitergeleitet werden. Obwohl nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS 1 ein Fahrzeugnetz (wie beispielsweise, ohne darauf beschränkt zu sein, einen CAN(car area network)-Bus) verwenden, um Daten zum und vom VCS 1 (oder Komponenten davon) weiterzuleiten.
Ausgaben an das VCS-System 1 können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereo-Systemausgang umfassen, ohne darauf beschränkt zu sein. Der Lautsprecher 13 ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 durch einen Digital-Analog-Wandler 9. Außerdem kann entlang der bei 19 bzw. 21 dargestellten bidirektionalen Datenströme auch eine Ausgabe an ein entferntes BLUETOOTH-Gerät, wie beispielsweise ein persönliches Navigationsgerät (PND, personal navigation device) 54, oder ein USB-Gerät, wie beispielsweise ein Fahrzeug-Navigationsgerät 60, erfolgen.
In einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Transceiver 15 zum Kommunizieren 17 mit einem mobilen Gerät (ND, nomadic device) 53 (z. B. einem Mobiltelefon, Smartphone, PDA oder einem beliebigen anderen Gerät mit drahtloser Fernnetzkonnektivität). Das mobile Gerät 53 kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen dem mobilen Gerät 53 und dem BLUETOOTH-Transceiver ist durch Kommunikation 14 dargestellt.
Das Koppeln eines mobilen Geräts 53 und des BLUETOOTH-Transceivers 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU davon unterrichtet, dass der Onboard-BLUETOOTH-Transceiver 15 mit einem BLUETOOTH-Transceiver in einem mobilen Gerät 53 gekoppelt werden wird.
Daten können zum Beispiel unter Verwendung eines Datentarifs, Data-over-Voice oder von Zweiton-Mehrfrequenz(DTMF, dual-tone multiple frequency)-Tönen, die mit dem mobilen Gerät 53 assoziiert sind, zwischen der CPU 3 und dem Netz 61 kommuniziert werden. Alternativ kann es wünschenswert sein, ein Onboard-Modem 63 mit einer Antenne 18 einzubauen, um Daten zwischen der CPU 3 und dem Netz 61 über das Sprachband zu kommunizieren 16. Das mobile Gerät 53 kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netz 61 aufbauen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein zellulares USB-Modem 63 sein, und die Kommunikation 20 kann zellulare Kommunikation sein.
In einer beispielhaften Ausführungsform ist der Prozessor 3 mit einem Betriebssystem versehen, das eine API zum Kommunizieren mit Modem-Anwendungssoftware beinhaltet. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder eine eingebettete Firmware auf dem BLUETOOTH-Transceiver zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie zum Beispiel einem, der in einem mobilen Gerät vorzufinden ist) herzustellen. Bluetooth ist ein Teilsatz der Kurzstreckennetz(PAN, personal area network)-Protokolle gemäß IEEE (Institute of Electrical and Electronics Engineers) 802. IEEE 802 LAN(local area network)-Protokolle umfassen WiFi (wireless fidelity) und weisen erhebliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind zur drahtlosen Kommunikation innerhalb eines Fahrzeugs 31 geeignet. Andere Kommunikationsmittel, die auf diesem Gebiet verwendet werden können, sind optische Freiraumkommunikation (wie zum Beispiel IrDA, infrared data association) und nicht-standardisierte IR(Infrarot)-Protokolle im Bereich der Unterhaltungselektronik.
In einer anderen Ausführungsform umfasst das mobile Gerät 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. In der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplex bekannte Technik implementiert sein, wenn der Besitzer des mobilen Geräts 53 über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Besitzer das Gerät nicht verwendet, kann die Datenübertragung die gesamte Bandbreite verwenden (in einem Beispiel 300 Hz bis 3,4 kHz). Obwohl Frequenzmultiplex möglicherweise für analoge zellulare Kommunikation zwischen dem Fahrzeug 31 und dem Internet üblich ist und immer noch verwendet wird, wurde es für digitale zellulare Kommunikation weitgehend durch Mischformen aus Codemultiplexzugriff (CDMA, Code Division Multiple Access), Zeitmultiplexzugriff (TDMA, Time Division Multiple Access), Raummultiplexzugriff (SDMA, Space Division Multiple Access) ersetzt. Diese sind allesamt ITU IMT-2000(G3)-konforme Standards und bieten Datenraten bis zu 2 Mbit/s für stationäre oder gehende Benutzer und 385 kbit/s für Benutzer in einem fahrenden Fahrzeug 31. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, der 200 Mbit/s für Benutzer in einem Fahrzeug 31 und 1 Gbit/s für stationäre Benutzer bietet. Falls der Benutzer über einen mit dem mobilen Gerät 53 assoziierten Datentarif verfügt, ist es möglich, dass der Datentarif Breitband-Übertragung ermöglicht und das System eine viel breitere Bandbreite verwenden könnte (was die Datenübertragung beschleunigt). In noch einer anderen Ausführungsform ist das mobile Gerät 53 durch ein zellulares Kommunikationsgerät (nicht dargestellt) ersetzt, das im Fahrzeug 31 installiert ist. In einer weiteren anderen Ausführungsform kann das ND 53 ein drahtloses LAN-Gerät sein, das zum Beispiel (und ohne Beschränkung) zur Kommunikation über ein 802.11g-Netz (d. h. WiFi) oder ein WiMax-Netz in der Lage ist.
In einer Ausführungsform können eingehende Daten durch das mobile Gerät 53 über Data-over-Voice oder Datentarif, durch den Onboard-BLUETOOTH-Transceiver und in den Prozessor 3 des Fahrzeugs 31 weitergeleitet werden. Im Falle bestimmter temporärer Daten zum Beispiel können die Daten bis zu einem Zeitpunkt, zu dem die Daten nicht mehr benötigt werden, auf der HDD oder anderen Speichermedien 7 gespeichert werden.
Zusätzliche Quellen, die über eine Schnittstelle mit dem Fahrzeug 31 verbunden sein können, beinhalten ein PND 54 zum Beispiel mit einem USB-Anschluss 56 und/oder einer Antenne 58, ein Fahrzeug-Navigationsgerät 60 mit einem USB 62- oder einem anderen Anschluss, ein Onboard-GPS-Gerät 24 oder ein Fernnavigationssystem (nicht dargestellt) mit Konnektivität zum Netz 61. USB ist eines aus einer Klasse von seriellen Netzprotokollen. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), EIA (Electronics Industry Association) serielle Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der Standards für serielle Kommunikation von Gerät zu Gerät. Die meisten der Protokolle können entweder für elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU 3 mit einer Vielzahl anderer Hilfsgeräte 65 in Kommunikation sein. Diese Geräte 65 können durch eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden sein. Die Zusatzgeräte 65 können Personal Media Player, drahtlose medizinische Geräte, tragbare Computer und dergleichen beinhalten, ohne darauf beschränkt zu sein.
Außerdem oder alternativ könnte die CPU 3 zum Beispiel unter Verwendung eines WiFi-Transceivers (IEEE 803.11) 71 mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein. Dies könnte es der CPU 3 ermöglichen, sich an entfernte Netze innerhalb des Bereichs des lokalen Routers 73 anzuschließen.
Zusätzlich dazu, dass in bestimmten Ausführungsformen beispielhafte Prozesse von einem Fahrzeug-Computersystem ausgeführt werden, das sich in einem Fahrzeug 31 befindet, können die beispielhaften Prozesse wenigstens zum Teil von einem oder mehreren Computersystemen außerhalb eines Fahrzeug-Computersystems und in Kommunikation damit ausgeführt werden. Solch ein System kann, ohne darauf beschränkt zu sein, ein drahtloses Gerät (z. B. und ohne Beschränkung ein Mobiltelefon) oder ein entferntes Computersystem (z. B. und ohne Beschränkung einen Server) umfassen, die durch das drahtlose Gerät verbunden sind. Gemeinschaftlich können solche Systeme als fahrzeugassoziierte Computersysteme (VACS, Vehicle Associated Computing Systems) bezeichnet werden. In bestimmen Ausführungsformen können bestimmte Komponenten des VACS abhängig von der jeweiligen Implementierung des Systems bestimmte Teile eines Prozesses ausführen. Falls ein Prozess als Beispiel und ohne Beschränkung einen Schritt des Sendens oder Empfangens von Informationen an ein gekoppeltes Gerät bzw. von einem gekoppelten Gerät umfasst, dann ist es wahrscheinlich, dass das drahtlose Gerät den Prozess nicht durchführt, weil das drahtlose Gerät keine Informationen an und von sich selbst senden und empfangen würde. Ein Durchschnittsfachmann weiß, wann es unangemessen ist, ein bestimmtes VACS auf eine gegebene Lösung anzuwenden. Bei allen Lösungen wird in Betracht gezogen, dass wenigstens das VCS 1, das sich innerhalb des Fahrzeugs 31 selbst befindet, zum Durchführen der beispielhaften Prozesse in der Lage ist.
2 veranschaulicht ein beispielhaftes Telematiksystem 200 einschließlich eines entfernten Telematikdienstanbieters 206, der über ein Netz 61 mit dem VCS 1 des Fahrzeugs 31 in Kommunikation steht. Das VCS 1 kann dafür ausgelegt sein, Fahrzeugdaten 202 gemäß den aktuellen Berichtseinstellungen 204 über das Netz 61 an den Telematikdienstanbieter 206 zu liefern. Der Telematikdienstanbieter 206 kann dafür ausgelegt sein, die Fahrzeugdaten 202 zu empfangen und zu unterhalten sowie eine oder mehrere Triggerbedingungen 208 zu unterhalten. Basierend auf dem Erfüllen verschiedener Triggerbedingungen 208, die von dem Telematikdienstanbieter 206 unterhalten werden, kann das VCS 1 ferner dafür ausgelegt sein, von dem entfernten Telematikdienstanbieter 206 erzeugte Befehle 210 über das Netz 61 zu empfangen, wobei die Befehle 210 dafür ausgelegt sind, die Fahrzeugberichtseinstellungen 204 zu ändern. Zusätzlich oder alternativ kann das VCS 1 dafür ausgelegt sein, die aktuellen Berichtseinstellungen 204 lokal anzupassen, basierend auf dem Erfüllen verschiedener Triggerbedingungen 208, die lokal von dem Fahrzeug 31 gespeichert werden.
Die Fahrzeugdaten 202 können verschiedene Informationselemente beinhalten, die über einen Fahrzeugbus oder -netz (zum Beispiel den CAN-Bus) erhältlich sind, was für Analysen nützlich sein kann. Zum Beispiel können die Fahrzeugdaten 202 von Fahrzeugsystemen wie Fahrzeugstabilitäts-/Traktionssteuerung, Antriebsstrang und Fahrerassistenz gesammelte Daten beinhalten. Beispielhafte Fahrzeugdaten 202 können dementsprechend Werte beinhalten, die von Fahrzeugsystemen wie Fahrzeuggeschwindigkeit, Lenkradwinkel, Vertikalverschiebung, Vertikalgeschwindigkeit, Gierraten, Querbeschleunigung, Stampfwinkel, Stampfrate, Fahrzeugschlupfwinkel, Rollwinkel, Rollrate, Radschlupf-/Raddurchdrehbedingungen, Fahrerdrehmoment, angewendetes Antriebsraddrehmoment, angewendeter Bremsdruck, verbleibender Krafstoff und Einsatz von Warnblinkanlage oder Sirenen abgerufen werden können, um einige nicht einschränkende Beispiele zu nennen. Die Fahrzeugdaten 202 können auch andere Typen von Informationen bezüglich des Fahrzeugs 31 beinhalten, wie einen geographischen Fahrzeugstandort (zum Beispiel von einem Bord-GPS-System), Datums- und Zeitinformationen darüber, zu welcher Zeit die Fahrzeugdaten 202 gesammelt wurden und Informationen, die das sendende Fahrzeug 31 identifizieren, wie eine Fahrzeugidentifikationsnummer (VIN), eine IMEI des VCS 1 oder eine andere fahrzeugspezifische Kennung.
Die Berichtseinstellungen 204 können Informationen beinhalten, die darauf hinweisen, wie häufig die Fahrzeugdaten 202 gesammelt werden sollten sowie welche Informationen in den gesammelten Fahrzeugdaten 202 enthalten sein sollten. Als eine Möglichkeit können die Berichtseinstellungen 204 eine Frequenzeinstellung beinhalten, die auf eine Aktualisierungsfrequenz oder -periode zwischen dem Liefern von Aktualisierungen der Fahrzeugdaten 202 an den Telematikdienstanbieter 206 hinweisen. Zum Beispiel können die Berichtseinstellungen 204 eine Standardberichtsfrequenz beinhalten, die darauf hinweist wie häufig die Fahrzeugdaten 202 an den Telematikdienstanbieter 206 zu liefern sind, wenn keine Triggerbedingungen 208 aufgetreten sind, und eine höhere Berichtsfrequenz, die darauf hinweist, wie häufig die Fahrzeugdaten 202 an den Telematikdienstanbieter 206 zu liefern sind, wenn eine oder mehrere Triggerbedingungen 208 aufgetreten sind. Die Standard- oder Normalfrequenz kann zum Beispiel alle dreißig Sekunden, jede Minute, alle drei Minuten oder alle fünf Minuten sein, als einige nichteinschränkende Möglichkeiten. Die höhere Frequenz kann zum Beispiel alle drei Sekunden, alle fünf Sekunden, alle dreißig Sekunden oder eine andere Frequenz sein, die häufigere Aktualisierungen als die Standard- oder Normalberichtsfrequenz beinhaltet. In einigen Fällen kann die höhere Frequenz als ein Vielfaches der Standardfrequenz, wie zweimal so schnell oder fünfmal so schnell wie die Standardfrequenz, definiert sein.
Die Berichtseinstellungen 204 können ferner eine Auflistung von Werten der Fahrzeugdaten 202 enthalten, die in den periodischen Aktualisierungen enthalten sein sollen. In einigen Fällen können die Berichtseinstellungen 204 mehrfache Sätze von Einstellungen beinhalten, wie einen ersten Satz von Fahrzeugdaten 202, der bei jeder ersten Zeitperiode geliefert werden soll, und einen zweiten Satz von Fahrzeugdaten, der bei jeder zweiten Zeitperiode geliefert werden soll. Als eine andere Möglichkeit können die Berichtseinstellungen 204 einen Satz von Fahrzeugdaten 202 beinhalten, der ungeachtet des Modus mit der Standardfrequenz geliefert werden soll, und einen zweiten Satz von Fahrzeugdaten 202, der mit einer höheren Frequenz geliefert werden soll, wenn eine Triggerbedingung 208 erfüllt wurde.
Der Telematikdienstanbieter 206 kann eine oder mehrere Computervorrichtungen, wie Computer, eine mikroprozessorbasierte Anwendungsvorrichtung, eine Benutzer-Netzwerkvorrichtung oder Netzknoten beinhalten. Der Telematikdienstanbieter 206 kann dafür ausgelegt sein, Programme auf einem oder mehreren Prozessoren auszuführen, wobei die Programme auf einem oder mehreren Speichergeräten des Telematikdienstanbieters 206 gespeichert sind. Der Telematikdienstanbieter 206 kann ferner Netzwerkhardware beinhalten, die dafür ausgelegt ist, dem Telematikdienstanbieter 206 zu ermöglichen, mit den Fahrzeugen 31 über das Netz 61 zu kommunizieren. Als ein Beispiel kann der Telematikdienstanbieter 206 dafür ausgelegt sein, die Fahrzeugdaten 202 von den Fahrzeugen 31 über das Netz 61 zu erhalten. Obwohl das Netz 61 als ein einzelnes Netz 61 dargestellt ist, kann das Netz 61 in einigen Beispielen als mehrere separate Netze 61 implementiert sein, wie ein privates Netz 61, das den Telematikdienstanbieter 206 aufnimmt, der für Datentransport zwischen dem Telematikdienstanbieter 206 und den Fahrzeugen 31 mit einem öffentlichen Netz wie dem Internet verbunden ist.
Die Triggerbedingungen 208 können Informationen beinhalten, die auf Bedingungen hinweisen, die bei Erfüllen durch die Fahrzeugdaten 202 eine Änderung in den Berichtseinstellungen 204 des Fahrzeugs 31 veranlassen. Die Triggerbedingungen 208 können ferner Informationen beinhalten, die darauf hinweisen, wie die Berichtseinstellungen 204 basierend auf dem Erfüllen der Bedingungen modifiziert werden sollten. Der Telematikdienstanbieter 206 kann dafür ausgelegt sein, die Triggerbedingungen 208 zu unterhalten, die empfangenen Fahrzeugdaten 202 (oder andere erfasste Daten bezüglich der Fahrzeuge 31) gegen die Triggerbedingungen 208 auszuwerten, und Befehle 210 an das Fahrzeug 31 zu liefern, um das Fahrzeug 31 zu veranlassen, seine Berichtseinstellungen 204 zu aktualisieren, wie durch die Triggerbedingungen 208 spezifiziert.
Zum Beispiel können die Triggerbedingungen 208 auslösende Triggerbedingungen 208 beinhalten, die dafür ausgelegt sind, die Berichtseinstellungen 204 auf der Basis des Auftretens einer Situation, in der häufigere oder komplettere Berichte von Fahrzeugdaten 202 gewünscht werden, zu ändern. Als eine Möglichkeit können die Triggerbedingungen 208 Fahrzeugdaten 202 beinhalten, die eine oder mehrere dynamische Fahrzeugschwellen überschreiten, die auf eine Fahrzeugverfolgung hinweisen (zum Beispiel hohe g-Kräfte, Beschleunigung, Bremsen usw.). Als eine weitere Möglichkeit können die Triggerbedingungen 208 Fahrzeugdaten 202 beinhalten, die auf eine oder ungewöhnliche Betriebsbedingungen hinweisen (wie zum Beispiel zu wenig Kraftstoff, Systemfehlfunktion usw.).
Weiterhin können die Triggerbedingungen 208 auch beendende Triggerbedingungen 208 beinhalten, in denen die erhöhten Berichtseinstellungen 204 nicht mehr nötig sind. Als eine Möglichkeit können die beendenden Triggerbedingungen eine vorbestimmte Zeitdauer beinhalten, die seit dem Erfüllen der auslösenden Triggerbedingungen vergangen ist (zum Beispiel ein vorbestimmtes Timeout). Als einige weitere Möglichkeiten können beendende Triggerbedingungen einen Aufhebungsbefehl beinhalten, der von einem Insassen des Fahrzeugs 31 oder von dem Telematikdienstanbieter 206 oder dem Erfüllen einer oder mehrerer Bedingungen, wie Fahrzeugschlüssel aus, verringerte Geschwindigkeiten des Fahrzeugs 31 oder zurückhaltendem Abbremsen des Fahrzeugs 31 geliefert wird.
Die Befehle 210 können Informationen beinhalten, die, wenn sie von dem Fahrzeug 31 empfangen werden, das Fahrzeug 31 veranlassen können, seine Berichtseinstellungen 204 zu ändern. Zum Beispiel kann ein Befehl 210 aktualisierte Berichtseinstellungen 204 beinhalten, die von dem Fahrzeug 31 verwendet werden sollten (zum Beispiel eine aktualisierte Berichtsfrequenz, ein aktualisierter Satz von Fahrzeugdaten 202, zu liefernde Elemente usw.) Als eine weitere Möglichkeit kann der Befehl 210 einen Hinweis darauf spezifizieren, welcher Satz von Berichtseinstellungen 204, der von dem Fahrzeug 31 unterhalten wird, von dem Fahrzeug 31 verwendet werden sollte (zum Beispiel normaler Berichtsmodus, schnellerer Berichtsmodus usw.)
Der Datenspeicher 212 kann eine oder mehrere Speichereinrichtungen beinhalten, die dafür ausgelegt sind, Informationen für den Telematikdienstanbieter 206 zu unterhalten. Zum Beispiel kann der Datenspeicher 212 die von den Fahrzeugen 31 empfangenen Fahrzeugdaten 202, die zum Verarbeiten der Triggerbedingungen 208 verwendet werden, und die Triggerbedingungen 208, die zum Erstellen der Befehle 210 verwendet werden, unterhalten. Der Datenspeicher 212 kann ebenfalls zusätzliche Informationen speichern, wie welche Triggerbedingungen 208 mit welchen Fahrzeugen 31 assoziiert sind (zum Beispiel gemäß einer Fahrzeugkennung), welche Fahrzeuge mit welcher Flotte assoziiert sind (zum Beispiel Abbilden von Fahrzeugkennungen auf Flottenkennungen) und welche Triggerbedingungen 208 mit welchen Flotten assoziiert sind (zum Beispiel gemäß einer Flottenkennung). Dementsprechend kann der Datenspeicher 212 verwendet werden, um Triggerbedingungen 208, die mit Fahrzeugen 31 im Allgemeinen assoziiert sind, Triggerbedingungen 208, die mit Fahrzeugen 31 assoziiert sind, die ein Teil einer Flotte sind und/oder Triggerbedingungen 208, die mit bestimmten Fahrzeugen 31 assoziiert sind, zu speichern.
Der Datenspeicher 212 kann dafür ausgelegt sein, von einer Fahrzeugkennung abgefragt zu werden, und kann beliebige Triggerbedingungen 208 bereitstellen, die zu dem bestimmten Fahrzeug 31 oder Fahrzeugen 31 allgemein passen. Folglich können die abgerufenen Triggerbedingungen 208 beliebige allgemeine Triggerbedingungen 208, Flottentriggerbedingungen 208 und fahrzeugspezifische Triggerbedingungen 208 beinhalten. In einigen Fällen können die Triggerbedingungen 208 eine Hierarchie bilden, so dass inkonsistente Triggerbedingungen 208 durch andere Triggerbedingungen 208 mit Priorität aufgehoben werden können. Zum Beispiel können die Flottentriggerbedingungen 208 oder fahrzeugspezifische Triggerbedingungen 208 die allgemeinen Triggerbedingungen 208 aufheben und die fahrzeugspezifischen Triggerbedingungen 208 können die Flottentriggerbedingungen 208 aufheben (oder umgekehrt).
3 veranschaulicht einen beispielhaften Prozess 300 zum Bereitstellen von Telematikaktualisierungsbefehlen 210 mit variabler Frequenz für das VCS 1 des Fahrzeugs 31. Der Prozess 300 kann zum Beispiel durch den Telematikdienstanbieter 206 in Kommunikation mit dem VCS 1 des Fahrzeugs 31 über das Netz 61 durchgeführt werden. In anderen Ausführungsformen wird das Verfahren 300 möglicherweise in anderen Steuergeräten implementiert oder unter mehreren Steuergeräten aufgeteilt.
Bei Block 302 empfängt der Telematikdienstanbieter 206 Fahrzeugdaten 202 von dem Fahrzeug 31. Zum Beispiel kann der Telematikdienstanbieter 206 eine periodische Aktualisierung der Fahrzeugdaten 202 empfangen, die von dem Fahrzeug 31 gemäß den Berichtseinstellungen 204 des Fahrzeugs 31 gesendet wurden. Die Fahrzeugdaten 202 können wie oben erörtert Informationen von Fahrzeugsystemen beinhalten sowie andere Informationen, wie einen geographischen Fahrzeugstandort, Datums- und Zeitinformationen, während denen die Fahrzeugdaten 202 gesammelt wurden, und Informationen, die das sendende Fahrzeug 31 identifizieren.
Bei Block 304 identifiziert der Telematikdienstanbieter 206 Triggerbedingungen 208, die auf das Fahrzeug 31 anwendbar sind. Zum Beispiel kann der Telematikdienstanbieter 206 den Datenspeicher 212 unter Verwendung der Informationen von den Fahrzeugdaten 202, die das Fahrzeug 31 identifizieren, abfragen, um beliebige Triggerbedingungen 208, die mit dem Fahrzeug 31 assoziiert sind, abzurufen. Zusätzlich oder alternativ kann der Telematikdienstanbieter 206 den Datenspeicher 212 abfragen, um eine Flotte, die mit dem Fahrzeug 31 assoziiert ist, zu identifizieren, und kann beliebige Triggerbedingungen 208 abrufen, die mit der Flotte assoziiert sind, mit der das Fahrzeug 31 assoziiert ist. Als noch ein weiteres Beispiel kann der Telematikdienstanbieter 206 beliebige Triggerbedingungen 208, die im Allgemeinen auf alle Fahrzeuge 31 anwendbar sind, abrufen.
Beim Entscheidungsblock 306 bestimmt der Telematikdienstanbieter 206 basierend auf den empfangenen Fahrzeugdaten 202 und den anwendbaren Triggerbedingungen 208, ob beliebige der anwendbaren Triggerbedingungen 208 erfüllt oder abgelaufen sind. Zum Beispiel kann der Telematikdienstanbieter 206 die identifizierten Triggerbedingungen 208 basierend auf den abgerufenen Fahrzeugdaten 202 auswerten. Die Triggerbedingungen 208 können als einige Möglichkeiten eine Identifikation beinhalten, dass das Fahrzeug 31 in ein vorbestimmtes geographisches Gebiet eingefahren ist oder dieses verlassen hat und/oder dass das Fahrzeug 31 in einem vorbestimmten Zeitfenster betrieben wird. Als ein weiteres Beispiel kann der Telematikdienstanbieter 206 ferner auswerten, ob Ablaufen beliebiger vorheriger ausgelöster Triggerbedingungen 208 aufgetreten ist. Abgelaufene Triggerbedingungen 208 können als einige Möglichkeiten ein Timeout beinhalten, nach dem aktualisierte Berichtseinstellungen 204 zu Standardberichtseinstellungen 204 zurückkehren. Falls beliebige Triggerbedingungen 208 erfüllt oder abgelaufen sind, geht die Steuerung zu Block 308 weiter. Andernfalls geht die Steuerung zu Block 302 weiter.
Bei Block 308 erzeugt der Telematikdienstanbieter 206 Aktualisierungsbefehle 210 für Berichtseinstellungen 204. Zum Beispiel kann der Telematikdienstanbieter 206 einen oder mehrere Befehle 210 erstellen, die an das Fahrzeug 31 ausgegeben werden sollen, wobei die Befehle 210 beliebige Anpassungen der Berichtseinstellungen 204 beinhalten, die ausgeführt werden sollen, wie durch bestimmte Triggerbedingungen 208, die erfüllt oder abgelaufen sind, spezifiziert. Der/die Befehl(e) 210 können aktualisierte Berichtseinstellungen 204 beinhalten, die von dem Fahrzeug 31 verwendet werden sollten. Als eine weitere Möglichkeit kann/können der/die Befehl(e) einen Hinweis darauf spezifizieren, welcher Satz von Berichtseinstellungen 204, der von dem Fahrzeug 31 unterhalten wird, von dem Fahrzeug 31 verwendet werden sollte (zum Beispiel normaler Berichtsmodus, schnellerer Berichtsmodus usw.).
Bei Block 310 sendet der Telematikdienstanbieter 206 den/die Aktualisierungsbefehl(e) 210 für Berichtseinstellungen 204 an das Fahrzeug 31. Nach Block 310 geht die Steuerung zu Block 302 über.
4 veranschaulicht einen beispielhaften Prozess 400 zum Bereitstellen von Telematikfahrzeugdaten 202 mit variabler Frequenz von dem VCS 1 zu dem entfernten Telematikdienstanbieter 206. Der Prozess 400 kann zum Beispiel durch das VCS 1 des Fahrzeugs 31 in Kommunikation mit dem Telematikdienstanbieter 206 stehen. In anderen Ausführungsformen wird das Verfahren 400 möglicherweise in anderen Steuergeräten implementiert oder unter mehreren Steuergeräten aufgeteilt.
Bei Block 402 sammelt das VCS 1 die Fahrzeugdaten 202. Zum Beispiel kann das VCS 1 die Fahrzeugdaten 202 über einen Fahrzeugbus von Fahrzeugsystemen wie Fahrzeugstabilitäts-/Traktionssteuerung, Antriebsstrang und Fahrerassistenzinformationen sammeln. Die Fahrzeugdaten 202 können auch andere Typen von Informationen bezüglich des Fahrzeugs 31 beinhalten, wie einen geographischen Fahrzeugstandort (zum Beispiel von einem Bord-GPS-System), Datums- und Zeitinformationen darüber, zu welcher Zeit die Fahrzeugdaten 202 gesammelt wurden und Informationen, die das Fahrzeug 31 identifizieren, wie eine VIN oder eine IMEI. In einigen Fällen können die Berichtseinstellungen 204 eine Auflistung von Werten von Fahrzeugdaten 202 beinhalten, die in den periodischen Aktualisierungen enthalten sein müssen, und das VCS 1 kann bestimmen, welche Elemente von Fahrzeugdaten 202 gemäß den Berichtseinstellungen 204 gesammelt werden.
Bei Entscheidungsblock 404 bestimmt das VCS 1, ob die Fahrzeugdaten 202 an den Telematikdienstanbieter 206 geliefert werden sollen. Zum Beispiel können die Berichtseinstellungen 204 eine Frequenzeinstellung beinhalten, die auf eine Aktualisierungsperiode zwischen dem Liefern von Aktualisierungen der Fahrzeugdaten 202 an den Telematikdienstanbieter 206 hinweisen. Basierend auf den Frequenzeinstellungen kann das VCS 1 bestimmen, ob ein Timeout abgelaufen ist, so dass aktualisierte Fahrzeugdaten 202 an den Telematikdienstanbieter 206 geliefert werden sollten. Wenn dies der Fall ist, geht die Steuerung zu Block 306 weiter, um die nächste Aktualisierung von Fahrzeugdaten 202 durchzuführen. Ansonsten geht die Steuerung zu Block 302 weiter, um mit dem Sammeln von Fahrzeugdaten 202 fortzufahren.
Bei Block 406 sendet das VCS 1 die gesammelten Fahrzeugdaten 202 an den Telematikdienstanbieter 206. Zum Beispiel kann das VCS 1 die gesammelten Fahrzeugdaten 202 in einer oder mehreren Nachrichten and den Telematikdienstanbieter 206 liefern. Nach Block 406 geht die Steuerung zu Block 402 über.
Bei Entscheidungsblock 408 bestimmt das VCS 1, ob beliebige Triggerbedingungen 208, die von dem Fahrzeug 31 unterhalten werden, erfüllt wurden oder abgelaufen sind. Zum Beispiel kann das VCS 1 die unterhaltenen Triggerbedingungen 208 gemäß den gesammelten Fahrzeugdaten 202 auswerten. Die Auswertung der von dem Fahrzeug 31 unterhaltenen Triggerbedingungen 208 kann unabhängig von dem Liefern von Aktualisierungen der Fahrzeugdaten 202 zu dem Telematikdienstanbieter 206 durchgeführt werden. Die Triggerbedingungen 208 können als einige nichteinschränkende Beispiele beinhalten, dass Fahrzeugdynamikdaten, die von den Fahrzeugsystemen abgerufen wurden, darauf hinweisen, dass eine Verfolgung von dem Fahrzeug 31 durchgeführt wird, und/oder dass ungewöhnliche Bedingungen des Fahrzeugs 31, wie zu wenig Kraftstoff, oder ein Hinweis auf eine Fehlfunktion des Fahrzeugs 31, vorliegen. Ablaufen der Triggerbedingungen 208 kann als einige Möglichkeiten ein Timeout beinhalten, nach dem aktualisierte Berichtseinstellungen 204 zu Standardberichtseinstellungen 204 zurückkehren, und/oder einen Aufhebungsbefehl, der von dem Telematikdienstanbieter 206 (zum Beispiel von einem Flottenmanager) ausgegeben wurde, die aktualisierten Berichtseinstellungen 204 zurückzuziehen. Falls beliebige Triggerbedingungen 208 erfüllt oder abgelaufen sind, geht die Steuerung zu Block 410 weiter. Andernfalls verbleibt die Steuerung bei Entscheidungsblock 408.
Bei Block 410 aktualisiert das VCS 1 die Berichtseinstellungen 204. Zum Beispiel kann das VCS 1 beliebige Anpassungen an den Berichtseinstellungen 204 vornehmen, die von den erfüllten oder abgelaufenen Triggerbedingungen 208 spezifiziert wurden. Nach Block 410 geht die Steuerung zu Entscheidungsblock 408 weiter.
Folglich kann das VCS 1 des Fahrzeugs 31 Triggerbedingungen 208 verwenden, um variable Berichtsfrequenzfunktionalität zu implementieren, um die Frequenz und den Inhalt der Übertragung von Fahrzeugdaten 202 anzupassen, um mit dem Abladen der Fahrzeugdaten 202 über Mobilfunk assoziierte Kosten mit den Vorteilen des Lieferns verbesserter Detailgenauigkeit der Fahrzeugdaten 202 während gewisser Bedingungen abzuwägen.
Obgleich oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Stattdessen dienen die in der Beschreibung verwendeten Ausdrücke der Beschreibung und nicht der Einschränkung, und es versteht sich, dass verschiedene Änderungen durchgeführt werden können, ohne vom Gedanken und Schutzbereich der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener Implementierungsausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
Es wird ferner beschrieben:

A. System, umfassend: mindestens ein Steuergerät eines Fahrzeugs, das ausgelegt ist zum: Identifizieren einer auslösenden Triggerbedingung für eine erhöhte Fahrzeugdatenberichtsfrequenz an einen entfernten Telematikdienstanbieter; Aktualisieren einer Telematikberichtsfrequenz von einer Standardfrequenz zu einer höheren Frequenz als Reaktion auf die auslösende Triggerbedingung; Identifizieren einer beendenden Triggerbedingung, unter der die erhöhte Berichtsfrequenz nicht länger benötigt wird; und Aktualisieren der Telematikberichtsfrequenz zurück zu der Standardfrequenz.
B. System nach A, wobei die auslösende Triggerbedingung Empfangen eines Befehls von dem entfernten Telematikdienstanbieter über eine Mobilfunkverbindung beinhaltet.
C. System nach B, wobei der entfernte Telematikdienstanbieter den Befehl als Reaktion auf Informationen von dem mindestens einen Steuergerät bereitstellt, die auf Folgendes hinweisen: (i) das Fahrzeug ist in ein vorbestimmtes geographisches Gebiet eingefahren und/oder (ii) das Fahrzeug hat ein vorbestimmtes geographisches Gebiet verlassen und/oder (iii) das Fahrzeug wird in einem vorbestimmten Zeitfenster betrieben.
D. System nach A, wobei die auslösende Triggerbedingung Identifizieren von Folgendem beinhaltet: (i) Fahrzeugdynamikdaten, die auf eine Verfolgung hinweisen und/oder (ii) ungewöhnlichen Fahrzeugbetriebsbedingungen.
E. System nach A, wobei die beendende Triggerbedingung Identifizieren von Folgendem beinhaltet: (i) einem Aufhebungsbefehl, der von einem Fahrzeuginsassen empfangen wird und/oder (ii) einem Aufhebungsbefehl, der von mindestens einem Steuergerät basierend auf vorbestimmten Bedingungen erzeugt wird, und/oder (iii) einem Aufhebungsbefehl, der von dem entfernten Telematikdienstanbieter empfangen wird.
F. System nach E, wobei die vorbestimmten Bedingungen Folgendes beinhalten: (i) Fahrzeugschlüssel aus und/oder Ablaufen eines Timeouts seit der auslösenden Triggerbedingung.
G. System nach A, wobei die Standardfrequenz in der Größenordnung von Minuten zwischen Aktualisierungen und die höhere Frequenz in der Größenordnung von Sekunden zwischen Aktualisierungen liegt.
H. System, umfassend: einen Server, der ausgelegt ist zum: Empfangen von Fahrzeugdaten von einem Fahrzeug; Identifizieren einer fahrzeugbezogenen Triggerbedingung; Auswerten der Triggerbedingung gemäß den empfangenen Fahrzeugdaten; Erzeugen, als Reaktion auf ein Auftreten einer Triggerbedingung, eines Befehls, der dafür ausgelegt ist, Berichtseinstellungen anzupassen, die von dem Fahrzeug beim Liefern der Fahrzeugdaten zum Server verwendet werden; und Senden des Befehls an das Fahrzeug.
I. System nach H, wobei die Fahrzeugdaten eine Fahrzeugkennung beinhalten und der Server ferner zu Folgendem ausgelegt ist: Abfragen eines Datenspeichers des Servers nach Triggerbedingungen, die mit der Fahrzeugkennung assoziiert sind; und Abfragen des Datenspeichers nach Triggerbedingungen, die mit einer mit der Fahrzeugkennung assoziierten Flottenkennung assoziiert sind.
J. System nach H, wobei der Befehl dafür ausgelegt ist, eine Berichtsfrequenz der von dem Fahrzeug erhaltenen Fahrzeugdaten zu erhöhen.
K. System nach H, wobei der Server ferner ausgelegt ist zum: Erzeugen, als Reaktion auf ein Ablaufen eines Auftretens der Triggerbedingung, eines zweiten Befehls, der dafür ausgelegt ist, Berichtseinstellungen anzupassen, die von dem Fahrzeug beim Liefern der Fahrzeugdaten zum Server verwendet werden; und Senden des zweiten Befehls an das Fahrzeug.
L. System nach K, wobei der Befehl dafür ausgelegt ist, eine Berichtsfrequenz der von dem Fahrzeug erhaltenen Fahrzeugdaten von einer Standardfrequenz auf eine höhere Frequenz zu erhöhen, und der zweite Befehl dafür ausgelegt ist, die Berichtsfrequenz der Fahrzeugdaten zur Standardfrequenz zurückzusetzen.
M. System nach K, wobei der Server ferner dafür ausgelegt ist, den Befehl als Reaktion auf das Auslösen einer Triggerbedingung durch die Fahrzeugdaten bereitzustellen, die auf Folgendes hinweisen: (i) das Fahrzeug ist in ein vorbestimmtes geographisches Gebiet eingefahren und/oder (ii) das Fahrzeug hat ein vorbestimmtes geographisches Gebiet verlassen und/oder (iii) das Fahrzeug wird in einem vorbestimmten Zeitfenster betrieben und/oder (iv) Fahrzeugdynamikdaten, die auf eine Verfolgung eines anderen Fahrzeugs hinweisen und/oder (v) ungewöhnliche Fahrzeugbetriebsbedingungen.
N. System, umfassend: ein Fahrzeugsteuergerät, das zu Folgendem ausgelegt ist: Sammeln von Fahrzeugdaten, die sich auf das Funktionieren eines Fahrzeugsystems beziehen, gemäß Berichtseinstellungen, die von dem Steuergerät unterhalten werden; Senden der Fahrzeugdaten an einen Server gemäß einer berichtseinstellungsspezifizierten Berichtsfrequenz; und Aktualisieren der Berichtseinstellungen als Reaktion auf das Empfangen eines Befehls, der dafür ausgelegt ist, das Steuergerät zu veranlassen, die Berichtseinstellungen anzupassen, von dem Server.
O. System nach N, wobei das Fahrzeugsteuergerät ferner dafür ausgelegt ist, die Berichtsfrequenz gemäß dem Befehl zu aktualisieren.
P. System nach N, wobei das Fahrzeugsteuergerät ferner dafür ausgelegt ist, die Berichtseinstellungen zu aktualisieren, um einen zusätzlichen Posten von Fahrzeugdaten an den Server zu senden.
Q. System nach P, wobei der zusätzliche Posten von Fahrzeugdaten ein Videostream ist, der von dem Fahrzeug aufgenommen wurde.
R. System nach N, wobei das Fahrzeugsteuergerät ferner dafür ausgelegt ist, als Reaktion auf einen Aufhebungsbefehl, der durch das Steuergerät von einem Fahrzeuginsassen empfangen wurde, zu den Standardeinstellungen der Berichtseinstellungen zurückzukehren.

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE 802 LAN [0025]
IEEE 802 PAN [0025]
IEEE 1394 [0028]
IEEE 1284 [0028]
IEEE 803.11 [0030]

Claims

System, umfassend: mindestens ein Steuergerät eines Fahrzeugs, das ausgelegt ist zum: Identifizieren einer auslösenden Triggerbedingung für eine erhöhte Fahrzeugdatenberichtsfrequenz an einen entfernten Telematikdienstanbieter; Aktualisieren einer Telematikberichtsfrequenz von einer Standardfrequenz zu einer höheren Frequenz als Reaktion auf die auslösende Triggerbedingung; Identifizieren einer beendenden Triggerbedingung, unter der die erhöhte Berichtsfrequenz nicht länger benötigt wird; und Aktualisieren der Telematikberichtsfrequenz zurück zu der Standardfrequenz.
System nach Anspruch 1, wobei die auslösende Triggerbedingung Empfangen eines Befehls von dem entfernten Telematikdienstanbieter über eine Mobilfunkverbindung beinhaltet.
System nach Anspruch 2, wobei der entfernte Telematikdienstanbieter den Befehl als Reaktion auf Informationen von dem mindestens einen Steuergerät bereitstellt, die auf Folgendes hinweisen: (i) das Fahrzeug ist in ein vorbestimmtes geographisches Gebiet eingefahren und/oder (ii) das Fahrzeug hat ein vorbestimmtes geographisches Gebiet verlassen und/oder (iii) das Fahrzeug wird in einem vorbestimmten Zeitfenster betrieben.
System nach Anspruch 1, wobei die auslösende Triggerbedingung Identifizieren von Folgendem beinhaltet: (i) Fahrzeugdynamikdaten, die auf eine Verfolgung hinweisen und/oder (ii) ungewöhnlichen Fahrzeugbetriebsbedingungen.
System nach Anspruch 1, wobei die beendende Triggerbedingung Identifizieren von Folgendem beinhaltet: (i) einem Aufhebungsbefehl, der von einem Fahrzeuginsassen empfangen wird und/oder (ii) einem Aufhebungsbefehl, der von mindestens einem Steuergerät basierend auf vorbestimmten Bedingungen erzeugt wird, und/oder (iii) einem Aufhebungsbefehl, der von dem entfernten Telematikdienstanbieter empfangen wird.
System nach Anspruch 5, wobei die vorbestimmten Bedingungen Folgendes beinhalten: (i) Fahrzeugschlüssel aus und/oder Ablaufen eines Timeouts seit der auslösenden Triggerbedingung.
System nach Anspruch 1, wobei die Standardfrequenz in der Größenordnung von Minuten zwischen Aktualisierungen und die höhere Frequenz in der Größenordnung von Sekunden zwischen Aktualisierungen liegt.