DE102019101548A1

DE102019101548A1 - Erweiterung von apis zwischen mobilvorrichtungen und einem fahrzeug auf die cloud

Info

Publication number: DE102019101548A1
Application number: DE102019101548.0A
Authority: DE
Inventors: Elizabeth Halash; Stefan Bankowski; Robin Mathew KURIAN; Jeffrey Hu
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2018-01-23
Filing date: 2019-01-22
Publication date: 2019-07-25
Also published as: US20190230206A1; CN110071954A

Abstract

Ein Server ist dazu programmiert, einen Anwendungsbefehl von einer gehosteten Anwendung zu empfangen, die von einem zweiten Server ausgeführt wird, einen simulierten Mobilvorrichtungsbefehl zu erzeugen, der eine von dem Anwendungsbefehl vorgegebene Funktion angibt, und den simulierten Mobilvorrichtungsbefehl an eine Telematiksteuerung eines Fahrzeugs zu senden, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.

Description

TECHNISCHES GEBIET
Aspekte der Offenbarung betreffen im Allgemeinen eine Erweiterung von Anwendungsprogrammierschnittstellen (API), die verwendet werden, um Kommunikation zwischen lokal mit Fahrzeugen vernetzten Mobilvorrichtungen zu ermöglichen, um eine Fernkommunikation über ein Weitverkehrsnetz zu unterstützen.
ALLGEMEINER STAND DER TECHNIK
Ein Benutzer kann sein Telefon mit einer Haupteinheit eines Fahrzeugs koppeln. Sobald es gekoppelt ist, kann das Telefon dazu imstande sein, Informationen mit der Haupteinheit auszutauschen. Beispielsweise kann das Telefon Audioinhalte von einem Internet-Radiodienst an die Haupteinheit zur Wiedergabe in dem Fahrzeug streamen. Oder das Telefon kann eine Navigationsanwendung ausführen, um dem Fahrzeug eine Wegbeschreibung bereitzustellen.
KURZDARSTELLUNG
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein System einen Server, der dazu programmiert ist, einen Anwendungsbefehl von einer gehosteten Anwendung zu empfangen, die von einem zweiten Server ausgeführt wird, einen simulierten Mobilvorrichtungsbefehl zu erzeugen, der eine von dem Anwendungsbefehl vorgegebene Funktion angibt, und den simulierten Mobilvorrichtungsbefehl an eine Telematiksteuerung eines Fahrzeugs zu senden, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein System eine Haupteinheitensteuerung, eine Telematiksteuereinheit (Telematics Control Unit - TCU), die dazu programmiert ist, einen Befehl von einem Server zu empfangen, und ein Gateway, das dazu programmiert ist, den Befehl von der TCU zu empfangen und den Befehl an die Haupteinheitensteuerung weiterzuleiten, wobei das Gateway dazu programmiert ist, den Befehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein Verfahren Senden eines simulierten Mobilvorrichtungsbefehls, der eine Funktion angibt, die von dem Anwendungsbefehl vorgegeben ist, der von einer durch einen Anwendungsserver gehosteten Mobilanwendung empfangenen wird, an eine Telematiksteuerung eines Fahrzeugs, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
Figurenliste

1 veranschaulicht einen beispielhaften Abschnitt eines Fahrzeugs, der eine Haupteinheitensteuerung beinhaltet, die dazu konfiguriert ist, Telematikdienste an das Fahrzeug bereitzustellen;
2 veranschaulicht eine beispielhafte Topologie zur Nachrichtenübermittlung innerhalb verschiedener Komponenten des Fahrzeugs über ein Gateway;
3 veranschaulicht ein beispielhaftes System zum Senden von Mobilbefehlen an ein Fahrzeug von einem Anwendungsserver;
4 veranschaulicht ein beispielhaftes Verfahren zum Verwenden eines Fahrzeug-API-Servers, um Telematikdienste an ein Fahrzeug von dem Anwendungsserver bereitzustellen; und
5 veranschaulicht ein beispielhaftes Verfahren zum Bereitstellen von Telematikdiensten an ein Fahrzeug von einer gehosteten Mobilanwendung, die durch einen Anwendungsserver über einen Fahrzeug-API-Server ausgeführt wird.

