DE102017107863A1

DE102017107863A1 - Verfahren und Vorrichtung für dynamische Fahrzeugkommunikationsantwort

Info

Publication number: DE102017107863A1
Application number: DE102017107863.0A
Authority: DE
Inventors: Basavaraj Tonshal; Panduranga Chary Kondoju; Praveen Kuman Yalavarty; John William SCHMOTZER
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-04-14
Filing date: 2017-04-11
Publication date: 2017-10-19
Also published as: US20170302522A1; CN107302558A

Abstract

Ein System umfasst einen Fahrzeugprozessor, der so konfiguriert ist, dass er von einer abgesetzten Instanz eine Abfrage empfängt, welche Antwortnetzparameter umfasst. Der Prozessor ist außerdem so konfiguriert, dass er basierend auf den Parametern eine Antworttransportrichtlinie bestimmt. Der Prozessor ist ferner so konfiguriert, dass er bestimmt, ob ein Netzwerk mit Charakteristiken, die durch die Richtlinie in Verbindung mit Parameterwerten definiert werden, gegenwärtig verbunden ist, und das Netzwerk verwendet, falls gegenwärtig verfügbar, um eine Abfrageantwort zu senden, andernfalls die Antwort in eine Warteschlange einreiht, bis solch ein Netzwerk verbunden ist.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen betreffen allgemein ein Verfahren und eine Vorrichtung für dynamische Fahrzeugkommunikationsantwort.
HINTERGRUND
Kommunikation mit einem Fahrzeugdatenverarbeitungssystem von einer abgesetzten, d.h. entfernten, Quelle kann die Form zeitkritischer und nicht-zeitkritischer Kommunikation annehmen. Auf zeitkritische Kommunikation kann zeitgerecht geantwortet werden oder kann zeitgerecht geantwortet werden müssen, um die Nutzbarkeit der Antwort zu bewahren. Nicht-zeitkritische Kommunikation kann zum Beispiel und ohne Einschränkung eine Anfrage über einen Fahrzeugsystemzustand zu Informationszwecken umfassen. Diese Daten müssten nicht unverzüglich gesammelt werden, und die Nutzbarkeit könnte dennoch bewahrt werden.
Ein Verwenden einer beliebigen verfügbaren Kommunikationsinfrastruktur kann zu Datenverlust und/oder zu Kosten führen, die höher als erwartet sind. In Abhängigkeit von einer Anzahl von Faktoren (z. B. und ohne Einschränkung Datengröße, Netzwerknutzungskosten, Neuübertragungsraten usw.) kann die Verwendung bestimmter Netzwerke die Kosten der Kommunikation mit einem Fahrzeug erhöhen. Dies kann in einer zeitkritischen Situation akzeptabel sein, aber wenn auf eine Abfrage nicht-zeitkritisch geantwortet werden kann, können alternative Kommunikationsstrategien eingesetzt werden.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform umfasst ein System einen Fahrzeugprozessor, der so konfiguriert ist, dass er von einer abgesetzten Instanz, d.h. entfernten Einheit, eine Abfrage empfängt, welche Antwortnetzwerkparameter umfasst. Der Prozessor ist außerdem so konfiguriert, dass er basierend auf den Parametern eine Antworttransportrichtlinie bestimmt. Der Prozessor ist ferner so konfiguriert, dass er bestimmt, ob ein Netzwerk mit Charakteristiken, die durch die Richtlinie in Verbindung mit Parameterwerten definiert werden, gegenwärtig verbunden ist, und das Netzwerk verwendet, falls gegenwärtig verfügbar, um eine Abfrageantwort zu senden, und andernfalls die Antwort in eine Warteschlange einreiht, bis solch ein Netzwerk verbunden ist.
In einer zweiten veranschaulichenden Ausführungsform umfasst ein computerimplementiertes Verfahren ein Bestimmen einer Netzwerkrichtlinie, um eine Antwort auf eine empfangene Abfrage zu senden, wobei die Abfrage Parameter umfasst, die von einem Fahrzeugcomputer verwendet werden, um basierend auf enthaltenen Parameterwerten zu bestimmen, welche Netzwerkrichtlinie verwendet werden soll, wobei die Richtlinie ein Netzwerk mit Charakteristiken definiert, welche Parameterwerten entsprechen. Das Verfahren umfasst außerdem ein Verwenden des Netzwerks, falls gegenwärtig verfügbar, um die Antwort zu senden, und Einreihen der Antwort in eine Warteschlange, falls das Netzwerk gegenwärtig nicht verfügbar ist.
In einer dritten veranschaulichenden Ausführungsform umfasst ein computerimplementiertes Verfahren ein Bestimmen einer Netzwerkrichtlinie, um eine Antwort auf eine empfangene Abfrage zu senden, wobei die Abfrage Parameter umfasst, die von einem Fahrzeugcomputer verwendet werden, um basierend darauf, welche Parameter in der Abfrage enthalten sind, zu bestimmen, welche Netzwerkrichtlinie verwendet werden soll, wobei die Richtlinie ein Netzwerk mit Charakteristiken definiert, welche Parameterwerten entsprechen, die in der Abfrage enthalten sind. Das Verfahren umfasst außerdem ein Verwenden des Netzwerks, falls verfügbar, um die Antwort zu senden, und Einreihen der Antwort in eine Warteschlange, falls das Netzwerk nicht verfügbar ist.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt ein veranschaulichendes Fahrzeugdatenverarbeitungssystem dar; und
2 stellt einen veranschaulichenden Fluss zum Antworten auf eine nicht-zeitkritische Kommunikation dar;
3 stellt ein veranschaulichendes Beispiel einer Kommunikationsrichtlinienimplementierung dar;
4 stellt ein veranschaulichendes Beispiel eines Netzwerkzustandsbeurteilungsprozesses dar;
5 stellt ein veranschaulichendes Beispiel von Transportkonfigurationsparametern dar, welche veranschaulichende Richtlinien definieren; und
6A bis 6C stellen veranschaulichende Datenübertragungsbeispiele dar, welche verschiedene Kommunikationsstrategien verwenden.
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 realisiert werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Einzelheiten von bestimmten Komponenten zu zeigen. Daher sollen hier offenbarte spezifische strukturelle und funktionale Einzelheiten nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einen Fachmann zu lehren, wie die vorliegende Erfindung auf verschiedene Art und Weise einzusetzen ist.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem 1 (VCS) für ein Fahrzeug 31. Ein Beispiel für ein derartiges fahrzeuggestütztes Datenverarbeitungssystem 1 ist das von THE FORD MOTOR COMPANY hergestellte SYNC-System. 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 veranschaulichenden Ausführungsform erfolgt die Interaktion durch Tastenbetätigungen, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
Bei der in 1 dargestellten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der innerhalb des Fahrzeugs vorgesehene Prozessor ermöglicht fahrzeuginterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nicht-persistentem 5 als auch mit persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nicht-persistente Speicher ein Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Allgemein kann persistenter (nichtflüchtiger) Speicher alle Formen von Speicher umfassen, die Daten bewahren, wenn ein Computer oder eine andere Einrichtung ausgeschaltet wird. Dazu gehören unter anderem HDDs, CDs, DVDs, Magnetbänder, Halbleiterlaufwerke, tragbare USB-Laufwerke (USB – universeller serieller Bus) und jede beliebige andere geeignete Form von persistentem Speicher.
Der Prozessor ist außerdem mit einer Anzahl von verschiedenen Eingängen versehen, die es dem Benutzer ermöglichen, über eine Schnittstelle eine Verbindung mit dem Prozessor herzustellen. Bei dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Zusatzeingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der ein Touchscreen-Bildschirm sein kann, und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist ein Eingangsselektor 51 vorgesehen, um einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Sowohl Eingaben in das Mikrofon als auch in den Zusatzanschluss werden durch einen Wandler (A/D) 27 von analog in digital umgewandelt, bevor sie zum Prozessor weitergegeben werden. Obwohl nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Zusatzkomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie beispielsweise einen CAN-Bus, ohne darauf beschränkt zu sein) verwenden, um Daten an das oder von dem VCS (oder Komponenten davon) weiterzugeben.
Ausgänge zum System können eine optische Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang umfassen, ohne darauf beschränkt zu sein. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Wandler 9 vom Prozessor 3. Ausgaben können zusammen mit den bidirektionalen Datenströmen, die bei 19 bzw. 21 dargestellt sind, auch an eine abgesetzte, d.h. entfernte, BLUETOOTH-Einrichtung, wie beispielsweise eine PND (personal navigation device) 54, oder eine USB-Vorrichtung, wie beispielsweise ein Fahrzeugnavigationssystem 60, erfolgen.
Bei einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger (BTT) 15, um mit einer nomadischen Einrichtung 53 (z. B. einem Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Einrichtung mit Anschlussmöglichkeit an ein drahtloses Remote-Netzwerk) eines Benutzers zu kommunizieren 17. Die nomadische Einrichtung kann dann zur Kommunikation 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 verwendet werden, zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57. Bei einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen der nomadischen Vorrichtung und dem BLUETOOTH-Sendeempfänger ist durch das Signal 14 dargestellt.
Die Kopplung einer nomadischen Vorrichtung 53 und des BLUETOOTH(BT)-Sendeempfängers 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden (BT-Paar). Dementsprechend wird die CPU angewiesen, dass der fahrzeuginterne BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer nomadischen Einrichtung gekoppelt wird.
Daten können zum Beispiel unter Nutzung 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 kommuniziert werden. Alternativ dazu kann es wünschenswert sein, ein fahrzeuginternes Modem 63 mit einer Antenne 18 einzubeziehen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Die nomadische Einrichtung (ND) 53 kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, zum Beispiel durch die Kommunikation 55 mit einem Mobilfunkmast 57. In einigen Ausführungsformen kann das Modem (MDM) 63 Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein zellulares USB-Modem sein, und die Kommunikation 20 kann zellulare Kommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API (application programming interface) umfasst, um mit Modem-Anwendungssoftware zu kommunizieren. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Transceiver zugreifen, um drahtlose Kommunikation mit einem abgesetzten, d.h. entfernten, BLUETOOTH-Transceiver (wie zum Beispiel dem in einer nomadischen Einrichtung anzutreffenden) herzustellen. Bluetooth ist ein Teilsatz der IEEE 802 PAN(Netzwerk für den persönlichen Bereich)-Protokolle. IEEE 802 LAN(lokales Netzwerk)-Protokolle umfassen WiFi und weisen eine erhebliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind für drahtlose Kommunikation in einem Fahrzeug geeignet. Andere Kommunikationsmittel, die in diesem Bereich verwendet werden können, sind freiraumoptische Kommunikation (wie beispielsweise IrDA) und nichtstandardisierte Consumer IR-Protokolle.
In einer anderen Ausführungsform umfasst die nomadische Vorrichtung 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. Bei der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplexen bekannte Methode implementiert sein, wenn der Eigentümer der nomadischen Einrichtung über die Einrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Eigentümer die Einrichtung nicht verwendet, 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. All diese sind Standards entsprechend ITU IMT-2000 (3G) und bieten Datenraten bis zu 2 Mbit/s für stationäre oder gehende Benutzer und 385 kbit/s für Benutzer in einem sich bewegenden Fahrzeug. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, das 100 Mbit/s für Benutzer in einem Fahrzeug und 1 Gbit/s für stationäre Benutzer bietet. Falls der Nutzer über einen mit der nomadischen Einrichtung verknüpften Datenplan verfügt, ist es möglich, dass der Datenplan Breitband-Übertragung gestattet und dass das System eine viel größere Bandbreite verwenden könnte (was die Datenübertragung beschleunigt). Bei noch einer anderen Ausführungsform wird die nomadische Einrichtung 53 durch eine (nicht dargestellte) zellulare Kommunikationseinrichtung ersetzt, die im Fahrzeug 31 installiert ist. Bei noch einer anderen Ausführungsform kann die nomadische Einrichtung (ND) 53 eine Einrichtung mit Wireless Local Area Netzwerk (LAN) sein, die in der Lage ist, zum Beispiel (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk zu kommunizieren.
Bei einer Ausführungsform können eingehende Daten durch die nomadische Einrichtung über Data-over-Voice oder einen Datenplan durch den fahrzeuginternen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf dem 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 seriellen Netzwerkprotokollen. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), 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 Protokolle können entweder für elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielzahl anderer Zusatzeinrichtungen 65 in Kommunikation stehen. Diese Einrichtungen können durch eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden sein. Die Zusatzeinrichtung 65 kann unter anderem persönliche Medien-Player, drahtlose medizinische Einrichtungen, tragbare Computer und dergleichen umfassen.
Ebenso oder alternativ dazu könnte die CPU mit einem fahrzeuggestützten drahtlosen Router 73, zum Beispiel unter Verwendung eines WiFi-Sendeempfängers (IEEE 803.11) 71, verbunden sein. Dies könnte der CPU den Anschluss an Remote-Netzwerke in Reichweite des lokalen Routers 73 ermöglichen.
Zusätzlich dazu, dass beispielhafte Prozesse in bestimmten Ausführungsformen durch ein Fahrzeugdatenverarbeitungssystem, das sich in einem Fahrzeug befindet, ausgeführt werden, können die beispielhaften Prozesse durch ein Datenverarbeitungssystem ausgeführt werden, das in Kommunikation mit einem Fahrzeugdatenverarbeitungssystem steht. Ein derartiges System kann unter anderem eine drahtlose Einrichtung (z. B. und ohne Beschränkung ein Mobiltelefon) oder ein abgesetztes, d.h. entferntes, Datenverarbeitungssystem (z. B. und ohne Beschränkung einen Server) umfassen, die durch die drahtlose Einrichtung verbunden sind. Zusammenkönnen solche Systeme als fahrzeugassoziierte Datenverarbeitungssysteme (VACS) bezeichnet werden. Bei bestimmten Ausführungsformen können bestimmte Komponenten des VACS, abhängig von der jeweiligen Implementierung des Systems, bestimmte Teile eines Prozesses durchführen. Als ein Beispiel und ohne Einschränkung ist es dann, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung umfasst, wahrscheinlich, dass den Prozess nicht die drahtlose Vorrichtung ausführt, da die drahtlose Vorrichtung Informationen nicht an und von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann weiß, wann es unangebracht ist, ein bestimmtes Datenverarbeitungssystem für eine gegebene Lösung anzuwenden.
In jeder der veranschaulichenden Ausführungsformen, die hierin erörtert werden, wird ein veranschaulichendes, nicht einschränkendes Beispiel eines Prozesses dargestellt, der von einem Datenverarbeitungssystem durchgeführt werden kann. In Bezug auf jeden Prozess ist es möglich, das Datenverarbeitungssystem, das den Prozess ausführt, für den begrenzten Zweck des Ausführens des Prozesses als ein Spezialprozessor zu konfigurieren, um den Prozess durchzuführen. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden und sind als Beispiele für Arten von Prozessen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu erreichen. Zusätzliche Schritte können auf Wunsch hinzugefügt oder aus den beispielhaften Prozessen entfernt werden.
Ein Fahrzeug-zu-Cloud-Protokoll kann so ausgelegt sein, dass es Kommunikation zwischen einem fahrzeuggestützten Datenverarbeitungssystem (VCS), wie beispielsweise einer Telematikeinheit eines Fahrzeugs, und einem vom Fahrzeug abgesetzten, d.h. entfernten, Dienstbereitstellungsnetzwerk bereitstellt. Das Protokoll kann eine Transportschicht, die zum Senden von Nachrichtennutzlasten zwischen dem VCS und dem Dienstbereitstellungsnetzwerk verwendet wird, sowie ein Format für die Nutzlasten der Nachrichten, die gesendet werden, definieren.
Ein Name/Wert-Paar-Modell kann ermöglichen, dass zu definierende Datenelemente der Nachrichten, die je nach Typ von Nachricht variieren, gesendet werden. Außerdem kann das Name/Wert-Paar-Modell ein Definieren von Unterdatensätzen ermöglichen (z. B. Informationen, die in Nachrichten aus Fahrzeugen einzubeziehen sind, Informationen, die in Nachrichten aus dem Dienstbereitstellungsnetzwerk einzubeziehen sind, Informationen, welche den Status des Fahrzeugs beschreiben, Informationen, die einen derzeitigen Standort des Fahrzeugs beschreiben, usw.). Diese Unterdatensätze können dann als eine Komponente in anderen Nachrichtendefinitionen wiederverwendet werden, ohne dass der Unterdatensatz jedes Mal neu definiert wird.
Des Weiteren kann das System durch die Verwendung des Name/Wert-Paar-Modells für die Datenübertragung Hinzufügung von Datenelementen zur Nachrichtendefinition ermöglichen, ohne eingesetzte Nachrichtenempfänger, welche die Kommunikation mit dem Dienstbereitstellungsnetzwerk unter Verwendung einer früheren Version der Nachrichtendefinition verwenden, unerwünscht zu beeinflussen. Da die Datenelemente nach Kennung und nicht nach Nachrichtenposition adressiert werden, können stattdessen aktualisierte Frameworkmodule verwendet werden, ohne bestehende eingesetzte Anwendungen oder Fahrzeuge, die mit einer früheren Version des Frameworks kompiliert werden, zu beeinträchtigen. In einem Beispiel können Google-Protokollpuffer als das Nutzlastprotokoll verwendet werden, um zu ermöglichen, dass eine Nachrichtendefinition entworfen und in einem Frameworkmodul, das in verschiedenen Programmiersprachen zu verwenden ist, automatisch erzeugt wird. Das Verpacken von Daten, das durch Verwenden von Protokollpuffern durchgeführt wird, kann eine effizientere Übertragung von Daten ermöglichen, als bei Verwenden eines Textname/Wert-Paar-Frameworks, wie beispielsweise einer erweiterbaren Auszeichnungssprache (XML), möglich sein kann.
Ein veranschaulichendes beispielhaftes Dienstbereitstellungsnetzwerk kann über ein Netzwerk durch einen Nachrichtenvermittler mit einem Fahrzeug in Kommunikation sein. Das Fahrzeug kann durch das VCS des Fahrzeugs in drahtloser Kommunikation mit dem Netzwerk sein. Wenn ein Fahrzeug zusammengebaut wird, kann das Fahrzeug verschiedene Hardware- und Softwarekomponenten umfassen.
Bei bestehenden Implementierungen kann ein VCS eines Fahrzeugs so konfiguriert sein, dass es Informationen über das Vorhandensein und die Version für wenigstens einen Teil der Hardware- und Softwarekomponenten des Fahrzeugs abfragt. Mithilfe der abgefragten Informationen und zusätzlicher Informationen, die das spezifische Fahrzeug identifizieren (z. B. Fahrzeugidentifizierungsnummer(VIN)-Informationen, die auf dem CAN-Bus (Controller Area Network) veröffentlicht werden, SIM-Informationen (Subscriber Identity Module) des Modems wie eine IMEI (International Mobile Station Equipment Identity) usw.), kann das VCS über das Netzwerk und den Nachrichtenvermittler kommunizieren, um ein Konto beim Dienstbereitstellungsnetzwerk zu erstellen. Das Dienstbereitstellungsnetz kann diese Kommunikationen von den Fahrzeugen empfangen und einen Datenspeicher der mit Kennungen der Fahrzeuge verbundenen Hardwarekonfigurationen und Software(z. B. Firmware- usw.)-Versionen unterhalten.
Ein Nachrichtenvermittler kann zusätzlich eine Veröffentlichen-/Subskribieren-Nachrichtenübermittlungsfunktionalität zur Kommunikation zwischen dem Dienstbereitstellungsnetzwerk und den Fahrzeugen bereitstellen. Das Veröffentlichen-/Subskribieren-Modell kann ein oder mehrere Themen verwenden, wobei die Themen logische Kanäle genannt werden, durch welche Herausgeber Nachrichten senden können und Subskribenten Nachrichten empfangen können. Statt alle Nachrichten zu empfangen, empfangen Subskribenten der Themen die Nachrichten, die in den von ihnen subskribierten Themen veröffentlicht werden, und alle Subskribenten eines Themas empfangen im Wesentlichen die gleichen Themennachrichten.
Bei dieser Implementierung könnte sowohl im Fahrzeug als auch in der Cloud zum Hinzufügen eines neuen Merkmals eine Anzahl von Parametersätzen geändert werden müssen, um das neue Merkmal zu aktivieren. Durch Verwenden der veranschaulichenden Ausführungsformen, die hierin dargelegt werden, und ähnlicher Konzepte kann eine Abstraktion von Fahrzeugdaten erreicht werden, die es nicht nötig macht, eine Schnittstelle spezifisch für eine Fahrzeugarchitektur oder eine spezifische Funktionalität zu entwickeln.
2 stellt einen veranschaulichenden Fluss zum Antworten auf eine nicht-zeitkritische Kommunikation dar. In Bezug auf die in dieser Figur beschriebenen, veranschaulichenden Ausführungsformen versteht es sich, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der vorliegend dargestellten beispielhaften Verfahren zeitweilig als ein Spezialprozessor aktiviert werden kann. Beim Ausführen von Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend zu einem Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, soweit angebracht, in Übereinstimmung mit einem vorkonfigurierten Prozessor fungierende Firmware bewirken, dass der Prozessor als ein Spezialprozessor fungiert, der für den Zweck des Durchführens des Verfahrens oder irgendeiner sinnvollen Variante davon bereitgestellt ist.
Es gibt drei Teilnehmer an einem Kommunikationsprozess in diesem veranschaulichenden Beispiel. Es gibt eine Cloud 201, die ein Backend-Netzwerk, eine abgesetzte, d.h. entfernte, Einrichtung, die mit dem Fahrzeug kommuniziert, oder einen beliebigen anderen Vermittler für ein abgesetztes Datenverarbeitungssystem oder einen abgesetzten Backend-Prozess, das/der Fahrzeugkommunikation versucht, umfassen kann, ohne darauf beschränkt zu sein. Es gibt außerdem einen Nachrichtenwarteschlangen-Telemetrietransport(MQTT)-Nachrichtenvermittler 203, der Kommunikation zwischen einer Cloud und einer Telematiksteuereinheit (TCU) 205 ermöglicht. Der Nachrichtenvermittler ist für das Weiterleiten von Nachrichten an die geeignete Instanz (anfordernde/n Teilnehmer/Instanz und/oder TCU) verantwortlich. Schließlich handhabt in diesem Beispiel die TCU 205 das Antworten auf eine Nachricht. In diesem Beispiel ist die TCU auch für das Auswählen der geeigneten Richtlinie für eine Nachrichtenantwort und Übermitteln der Antwort über einen entsprechend geeigneten Kanal verantwortlich. Die TCU kann diese Funktion in Verbindung mit einem fahrzeuginternen verteilten Konnektivitätsmanager (IVDCM) ausführen. Der MQTT-Vermittler kann sich in der Cloud befinden und Kommunikation zwischen der TCU/dem IVDCM und einer Backend-Instanz handhaben.
In diesem veranschaulichenden Beispiel veröffentlicht die Cloud einen nicht-zeitkritischen Befehl, der eine dynamische Abfrage von CAN(Controller Area Network)-Signalen einschließlich einer Liste von CAN-Signalnamen, die für die Abfrage von Interesse sind, umfassen kann 207. Der Nachrichtenvermittler empfängt die Abfrage und leitet die Abfrage an ein geeignetes Modul weiter 209, das auf der TCU ausgeführt wird, um die Anforderung handzuhaben. Diese Nachricht/Abfrage kann eine bestimmte Richtlinie umfassen, die auf eine Antwort angewendet und/oder einen Satz von Parametern für die Antwort definieren sollte, der verwendet werden kann, um zu bestimmen, welche Richtlinie verwendet werden sollte.
Das entsprechende TCU-Modul empfängt dann die Abfrage und erstellt eine Antwort, welche Signalnamen, Signalwerte, Signalnachrichtennamen usw. umfasst 211. Diese Antwort wird als nicht-zeitkritische Befehlsantwort verpackt und an den Nachrichtenvermittler zur Beantwortung zurückgegeben 213. Die TCU kann basierend auf einer definierten Richtlinie bestimmen, welche verfügbaren oder wünschenswerten Kommunikationskanäle zur Übertragung der Nachricht geeignet sind. Sobald ein geeigneter Kanal verfügbar/verbunden ist, empfängt der Nachrichtenvermittler die Antwort und kann die Abfrageantwort an die anfordernde Instanz zurückgeben 215.
3 stellt ein veranschaulichendes Beispiel einer Kommunikationsrichtlinienimplementierung dar. In Bezug auf die in dieser Figur beschriebenen, veranschaulichenden Ausführungsformen versteht es sich, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der vorliegend dargestellten beispielhaften Verfahren zeitweilig als ein Spezialprozessor aktiviert werden kann. Beim Ausführen von Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend zu einem Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, soweit angebracht, in Übereinstimmung mit einem vorkonfigurierten Prozessor fungierende Firmware bewirken, dass der Prozessor als ein Spezialprozessor fungiert, der für den Zweck des Durchführens des Verfahrens oder irgendeiner sinnvollen Variante davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel empfängt der Prozess eine Nachricht, wie beispielsweise eine CAN-Abfrage 301, zur Beantwortung. Verschiedene Nachrichtentypen können verschiedene Antworten (in Bezug auf verwendete Netzwerke) empfangen, so dass der Prozess dann einen Satz von Transportprotokollen (Richtlinien) lädt oder darauf zugreift 303. Basierend auf der Beschaffenheit der Nachricht, auf welche die Antwort gegeben wird, wird eine bestimmte Richtlinie für die Antwort ausgewählt 305.
Wie in 5 zu sehen ist, definieren die Richtlinien ein oder mehrere geeignete Kommunikationsnetze zur Verwendung beim Antworten auf eine bestimmte Nachricht. Falls ein Netzwerk, das einem zulässigen Netzwerk entspricht, wie durch die Richtlinie definiert, verfügbar ist 307, verpackt der Prozess die Daten für die Antwort 309 und sendet die Daten 311 unter Verwendung des basierend auf der ausgewählten Richtlinie identifizierten Netzwerks.
Falls dagegen das gewünschte Netzwerk nicht verfügbar ist, oder falls kein Netzwerk verfügbar ist, das durch die Richtlinie definierte Parameter erfüllt, kann der Prozess unverzüglich eine Fehlermeldung senden 313. Diese lässt die anfordernde Instanz wissen, dass die Antwort unter Verwendung einer für die Antwort gewählten Richtlinie nicht sofort gehandhabt werden konnte. Dies bedeutet nicht unbedingt, dass keine Antwort bereitgestellt wird, sondern nur, dass zu diesem Zeitpunkt keine bereitgestellt werden kann.
Bestimmte Nachrichten können zu einem späteren Zeitpunkt beantwortet werden, und der Prozess reiht die Antwort gegebenenfalls für eine spätere Zustellung in eine Warteschlange ein 315. Da die Antwort in diesem Beispiel basierend auf einem Mangel an geeigneter Netzwerkverbindung nicht zugestellt werden kann, subskribiert der Prozess einen Meldungsprozess 317, der es dem Prozess ermöglicht, zu erfahren, wann ein geeignetes Netzwerk verfügbar wird. Dies könnte zum Beispiel aufgrund einer Verbindung mit einem neuen Netzwerk oder einer Änderung der Signalstärke eines bestehenden Netzwerks sein. Andere Änderungen an Netzwerkcharakteristiken können ebenfalls bewirken, dass sich ein gegenwärtig verbundenes, aber ungeeignetes Netzwerk in ein Netzwerk verwandelt, das sich zur Antwortzustellung eignet.
Sobald ein Netzwerk verfügbar ist 319, das die durch die Richtlinie definierten Charakteristiken aufweist, wie für die Antwort wünschenswert, kann der Prozess die Daten verpacken 321 und die Daten unter Verwendung des geeigneten Netzwerks senden 323. In den veranschaulichenden Beispielen ist der IVDCM (der sich im Fahrzeug befindet) für das Auswählen des geeigneten Netzwerks zur Kommunikation basierend auf der Richtlinie verantwortlich, die aus den Parametern entwickelt wird, die in der anfänglichen Nachricht enthalten sind, die vom MQTT (an den eine Antwort gesendet wird) empfangen werden.
4 stellt ein veranschaulichendes Beispiel eines Netzwerkzustandsbeurteilungsprozesses dar. In Bezug auf die in dieser Figur beschriebenen, veranschaulichenden Ausführungsformen versteht es sich, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der vorliegend dargestellten beispielhaften Verfahren zeitweilig als ein Spezialprozessor aktiviert werden kann. Beim Ausführen von Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend zu einem Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, soweit angebracht, in Übereinstimmung mit einem vorkonfigurierten Prozessor fungierende Firmware bewirken, dass der Prozessor als ein Spezialprozessor fungiert, der für den Zweck des Durchführens des Verfahrens oder irgendeiner sinnvollen Variante davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel beurteilt der Prozess alle verbundenen Netzwerke, um einen Satz von Charakteristiken für jedes verbundene Netzwerk festzulegen. Diese Charakteristiken können mit Parametern verglichen werden, die durch die Richtlinie für eine bestimmte Antwort definiert werden, um zu bestimmen, ob ein bestimmtes Netzwerk zur Verwendung beim Senden der Antwort geeignet ist. Dies bedeutet nicht, dass ein bestimmtes Netzwerk nicht zum Senden einer Nachricht verwendet werden könnte, sondern eher dass eine Richtlinie, die für die Antwort ausgewählt wird, Charakteristiken eines wünschenswerten Netzwerks für die bestimmte Antwort definieren kann, und die TCU eine Antwort solange verzögern kann, bis ein richtlinienkompatibles Netzwerk verfügbar ist.
Der Prozess beurteilt alle der physikalischen Netzwerke, die mit dem Fahrzeug verbunden sind 401, und er bestimmt die Richtliniencharakteristiken jedes Netzwerks. Ein bestimmtes Netzwerk wird zur Beurteilung ausgewählt 403, und der Prozess prüft die jeweiligen Charakteristiken des Netzwerks 405. Diese Charakteristiken können Latenz, Bandbreite, einen bestimmten Netzwerktyp, Priorität, kostentragende Instanz (die für Daten bezahlt), voraussichtliche Übertragungszeit usw. umfassen, ohne darauf beschränkt zu sein. Ein spezifisches Netzwerk kann für bestimmte Kommunikationen auf der Basis einer MAC-ID definiert werden.
Sobald der Prozess die Beurteilung des Netzwerks abgeschlossen hat, bestimmt der Prozess, ob es irgendwelche Subskriptionen bezüglich Informationen in Bezug auf das jeweilige Netzwerk gibt 407. Da einige Richtlinien ein Netzwerk eines bestimmten Typs oder sogar ein spezifisches Netzwerk eines bestimmten Typs durch eine MAC-Adresse definieren, kann es Subskriptionen geben, die in Bezug auf bevorstehende Nachrichtenantworten für bestimmte Netzwerktypen erzeugt werden. Subskriptionen können auch allgemeiner sein – zum Beispiel könnte eine Subskription für ein Netzwerk mit hoher Bandbreite sein, wofür vom Kunden gezahlt wird.
Falls das Netzwerk Subskriptionen aufweist, oder falls es eine Subskription eines Themas gibt, das den Charakteristiken des Netzwerks (wie beispielsweise der hohen Bandbreite, dem vom Kunden bezahlten Netzwerkthema, die zuvor als Beispiel erwähnt wurden) entspricht, kann der Prozess an die subskribierende Instanz antworten. Andernfalls kann der Prozess die Charakteristiken des Netzes zum Abruf durch spätere Richtlinienanforderungen speichern 409 und zur Beurteilung des nächsten Netzwerks übergehen. Da die Charakteristiken sich mit der Zeit ändern können, und da beständig neue Netzwerke hinzugefügt oder verworfen werden können, kann dieser Prozess im Hintergrund und/oder periodisch während der Verwendung eines Fahrzeugs ausgeführt werden.
Wenn es eine oder mehrere Instanzen gibt, die ein bestimmtes Thema subskribieren, das einem Netzwerk oder einem Satz von Charakteristiken entspricht, kann der Prozess bestimmen, ob die gewünschten Parameter, die von der Instanz spezifiziert werden, erfüllt werden 413. In einem anderen Beispiel kann der Prozess alle Charakteristiken des Netzwerks an die subskribierende Instanz melden, und die Instanz kann bestimmen, ob das Netzwerk geeignet ist. Hierbei meldet der Prozess das Netzwerk als ein Übertragungskandidatennetzwerk 415, falls die gewünschten Charakteristiken erfüllt werden.
Da Subskriptionen durch eine mit einer bestimmten bevorstehenden Antwort assoziierte Richtlinie bei Bedarf dynamisch erstellt werden können, können die Subskriptionen spezifisch genug sein, um alle möglichen Charakteristiken eines bestimmten Netzwerks zu erfassen. In solch einem Modell würde die Antwort an die subskribierende Instanz das gemeldete Netzwerk „automatisch“ als ein Kandidatennetzwerk identifizieren. In anderen Modellen kann eine subskribierende Instanz bestimmte „notwendige“ Parameter subskribieren und dann alle Charakteristiken von gemeldeten Netzwerken beurteilen, um einen geeigneten Kandidaten zu bestimmen. Wenn es zum Beispiel bevorzugte, aber optionale Charakteristiken von Netzwerken gibt, kann das anfordernde System mehrere Kandidatennetze empfangen, die dem Hauptsubskriptionsthema (z. B. WiFi) entsprechen, und dann bestimmen, welches dieser Netzwerke über den besten Satz von optionalen Charakteristiken verfügt.
In diesem Beispiel handhabt der Prozess auch Subskriptionsverwaltung. Demnach wartet der Prozess nach dem Melden des Kandidatennetzes 415 auf eine Bestätigung, dass die gewünschten Daten gesendet wurden. Dieser Teilprozess kann auch im Hintergrund abgewickelt werden, so dass zusätzliche Kandidatennetzwerke gemeldet werden können. Falls keine Datenübertragungsbestätigung empfangen wird, wie beispielsweise wenn aufgrund eines Fehlers eine Transfer-unvollständig-Meldung empfangen wird 419, kann der Prozess die Netzwerkcharakteristiken einfach aufzeichnen und bestimmen, ob noch irgendwelche Netzwerke zur Beurteilung übrig sind 411. Wenn eine Meldung empfangen wird, dass der Transfer erfolgreich ist, kann der Prozess die jeweilige Subskription 421 für die anfordernde Instanz/Anwendung desubskribieren, da die entsprechende Antwort erfolgt ist, für welche die Subskription erstellt wurde.
5 stellt ein veranschaulichendes Beispiel von Transportkonfigurationsparametern dar, die verwendet werden können, um eine bestimmte Richtlinie auszuwählen. Dies ist keine erschöpfende Liste von Parametern, zeigt aber einige mögliche Erwägungen, die bestimmten Richtlinien entsprechen können, die mit verschiedenen Typen von Antworten assoziiert sind.
Ein Interaktivitätsgrad 511, der mit einer Antwort assoziiert ist, definiert, ob eine Antwort eine Vordergrund(VG)- oder eine Hintergrundantwort (HG) ist. Für diesen und eine Anzahl von anderen Parametern gibt es viele Richtlinien, welche die jeweilige Erwägung ignorieren, was in diesem Beispiel als nicht zutreffend (NZ) dargestellt ist. Eine Erwägung der Größe 513 schreibt vor, ob Latenz (kurz, KZ) oder Bandbreite (groß, GR) für ein Netzwerk (angesichts der Verfügbarkeit mehrerer Netzwerke) ein Hauptanliegen ist. Zusammen definieren Interaktivität und Größe einen Satz von Richtlinien hohen Intentionsniveaus, die für bestimmte Kommunikationstypen verwendet werden.
Für andere Kommunikationen als jenen, die durch die Parameter hohen Intentionsniveaus vorgeschrieben werden, können Richtlinienparameter niedrigen Niveaus verwendet werden 515. Wenn eine Anforderung diktiert, dass Richtlinien niedrigen Niveaus verwendet werden sollen, kann eine Vielfalt anderer Parameter vorschreiben, welche Richtlinie verwendet wird. In diesem veranschaulichenden Beispiel definiert die Nachrichtenanforderung entweder einen Satz von Parametern zur Erwägung oder ist als eine Nachricht eines bestimmten Typs charakterisierbar, für welche Antwortparameter bereits definiert sind.
Der physikalische Netzwerkparameter 517 definiert in spezifiziertes Netzwerk, das in einer Antwortdefinition oder als ein Parameter in der Nachrichtenanforderung enthalten sein kann. In einigen Richtlinien „muss“ dieses Netzwerk verwendet werden (d. h. es wird verwendet, falls verfügbar, und es wird darauf gewartet, falls nicht verfügbar). In anderen Richtlinien wird das Netzwerk lediglich bevorzugt, und ist es nicht verfügbar, dann wird ein anderes angemessenes Kandidatennetzwerk gewählt.
Priorität 519 definiert eine Antwortpriorität, die verwendet werden kann, falls mehrere Antworten dasselbe Kommunikationsnetz anfordern. Einer Antwort mit höherer Priorität kann Transportpräferenz gegenüber einer anderen Antwort mit niedrigerer Priorität eingeräumt werden. Die Priorität kann außerdem vorschreiben, ob ein spezifiziertes Netzwerk (das der Richtlinie entspricht) verwendet werden sollte, oder ob ein bestes verfügbares Netzwerk verwendet werden sollte. Wie zum Beispiel aus den hierin aufgeführten beispielhaften Richtlinienbeschreibungen ersichtlich ist, werden Nachrichtenantworten mit hoher Priorität für bestimmte Netzwerke gemäß bestimmten Richtlinien bevorzugt, aber falls ein bevorzugtes Netzwerk nicht verfügbar ist, wird ein nächstbestes Netzwerk gewählt. Nachrichten mit mittlerer oder niedriger Priorität werden solange verzögert, bis ein geeignetes Netzwerk verfügbar ist.
Der Kostenparameter 521 diktiert, ob eine Instanz, die für die Übertragung von Daten bezahlt, erwogen werden sollte oder nicht. Beispiele umfassen, ohne darauf beschränkt zu sein, NZ/Ignorieren (kostenirrelevant), OEM_PAID (Kosten vom Hersteller bezahlt), CUSTOMER_PAID (Kosten vom Kunden bezahlt), FREE (kostenlos) usw. Da einige Anforderungen von einem OEM gestellt werden können und wenig oder gar nichts mit einem Kundenerlebnis zu tun haben, kann es nicht angebracht sein, dass ein vom Kunden bezahltes Netzwerk für diese Antworten verwendet wird. Andererseits kann es angebracht sein, dass explizite Kundenanforderungen für bestimmte Daten durch ein vom Kunden bezahltes Netzwerk geleitet werden und die Verwendung eines OEM-bezahlten Netzwerks vermeiden.
Daten/Zeit der Antwort 523 kann beim Auswählen einiger der Richtlinien ebenfalls erwogen werden. Dies kann eine Erwägung dessen umfassen, ob ein Netzwerk zu einer bestimmten Zeit/an einem bestimmten Datum verfügbar oder wahrscheinlich verfügbar ist. Bestimmte Antworten können auch Netzwerkausfallsicherung unterstützen 525, was die Auswahl eines alternativen Netzwerks ist, falls eine Übertragung eines bevorzugten Netzwerks aus irdendeinem Grund ausfällt.
Intelligentes Disponieren 527 ist in diesem Beispiel mit einer einzigen Richtlinie assoziiert. Intelligentes Disponieren ermöglicht ein Disponieren der Antwort u. a. basierend auf bekannten Netzabdeckungskarten und einem Fahrzeugstandort (z. B. kann die Antwort für einen Zeitpunkt disponiert werden, zu dem ein Fahrzeug voraussichtlich an einem bestimmten Ort mit einer bestimmten bekannten Abdeckung ist).
Für bestimmte Nachrichten kann auch eine MAC-ID spezifiziert werden 529, die einen spezifischen WiFi-Zugangspunkt definiert, der zur Nachrichtenübertragung verwendet werden soll. Das Ergebnis all dieser Erwägungen ist eine Richtlinienauswahl 531, welche Auswahlkriterien und, welches Netzwerk (das bestimmte Parameter erfüllt) verwendet werden soll, diktiert. Es folgen einige Beispiele der Richtlinien:
Richtlinie A – Priorität: Hoch; Regel – Falls mehrere Netzwerke verfügbar sind, beurteilen und das mit der geringsten Latenz wählen.
Richtlinie B – Priorität: Mittel; Regel – Auswählen des physikalischen Netzwerks, wie in Richtlinie niedrigen Niveaus spezifiziert. Falls das spezifizierte physikalische Netzwerk nicht verfügbar ist, auf Verfügbarkeit des Netzwerks warten.
Richtlinie C – Priorität: Hoch; Regel – Auswählen des physikalischen Netzwerks, wie in Richtlinie niedrigen Niveaus spezifiziert, als Wi-Fi-Zugangspunkt mit MAC-ID. Falls der spezifizierte Wi-Fi-Zugangspunkt nicht verfügbar ist, dann die verfügbaren Netzwerke beurteilen und das mit der geringsten Latenz wählen.
Wie aus den veranschaulichenden Richtlinienbeispielen in Bezug auf Richtlinien mit hoher Priorität (in diesem Beispiel nur zur Veranschaulichung) ersichtlich ist, wird ein bestimmtes Netzwerk durch einen oder mehrere Parameter als bevorzugt definiert, und dann wird eine zweitrangige Erwägung in Bezug auf verfügbare Netzwerke angestellt, falls das bevorzugte Netzwerk nicht verfügbar ist. In Bezug auf die Übertragungen mit niedriger und mittlerer Priorität wird auf ein Netzwerk spezifizierter Parameter gewartet, wenn gegenwärtig nicht verfügbar.
Richtlinie A in diesem Beispiel ist insofern anders, als es sich dabei um Richtlinien hohen Intentionsniveaus handelt, welche Parameter niedrigen Niveaus ignorieren. Diese Übertragung wird auf der Basis jedes verfügbaren Netzwerks durchgeführt, wobei einer bestimmten Netzwerkcharakteristik basierend auf einer bestimmten Richtlinie Präferenz eingeräumt wird. In diesen vier Richtlinien werden selbst die Antworten mit niedriger und mittlerer Priorität auf jedem verfügbaren Netzwerk gesendet.
6A bis 6C stellen veranschaulichende Datenübertragungsbeispiele dar, welche verschiedene Kommunikationsstrategien verwenden. Bezüglich den in diesen Figuren beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Spezialprozessor befähigt werden kann. Beim Ausführen von Code, der Anweisungen zum Durchführen einiger oder aller Schritte der Verfahren bereitstellt, kann der Prozessor vorübergehend zu einem Spezialprozessor umfunktioniert werden, bis ein Verfahren abgeschlossen ist. In einem anderen Beispiel kann, soweit es angemessen ist, Firmware, die gemäß einem vorkonfigurierten Prozessor wirkt, verursachen, dass der Prozessor als ein Spezialprozessor wirkt, der zum Zwecke des Ausführens der Verfahren oder einiger vernünftiger Varianten davon bereitgestellt wird.
Im veranschaulichenden Beispiel, das in 6A dargestellt ist, sendet eine Anwendung, die sich auf der TCU 601 befindet, eine Anforderung 606, die Übertragungskonfigurationsparameter (Antwortparameter) und die Daten für die Antwort umfasst. Ein fahrzeuginterner verteilter Konnektivitätsmanager (IVDCM) 603 bestimmt basierend auf den zugeordneten Antwortparametern und der IVDCM-Konfiguration, welches physikalische Netzwerk für die Antwort verwendet werden soll 607. Falls das physikalische Netzwerk verfügbar ist 609, wird eine Anforderung 611 an den MQT-Vermittler 605 gesendet, welche Antwortübertragung anfordert. Falls das ausgewählte Netzwerk (oder ein Ersatznetzwerk) nicht verfügbar ist, kann der IVDCM einen Antwortfehler an die anfordernde Anwendung melden.
6B stellt einen Prozess dar, der umfassender als der von 6A ist und der in diesem Beispiel der Anwendung ermöglicht, ein Thema zu subskribieren, das relevanten Transportparametern entspricht. Wenn ein Netzwerk, das den bzw. die gewünschten Parameter erfüllt, verfügbar ist, kann die Anwendung die Antwort zur endgültigen Übertragung erneut senden.
In diesem Prozess sendet die Anwendung 601 eine Anforderung 606, wie in 6A. Der IVDCM wählt ein Netzwerk aus, wie zuvor 607, und prüft auf ein Netzwerk, das die Richtlinienbeschränkungen erfüllt. Falls das Netzwerk verfügbar ist, schreitet die Übertragung 611 an den MQTT-Vermittler 605 fort, wie in 6A.
Falls das Netzwerk jedoch nicht verfügbar ist, ergreift die Anwendung bei Empfang der Fehlermeldung 613 weitere Maßnahmen. Die Anwendung speichert die Antwortdaten (falls für die jeweilige Antwort angebracht) 615 und wählt (basierend auf der Richtlinie) eine Erwägung für ein gewünschtes Netzwerk aus. Basierend auf dieser Netzwerkbeschränkung wird eine Subskription des IVDCMs erstellt 617. Zum Beispiel könnte die Subskription Identifizierung eines vom Kunden bezahlten Netzwerks sein. Auf einer Fahrt kann jegliche Anzahl von Netzwerken verfügbar werden, und falls irgendwelche vom Kunden bezahlte sind, könnte eine Antwort 621 an die Anwendung gesendet werden. Es kann auch der Fall eintreten, dass gemäß dieser Richtlinie kostenlose Netzwerke akzeptierbar sind, so dass eine weitere Subskription kostenloser Netzwerke erstellt werden könnte. Der IVDCM beurteilt die Netzwerke, wenn sie verfügbar werden 619, und falls irgendeines die Subskriptionsparameter erfüllt, kann die entsprechende Antwort unter Identifizierung des Netzwerks gesendet werden.
Sobald das geeignete Netzwerk als verfügbar identifiziert wurde, kann die Anwendung die Anforderung erneut senden 623. Der IVDCM kann dann das identifizierte Netzwerk als zur Übertragung geeignet auswählen 625. Da das Netzwerk unverfügbar werden kann, kann der Prozess außerdem den Subskriptionsprozess wiederholen 627, falls das Netzwerk plötzlich unverfügbar wurde. Andernfalls kann das ausgewählte Netzwerk verwendet werden, um die Antwort an den MQTT-Vermittler zu senden 611. Der veranschaulichende Prozess kann zum Beispiel verwendet werden, wenn keine Übertragung gewünscht wird, sofern nicht ein spezifiziertes Netzwerk bestimmter Parameter verfügbar ist.
6C stellt ein veranschaulichendes Beispiel eines Prozesses ähnlich 6B dar. Dieser veranschaulichende Prozess ist kann verwendet werden, wenn eine Richtlinie diktiert, dass ein sekundäres Netzwerk verwendet werden soll, falls ein bevorzugtes Netzwerk nicht verfügbar ist (wie beispielsweise für Übertragungen mit hoher Priorität in den veranschaulichenden Beispielen).
In diesem veranschaulichenden Beispiel sendet 606 die Anwendung 601 wiederum die anfängliche Anforderung, welche bestimmte Netzwerkpräferenzen spezifiziert, und eine Datennutzlast. Der IVDCM 603 versucht, das geeignete verbundene physikalische Netzwerk 607 zur Übertragung der Anforderung an den MQTT-Vermittler 605 auszuwählen.
Falls das Netzwerk nicht verfügbar ist, kann eine Fehlermeldung an die Anwendung gesendet werden 613. In diesem Beispiel wartet die Anwendung nicht einfach darauf, dass ein gewünschtes Netzwerk verfügbar wird, sondern versucht stattdessen, ein sekundäres Netzwerk zur Übertragung zu verwenden. Demgemäß sendet die Anwendung eine Abfrage 629 im Hinblick auf die Konfigurationsparameter von Netzwerken, die gegenwärtig verfügbar sind. Eine Antwort vom IVDCM identifiziert die verfügbaren Netzwerke und ihre jeweiligen Parameter 631.
Die Anwendung wählt dann ein Netzwerk aus den verfügbaren Netzwerken aus. Oder, genauer gesagt, wurden in diesem Beispiel die Konfigurationsparameter jedes Netzwerks an die Anwendung zurückgesendet, und die Anwendung wählt den am meisten gewünschten Satz von Konfigurationsparameter 633 oder einen besonders wichtigen Parameter aus. Die mit der Neuübertragung der Anforderung 623 zurückgesendeten Konfigurationsparameter können dann so zugeschnitten werden, dass sie den verfügbaren Parametern entsprechen, die hoffentlich zur Auswahl des geeigneten Netzwerks führen.
Der IVDCM empfängt die Neuübertragung und wählt das physikalische Netzwerk aus, das die neuen Parameter erfüllt 625. Falls das Netzwerk unverfügbar wird, kann wiederum der Abfrageprozess wiederholt werden, oder es kann eine Subskription eines bevorzugten Netzwerks und/oder des sekundären Netzwerks erzeugt werden 627. Andernfalls wird die Anforderung unter Verwendung des ausgewählten Netzwerks an den MQTT-Vermittler 611 weitergeleitet.
Durch die Verwendung der dynamischen Antwortstrukturierung brauchen neue Abfragen einfach nur Richtlinienbeschränkungen vorzuschreiben, um Antworten dazu zu strukturieren. Dies kann gewährleisten, dass geeignete Transporterwägungen zur Einbeziehung neuer Abfragen und Antwortdaten angestellt werden, ohne dass ein bestimmtes Modul oder eine bestimmte Anwendung, das/die sich im Fahrzeug befindet, neu konfiguriert werden muss.
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 vom Gedanken und Schutzumfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener Umsetzungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE 802 PAN(Netzwerk für den persönlichen Bereich)-Protokolle [0022]
IEEE 802 LAN(lokales Netzwerk)-Protokolle [0022]
IEEE 802 PAN [0022]
IEEE 1394 [0025]
IEEE 1284 [0025]
IEEE 803.11 [0027]

