DE102018118153A1

DE102018118153A1 - Konnektivität über virtuelle netzwerkschnittstelle

Info

Publication number: DE102018118153A1
Application number: DE102018118153.1A
Authority: DE
Inventors: Pramita Mitra; Pietro Buttolo; Basavaraj Tonshal; Qianyi WANG; Gary Steven Strumolo; Kelly Lee Zechel; Brian Nash; Theodore Wingrove
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-07-28
Filing date: 2018-07-26
Publication date: 2019-01-31
Also published as: CN109309660A; US10141967B1

Abstract

Eine Mobilvorrichtung empfängt eine eine Nachricht von einer Fahrzeugrechenplattform über RPC (Remote Process Communication), aktualisiert eine Ursprungsadresse der Nachricht, um die Mobilvorrichtung anzuzeigen, sendet die Nachricht an eine Zieladresse der Nachricht, empfängt eine Antwortnachricht von dem Ziel, aktualisiert eine Zieladresse der Antwortnachricht, um die Rechenplattform anzuzeigen und sendet die Antwortnachricht über die RPC an die Rechenplattform. Eine Rechenvorrichtung konstruiert eine RPC(Remote Procedure Call)-Nachricht von einer Anwendung für eine virtuelle Netzwerkschnittstelle für eine von einer Fahrzeuganwendung empfangene Anforderung eines Netzwerkprotokolls, das von einer Mobilvorrichtung nicht unterstützt wird, und sendet den RPC an die Mobilvorrichtung, um die Mobilvorrichtung dazu zu veranlassen, eine Ursprungsadresse der Anforderung zu aktualisieren, um die Mobilvorrichtung anzuzeigen und die Anforderung an eine Zieladresse der Anforderung zu senden.

Description

TECHNISCHES GEBIET
Aspekte dieser Offenbarung betreffen im Allgemeinen eine virtuelle Netzwerkschnittstelle zur Verwendung durch Fahrzeuganwendungen, die auf Netzwerkkonnektivität einer verbundenen Mobilvorrichtung zugreifen.
ALLGEMEINER STAND DER TECHNIK
Mobilvorrichtungen, wie etwa Smartphones, können mit einer Fahrzeug-Haupteinheit verbunden sein, um den Fahrzeuginsassen verbundene Dienste bereitzustellen. Diese verbundenen Dienste können Freisprecheinrichtungen, Audiostreaming und Integration mit eingebrachten Anwendungen von Mobilvorrichtungen beinhalten. Anwendungen, die von der Mobilvorrichtung ausgeführt werden, können die Netzwerkkonnektivität der Mobilvorrichtung nutzen. Anwendungen, die von dem Fahrzeug ausgeführt werden, können jedoch eine Verbindung mit der Mobilvorrichtung (z. B. über WLAN, BLUETOOTH oder USB) erfordern, um die Netzwerkkonnektivität der Mobilvorrichtung zu nutzen.
KURZDARSTELLUNG
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet eine Mobilvorrichtung. Die Mobilvorrichtung ist dazu programmiert, eine Nachricht von einer Fahrzeugrechenplattform über RPC (Remote Process Communication) zu empfangen, eine Ursprungsadresse der Nachricht zu aktualisieren, um die Mobilvorrichtung anzuzeigen, die Nachricht an eine Zieladresse der Nachricht zu senden, eine Antwortnachricht von dem Ziel zu empfangen, eine Zieladresse der Antwortnachricht zu aktualisieren, um die Rechenplattform anzuzeigen und die Antwortnachricht über die RPC an die Rechenplattform zu senden.
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet eine Rechenplattform. Die Rechenvorrichtung ist dazu programmiert, eine RPC(Remote Procedure Call)-Nachricht von einer Anwendung für eine virtuelle Netzwerkschnittstelle zu konstruieren für eine von einer Fahrzeuganwendung empfangene Anforderung eines Netzwerkprotokolls, das von einer Mobilvorrichtung nicht unterstützt wird, und den RPC an die Mobilvorrichtung zu senden, um die Mobilvorrichtung dazu zu veranlassen, eine Ursprungsadresse der Anforderung zu aktualisieren, um die Mobilvorrichtung anzuzeigen und die Anforderung an eine Zieladresse der Anforderung zu senden.
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein Verfahren Empfangen durch eine Rechenplattform von einer Mobilvorrichtung von Anzeigen von Netzwerkprotokollen, die von der Mobilvorrichtung nativ unterstützt werden; Empfangen einer Anforderung von einer Fahrzeuganwendung, die ein Netzwerkprotokoll nutzt; Senden der Anforderung an die Mobilvorrichtung zur Handhabung durch eine native Anwendung der Mobilvorrichtung als Reaktion darauf, dass das Netzwerkprotokoll nativ unterstützt wird, und anderenfalls Senden der Anforderung an die mobile Anwendung unter Verwendung eines Proxying - Ansatzes.
Figurenliste

1 veranschaulicht ein beispielhaftes Diagramm eines Systems, das dazu konfiguriert ist, einem Fahrzeug Telematik-Dienste bereitzustellen;
2 veranschaulicht ein beispielhaftes Datenflussdiagramm einer Fahrzeuganwendung, die die Netzwerkkonnektivität der Mobilvorrichtung über einen Netzwerkschnittstellen-Proxy nutzt;
3 veranschaulicht einen beispielhaften Prozess für die Rechenplattform, der es der Fahrzeuganwendung ermöglicht, die Netzwerkkonnektivität der Mobilvorrichtung zu verwenden; und
4 veranschaulicht einen beispielhaften Prozess für die Mobilvorrichtung, der es der Fahrzeuganwendung ermöglicht, die Netzwerkkonnektivität der Mobilvorrichtung zu verwenden.