DETAILLIERTE BESCHREIBUNG
Ausführliche Ausführungsformen der vorliegenden Erfindung werden hier nach Bedarf offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen für die Erfindung, die in verschiedenen und alternativen Formen ausgeführt sein kann, lediglich beispielhaft sind. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Demnach sind hier offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielfältige Verwendung der vorliegenden Erfindung zu lehren.
Viele derzeitige Telematiklösungen erfordern eine physische Verbindung zwischen einem Fahrzeug-Infotainmentsystem und einer Mobilvorrichtung eines Benutzers. Aufgrund von Unterschieden in der Hardware, Software und Umsetzung von Mobilvorrichtungen können oftmals Probleme beim Herstellen und Aufrechterhalten der Verbindung zwischen einer Mobilvorrichtung und einem Fahrzeug auftreten. Dies kann unerwünschte Wirkungen bei Mobilanwendungen zur Folge haben, die zu merklichen Qualitätsproblemen und Frust seitens des Benutzers führen. Darüber hinaus reduzieren derzeitige Systeme verfügbare Anwendungsfälle auf jene, die stattfinden können, während sich ein Benutzer physisch in einem Fahrzeug befindet, wobei eine Mobilvorrichtung mit dem Fahrzeug-Infotainmentsystem verbunden ist.
Bei Verwendung der derzeitigen Mobilanwendung-zu-Fahrzeug-Funktionalität können einzelne Anwendungen, die von einer Mobilvorrichtung ausgeführt werden, die in der Haupteinheit registriert ist, Befehle zum Steuern der HMI des Infotainmentsystems senden sowie Fahrzeugdaten über dieselbe Registrierungsverbindung anfordern. Diese Funktionalität lässt sich auf Anwendungen erweitern, die von einem Cloud-Server anstatt auf der Mobilvorrichtung ausgeführt werden. Beispielsweise können Cloud-basierte Anwendungen dazu konfiguriert sein, Befehle über ein Webprotokoll, z. B. über das Hypertext Transfer Protocol (HTTP), zu senden. Diese Befehle können von einem API-Gateway empfangen werden, das die Befehle aktuellen Fahrzeugbefehlen zuordnet, die das Infotainment annehmen und verstehen kann. Diese zugeordneten Befehle können dann von dem API-Gateway an ein Modem des Fahrzeugs weitergeleitet werden. Das Modem kann sich bei der Haupteinheit ähnlich wie eine Mobilanwendung registrieren, um es dem Modem zu ermöglichen, Befehle zu senden, um Ereignisse in dem Fahrzeug, wie z. B. HMI-Benachrichtigungen oder eine Veränderung der Fahrzeugsitz-, Radio- oder Klimaeinstellungen, auszulösen oder Daten zurück von dem Fahrzeug anzufordern, die an den Cloud-Server zu senden sind.
Demnach muss eine physische (und sich in dem Fahrzeug befindende) Mobilvorrichtung nicht mehr mit einer Haupteinheit des Fahrzeugs (z. B. über BLUETOOTH, USB, WLAN usw.) verbunden sein. Durch Entkoppeln dieser beiden physischen Einheiten und Einführen einer Cloud-Komponente können Vorrichtungsverbindungsprobleme beseitigt werden und kann die Fähigkeit, Befehle jederzeit an ein Fahrzeug zu senden, eingeführt werden. Überdies kann unter Verwendung des Cloud-Servers eine Anwendungsfunktionalität unter Verwendung des Fahrzeugs unabhängig davon durchgeführt werden, ob sich ein Benutzer physisch in dem Fahrzeug mit verbundener Mobilvorrichtung befindet. Die Funktionalität, Befehle und Reaktionen der Haupteinheit können jedoch gleich bleiben, wodurch sich der technische Überarbeitungsaufwand verringert, der nötig ist, um eine Unterstützung für Cloud-basierte Anwendungen hinzuzufügen. Stattdessen kann sich die Haupteinheit mit der Modemkomponente des Fahrzeugs so verbinden, als wäre das Modem eine andere Mobilvorrichtung die zum Ausführen von Anwendungen imstande ist. So kann, anstatt BLUETOOTH oder USB zu verwenden, die Verbindung mit der Haupteinheit über das interne Netz des Fahrzeugs umgesetzt werden. Weitere Aspekte der Offenbarung sind nachstehend ausführlich erörtert.
1 veranschaulicht einen beispielhaften Abschnitt eines Fahrzeugs 102, der eine Haupteinheitensteuerung 104 beinhaltet, die dazu konfiguriert ist, Telematikdienste an das Fahrzeug 102 bereitzustellen. Das Fahrzeug 102 kann verschiedene Arten von Personenkraftwagen, wie z. B. Softroader (Crossover Utility Vehicle - CUV), Geländewagen (Sports Utility Vehicle - SUV), LKW, Wohnmobile (Recreational Vehicle - RV), Boote, Flugzeuge oder andere mobile Maschinen zum Befördern von Personen oder Transportieren von Gütern, einschließen. Zu Telematikdiensten können als einige nicht einschränkende Möglichkeiten Navigation, Routenführung, Fahrzeugdiagnosen, lokale Unternehmenssuche, Unfallmeldungen und Freisprechanrufe gehören. Die Haupteinheitensteuerung 104 kann mit einer Mobilvorrichtung 152 und einem Gateway 142 in Kommunikation stehen. In einem Beispiel kann das System 100 das SYNC-System einschließen, das durch die Ford Motor Company in Dearborn, Michigan, USA, hergestellt wird. 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.
Eine Haupteinheitensteuerung 104 kann einen oder mehrere Prozessoren 106 beinhalten, die dazu konfiguriert sind, Anweisungen, Befehle und andere Routinen durchzuführen, um die hier beschriebenen Verfahren zu unterstützen. Beispielsweise kann die Haupteinheitensteuerung 104 dazu konfiguriert sein, Anweisungen von Fahrzeuganwendungen 110 auszuführen, um Funktionen wie etwa Navigation, Unfallmeldung, Satellitenradiodecodierung und Freisprechanrufe bereitzustellen. Derartige Anweisungen und andere Daten können nichtflüchtig unter Verwendung einer Vielfalt an Arten computerlesbarer Speichermedien 112 aufbewahrt werden. Das computerlesbare Medium 112 (auch als prozessorlesbares Medium oder prozessorlesbarer Speicher bezeichnet) schließt ein jedes dauerhaftes Medium (z. B. ein physisches Medium) ein, das an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, die von dem Prozessor 106 der Haupteinheitensteuerung 104 gelesen werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung vielfältiger Programmiersprachen und/oder - techniken, einschließlich unter anderem entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL, erstellt worden sind.
Die Haupteinheitensteuerung 104 kann mit verschiedenen Merkmalen versehen sein, über welche die Fahrzeuginsassen auf die Haupteinheitensteuerung 104 zugreifen können. Beispielsweise kann die Haupteinheitensteuerung 104 einen Audioeingang 114, der dazu konfiguriert ist, Sprachbefehle von Fahrzeuginsassen über ein verbundenes Mikrofon 116 zu empfangen, und einen zusätzlichen Audioeingang 118, der dazu konfiguriert ist, Audiosignale von verbundenen Vorrichtungen zu empfangen, beinhalten. Bei dem zusätzlichen Audioeingang 118 kann es sich um eine physische Verbindung, wie etwa ein Stromkabel oder ein Glasfaserkabel, oder einen drahtlosen Eingang, wie etwa eine BLUETOOTH-Audioverbindung, handeln. In einigen Beispielen kann der Audioeingang 114 dazu konfiguriert sein, Audioverarbeitungsfähigkeiten, wie z. B. Vorverstärkung von niederpegeligen Signalen und Umwandlung von analogen Eingaben in digitale Daten zum Verarbeiten durch den Prozessor 106, bereitzustellen.
Die Haupteinheitensteuerung 104 kann zudem einen oder mehrere Audioausgänge 120 zu einem Eingang eines Audiomoduls (nicht veranschaulicht) mit einer Audiowiedergabefunktionalität bereitstellen. In anderen Beispielen kann die Haupteinheitensteuerung 104 den Audioausgang 120 an einen Insassen durch die Verwendung eines oder mehrerer dedizierter Lautsprecher (nicht veranschaulicht) bereitstellen. Das Audiomodul kann einen Eingangswähler beinhalten, der dazu konfiguriert ist, Audioinhalte von einer ausgewählten Audioquelle an einen Audioverstärker zur Wiedergabe über Fahrzeuglautsprecher oder Kopfhörer (alle nicht veranschaulicht) bereitzustellen. Zu den Audioquellen können als einige Beispiele decodierte amplitudenmodulierte (AM) oder frequenzmodulierte (FM) Funksignale und Audiosignale von Audiowiedergaben von Compact Disks (CDs) oder Digital Versatile Disks (DVDs) gehören. Die Audioquellen können zudem Audioinhalte einschließen, die von der Haupteinheitensteuerung 104 empfangen wurden, wie z. B. von der Haupteinheitensteuerung 104 erzeugte Audioinhalte, aus mit einem Universal-Serial-Bus(USB)-Teilsystem 132 der Haupteinheitensteuerung 104 verbundenen Flash-Speicherlaufwerken decodierte Audioinhalte und vom Mikrofon 116 oder zusätzlichen Audioeingang 118 durch die Haupteinheitensteuerung 104 geleitete Audioinhalte.
Die Haupteinheitensteuerung 104 kann eine Sprachschnittstelle 134 nutzen, um der Haupteinheitensteuerung 104 eine Freisprechschnittstelle bereitzustellen. Die Sprachschnittstelle 134 kann eine Spracherkennung von über das Mikrofon 116 empfangenen Audioinhalten gemäß einer Standardgrammatik, die verfügbare Befehlsfunktionen beschreibt, und eine Erzeugung von Sprachaufforderungen zur Ausgabe unterstützen. Die Sprachschnittstelle 134 kann Techniken der probabilistischen Spracherkennung unter Verwendung der Standardgrammatik im Vergleich zur eingegebenen Sprache nutzen. In vielen Fällen kann die Sprachschnittstelle 134 eine Standardbenutzerprofileinstellung zur Verwendung durch die Spracherkennungsfunktionen beinhalten, um zu ermöglichen, dass die Spracherkennung so eingestellt ist, dass sie im Durchschnitt gute Ergebnisse bereitstellt, was positive Erfahrungen für die maximale Anzahl von Erstbenutzern zur Folge hat. In einigen Fällen kann das System dazu konfiguriert sein, die durch den Eingangswähler 124 vorgegebene Audioquelle zeitweise stummzuschalten oder anderweitig zu übersteuern, wenn eine Audioaufforderung zur Ausgabe durch die Haupteinheitensteuerung 104 bereit ist und eine andere Audioquelle zur Wiedergabe ausgewählt wird.
Die Haupteinheitensteuerung 104 kann zudem Eingaben von Steuerungen 136 von Mensch-Maschine-Schnittstellen (HMI) empfangen, die dazu konfiguriert sind, eine Interaktion der Insassen mit dem Fahrzeug 102 zu ermöglichen. Beispielsweise kann die Haupteinheitensteuerung 104 mit einer oder mehreren Tasten oder anderen HMI-Steuerelementen, die dazu konfiguriert sind, Funktionen an der Haupteinheitensteuerung 104 aufzurufen (z. B. Audiotasten am Lenkrad, einer Sprechtaste, Steuerelementen im Armaturenbrett usw.), verknüpft sein. Die Haupteinheitensteuerung 104 kann zudem eine oder mehrere Anzeigen 138 ansteuern, die dazu konfiguriert sind, über eine Videosteuerung 140 eine visuelle Ausgabe an Fahrzeuginsassen bereitzustellen, oder anderweitig mit diesen kommunizieren. 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 Haupteinheitensteuerung 104 kann ferner dazu konfiguriert sein, mit anderen Komponenten des Fahrzeugs 102 über ein Gateway 142 zu kommunizieren. Weitere Aspekte des Betriebs des Gateways 142 sind nachfolgend unter Bezugnahme auf 2 näher erörtert.
Die Haupteinheitensteuerung 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, wie z. B. Mobiltelefone, Tablet-Computer, Smartwatches, Laptop-Computer, tragbare Musikwiedergabevorrichtungen oder andere Vorrichtungen, die zur Kommunikation mit der Haupteinheitensteuerung 104 imstande sind, handeln. In vielen Beispielen kann die Haupteinheitensteuerung 104 einen drahtlosen Sendeempfänger 150 (z. B. ein BLUETOOTH-Modul, einen ZIGBEE-Sendeempfänger, einen WLAN-Sendeempfänger, einen IrDA-Sendeempfänger, einen RFID-Sendeempfänger usw.) beinhalten, der dazu konfiguriert ist, mit einem kompatiblen drahtlosen Sendeempfänger 154 der Mobilvorrichtung 152 zu kommunizieren. Zusätzlich oder alternativ dazu kann die Haupteinheitensteuerung 104 mit der Mobilvorrichtung 152 über eine drahtgebundene Verbindung, wie z. B. über eine USB-Verbindung zwischen der Mobilvorrichtung 152 und dem USB-Teilsystem 132, kommunizieren. In einigen Beispielen kann die Mobilvorrichtung 152 batteriebetrieben sein, während die Mobilvorrichtung 152 in anderen Fällen mindestens einen Teil ihrer Leistung über die drahtgebundene Verbindung von dem Fahrzeug 102 beziehen kann. In einigen Fällen kann die Mobilvorrichtung 152 durch drahtloses induktives Laden mit Leistung versorgt werden.
Ein Kommunikationsnetz 156 kann an mit dem Kommunikationsnetz 156 verbundene Vorrichtungen Kommunikationsdienste, wie z. B. paketvermittelte Netzdienste (z. B. Internetzugang, VoIP-Kommunikationsdienste), bereitstellen. Ein Beispiel für ein Kommunikationsnetz 156 kann ein Mobilfunknetz einschließen. Die Mobilvorrichtungen 152 können eine Netzkonnektivität mit dem Kommunikationsnetz 156 über ein Vorrichtungsmodem 158 der Mobilvorrichtung 152 bereitstellen. Um die Kommunikation über das Kommunikationsnetz 156 zu erleichtern, können die Mobilvorrichtungen 152 mit eindeutigen Vorrichtungskennungen (z. B. Mobilvorrichtungsnummern (Mobile Device Numbers - MDNs), Internet-Protocol(IP)-Adressen usw.) assoziiert sein, um die Kommunikation der Mobilvorrichtungen 152 über das Kommunikationsnetz 156 zu identifizieren. In einigen Fällen können Insassen des Fahrzeugs 102 oder Vorrichtungen mit der Berechtigung zum Verbinden mit der Haupteinheitensteuerung 104 durch die Haupteinheitensteuerung 104 gemäß den Daten 160 zu gekoppelten Vorrichtungen identifiziert werden, die in dem Speichermedium 112 aufbewahrt werden. Die Daten 160 zu gekoppelten Vorrichtungen können beispielsweise die eindeutigen Vorrichtungskennungen der Mobilvorrichtungen 152 angeben, die zuvor mit der Haupteinheitensteuerung 104 des Fahrzeugs 102 gekoppelt wurden, sodass sich die Haupteinheitensteuerung 104 ohne Eingreifen des Benutzers automatisch erneut mit den Mobilvorrichtungen 152 verbinden kann, auf die in den Daten 160 zu gekoppelten Vorrichtungen verwiesen wird.
Wenn eine Mobilvorrichtung 152, die Netzkonnektivität unterstützt, mit der Haupteinheitensteuerung 104 gekoppelt und verbunden wird, kann die Mobilvorrichtung 152 der Haupteinheitensteuerung 104 das Verwenden der Netzkonnektivität des Vorrichtungsmodems 158 gestatten, um über das Kommunikationsnetz 156 mit einem Telematik-Server oder einer anderen entfernten Rechenvorrichtung zu kommunizieren. In einem Beispiel kann die Haupteinheitensteuerung 104 einen Daten-über-Sprache-Tarif oder Datentarif der Mobilvorrichtung 152 zum Kommunizieren von Informationen zwischen der Haupteinheitensteuerung 104 und dem Kommunikationsnetz 156 nutzen. Zusätzlich oder alternativ dazu kann die Haupteinheitensteuerung 104 eine Telematiksteuereinheit 144 nutzen, um Informationen zwischen der Haupteinheitensteuerung 104 und dem Kommunikationsnetz 156 zu kommunizieren, ohne die Kommunikationsfähigkeiten der Mobilvorrichtung 152 zu verwenden.
Ebenso wie die Haupteinheitensteuerung 104 kann die Mobilvorrichtung 152 einen oder mehrere Prozessoren 164 beinhalten, die dazu konfiguriert sind, Anweisungen von Mobilanwendungen 170 auszuführen, die in einen Speicher 166 der Mobilvorrichtung 152 von einem Speichermedium 168 der Mobilvorrichtung 152 geladen werden. In einigen Beispielen können die Mobilanwendungen 170 dazu konfiguriert sein, mit der Haupteinheitensteuerung 104 über den drahtlosen Sendeempfänger 154 und mit anderen Netzdiensten über das Vorrichtungsmodem 158 zu kommunizieren.
Die Haupteinheitensteuerung 104 kann z. B. eine Vorrichtungsverbindungsschnittstelle 172 beinhalten, um die Integration von Funktionalität der Mobilanwendungen 170 zu ermöglichen, die dazu konfiguriert sind, mit einem Vorrichtungsverbindungsanwendungskern 174, der von der Mobilvorrichtung 152 ausgeführt wird, zu kommunizieren. In einigen Beispielen können sich die Mobilanwendungen 170, die Kommunikation mit der Vorrichtungsverbindungsschnittstelle 172 unterstützen, statisch mit dem Vorrichtungsverbindungsanwendungskern 174 verbinden oder dessen Funktionalität anderweitig in den Binärcode der Mobilanwendung 170 integrieren. In anderen Beispielen können die Mobilanwendungen 170, die Kommunikation mit der Vorrichtungsverbindungsschnittstelle 172 unterstützen, auf eine Anwendungsprogrammierschnittstelle (Application Programming Interface - API) eines gemeinsamen oder getrennten Vorrichtungsverbindungsanwendungskerns 174 zugreifen, um die Kommunikation mit der Vorrichtungsverbindungsschnittstelle 172 zu ermöglichen.
Die Integration von Funktionalität, die von der Vorrichtungsverbindungsschnittstelle 172 bereitgestellt wird, kann als ein Beispiel die Fähigkeit von Mobilanwendungen 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 Vorrichtungsverbindungsschnittstelle 172 kann zudem den Mobilanwendungen 170 über das Gateway 142 Zugriff auf Fahrzeuginformationen bereitstellen, die der Haupteinheitensteuerung 104 zur Verfügung stehen. Die Vorrichtungsverbindungsschnittstelle 172 kann ferner den Mobilanwendungen 170 Zugriff auf die Fahrzeuganzeige 138 bereitstellen. Ein Beispiel für eine Vorrichtungsverbindungsschnittstelle 172 kann die SYNC-APPLINK-Komponente des SYNC-Systems sein, das von der Ford Motor Company in Dearborn, Michigan, USA, bereitgestellt wird. Zu anderen Beispielen für Vorrichtungsverbindungsschnittstellen 172 können MIRRORLINK, APPLE CARPLAY und ANDROID AUTO gehören.
2 veranschaulicht eine beispielhafte Topologie 200 zur Nachrichtenübermittlung innerhalb verschiedener Komponenten des Fahrzeugs 102 über das Gateway 142. Jedes Steuergerät (Electronic Control Unit - ECU) 202 kann mit einem von einer Vielzahl von Teilnetzen 208 verbunden sein. Die Telematiksteuereinheit (TCU) 144 ist enthalten, um eine Kommunikation zwischen verschiedenen Komponenten des Fahrzeugs 102 und dem Kommunikationsnetz 156 zu ermöglichen. Die TCU 144 kann mit einem Backbone-Abschnitt 210 der Topologie 200 verbunden sein und kann über das Gateway 142 mit den ECU 202 kommunizieren. Wenngleich in 2 eine beispielhafte Topologie 200 dargestellt ist, sollen die veranschaulichten beispielhaften Komponenten nicht der Einschränkung dienen. Tatsächlich kann die Topologie 200 mehr oder weniger Komponenten aufweisen und können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden. Als ein Beispiel können die ECU 202 und die TCU 144 jeweils mit einem oder mehreren gleichen oder unterschiedlichen Arten von Knoten als die Teilnetze 208 und das Backbone 210 verbunden sein.
Die ECU 202 können verschiedene Hardware- und Softwarekomponenten beinhalten, die dazu konfiguriert sind, verschiedene Fahrzeugfunktionen zu überwachen und zu verwalten. Die ECU 202 können demnach einen oder mehrere Prozessoren (z. B. Mikroprozessoren) (nicht dargestellt) beinhalten, die dazu konfiguriert sind, Firmware- oder Softwareprogramme auszuführen, die in einer oder mehreren Speichervorrichtungen (nicht dargestellt) der ECU 202 gespeichert sind. Während die ECU 202 als getrennte Komponenten veranschaulicht sind, können die Fahrzeug-ECU 202 physische Hardware, Firmware und/oder Software gemein haben, sodass die Funktionalität mehrerer ECU 202 in einer einzigen ECU 202 zusammengefasst sein kann und die Funktionalität verschiedener derartiger ECU 202 über eine Vielzahl von ECU 202 verteilt sein kann.
Zu den ECU 202 können eine Antriebsstrangsteuerung 202-A, die dazu konfiguriert ist, mit einer oder mehreren Leistungsquellen des Fahrzeugs, wie etwa Motor, Batterie usw., verbundene Betriebskomponenten zu verwalten, eine Getriebesteuerung 202-B, die dazu konfiguriert ist, die Leistungsübertragung zwischen Antriebsstrang und Rädern des Fahrzeugs zu verwalten, eine Karosseriesteuerung 202-C, die dazu konfiguriert ist, verschiedene Leistungssteuerfunktionen, wie etwa Außenbeleuchtung, Innenbeleuchtung, schlüssellosen Zugang, Fernstart und Verifizierung des Status von Zugangspunkten, zu verwalten, ein Scheinwerfersteuermodul (Headlamp Control Module - HCM) 202-D, das dazu konfiguriert ist, Licht-Ein/Aus-Einstellungen zu steuern, erweiterte Fahrassistenzsysteme (Advanced Driver Assistance Systems - ADAS) 202-E, wie etwa adaptive Geschwindigkeitsregelung oder automatisches Bremsen, eine Klimaregelungsverwaltungssteuerung 202-F, die dazu konfiguriert ist, Heiz- und Kühlsystemkomponenten (z. B. Kompressorkupplung, Gebläselüfter, Temperatursensoren usw.) zu überwachen und verwalten, und eine Steuerung für ein globales Positionsbestimmungssystem (Global Positioning System - GPS) 202-G, die dazu konfiguriert ist, Fahrzeugstandortinformationen bereitzustellen, gehören. Die Haupteinheitensteuerung 104 kann zudem eines der ECU 202 sein, wie dargestellt. Es ist anzumerken, dass es sich hierbei lediglich um Beispiele handelt und Fahrzeuge 102 verwendet werden können, die mehr, weniger oder andere ECU 202 aufweisen.
Die TCU 144 kann einen oder mehrere Prozessoren (nicht dargestellt) (z. B. Mikroprozessoren) beinhalten, die dazu konfiguriert sind, Firmware- oder Softwareprogramme auszuführen, die in einer oder mehreren entsprechenden Speichervorrichtungen der TCU 144 gespeichert sind. Die TCU 144 kann ein Modem oder andere Netzhardware beinhalten, um die Kommunikation zwischen dem Fahrzeug 102 und einem oder mehreren Netzen außerhalb des Fahrzeugs 102 zu ermöglichen. Zu diesen externen Netzen können als einige nicht einschränkende Beispiele das Internet, ein Kabelfernsehverteilungsnetz, ein Satellitenverbindungsnetz, ein lokales Netz, ein Weitverkehrsnetz und ein Telefonnetz gehören.
Das Gateway 142 kann dazu konfiguriert sein, einen Datenaustausch zwischen Fahrzeug-ECU 202 zu ermöglichen. Das Gateway 142 kann ferner dazu konfiguriert sein, einen Datenaustausch zwischen den Fahrzeug-ECU 202 und der im Backbone 210 angeordneten TCU 144 zu ermöglichen. In einem Beispiel können die Fahrzeug-ECU 202 und die TCU 144 mit dem Gateway 142 unter Verwendung eines CAN-Kommunikationsprotokolls, wie etwa unter anderem eines Hochgeschwindigkeits(High-Speed - HS)-CAN, eines Mittelgeschwindigkeits(Mid-Speed - MS)-CAN oder eines Niedriggeschwindigkeits(Low-Speed - LS)-CAN, kommunizieren. Unterschiedliche Teilnetze 208 können unterschiedliche CAN-Protokoll-Geschwindigkeiten nutzen. In einem Beispiel können eines oder mehrere der Teilnetze HS-CAN umsetzen, während ein oder mehrere andere Teilnetze 208 MS-CAN umsetzen können. In noch anderen Beispielen kann das Gateway 142 dazu konfiguriert sein, Kommunikation unter Verwendung eines oder mehrerer von einem Ethernet-Netz, einem Media-Oriented-System-Transfer(MOST)-Netz, einem FlexRay-Netz oder einem Local-Interconnect-Netz (LIN) zu ermöglichen.
Eines oder mehrere der Teilnetze 208 können ein Hauptteilnetz definieren, das als Backbone 210 bezeichnet werden kann. Das Backbone 210 kann einen Abschnitt der Topologie 200 beinhalten, der dazu konfiguriert ist, als Kommunikationsverbindungspunkt für die anderen Teilnetze 208 des Fahrzeugs 102 zu dienen. Demnach kann das Backbone 210 dazu konfiguriert sein, Datenverkehr in einem größeren Volumen als dem über die anderen Teilnetze 208 bereitgestellten zu verwalten und weiterzuleiten. Unter Verwendung der Nachrichtenverarbeitungsfunktionen des Gateways 142 kann das Gateway 142 dazu konfiguriert sein, Nachrichtenrahmen zwischen der im Backbone 210 angeordneten TCU 144 und der einen oder den mehreren in den anderen Teilnetzen 208 angeordneten Fahrzeug-ECU 202 zu übertragen.
Das Gateway 142 kann dazu konfiguriert sein, zu identifizieren, in welchem Teilnetz 208 sich die ECU 202 und die TCU 144 jeweils befinden. Dies kann anhand einer entsprechenden physischen Netzadresse der ECU 202 und der TCU 144 erfolgen. In einem Beispiel kann das Gateway 142 in Reaktion darauf, dass es eine Anforderung zum Weiterleiten einer Nachricht an eine jeweilige ECU 202 oder die TCU 144 empfängt, einen Speicher abfragen, um eine Netzadresse zu identifizieren, die der ECU 202 oder der TCU 144 entspricht. Beispielsweise kann das Gateway 142 einen Speicher, der dazu konfiguriert ist, die Netzadressen zu speichern, sowie ein Weiterleitungsschema, das definiert, welche Nachrichten an welche Teilnetze 208 und/oder das Backbone 210 weitergeleitet werden, beinhalten. Dieses Weiterleiten kann durch das Gateway 142 auf Grundlage von in der Nachricht enthaltenen vordefinierten Parametern, wie z. B. eines Nachrichtentyps und/oder Kennungen der ECU 202 oder der TCU 144, welche die Quelle und/oder das Ziel der Nachricht angeben, bestimmt werden.
3 veranschaulicht ein beispielhaftes System 300 zum Senden von Mobilvorrichtungsbefehlen 306 an ein Fahrzeug 102 von einem Anwendungsserver 302. Wie dargestellt, können das Fahrzeug 102, ein Anwendungsserver 302 und ein Fahrzeug-API-Server 304 dazu konfiguriert sein, über ein Kommunikationsnetz 156 zu kommunizieren. Der Anwendungsserver 302 kann dazu konfiguriert sein, eine gehostete Mobilanwendung 308 auszuführen, um einen Anwendungsbefehl 310 an den Fahrzeug-API-Server 304 zu senden. Der API-Server 304 kann dazu konfiguriert sein, ein API-Gateway 312 auszuführen. In Reaktion auf den Empfang des Anwendungsbefehls 310 kann der API-Server 304 dazu konfiguriert sein, das API-Gateway 312 zu nutzen, um einen simulierten Mobilvorrichtungsbefehl 314 an das Fahrzeug 102 zu senden. Wie nachfolgend näher erläutert, kann der simulierte Mobilvorrichtungsbefehl 314 von dem Fahrzeug 102 so verarbeitet werden, als wäre der simulierte Mobilvorrichtungsbefehl 314 von einer Mobilanwendung 170 einer Mobilvorrichtung 152 gesendet worden, die direkt mit dem Fahrzeug 102 verbunden ist. Wenngleich in 3 ein beispielhaftes System 300 dargestellt ist, sollen die veranschaulichten beispielhaften Komponenten nicht der Einschränkung dienen. Tatsächlich kann das System 300 mehr oder weniger Komponenten aufweisen und können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden.
Der Anwendungsserver 302 kann verschiedene Arten von Rechenvorrichtungen, wie z. B. einen Computerarbeitsplatz, einen Server, einen Desktop-Computer, eine virtuelle Serverinstanz, die von einem Großrechner-Server ausgeführt wird, oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung, einschließen. Rechenvorrichtungen wie der Anwendungsserver 302 beinhalten im Allgemeinen einen Speicher, in den computerausführbare Anweisungen und Daten aus einem Speicher geladen werden können, wobei die Anweisungen von einem oder mehreren Prozessoren der Rechenvorrichtung ausführbar sein können. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert werden. Der computerlesbare Speicher (auch als prozessorlesbares Medium oder prozessorlesbarer Speicher bezeichnet) schließt ein jedes dauerhaftes (z. B. physisches) Medium ein, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von dem Prozessor des Analyseservers) gelesen werden können. Im Allgemeinen empfangen Prozessoren Anweisungen, z. B. von dem Speicher über das computerlesbare Speichermedium, und führen diese Anweisungen aus, wodurch sie einen oder mehrere Verfahren, einschließlich eines oder mehrerer der hier beschriebenen Verfahren, durchführen. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielfalt an Programmiersprachen und/oder -techniken, einschließlich unter anderem entweder allein oder in Kombination Java, C, C++, C#, Fortran, Pascal, Visual Basic, Java Script, Perl, PL/SQL usw., erstellt worden sind.
Ebenso wie der Anwendungsserver 302 kann der Fahrzeug-API-Server 304 verschiedene Arten von Rechenvorrichtungen (nicht dargestellt) einschließen, die einen Speicher beinhalten, auf dem computerausführbare Anweisungen gespeichert sein können, wobei die Anweisungen von einem oder mehreren Prozessoren der Rechenvorrichtung ausführbar sein können.
Wie oben angemerkt, kann die Mobilvorrichtung 152 dazu konfiguriert sein, die Mobilanwendungen 170 auszuführen. Diese Mobilanwendungen 170 können mit dem Fahrzeug über die Vorrichtungsverbindungsschnittstelle 172 kommunizieren, um die Integration von Funktionalität der Mobilanwendungen 170 zu ermöglichen, die dazu konfiguriert sind, mit einem Vorrichtungsverbindungsanwendungskern 174, der von der Mobilvorrichtung 152 ausgeführt wird, zu kommunizieren. Die Mobilanwendungen 170 können diese Schnittstellen nutzen, um Mobilvorrichtungsbefehle 306 an Steueraspekte des Fahrzeugs 102 zu senden sowie Mobilvorrichtungsbefehle 306 von der Haupteinheitensteuerung 104 zu empfangen (umgekehrte Richtung nicht dargestellt).
Der Anwendungsserver 302 kann ebenso Mobilanwendungen 308 hosten, die durch den Anwendungsserver 302 anstatt durch die Mobilvorrichtung 152 ausgeführt werden, die jedoch ebenfalls dazu konfiguriert sind, Dienste an das Fahrzeug 102 bereitzustellen. Diese gehosteten Mobilanwendungen 308 können dazu konfiguriert sein, Befehle über ein Webprotokoll (z. B. HTTP) anstatt über eine Drahtlos- oder andere Protokollverbindung zwischen der Mobilvorrichtung 152 und dem Fahrzeug 102 zu senden.
Der Fahrzeug-API-Server 304 kann dazu konfiguriert sein, das API-Gateway 312 auszuführen. Das API-Gateway 312 kann eine Anwendung sein, die auf dem Fahrzeug-API-Server 304 installiert und dazu programmiert ist, den Fahrzeug-API-Server 304 dazu zu veranlassen, die Anwendungsbefehle 310 von dem Anwendungsserver 302 zu empfangen, Sicherheitsaspekte der Anwendungsbefehle 310 zu prüfen und simulierte Mobilvorrichtungsbefehle 314 zu erzeugen, die an das Fahrzeug 102 zu senden sind.
Die simulierten Mobilvorrichtungsbefehle 314 können von der TCU 144 des Fahrzeugs 102 empfangen, von der TCU 144 als simulierte Mobilvorrichtungsbefehle 314 erkannt und verwendet werden, um das Fahrzeug 102 ähnlich zu steuern, wie das Fahrzeug 102 unter Verwendung von Mobilvorrichtungsbefehlen 306 gesteuert werden kann. Somit kann die TCU 144 tatsächlich anstelle der gekoppelten Mobilvorrichtung 152 beim Bereitstellen von Anwendungsbefehlen an die Haupteinheitensteuerung 104 fungieren.
4 veranschaulicht ein beispielhaftes Verfahren 400 zum Verwenden eines Fahrzeug-API-Servers 304, um Telematikdienste an ein Fahrzeug 102 von dem Anwendungsserver 302 bereitzustellen. In einem Beispiel kann das Verfahren 400 unter Verwendung der oben in Bezug auf die 1-3 beschriebenen Systeme durchgeführt werden.
Bei 402 empfängt der Fahrzeug-API-Server 304 einen Anwendungsbefehl 310 von einer gehosteten Mobilanwendung 308, die von dem Anwendungsserver 302 ausgeführt wird. In einem Beispiel kann der Anwendungsbefehl 310 in einer Webanforderung, wie z. B. einer HTTP-Anforderung, enthalten sein. Der Anwendungsbefehl 310 kann über das Kommunikationsnetz 156 gesendet werden, bei dem es sich um ein Weitverkehrsnetz wie das Internet handeln kann, und kann durch eine Cloud-API des Fahrzeug-API-Servers 304 empfangen werden. Zu Beispielen für die Cloud-API gehören Schnittstellen zum Steuern verschiedener Fahrzeugfunktionen (z. B. Verriegeln, Entriegeln, Start/Stopp des Motors, Senden eines Ziels an das fahrzeuginterne Navigationssystem, Regeln des Klimas, Radios, anderer fahrzeuginterner Einstellungen usw.). Die Cloud-API kann zusätzlich oder alternativ dazu Schnittstellen zum Empfangen von Fahrzeuginformationen (z. B. globaler Standort des Fahrzeugs 102, Geschwindigkeit des Fahrzeugs 102, Fahrzeugdiagnosestatus, Fahrzeugzustand usw.) beinhalten.
Das Zielfahrzeug 102 kann in dem Anwendungsbefehl 310 durch die Fahrzeug-FIN identifiziert werden. In einem anderen Beispiel kann das Zielfahrzeug 102 in dem Anwendungsbefehl 310 gemäß einer verschleierten FIN identifiziert werden, um eine andere und dennoch eindeutige Fahrzeugkennung gegenüber Dritten bereitzustellen. Dadurch ist es immer noch möglich, ein einziges, eindeutiges Fahrzeug 102 zu steuern, entfallen jedoch Bedenken bezüglich des Datenschutzes, die sich auf ein Offenlegen der FIN gegenüber fremden Dritten beziehen.
Bei Vorgang 404 erzeugt der Fahrzeug-API-Server 304 einen simulierten Mobilvorrichtungsbefehl 314 in Reaktion auf den Empfang des Anwendungsbefehls 310. In einem Beispiel führt das API-Gateway 312 eine oder mehrere Prüfungen an dem empfangenen Anwendungsbefehl 310 durch. Zu diesen Prüfungen können als einige Beispiele Identitäts-, Sicherheits-, Berechtigungs-, Fähigkeits- und Abonnementprüfungen gehören.
Beispielsweise kann das API-Gateway 312 Informationen zur Konfiguration der Fahrzeugkonstruktion speichern oder Zugang dazu haben. Diese Informationen können nach der FIN oder einer anderen Fahrzeugkennung indexiert sein und können die im Fahrzeug 102 zum Herstellungszeitraum installierte Ausstattung angeben. Die installierte Ausstattung kann beeinflussen, welche Funktionen ausgelöst werden können. In einem Beispiel kann es sein, dass, wenn das Fahrzeug 102 nicht über elektrisch verstellbare Sitze verfügt, eine App für „elektrisch verstellbare Sitze“ nicht dazu imstande ist, zu funktionieren oder Befehle an dieses beispielhafte Fahrzeug 102 zu senden. Das API-Gateway 312 kann eine entsprechende Prüfung vornehmen, um sicherzustellen, dass das Zielfahrzeug 102 für den empfangenen Anwendungsbefehl 310 die Ausstattung zum Ausführen der Anforderung aufweist.
In einem anderen Beispiel kann das API-Gateway 312 Identitätsprüfungen durchführen, um zu prüfen, ob es sich bei dem Drittanrufer-Anwendungsserver 302 tatsächlich um den handelt, der er vorgibt zu sein. Beispielsweise können die Identitätsprüfungen einen Authentifizierungsmechanismus wie etwa OAuth-2.0-Anmeldeinformationen verwenden, um den Anwendungsserver 302 und/oder die gehostete Mobilanwendung 308 des Anwendungsservers 302 zu bestätigen.
Als wieder anderes Beispiel kann das API-Gateway 312 Berechtigungsprüfungen durchführen. Beispielsweise kann das API-Gateway 312 eine Richtlinienarchitektur umsetzen, die es dem Fahrzeug-API-Server 304 ermöglicht, Berechtigungen je Drittpartner per API zu definieren, sowie es dem Benutzer ermöglicht, zusätzlich kategoriebasierten Zugriff für Dritte zuzulassen, um auf ihr privates oder zeitweise benutztes Fahrzeug 102 zuzugreifen.
In einigen Fällen können bestimmte fahrzeuginterne Infotainment-Funktionen ein benutzerbasiertes Abonnement zur Aktivierung erfordern. Beispielsweise kann eine Online-Verkehrsfunktion, die Informationen zu aktuellen Verkehrsbedingungen bereitstellt, ein Abonnement erfordern. Somit kann bei einigen API der Status des Abonnements für eine bestimmte Funktion durch das API-Gateway 312 geprüft werden, bevor ein Befehl an das Fahrzeug 102 gesendet wird. Wenn das Abonnement inaktiv ist, wäre es nicht möglich, die API-Anforderung abzuschließen.
Das API-Gateway 312 kann ferner die Cloud-API auf eine Vorrichtungsverbindungs-API abbilden und die abgebildete Nachricht als einen simulierten Mobilvorrichtungsbefehl 314 weiterleiten, der zur Übertragung an das Fahrzeug 102 zu verschlüsseln ist. Das API-Gateway 312 kann entsprechend Sicherheit durch die Verschlüsselung von Nachrichten zwischen der Cloud und dem Fahrzeug 102 anwenden.
Der Fahrzeug-API-Server 304 sendet den simulierten Mobilvorrichtungsbefehl 314 an das Fahrzeug 102 bei 406. In einem Beispiel sendet der Fahrzeug-API-Server 304 den simulierten Mobilvorrichtungsbefehl 314 an das Fahrzeug 102 über das Kommunikationsnetz 156, um von der TCU 144 des Fahrzeugs 102 empfangen zu werden. Nach dem Vorgang 406 endet das Verfahren 400.
5 veranschaulicht ein beispielhaftes Verfahren 500 zum Bereitstellen von Telematikdiensten an das Fahrzeug 102 von der gehosteten Mobilanwendung 308, die von dem Anwendungsserver 302 ausgeführt wird, über einen Fahrzeug-API-Server 304.
Bei 502 empfängt die TCU 144 des Fahrzeugs 102 einen verschlüsselten Befehl von dem Fahrzeug-API-Server 304. In einem Beispiel ist der Befehl ein simulierter Mobilvorrichtungsbefehl 314, wie er über das Verfahren 400 gesendet wird. In einem anderen Beispiel liegt der Befehl in einer anderen Befehlsform vor, wie z. B. als ein Türentriegelungsbefehl, der nicht auf Grundlage einer gehosteten Mobilanwendung 308 gesendet wird. Die TCU 144 kann den simulierten Mobilvorrichtungsbefehl 314 zur Verarbeitung an das Gateway 142 senden.
Bei Vorgang 504 entschlüsselt das Gateway 142 den Befehl. Beispielsweise enthält der simulierte Mobilvorrichtungsbefehl 314 von dem Fahrzeug-API-Server 304 einen anderen Befehl für das fahrzeuginterne Telematiksystem. Das Gateway 142 versteht den enthaltenen Befehl nicht. Das Gateway 142 entschlüsselt jedoch den simulierten Mobilvorrichtungsbefehl 314, um den enthaltenen Befehl zu entpacken.
Das Gateway 142 bestimmt bei 506, ob der Befehl ein simulierter Mobilvorrichtungsbefehl 314 ist. In einem Beispiel kann der Befehl ein Feld oder eine andere Kennung enthalten, das bzw. die angibt, dass der Befehl ein Vorrichtungsverbindungsbefehl ist, der für die Haupteinheitensteuerung 104 bestimmt ist. Wenn bestimmt wird, dass der Befehl ein simulierter Mobilvorrichtungsbefehl 314 ist, geht die Steuerung zu Vorgang 508 über. Anderenfalls geht die Steuerung zu Vorgang 512 über. Demnach weiß das Gateway 142, dass es den Befehl in dem simulierten Mobilvorrichtungsbefehl 314 an die Haupteinheitensteuerung 104 senden soll, nachdem es die Nachricht von dem Fahrzeug-API-Server 304 entpackt hat.
Bei 508 leitet das Gateway 142 den simulierten Mobilvorrichtungsbefehl 314 an die Haupteinheitensteuerung 104 weiter. In einem Beispiel kann die Haupteinheitensteuerung 104 die Nachricht über eines der Teilnetze 208 empfangen.
Bei Vorgang 510 verarbeitet die Haupteinheitensteuerung 104 den simulierten Mobilvorrichtungsbefehl 314. In einem Beispiel kann die Haupteinheitensteuerung 104 den simulierten Mobilvorrichtungsbefehl 314 an die Vorrichtungsverbindungsschnittstelle 172 senden, als wäre der simulierte Mobilvorrichtungsbefehl 314 von einer verbundenen Mobilvorrichtung 152 empfangen worden. Demnach kann die Haupteinheitensteuerung 104 den simulierten Mobilvorrichtungsbefehl 314 verarbeiten, um Telematikfunktionen bereitzustellen, obwohl der Befehl nicht von einer Mobilvorrichtung stammt, die sich in dem Innenraum des Fahrzeugs 102 befindet. Nach dem Vorgang 510 endet das Verfahren 500.
Bei 512 leitet das Gateway 142 den Befehl an die durch den Befehl vorgegebene Ziel-ECU 202 weiter. Demnach können andere Befehle als der simulierte Mobilvorrichtungsbefehl 314 weiterhin durch das Gateway 142 verarbeitet werden, ohne durch die Funktionalität der simulierten Mobilvorrichtungsbefehle 314 beeinflusst zu werden. Nach dem Vorgang 512 endet das Verfahren 500.
Hier beschriebene Rechenvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa durch die vorstehend aufgeführten, ausführbar sein können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -techniken, einschließlich unter anderem entweder allein oder in Kombination Java™, C, C++, C#, Visual Basic, Java Script, Perl usw., erstellt worden sind. 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 er ein oder mehrere Verfahren, einschließlich eines oder mehrerer der hier beschriebenen Verfahren, durchführt. Derartige Anweisungen und andere Daten können unter Verwendung vielfältiger computerlesbarer Medien gespeichert und übertragen werden.
Während vorstehend Ausführungsbeispiele beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und nicht einschränkende Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Außerdem können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden.
Gemäß der vorliegenden Erfindung wird ein System bereitgestellt, das einen Server aufweist, der dazu programmiert ist, einen Anwendungsbefehl von einer gehosteten Anwendung zu empfangen, die von einem zweiten Server ausgeführt wird, einen simulierten Mobilvorrichtungsbefehl zu erzeugen, der eine von dem Anwendungsbefehl vorgegebene Funktion angibt, und den simulierten Mobilvorrichtungsbefehl an eine Telematiksteuerung eines Fahrzeugs zu senden, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
Gemäß einer Ausführungsform wird die Vorrichtungsverbindungsschnittstelle durch eine Haupteinheitensteuerung des Fahrzeugs ausgeführt und beinhaltet der Anwendungsbefehl eine Anforderung zum Anzeigen von Informationen auf einem Bildschirm einer Haupteinheitensteuerung des Fahrzeugs.
Gemäß einer Ausführungsform ist der Server ferner dazu programmiert, den simulierten Mobilvorrichtungsbefehl gemäß einem Verschlüsselungsprotokoll zu verschlüsseln, das von einem Gateway des Fahrzeugs unterstützt wird.
Gemäß einer Ausführungsform ist der Server ferner dazu programmiert, in dem simulierten Mobilvorrichtungsbefehl anzugeben, dass der simulierte Mobilvorrichtungsbefehl für die Vorrichtungsverbindungsschnittstelle bestimmt ist.
Gemäß einer Ausführungsform handelt es sich bei der gehosteten Anwendung, die von dem zweiten Server gehostet wird, um eine Navigationsanwendung, eine Fahrzeugentriegelungsanwendung oder eine Online-Verkehrsanwendung.
Gemäß einer Ausführungsform ist der Server ferner dazu programmiert, zu bestätigen, dass die Funktion durch eine Konstruktionskonfiguration des Fahrzeugs unterstützt wird.
Gemäß einer Ausführungsform erfordert die Funktion ein Abonnement des Fahrzeugs für einen Dienst und ist der Server ferner dazu programmiert, zu bestätigen, dass das Fahrzeug den Dienst abonniert hat.
Gemäß der vorliegenden Erfindung wird ein Fahrzeug bereitgestellt, das eine Haupteinheitensteuerung, eine Telematiksteuereinheit (TCU), die dazu programmiert, ist einen Befehl von einem Server zu empfangen, und ein Gateway, das dazu programmiert ist, den Befehl von der TCU zu empfangen und den Befehl an die Haupteinheitensteuerung weiterzuleiten, aufweist, wobei die Haupteinheitensteuerung dazu programmiert ist, den Befehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
Gemäß einer Ausführungsform ist die Haupteinheitensteuerung ferner dazu programmiert, einen zweiten Befehl unter Verwendung der Vorrichtungsverbindungsschnittstelle auszuführen, wobei der zweite Befehl von einer Mobilvorrichtung in dem Fahrzeug empfangen wird, wobei die Mobilvorrichtung direkt mit der Haupteinheitensteuerung verbunden ist.
Gemäß einer Ausführungsform gibt der Befehl an, dass der Befehl ein simulierter Mobilvorrichtungsbefehl ist, der für die Vorrichtungsverbindungsschnittstelle bestimmt ist.
Gemäß einer Ausführungsform wird der Befehl von einer gehosteten Mobilanwendung empfangen, die von einem Anwendungsserver ausgeführt wird, der mit dem Server in Kommunikation steht.
Gemäß einer Ausführungsform ist der Befehl ein Befehl von einer Navigationsanwendung, einer Fahrzeugentriegelungsanwendung oder einer Online-Verkehrsanwendung, die von dem Server gehostet wird.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren Senden eines simulierten Mobilvorrichtungsbefehls, der eine Funktion angibt, die von einem Anwendungsbefehl vorgegeben ist, der von einer durch einen Anwendungsserver gehosteten Mobilanwendung empfangenen wird, an eine Telematiksteuerung eines Fahrzeugs, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
Gemäß einer Ausführungsform wird die Vorrichtungsverbindungsschnittstelle durch eine Haupteinheitensteuerung des Fahrzeugs ausgeführt und beinhaltet der Anwendungsbefehl eine Anforderung zum Anzeigen von Informationen auf einem Bildschirm einer Haupteinheitensteuerung des Fahrzeugs.
Gemäß einer Ausführungsform ist der Anwendungsserver ferner dazu programmiert, den simulierten Mobilvorrichtungsbefehl zu verschlüsseln.
Gemäß einer Ausführungsform ist der Anwendungsserver ferner dazu programmiert, in dem simulierten Mobilvorrichtungsbefehl anzugeben, dass der simulierte Mobilvorrichtungsbefehl für die Vorrichtungsverbindungsschnittstelle bestimmt ist.
Gemäß einer Ausführungsform handelt es sich bei der Mobilanwendung um eine Navigationsanwendung, eine Fahrzeugentriegelungsanwendung oder eine Online-Verkehrsanwendung.