Claims

System, umfassend: einen Fahrzeugprozessor, der konfiguriert ist zum: Empfangen einer Abfrage, welche Antwortnetzwerkparameter umfasst, von einer abgesetzten Instanz; Bestimmen einer Antworttransportrichtlinie basierend auf den Parametern; Bestimmen, ob ein Netzwerk mit Charakteristiken, die durch die Richtlinie in Verbindung mit Parameterwerten definiert werden, gegenwärtig verbunden ist; und Verwenden des Netzwerks, falls gegenwärtig verfügbar, um eine Abfrageantwort zu senden, andernfalls Einreihen der Antwort in eine Warteschlange, bis solch ein Netzwerk verbunden ist.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist zum: Subskribieren eines Meldungsthemas in Bezug auf ein oder mehrere Netzwerkcharakteristiken, falls das Netzwerk mit Charakteristiken, die durch die Richtlinie definiert werden, nicht verfügbar ist; und Empfangen einer Antwort basierend auf der Subskription, wenn ein Netzwerk mit Charakteristiken, die dem einen oder den mehreren Charakteristiken in Bezug auf das Meldungsthema entsprechen, verbunden ist.
System nach Anspruch 1 oder Anspruch 2, wobei Richtlinien, die auf Abfragen einer ersten Priorität, wie durch die Abfrage definiert, anwendbar sind, ein bevorzugtes Netzwerk, das durch die Richtlinie definiert wird, und ein sekundäres Netzwerk identifizieren, das verwendet werden soll, wenn das bevorzugte Netzwerk nicht verfügbar ist.
System nach Anspruch 1 oder Anspruch 2, wobei Richtlinien, die auf Abfragen mit zugehörigen, durch die Abfrage definierten Antwortnetzwerkparameterwerten hohen Intentionsniveaus anwendbar sind, eine Auswahl eines bevorzugten Netzwerks, das durch die Richtlinie in Verbindung mit Parameterwerten definiert wird, falls verfügbar, und eine Auswahl eines beliebigen verfügbaren sekundären Netzwerks vorschreiben, falls das bevorzugte Netzwerk nicht verfügbar ist.
System nach Anspruch 4, wobei die Parameterwerte hohen Intentionsniveaus einen Parameter umfassen, der Auswahl eines Netzwerks mit hoher Bandbreite vorschreibt.
System nach Anspruch 4, wobei die Parameterwerte hohen Intentionsniveaus einen Parameter umfassen, der Auswahl eines Netzwerks mit geringer Latenz vorschreibt.
System nach einem der Ansprüche 1 bis 3, wobei die Parameterwerte Spezifizierung eines bestimmten Netzwerktransporttyps umfassen.
System nach einem der Ansprüche 1 bis 3, wobei die Parameterwerte Spezifizierung einer Instanz umfassen, welche Kosten für Netzübertragung bezahlt.
System nach einem der Ansprüche 1 bis 3, wobei die Parameterwerte Spezifizierung eines bestimmten Datums und einer bestimmten Zeit für die Antwort umfassen.
System nach einem der Ansprüche 1 bis 3, wobei die Parameterwerte Spezifizierung einer WiFi-Zugangspunkt-MAC-ID umfassen, die ein spezifisches WiFi-Netzwerk definiert, das beim Senden der Antwort verwendet werden soll.
Computerimplementiertes Verfahren, umfassend: Bestimmen einer Netzwerkrichtlinie, um eine Antwort auf eine empfangene Abfrage zu senden, wobei die Abfrage Parameter umfasst, die von einem Fahrzeugcomputer verwendet werden, um basierend auf enthaltenen Parameterwerten zu bestimmen, welche Netzwerkrichtlinie verwendet werden soll, wobei die Richtlinie ein Netzwerk mit Charakteristiken definiert, welche Parameterwerten entsprechen; Verwenden des Netzwerks, falls gegenwärtig verfügbar, zum Senden der Antwort; und Einreihen der Antwort in eine Warteschlange, falls das Netzwerk gegenwärtig nicht verfügbar ist.
Verfahren nach Anspruch 11, wobei die Parameter eine Netzwerktransporttyppräferenz umfassen.
Verfahren nach Anspruch 11, wobei die Parameter eine Spezifizierung einer Instanz umfassen, welche Kosten für Netzübertragung bezahlt.
Verfahren nach Anspruch 11, wobei die Parameter eine Spezifizierung eines bestimmten Datums und einer bestimmten Zeit für die Antwort umfassen.
Verfahren nach Anspruch 11, wobei die Parameter eine Spezifizierung einer WiFi-Zugangspunkt-MAC-ID umfassen, die ein spezifisches WiFi-Netzwerk definiert, das beim Senden der Antwort verwendet werden soll.
Verfahren nach einem der Ansprüche 11 bis 15, ferner umfassend: Bestimmen eines sekundären Netzwerks, das durch die bestimmte Richtlinie definiert wird, zur Verwendung vor dem Einreihen in eine Warteschlange, falls das anfängliche Netzwerk, das durch die Richtlinie definiert wird, nicht verfügbar ist.
Verfahren nach Anspruch 16, wobei die Richtlinie das sekundäre Netzwerk als ein beliebiges verfügbares Netzwerk definiert.
Verfahren nach Anspruch 17, wobei die Parameterwerte mindestens einen Parameterwert hohen Intentionsniveaus umfassen.
Verfahren nach Anspruch 18, wobei der Parameterwert hohen Intentionsniveaus mindestens einer von einer Latenzpräferenz oder einer Bandbreitenpräferenz ist.
Computerimplementiertes Verfahren, umfassend: Bestimmen einer Netzwerkrichtlinie, um eine Antwort auf eine empfangene Abfrage zu senden, wobei die Abfrage Parameter umfasst, die von einem Fahrzeugcomputer verwendet werden, um basierend darauf, welche Parameter in der Abfrage enthalten sind, zu bestimmen, welche Netzwerkrichtlinie verwendet werden soll, wobei die Richtlinie ein Netzwerk mit Charakteristiken definiert, welche Parameterwerten entsprechen, die in der Abfrage enthalten sind; Verwenden des Netzwerks, falls verfügbar, um die Antwort zu senden; und Einreihen der Antwort in eine Warteschlange, falls das Netzwerk nicht verfügbar ist.