DETAILLIERTE BESCHREIBUNG
Nach Bedarf sind in der vorliegenden Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt sein kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Einzelheiten bestimmter Komponenten zu zeigen. Demnach sind hierin offenbarte spezifische strukturelle und funktionelle Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als repräsentative Basis, um den Fachmann den vielfältigen Gebrauch der vorliegenden Erfindung zu lehren.
Wenn eine durch ein Fahrzeug ausgeführte Anwendung unter Verwendung eines Standardprotokolls, wie etwa HTTP (Hypertext Transfer Protocol), Daten anfordert, kann das Fahrzeug die HTTP-Header-Informationen der verbundenen Vorrichtung (z. B. über Smart Device Link (SDL)) bereitstellen und die Mobilvorrichtung kann eine Anwendung ausführen, die das Standardprotokoll als einen Ferndienst implementiert, um Daten unter Verwendung der Mobilvorrichtung hoch- oder herunterzuladen. Wenn die Fahrzeuganwendung jedoch ein Anwendungsschichtprotokoll, wie etwa MQTT (MQ Telemetry Transport) verwendet, das nicht von einem Dienst der Mobilvorrichtung unterstützt wird, kann die Mobilvorrichtung nicht dazu in der Lage sein, die Anforderung für die Fahrzeuganwendung zu erfüllen.
Auch wenn ein Fahrzeuginsasse eine Mobilvorrichtung dazu konfigurieren kann, als Hotspot für das Fahrzeug zu agieren, um diese als Modem zu verwenden, kann eine derartige Konfiguration verhindern, dass der Insasse die Mobilvorrichtung zur drahtlosen Projektion an die Fahrzeugbenutzerschnittstelle verwenden kann. Desweiteren erfordert Hotspot-Funktionalität üblicherweise, dass ein Fahrzeuginsasse den im Allgemeinen nicht aktivierten Hotspot aktiv aktiviert.
Ein verbessertes System und ein verbessertes Verfahren, um Fahrzeuganwendungen zu ermöglichen, die Konnektivität der Mobilvorrichtung nutzen ist bereitgestellt. Eine von der Fahrzeugrechenplattform ausgeführte Anwendung nutzt eine virtuelle Netzwerkschnittstelle, um eine Netzwerkschnittstelle einer verbundenen Vorrichtung darzustellen. Unter Verwendung eines Packet-Sniffer (z. B. des Schicht-drei-Packet-Sniffer) werden von der Anwendung erzeugte IP-Pakete erfasst. Diese IP-Pakete können unter Verwendung eines Remote-Procedure-Mechanismus (z. B. des RPC-Mechanismus von SDL) an die Mobilvorrichtung übertragen werden, wobei die Quell-IP-Adresse des Pakets in die IP-Adresse der Mobilvorrichtung geändert wird. Dieses aktualisierte IP-Paket wird dann von der Mobilvorrichtung an die Ziel-IP gesendet. Wenn eine Antwort auf das Paket an der Mobilvorrichtung zurückempfangen wird, wird die Paketadresse erneut aktualisiert, und das Paket wird über den RPC-Mechanismus (z. B. über den SDL-Kern) zurückgeleitet und damit zurück zur Fahrzeuganwendung. Die virtuelle Netzwerkschnittstelle kann ferner Fahrzeuganwendungen ermöglichen, aktive Netzwerkzustandsinformationen in Bezug auf die verbundene Mobilvorrichtung (z. B. Mobilfunkverbindung, WLAN-Verbindung usw.) zu empfangen. Weitere Aspekte der Offenbarung sind nachstehend ausführlich beschrieben.
1 veranschaulicht eine beispielhafte Darstellung eines Systems 100, das dazu konfiguriert ist, einem Fahrzeug 102 Telematik-Dienste bereitzustellen. Das Fahrzeug 102 kann verschiedene Arten von Personenkraftwagen beinhalten, wie zum Beispiel Softroader (CUV), Geländewagen (SUV), LKW, Wohnmobile (RV), Boote, Flugzeuge oder andere mobile Maschinen zum Befördern von Personen oder Transportieren von Gütern. Telematik-Dienste können unter anderem Navigation, Routenführungen, Fahrzeugdiagnosen, lokale Unternehmenssuche, Unfallmeldungen und Freisprecheinrichtungen beinhalten. In einem Beispiel kann das System 100 das SYNC-System enthalten, hergestellt durch die Ford Motor Company in Dearborn, MI. Es ist anzumerken, dass es sich bei dem veranschaulichten System 100 lediglich um ein Beispiel handelt und mehr, weniger und/oder anders angeordnete Elemente verwendet werden können.
Die Rechenplattform 104 kann einen oder mehrere Prozessoren 106 beinhalten, die dazu konfiguriert sind, Anweisungen, Befehle und andere Routinen durchzuführen, um die hier beschriebenen Prozesse zu unterstützen. Beispielsweise kann die Rechenplattform 104 dazu konfiguriert sein, Anweisungen von Fahrzeuganwendungen 110 auszuführen, um Funktionen, wie etwa Navigation, Unfallmeldung, Satellitenradioentschlüsselung und Freisprecheinrichtung, bereitzustellen. Solche Anweisungen und andere Daten können nicht flüchtig unter Verwendung einer Vielzahl von Arten von elektronisch lesbaren Speichermedien 112 vorgehalten werden. Das computerlesbare Medium 112 (auch als prozessorlesbares Medium oder Speicher bezeichnet) beinhaltet ein beliebiges nicht-transitorisches Medium (z. B. ein physisches Medium), das an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, die durch den Prozessor 106 der Rechenplattform 104 gelesen werden können. Durch den Computer ausführbare Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, welche unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt wurden, einschließlich unter anderem und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL.
Die Rechenplattform 104 kann mit verschiedenen Merkmalen bereitgestellt sein, durch welche die Fahrzeuginsassen eine Schnittstelle mit der Rechenplattform 104 herstellen können. Zum Beispiel kann die Rechenplattform 104 einen Audioeingang 114 beinhalten, welcher dazu konfiguriert ist, er Sprachbefehle von Fahrzeuginsassen über ein verbundenes Mikrofon 116 zu empfangen, und einen zusätzlichen Audioeingang 118, welcher dazu konfiguriert ist, Audiosignale von verbundenen Vorrichtungen zu empfangen. Bei dem zusätzlichen Audioeingang 118 kann es sich um eine physische Verbindung, wie zum Beispiel ein Stromkabel oder ein Glasfaserkabel, oder einen drahtlosen Eingang handeln, wie etwa eine BLUETOOTH-Audioverbindung. In einigen Beispielen kann der Audioeingang 114 dazu konfiguriert sein, Audioverarbeitungsfunktionen bereitzustellen, wie etwa das Vorverstärken von niedrigen Signalen und das Umwandeln von analogen Eingaben in digitale Daten zum Verarbeiten durch den Prozessor 106.
Die Rechenplattform 104 kann ebenfalls einen oder mehrere Audioausgänge 120 zu einem Eingang eines Audiomoduls 122 mit einer Audiowiedergabefunktionalität bereitstellen. In anderen Beispielen kann die Rechenplattform 104 den Audioausgang durch die Verwendung eines oder mehrerer fest zugeordneter Lautsprecher (nicht abgebildet) für den Insassen bereitstellen. Das Audiomodul 122 kann eine Eingangswähleinheit 124 beinhalten, welche dazu konfiguriert ist, einem Audioverstärker 128 zum Wiedergeben über die Fahrzeuglautsprecher 130 oder Kopfhörer (nicht abgebildet) Audioinhalte von einer ausgewählten Audioquelle 126 bereitzustellen. Die Audioquellen 126 können beispielsweise entschlüsselte amplitudenmodulierte (AM) oder frequenzmodulierte (FM) Radiosignale und Audiosignale von Audiowiedergaben von Compact Disks (CDs) oder Digital Versatile Disks (DVDs) beinhalten. Die Audioquellen 126 können ferner Audiodaten beinhalten, welche von der Rechenplattform 104 empfangen wurden, wie etwa durch die Rechenplattform 104 erzeugte Audioinhalte, von Flash-Speichersticks entschlüsselte Audioinhalte, welche mit einem USB(universeller serieller Bus)-Teilsystem 132 der Rechenplattform 104 verbunden sind, und vom zusätzlichen Audioeingang 118 durch die Rechenplattform 104 geleitete Audioinhalte.
Die Rechenplattform 104 kann eine Sprachschnittstelle 134 verwenden, um eine Freisprechschnittstelle für die Rechenplattform 104 bereitzustellen. Die Sprachschnittstelle 134 kann eine Spracherkennung von über das Mikrofon 116 empfangenen Audiodaten gemäß einer Standardgrammatik, die verfügbare Befehlsfunktionen beschreibt und das Erzeugen von Sprachaufforderungen zur Ausgabe über das Audiomodul 122 unterstützen. Die Sprachschnittstelle 134 kann Techniken der probabilistischen Spracherkennung unter Verwendung der Standardgrammatik 176 im Vergleich zur eingegebenen Sprache nutzen. In vielen Fällen kann die Sprachschnittstelle 134 eine Standard-Benutzerprofileinstellung zur Verwendung durch die Spracherkennungsfunktionen beinhalten, um zu ermöglichen, dass die Spracherkennung so eingestellt wird, dass sie im Durchschnitt gute Ergebnisse bereitstellt, was zu positiven Erfahrungen für die maximale Anzahl anfänglicher Benutzer führt. In einigen Fällen kann das System dazu konfiguriert sein, die durch die Eingangswähleinheit 124 vorgegebene Audioquelle zeitweise stummzuschalten oder anderweitig zu überspielen, wenn eine Audioaufforderung durch die Rechenplattform 104 ausgegeben werden kann und eine andere Audioquelle 126 zur Wiedergabe ausgewählt ist.
Die Standardgrammatik 135 beinhaltet Daten, um der Sprachschnittstelle 134 zu ermöglichen, eine gesprochene Eingabe mit Wörtern und Wendungen abzugleichen, die durch Regeln in der Standardgrammatik 135 definiert sind. Die Standardgrammatik 135 kann dazu ausgestaltet sein, einen vordefinierten Satz von Wörtern oder Wendungen zu erkennen. Eine komplexere Standardgrammatik 135 kann dazu ausgestaltet sein, um semantische Inhalte aus einer Vielzahl von Äußerungen des Benutzers zu erkennen und zu organisieren. In einem Beispiel kann die Standardgrammatik 135 Befehle beinhalten, um Telematik-Funktionen des Fahrzeugs 102, wie etwa „Anruf“, „Führungen“ oder „Navigationsziel einstellen“ einzuleiten. In einem anderen Beispiel kann die Standardgrammatik 135 Befehle beinhalten, um eine andere Funktionalität des Fahrzeugs 102 zu steuern, wie etwa „Fenster öffnen“, „Frontscheinwerfer an“ oder „Radiovoreinstellung drei einstellen“.
Die Rechenplattform 104 kann zudem Eingaben von Steuerungen 136 einer Mensch-Maschine-Schnittstelle (Human-Machine Interface - HMI) empfangen, die dazu konfiguriert sind, eine Interaktion zwischen Insassen und Fahrzeug 102 bereitzustellen. Beispielsweise kann die Rechenplattform 104 mit einer oder mehreren Tasten oder anderen HMI-Steuerungen eine Schnittstelle herstellen, welche dazu konfiguriert sind, Funktionen auf der Rechenplattform 104 aufzurufen (z. B. Audiotasten am Lenkrad, eine Sprechtaste, Steuerungen auf der Armaturentafel usw.). Die Rechenplattform 104 kann zudem eine oder mehrere Anzeigen 138 antreiben oder anderweitig damit kommunizieren, die dazu konfiguriert sind, über eine Videosteuerung 140 eine visuelle Ausgabe für die Fahrzeuginsassen bereitzustellen. In einigen Fällen kann es sich bei der Anzeige 138 um einen Touchscreen handeln, der ferner dazu konfiguriert ist, berührungsbasierte Eingaben des Benutzers über die Videosteuerung 140 zu empfangen, wohingegen in anderen Fällen die Anzeige 138 lediglich eine Anzeige ohne die Möglichkeit zur berührungsbasierten Eingabe sein kann.
Die Rechenplattform 104 kann ferner dazu konfiguriert sein, über ein oder mehrere fahrzeuginterne Netzwerke 142 mit anderen Komponenten des Fahrzeugs 102 zu kommunizieren. Die fahrzeuginternen Netzwerke 142 können beispielsweise eines oder mehrere der Folgenden beinhalten: ein lokales Netzwerk der Fahrzeugsteuerung (CAN), ein Ethernet-Netzwerk oder eine mediengebundene Systemübertragung (MOST). Durch die fahrzeuginternen Netzwerke 142 kann die Rechenplattform 104 mit anderen Systemen im Fahrzeug 102 kommunizieren, wie etwa einem Fahrzeugmodem 144 (bei einigen Konfigurationen unter Umständen nicht vorhanden), einem GPS(Global Positioning System)-Modul 146, welches dazu konfiguriert ist, den aktuellen Standort und die Fahrtrichtung des Fahrzeugs 102 bereitzustellen, und verschiedenen Fahrzeug-ECUs 148, die dazu konfiguriert sind, mit der Rechenplattform 104 zusammenzuarbeiten. Unter anderem können die Fahrzeug-ECUs 148 Folgendes beinhalten: ein Antriebsstrangsteuermodul, welches dazu konfiguriert ist, um die Betriebskomponenten des Motors zu steuern (z. B. Leerlaufregler, Komponenten der Kraftstoffzufuhr, Komponenten zur Schadstoffausstoßüberwachung usw.) und die Betriebskomponenten des Motors zu überwachen (z. B. Status von Diagnosecodes des Motors); ein Karosseriesteuermodul, welches dazu konfiguriert ist, unterschiedliche Funktionen zur Leistungssteuerung zu verwalten, wie etwa Außenbeleuchtung, Innenraumbeleuchtung, schlüsselloser Zugang, Fernstart, und den Status von Zugangspunkten überprüft (z. B. Schließstatus der Motorhaube, der Türen und/oder des Kofferraums des Fahrzeugs 102); ein Funk-Sender-Empfängermodul, welches dazu konfiguriert ist, mit Funkschlüsseln oder anderen lokalen Vorrichtungen des Fahrzeugs 102 zu kommunizieren; und ein Klimasteuerungsverwaltungsmodul, welches dazu konfiguriert ist, die Heiz- und Kühlsystemkomponenten zu steuern und zu überwachen (z. B. Steuerung von Kompressorkupplung und Gebläselüfter, Temperatursensorinformationen usw.).
Wie veranschaulicht, können das Audiomodul 122 und die HMI-Steuerungen 136 über ein erstes fahrzeuginternes Netzwerk 142-A mit der Rechenplattform 104 kommunizieren und das Fahrzeugmodem 144, das GPS-Modul 146 und die Fahrzeug-ECUs 148 können über ein zweites fahrzeuginternes Netzwerk 142-B mit der Rechenplattform 104 kommunizieren. In anderen Beispielen kann die Rechenplattform 104 mit mehr oder weniger fahrzeuginternen Netzwerken 142 verbunden sein. Zusätzlich oder alternativ können eine oder mehrere HMI-Steuerungen 136 oder andere Komponenten über andere fahrzeuginterne Netzwerke 142, die von den abgebildeten Netzwerken abweichen, oder direkt ohne Verbindung zu einem fahrzeuginternen Netzwerk 142 mit der Rechenplattform 104 verbunden sein.
Die Rechenplattform 104 kann zudem dazu konfiguriert sein, mit Mobilvorrichtungen 152 der Fahrzeuginsassen zu kommunizieren. Bei den Mobilvorrichtungen 152 kann es sich um beliebige verschiedener Arten von tragbaren Rechenvorrichtungen handeln, wie etwa Mobiltelefone, Tablet-Computer, Smartwatches, Laptop-Computer, tragbare Musikwiedergabevorrichtungen oder andere Vorrichtungen, die zur Kommunikation mit der Rechenplattform 104 in der Lage sind. In vielen Beispielen kann die Rechenplattform 104 einen drahtlosen Sender-Empfänger 150 (z. B. ein BLUETOOTH-Modul, einen ZIGBEE-Sender-Empfänger, einen WLAN-Sender-Empfänger, einen IrDA-Sender-Empfänger, einen RFID-Sender-Empfänger usw.) beinhalten, welcher dazu konfiguriert ist, mit einem kompatiblen drahtlosen Sender-Empfänger 154 der Mobilvorrichtung 152 zu kommunizieren. Zusätzlich oder alternativ kann die Rechenplattform 104 über eine drahtgebundene Verbindung mit der Mobilvorrichtung 152 kommunizieren, wie etwa über eine USB-Verbindung zwischen der Mobilvorrichtung 152 und dem USB-Teilsystem 132. In einigen Beispielen kann die Mobilvorrichtung 152 batteriebetrieben sein, während die Mobilvorrichtung 152 in anderen Fällen mindestens einen Teil ihrer Leistung über eine drahtgebundene Verbindung von dem Fahrzeug 102 bezieht.
Das Kommunikationsnetzwerk 156 kann Vorrichtungen, welche mit dem Kommunikationsnetzwerk 156 verbunden sind, Verbindungsdienste bereitstellen, wie etwa paketvermittelte Netzwerkdienste (z. B. Internetzugang, VoIP-Kommunikationsdienste). Ein Beispiel für ein Kommunikationsnetzwerk 156 kann ein Mobilfunknetz beinhalten. Mobilvorrichtungen 152 können eine Netzwerkkonnektivität zum Kommunikationsnetzwerk 156 über ein Vorrichtungsmodem 158 der Mobilvorrichtung 152 bereitstellen. Um die Kommunikation über das Kommunikationsnetzwerk 156 zu ermöglichen, können Mobilvorrichtungen 152 mit einzigartigen Vorrichtungskennzeichen (z. B. Nummern für Mobilvorrichtungen (MDNs), IP(Internet Protocol)-Adressen usw.) assoziiert sein, um die Kommunikation der Mobilvorrichtungen 152 über das Kommunikationsnetzwerk 156 zu identifizieren. In einigen Fällen können Insassen des Fahrzeugs 102 oder Vorrichtungen mit der Berechtigung zum Verbinden mit der Rechenplattform 104 durch die Rechenplattform 104 gemäß den Daten zu gepaarten Vorrichtungen 160 identifiziert werden, welche im Speichermedium 112 gespeichert sind. Die Daten 160 zu gekoppelten Vorrichtungen können zum Beispiel die einzigartigen Vorrichtungskennzeichen der Mobilvorrichtungen 152 anzeigen, die zuvor mit der Rechenplattform 104 des Fahrzeugs 102 gekoppelt wurden, sodass die Rechenplattform 104 ohne Eingreifen des Benutzers automatisch erneut mit den Mobilvorrichtung 152 verbunden werden kann, auf die in den Daten 160 zu gekoppelten Vorrichtungen verwiesen wird.
Wenn eine Mobilvorrichtung 152, die Netzwerkkonnektivität unterstützt, mit der Rechenplattform 104 gepaart wird, kann die Mobilvorrichtung 152 der Rechenplattform 104 das Verwenden der Netzwerkkonnektivität des Vorrichtungsmodems 158 gestatten, um über das Kommunikationsnetzwerk 156 mit dem entfernten Telematik-Server 162 oder der entfernten Rechenvorrichtung zu kommunizieren. In einem Beispiel kann die Rechenplattform 104 einen Daten-über-Sprache-Plan oder einen Datenplan der Mobilvorrichtung 152 zum Kommunizieren von Informationen zwischen der Rechenplattform 104 und dem Kommunikationsnetzwerk 156 verwenden. Zusätzlich oder alternativ kann die Rechenplattform 104 das Fahrzeugmodem 144 verwenden, um Informationen zwischen der Rechenplattform 104 und dem Kommunikationsnetzwerk 156 zu kommunizieren, ohne dabei Kommunikationseinrichtungen der Mobilvorrichtung 152 zu verwenden.
Ähnlich der Rechenplattform 104 kann die Mobilvorrichtung 152 einen oder mehrere Prozessoren 164 beinhalten, die dazu konfiguriert sind, Anweisungen von mobilen Anwendungen 170 auszuführen, die von einem Speichermedium 168 der Mobilvorrichtung 152 auf einen Speicher 166 der Mobilvorrichtung 152 geladen werden. In einigen Beispielen können die mobilen Anwendungen 170 dazu konfiguriert sein, mit der Rechenplattform 104 über den drahtlosen Sender-Empfänger 154 und mit dem entfernten Telematik-Server 162 oder anderen Netzwerkdiensten über das Vorrichtungsmodem 158 zu kommunizieren.
Die Rechenplattform 104 kann beispielsweise eine Vorrichtungsverknüpfungsschnittstelle 172 beinhalten, um die Integration von Funktionalität der mobilen Anwendungen 170, die dazu konfiguriert sind, mit einem Vorrichtungsverknüpfungsanwendungskern 174, der von der Mobilvorrichtung 152 ausgeführt wird, zu kommunizieren, zu ermöglichen. In einigen Beispielen können die mobilen Anwendungen 170, die eine Kommunikation mit der Vorrichtungsverknüpfungsschnittstelle 172 unterstützen, die Funktionalität des Vorrichtungsverknüpfungsanwendungskerns 174 statisch mit der binären Darstellung der mobilen Anwendung 170 verknüpfen oder anderweitig in diese integrieren. In anderen Beispielen können die mobilen Anwendungen 170, die eine Kommunikation mit der Vorrichtungsverknüpfungsschnittstelle 172 unterstützen, auf eine Anwendungsprogrammierschnittstelle (Application Programming Interface - API) eines gemeinsamen oder getrennten Vorrichtungsverknüpfungsanwendungskerns 174 zugreifen, um die Kommunikation mit der Vorrichtungsverknüpfungsschnittstelle 172 zu ermöglichen.
Die Integration von Funktionalität, die von der Vorrichtungsverknüpfungsschnittstelle bereitgestellt wird, kann beispielsweise die Fähigkeit mobiler Anwendungen 170, die von der Mobilvorrichtung 152 ausgeführt werden, zusätzliche Sprachbefehle in die Grammatik von über die Sprachschnittstelle 134 verfügbaren Befehlen zu integrieren, beinhalten. Die Vorrichtungsverknüpfungsschnittstelle 172 kann den mobilen Anwendungen 170 über die fahrzeuginternen Netzwerke 142 zudem Zugriff auf Fahrzeuginformationen bereitstellen, die der Rechenplattform 104 zur Verfügung stehen. Ein Beispiel für eine Vorrichtungsverknüpfungsschnittstelle 172 kann die SYNC-APPLINK-Komponente des SYNC-Systems darstellen, bereitgestellt durch die Ford Motor Company in Dearborn, MI. Andere Beispiele für Vorrichtungsverknüpfungsschnittstellen 172 können MIRRORLINK, APPLE CARPLAY und ANDROID AUTO beinhalten.
2 veranschaulicht ein beispielhaftes Datenflussdiagramm 200 einer Fahrzeuganwendung 110, die die Netzwerkkonnektivität der Mobilvorrichtung 152 nutzt. Diese Konnektivität kann mittels einer Anwendung für ein virtuelles Netzwerk 202 der Rechenplattform 104 und einer mobilen Anwendung für ein virtuelles Netzwerk 208 der Mobilvorrichtung 152 genutzt werden.
Die Anwendung für die virtuelle Netzwerkschnittstelle 202 kann ein Beispiel für eine Fahrzeuganwendung 110 sein, die in dem Speicher 112 gespeichert wird und von dem einen oder den mehreren Prozessoren 106 der Rechenplattform 104 ausgeführt wird. Die Anwendung für die virtuelle Netzwerkschnittstelle 202 kann einen virtuellen Schnittstellen-Manager 204 und ein virtuelles Schnittstellen-Plugin 206 beinhalten. Der virtuelle Schnittstellen-Manager 204 kann dazu konfiguriert sein, IP(Internet Protocol)-Pakete oder andere Daten von der Fahrzeuganwendung 110 zu empfangen, wie etwa Anforderungen erhalten oder hochladen, und diese Anforderungen in einem Tunnel zur Verarbeitung durch das virtuelle Schnittstellen-Plugin 206 einzustellen. In einem Beispiel verwendet der virtuelle Schnittstellen-Manager 204 der Anwendung für das virtuelle Netzwerk 202 einen Packet-Sniffer (z. B. einen Schicht-drei-Packet-Sniffer), um von der Fahrzeuganwendung 110 erzeugte IP-Pakete zu erfassen.
Das virtuelle Schnittstellen-Plugin 206 kann dazu konfiguriert sein, auf den Tunnelverkehr zuzugreifen, um den Verkehr an die Vorrichtungsverknüpfungsschnittstelle 172 zu senden. In einigen Beispielen kann die Anwendung für die virtuelle Netzwerkschnittstelle 202 dazu konfigurierbar sein, verschiedene Vorrichtungsverknüpfungsschnittstellen 172 zu nutzen. In derartigen Beispielen kann die Anwendung für die virtuelle Netzwerkschnittstelle 202 mehrere virtuelle Schnittstellen-Plugins 206 beinhalten oder anderweitig auf diese Zugriff haben, und kann das virtuelle Schnittstellen-Plugin 206, das der verwendeten spezifischen Vorrichtungsverknüpfungsschnittstelle 172 entspricht, nutzen.
Die Vorrichtungsverknüpfungsschnittstelle 172 und der Vorrichtungsverknüpfungsanwendungskern 174 können dazu konfiguriert sein, einen Kommunikationsverknüpfung zwischen der Rechenplattform 104 und der Mobilvorrichtung 152 aufrecht zu erhalten. In einem Beispiel kann die Kommunikationsverknüpfung durch Dienste des drahtlosen Sender-Empfängers 150 der Rechenplattform 104 (z. B. für eine WLAN- oder BLUETOOTH-Verknüpfung) oder durch die Dienste des USB-Teilsystems 132 der Rechenplattform 104 (z. B. für eine USB-Verknüpfung) unterstützt werden.
Das virtuelle Schnittstellen-Plugin 206 kann die Vorrichtungsverknüpfungsschnittstelle 172 nutzen, um die von dem virtuellen Schnittstellen-Manager 204 überwachten IP-Pakete an die Mobilvorrichtung 152 zu übertragen. In einem Beispiel kann das virtuelle Schnittstellen-Plugin 206 einen Remote-Procedure-Mechanismus (z. B. den über SDL verfügbaren RPC-Mechanismus) nutzen, um die Pakete an die Mobilvorrichtung 152 zu senden. Der Vorrichtungsverknüpfungsanwendungskern 174 kann Daten von der Vorrichtungsverknüpfungsschnittstelle 172 empfangen und die empfangenen Daten der mobilen Anwendung für das virtuelle Netzwerk 208 bereitstellen.
Die mobile Anwendung für das virtuelle Netzwerk 208 kann ein Beispiel für eine mobile Anwendung 170 sein, die in dem Speicher 168 gespeichert wird und von dem einen oder den mehreren Prozessoren 164 der Mobilvorrichtung 152 ausgeführt wird. Die mobile Anwendung für das virtuelle Netzwerk 208 kann einen IP-Daten-Manager 210 und einen Proxy 212 beinhalten. Der IP-Daten-Manager 210 kann dazu konfiguriert sein, die binären Paketdaten von dem Vorrichtungsverknüpfungsanwendungskern 174 zu empfangen und zu entschlüsseln. Der IP-Daten-Manager 210 kann ferner dazu konfiguriert sein, die empfangenen IP-Paketdaten an den Proxy 212 zu senden.
Der Proxy 212 kann dazu konfiguriert sein, ein neues IP-Paket für die von dem IP-Daten-Manager 210 empfangenen Daten zu erstellen. Der Proxy 212 kann zudem die Quell-IP-Adresse des Pakets so aktualisieren, dass sie die IP-Adresse der Mobilvorrichtung 152 ist, nicht die der Rechenplattform 104. Der Proxy 212 kann ferner ein TCP-Socket erstellen und das IP-Datenpaket auf die physische Netzwerkschnittstelle 214 der Mobilvorrichtung 152 schreiben. Dieses aktualisierte IP-Paket kann dann an das Ziel-IP von der Mobilvorrichtung 152 über die physische Netzwerkschnittstelle 214 gesendet werden.
Eine Antwort auf das Paket kann an der physischen Netzwerkschnittstelle 214 der Mobilvorrichtung 152 zurückempfangen werden. Das Antwortpaket kann dann an die mobile Anwendung für das virtuelle Netzwerk 208 übergeben werden. Der Proxy 212 kann das Antwortpaket empfangen, das Antwortpaket wieder mit den Adressinformationen der Rechenplattform 104 aktualisieren und es an den IP-Daten-Manager 210 zurückgeben. Der IP-Daten-Manager 210 kann eine binäre Darstellung konstruieren und die Darstellung an den Vorrichtungsverknüpfungsanwendungskern 174 übergeben. Der Vorrichtungsverknüpfungsanwendungskern 174 kann die Antwort über den RPC-Mechanismus an die Vorrichtungsverknüpfungsschnittstelle 172 zurücksenden, um die Antwort an die Anwendung für die virtuelle Netzwerkschnittstelle 202 zu übertragen. Das virtuelle Schnittstellen-Plugin 206 der Anwendung für das virtuelle Netzwerk 202 kann das Paket gemäß dem Protokoll des virtuellen Schnittstellen-Plugins 206 entschlüsseln und kann das entschlüsselte Paket dem virtuellen Schnittstellen-Manager 204 bereitstellen, um zu dem Tunnel hinzugefügt zu werden. Die Fahrzeuganwendung 110 kann das entschlüsselte Paket dementsprechend aus dem Tunnel lesen. Dementsprechend kann die Fahrzeuganwendung 110 die Verbindung der Mobilvorrichtung 152 zu dem Kommunikationsnetzwerk 156 nutzen, ohne Rücksicht darauf, ob die Mobilvorrichtung 152 das jeweilige, von der Fahrzeuganwendung 110 genutzte Protokoll unterstützt.
Zusätzlich zu dem Strom von Paketen kann die virtuelle Netzwerkschnittstelle ferner Fahrzeuganwendungen 110 ermöglichen, aktive Netzwerkzustandsinformationen in Bezug auf die verbundene Mobilvorrichtung 152 (z. B. Mobilfunkverbindung, WLAN-Verbindung usw.) zu empfangen. In einem Beispiel kann die Fahrzeuganwendung 110 Netzwerkzustandsinformationen von der Anwendung für das virtuelle Netzwerk 202 anfordern, was wiederum das virtuelle Schnittstellen-Plugin 206 dazu veranlassen kann, den Status der Verbindung zwischen der Vorrichtungsverknüpfungsschnittstelle 172 und dem Vorrichtungsverknüpfungsanwendungskern 174 von der Vorrichtungsverknüpfungsschnittstelle 172 abzufragen. Besteht keine Verbindung zu einer Mobilvorrichtung 152, kann die Vorrichtungsverknüpfungsschnittstelle 172 dem virtuellen Schnittstellen-Plugin 206 melden, dass keine Verbindung vorhanden ist, was wiederum die Anwendung für die virtuelle Netzwerkverbindung 202 dazu veranlassen kann, die Fahrzeuganwendung110 zu informieren, dass keine Netzwerkschnittstelle verfügbar ist. Ist jedoch eine Mobilvorrichtung 152 verbunden, kann der Vorrichtungsverknüpfungsanwendungskern 174 Informationen in Bezug auf den Netzwerkzustand der verbundenen Mobilvorrichtung 152 an die der Vorrichtungsverknüpfungsschnittstelle 172 zurückgeben. In einem Beispiel kann die Vorrichtungsverknüpfungsschnittstelle 172 anzeigen, ob die Mobilvorrichtung 152 mit dem Kommunikationsnetzwerk 156 durch die physische Netzwerkschnittstelle 214 über eine Mobilfunkverbindung und/oder eine WLAN-Verbindung verbunden ist. Zusätzlich oder alternativ kann die Vorrichtungsverknüpfungsschnittstelle 172 andere Details zu der von der physischen Netzwerkschnittstelle 214 bereitgestellten Netzwerkverbindung anzeigen, wie etwa Datenverbindungsgeschwindigkeit, Latenz und Menge an Paketverlusten oder erneuten Übertragungen.
3 veranschaulicht einen beispielhaften Prozess 300 für die Rechenplattform 104, der es der Fahrzeuganwendung 110 ermöglicht, die Netzwerkkonnektivität der Mobilvorrichtung 152 zu verwenden. In einem Beispiel kann der Prozess 300 unter Nutzung der Anwendung für die virtuelle Netzwerkschnittstelle 202 der Rechenplattform 104 durchgeführt werden.
Bei Vorgang 302 empfängt die Rechenplattform 104 eine Anforderung von einer Fahrzeuganwendung 110. In einem Beispiel kann die Fahrzeuganwendung 110 eine Anforderung zum Abrufen oder Hochladen für MQTT an die Anwendung für die virtuelle Netzwerkschnittstelle 202 senden.
Bei 304 schreibt die Rechenplattform 104 Nachrichtendaten in einen Tunnel. In einem Beispiel empfängt der virtuelle Schnittstellen-Manager 204 der Anwendung für die virtuelle Netzwerkschnittstelle 202 die Anforderung von der Fahrzeuganwendung 110 und stellt die Anforderungen in den Tunnel ein. Bei 306 liest die Rechenplattform 104 Nachrichtendaten aus dem Tunnel. In einem Beispiel greift das virtuelle Schnittstellen-Plugin 206 auf den Tunnelverkehr zu, um die Anforderung zu empfangen. Das virtuelle Schnittstellen-Plugin 206 kann ferner die Anforderung der Vorrichtungsverknüpfungsschnittstelle 172 bereitstellen.
Bei 308 konstruiert die Rechenplattform 104 eine Nachricht für RPC. In einem Beispiel konstruiert die Vorrichtungsverknüpfungsschnittstelle 172 die RPC-Nachricht. Bei 310 sendet die Rechenplattform 104 die RPC-Nachricht an die verbundene Mobilvorrichtung 152. In einem Beispiel sendet die Vorrichtungsverknüpfungsschnittstelle 172 die konstruierte RPC-Nachricht an die verbundene Mobilvorrichtung 152. Die Mobilvorrichtung 152 kann die RPC-Nachricht wie in Bezug auf den Prozess 400 ausführlicher erörtert verarbeiten.
Bei 312 empfängt die Rechenplattform 104 eine Antwort auf die Nachricht von der verbundenen Mobilvorrichtung 152. In einem Beispiel empfängt die Vorrichtungsverknüpfungsschnittstelle 172 die Antwort wie in Bezug auf den Prozess 400 ausführlicher erörtert. Die Vorrichtungsverknüpfungsschnittstelle 172 kann die empfangene Antwort-RPC-Nachricht ferner an das virtuelle Schnittstellen-Plugin 206 senden. Bei 314 entschlüsselt die Rechenplattform 104 die Antwortnachricht. In einem Beispiel entschlüsselt das virtuelle Schnittstellen-Plugin 206 die empfangene Nachricht gemäß der von der Vorrichtungsverknüpfungsschnittstelle 172 bereitgestellten Verbindungsart.
Bei 316 schreibt die Rechenplattform 104 die Antwortnachricht in den Tunnel. In einem Beispiel schreibt das virtuelle Schnittstellen-Plugin 206 die entschlüsselten Nachrichtendaten in den Tunnel. Bei 318 liest die Rechenplattform 104 die Antwortnachricht an den Tunnel. In einem Beispiel liest der virtuelle Schnittstellen-Manager 204 die entschlüsselten Nachrichtendaten an den Tunnel als Reaktion auf eine Anforderung von der Fahrzeuganwendung 110 von Daten von der Verbindung. Bei 320 empfängt die Fahrzeuganwendung 110 der Rechenplattform 104 die Antwortnachricht. Demzufolge kann die Fahrzeuganwendung 110 die Netzwerkdienste der verbundenen Mobilvorrichtung über RPC nutzen, selbst wenn die angeforderten Netzwerkdienste von der Mobilvorrichtung 152 nicht nativ unterstützt werden. Nach Vorgang 320 endet der Prozess 300.
4 veranschaulicht einen beispielhaften Prozess 400 für die Mobilvorrichtung 152, der es der Fahrzeuganwendung 110 ermöglicht, die Netzwerkkonnektivität der Mobilvorrichtung 152 zu verwenden. In einem Beispiel kann der Prozess 300 unter Nutzung der mobilen Anwendung für das virtuelle Netzwerk 208 der Mobilvorrichtung 152 durchgeführt werden.
Bei 402 empfängt die Mobilvorrichtung 152 eine Nachricht von einem verbundenen Fahrzeug 102 über RPC. In einem Beispiel kann die Nachricht an dem Vorrichtungsverknüpfungsanwendungskern 174 als Reaktion auf das vorstehend in Bezug auf Vorgang 310 des Prozesses 300 erörterte Senden empfangen werden. Bei 404 entschlüsselt die Mobilvorrichtung 152 die Nachricht. In einem Beispiel empfängt der IP-Daten-Manager 210 der mobilen Anwendung für das virtuelle Netzwerk 208 die RPC-Nachricht und entschlüsselt die binären Paketdaten von dem Vorrichtungsverknüpfungsanwendungskern 174. Der IP-Daten-Manager 210 kann ferner dazu konfiguriert sein, die empfangenen IP-Paketdaten an den Proxy 212 zu senden.
Bei 406 erstellt die Mobilvorrichtung 152 eine Nachricht mit der Mobilvorrichtung 152 als Ursprungsadresse. In einem Beispiel kann der Proxy 212 die Quelladresse der Nachricht so aktualisieren, dass sie die Adresse der Mobilvorrichtung 152 ist, nicht die der Rechenplattform 104. Bei 408 sendet die Mobilvorrichtung 152 die Nachricht an ein Ziel. In einem Beispiel erstellt der Proxy 212 ein Socket und schreibt die Nachricht auf die physische Netzwerkschnittstelle 214 der Mobilvorrichtung 152. Dieses aktualisierte Nachricht kann dann an das Zieladresse von der Mobilvorrichtung 152 über die physische Netzwerkschnittstelle 214 gesendet werden.
Bei 410 empfängt die Mobilvorrichtung 152 eine Antwortnachricht. In einem Beispiel kann die Antwort auf das Paket an der physischen Netzwerkschnittstelle 214 der Mobilvorrichtung 152 zurückempfangen werden. Das Antwortpaket kann dann an die mobile Anwendung für das virtuelle Netzwerk 208 übergeben werden. Bei 412 erstellt die Mobilvorrichtung 152 eine Nachricht mit dem Fahrzeug als Zieladresse. In einem Beispiel aktualisiert der Proxy 212 das Antwortpaket mit den Adressinformationen der Rechenplattform 104 gibt es an den IP-Daten-Manager 210 zurück. Bei 414 konstruiert die Mobilvorrichtung 152 eine Antwortnachricht für RPC. In einem Beispiel konstruiert der IP-Daten-Manager 210 eine binäre Darstellung übergibt die Darstellung an den Vorrichtungsverknüpfungsanwendungskern 174.
Bei 416 sendet die Mobilvorrichtung 152 die Antwortnachricht an die Rechenplattform 104 des verbundenen Fahrzeugs 102 über RPC. Die Antwortnachricht kann von der Rechenplattform 104 wie vorstehend in Bezug auf Vorgang 312 erörtert empfangen werden. Nach Vorgang 416 endet der Prozess 400.
Abweichungen von den vorstehend genannten Systemen und Prozessen sind möglich. In einem Beispiel kann die Rechenplattform 104 Protokolle, die von der Mobilvorrichtung 152 nativ unterstützt werden, von der Mobilvorrichtung 152 abfragen. Auf Grundlage des Ergebnisses der Abfrage, wenn die Mobilvorrichtung 152 das von der Fahrzeuganwendung 110 angeforderte Protokoll nicht unterstützt, können die vorstehend genannten Prozesse 300 und 400 genutzt werden. Wenn die Mobilvorrichtung 152 jedoch über eine native Fähigkeit verfügt, das Protokoll zu unterstützen, dann kann stattdessen eine Anforderung, dass die Mobilvorrichtung 152 ihre native Funktionalität nutzen soll, gesendet werden, wobei die Tunneling- und Proxy-Vorgänge vermieden werden. Als konkretes Beispiel kann die Mobilvorrichtung 152 antworten, dass sie HTTP aber nicht MQTT oder FTP (File Transfer Protocol) unterstützt. Demzufolge kann eine HTTP-Anforderung von Daten an die Mobilvorrichtung über RPC gesendet werden, um die Mobilvorrichtung 152 dazu zu veranlassen, ihren nativen Webbrowser zu nutzen, um die angeforderten Daten abzurufen und dann die angeforderten Daten, nachdem sie abgerufen wurden, zurückzusenden. Eine FTP- oder MQTT-Anforderung kann jedoch unter Verwendung der Mobilvorrichtung 152 als Proxy getunnelt und verarbeitet werden.
Hierin beschriebene Rechenvorrichtungen, wie etwa die Rechenplattform 104, die Mobilvorrichtung 152 und der Telematik-Server 162 beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa die vorstehend aufgelisteten, ausgeführt werden können. Computerausführbare Anweisungen, wie etwa die der Anwendung für die virtuelle Netzwerkschnittstelle 202 oder der mobilen Anwendung für das virtuelle Netzwerk 208, können von Computerprogrammen kompiliert oder ausgewertet werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt wurden, einschließlich unter anderem und entweder allein oder in Kombination Java™, C, C++, C#, Visual Basic, Java Script, Python, JavaScript, Perl, PL/SQL, Prolog, LISP, Corelet usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch ein oder mehrere Prozesse durchgeführt werden, einschließlich eines oder mehrerer der hier beschriebenen Prozesse. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert und übertragen werden.
Hinsichtlich der hier beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte solcher Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben wurden, derartige Prozesse aber mit den beschriebenen Schritten in einer Reihenfolge durchgeführt werden könnten, die von der hier beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte hier beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt, dienen die vorliegenden Beschreibungen von Prozessen dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Ansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die vorgestellten Beispiele handelt, würden beim Lesen der vorstehenden Beschreibung ersichtlich. Der Umfang sollte nicht unter Bezugnahme auf die vorstehende Beschreibung ermittelt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche gemeinsam mit dem vollständigen Umfang von Äquivalenten, zu denen derartige Patentansprüche berechtigt sind. Es wird erwartet und beabsichtigt, dass es hinsichtlich der hier erläuterten Techniken künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutungen zugeordnet werden, wie sie mit den hier beschriebenen Technologien vertrauten Fachleuten bekannt sind, sofern hier kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „einer“, „eine“, „der“, „die“, „das“ usw. dahingehend auszulegen, dass ein oder mehrere der aufgeführten Elemente genannt werden, es sei denn, ein Patentanspruch enthält eine ausdrücklich gegenteilige Einschränkung.
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Schutzumfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Zusätzlich geht aus der vorstehenden detaillierten Beschreibung hervor, dass verschiedene Merkmale in verschiedenen Ausführungsformen zum Zwecke der Vereinfachung der Offenbarung zusammengefasst sind. Dieses Offenbarungsverfahren soll nicht dahingehend ausgelegt werden, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich in jedem Patentanspruch genannt erfordern. Stattdessen liegt der Gegenstand der Erfindung in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Ansprüche widerspiegeln. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als separat beanspruchter Gegenstand steht.
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben werden, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende und keine einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener umgesetzter Ausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden.