Claims

System, umfassend: einen Server, der programmiert ist zum: Empfangen eines Anwendungsbefehls von einer gehosteten Anwendung, die von einem zweiten Server ausgeführt wird, Erzeugen eines simulierten Mobilvorrichtungsbefehls, der eine von dem Anwendungsbefehl vorgegebene Funktion angibt, und Senden des simulierten Mobilvorrichtungsbefehls an eine Telematiksteuerung eines Fahrzeugs, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
System nach Anspruch 1, wobei die Vorrichtungsverbindungsschnittstelle durch eine Haupteinheitensteuerung des Fahrzeugs ausgeführt wird und der Anwendungsbefehl eine Anforderung zum Anzeigen von Informationen auf einem Bildschirm einer Haupteinheitensteuerung des Fahrzeugs beinhaltet.
System nach Anspruch 1, wobei der Server ferner dazu programmiert ist, den simulierten Mobilvorrichtungsbefehl gemäß einem Verschlüsselungsprotokoll zu verschlüsseln, das von einem Gateway des Fahrzeugs unterstützt wird.
System nach Anspruch 1, wobei der Server ferner dazu programmiert ist, in dem simulierten Mobilvorrichtungsbefehl anzugeben, dass der simulierte Mobilvorrichtungsbefehl für die Vorrichtungsverbindungsschnittstelle bestimmt ist.
System nach Anspruch 1, wobei es sich bei der gehosteten Anwendung, die von dem zweiten Server gehostet wird, um eine Navigationsanwendung, eine Fahrzeugentriegelungsanwendung oder eine Online-Verkehrsanwendung handelt.
System nach Anspruch 1, wobei der Server ferner dazu programmiert ist, zu bestätigen, dass die Funktion durch eine Konstruktionskonfiguration des Fahrzeugs unterstützt wird.
System nach Anspruch 1, wobei die Funktion ein Abonnement des Fahrzeugs für einen Dienst erfordert und der Server ferner dazu programmiert ist, zu bestätigen, dass das Fahrzeug den Dienst abonniert hat.
Verfahren, umfassend: Senden eines simulierten Mobilvorrichtungsbefehls, der eine Funktion angibt, die von einem Anwendungsbefehl vorgegeben ist, der von einer durch einen Anwendungsserver gehosteten Mobilanwendung empfangenen wird, an eine Telematiksteuerung eines Fahrzeugs, um das Fahrzeug dazu zu veranlassen, den Anwendungsbefehl unter Verwendung einer Vorrichtungsverbindungsschnittstelle auszuführen, die zur Kommunikation zwischen dem Fahrzeug und sich in dem Fahrzeug befindenden Mobilvorrichtungen konfiguriert ist.
Verfahren nach Anspruch 8, wobei die Vorrichtungsverbindungsschnittstelle durch eine Haupteinheitensteuerung des Fahrzeugs ausgeführt wird und der Anwendungsbefehl eine Anforderung zum Anzeigen von Informationen auf einem Bildschirm einer Haupteinheitensteuerung des Fahrzeugs beinhaltet.
Verfahren nach Anspruch 8, wobei der Anwendungsserver ferner dazu programmiert ist, den simulierten Mobilvorrichtungsbefehl zu verschlüsseln.
Verfahren nach Anspruch 8, wobei der Anwendungsserver ferner dazu programmiert ist, in dem simulierten Mobilvorrichtungsbefehl anzugeben, dass der simulierte Mobilvorrichtungsbefehl für die Vorrichtungsverbindungsschnittstelle bestimmt ist.
Verfahren nach Anspruch 8, wobei es sich bei der Mobilanwendung um eine Navigationsanwendung, eine Fahrzeugentriegelungsanwendung oder eine Online-Verkehrsanwendung handelt.