Claims

System, umfassend: eine Mobilvorrichtung, die dazu programmiert ist, eine Nachricht von einer Fahrzeugrechenplattform über RPC (Remote Process Communication) zu empfangen, eine Ursprungsadresse der Nachricht zu aktualisieren, um die Mobilvorrichtung anzuzeigen, die Nachricht an eine Zieladresse der Nachricht zu senden, eine Antwortnachricht von dem Ziel zu empfangen, eine Zieladresse der Antwortnachricht zu aktualisieren, um die Mobilvorrichtung anzuzeigen, und die Antwortnachricht über die RPC an die Rechenplattform zu senden.
System nach Anspruch 1, wobei die Nachricht von einer Fahrzeuganwendung, die von der Rechenplattform ausgeführt wird und über eines oder mehrere von MQTT (MQ Telemetry Transport)-Protokoll, FTP (File Transfer Protocol) oder HTTP (Hypertext Transfer Protocol) kommuniziert, gesendet wird.
System nach Anspruch 1, wobei die Ursprungsadresse und die Zieladresse IP(Internet Protocol)-Adressen sind.
System nach Anspruch 1, wobei der RPC gemäß dem SDL(Smart Device Link)-Protokoll durchgeführt wird.
System nach Anspruch 1, wobei die Mobilvorrichtung einen Proxy beinhaltet, der dazu programmiert ist, die Ursprungsadresse der Nachricht zu aktualisieren und die Zieladresse der Antwortnachricht zu aktualisieren.
System nach Anspruch 1, wobei die Mobilvorrichtung einen Daten-Manager beinhaltet, der zu Folgendem programmiert ist: Übersetzen der Nachricht aus einem Format der RPC in ein Format zur Übertragung über ein Kommunikationsnetzwerk an die Zieladresse, und Übersetzen der Antwortnachricht aus dem Format zur Übertragung über das Kommunikationsnetzwerk in das Format der RPC.
System nach Anspruch 1, ferner umfassend: eine Rechenplattform, die dazu programmiert ist, eine RPC(Remote Procedure Call)-Nachricht von einer Anwendung für eine virtuelle Netzwerkschnittstelle zu konstruieren für eine von einer Fahrzeuganwendung empfangene Anforderung eines Netzwerkprotokolls, das von einer Mobilvorrichtung nicht unterstützt wird, und den RPC an die Mobilvorrichtung zu senden, um die Mobilvorrichtung dazu zu veranlassen, eine Ursprungsadresse der Anforderung zu aktualisieren, um die Mobilfunkvorrichtung anzuzeigen und die Anforderung an eine Zieladresse der Anforderung zu senden.
System nach Anspruch 7, wobei die Rechenplattform ferner zu Folgendem programmiert ist: Abfragen von Netzwerkprotokollen, die von der Mobilvorrichtung nativ unterstützt werden, von der Mobilvorrichtung, und Identifizieren, dass das Netzwerkprotokoll von der Mobilvorrichtung nicht unterstützt wird gemäß der Abfrage.
System nach Anspruch 7, wobei die Rechenplattform ferner zu Folgendem programmiert ist: Empfangen einer zweiten Anforderung von einer zweiten Fahrzeuganwendung eines zweiten Netzwerkprotokolls, das von der Mobilvorrichtung unterstützt wird, und Senden der zweiten Anforderung an die Mobilvorrichtung zur Verarbeitung durch eine Anwendung der Mobilvorrichtung, die dem zweiten Netzwerkprotokoll entspricht.
System nach Anspruch 7, wobei die Rechenplattform ferner zu Folgendem programmiert ist: Empfangen einer Antwort auf die Anforderung von der Mobilvorrichtung, und Senden der Antwort an die Fahrzeuganwendung.
System nach Anspruch 10, wobei die Rechenplattform ferner dazu programmiert ist, einen Netzwerkstatus von der Mobilvorrichtung zu empfangen, der Details zu einer Netzwerkverbindung anzeigt, die von einer physischen Schnittstelle der Mobilvorrichtung einem Kommunikationsnetzwerk bereitgestellt wird, über das die Zieladresse erreicht wird.
Verfahren, umfassend: Empfangen durch eine Rechenplattform von einer Mobilvorrichtung von Anzeigen von Netzwerkprotokollen, die von der Mobilvorrichtung nativ unterstützt werden; Empfangen einer Anforderung von einer Fahrzeuganwendung, die ein Netzwerkprotokoll nutzt; Senden der Anforderung an die Mobilvorrichtung zur Handhabung durch eine native Anwendung der Mobilvorrichtung als Reaktion darauf, dass das Netzwerkprotokoll nativ unterstützt wird; und anderenfalls Senden der Anforderung an die mobile Anwendung unter Verwendung eines Proxying-Ansatzes.
Verfahren nach Anspruch 12, wobei der Proxying-Ansatz Folgendes umfasst: Konstruieren einer RPC(Remote Procedure Call)-Nachricht durch eine Anwendung für eine virtuelle Netzwerkschnittstelle, und Senden des RPC an die Mobilvorrichtung, um die Mobilvorrichtung dazu zu veranlassen, eine Ursprungsadresse der Anforderung zu aktualisieren, um die Mobilfunkvorrichtung anzuzeigen und die Anforderung an eine Zieladresse der Anforderung zu senden.
Verfahren nach Anspruch 13, ferner umfassend Durchführen des RPC gemäß dem SDL(Smart Device Link)-Protokoll.
Verfahren nach Anspruch 14, ferner umfassend: Empfangen einer Antwort auf die Anforderung von der Mobilvorrichtung, und Senden der Antwort an die Fahrzeuganwendung.