DE102008046929B4

DE102008046929B4 - Verfahren und Vorrichtung zum Realisieren eines mobilen Servers

Info

Publication number: DE102008046929B4
Application number: DE102008046929A
Authority: DE
Inventors: Ansaf I. Livonia Alrabady; Thomas M. P. Rochester Catsburg
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2007-09-17
Filing date: 2008-09-12
Publication date: 2010-07-22
Anticipated expiration: 2028-09-13
Also published as: US7818403B2; DE102008046929A1; US20090077267A1

Abstract

Verfahren zum Übertragen von Daten von einer Client-Einrichtung an ein Computer-Modul in einem Fahrzeug, wobei das Verfahren umfasst, dass
eine Anforderung bezüglich einer Software-Komponente von der Client-Einrichtung über einen Standard-Port an dem fahrzeuginternen Kommunikations-Gateway-Modul empfangen wird, wobei die Software-Komponente ein Modul eines nicht standardisierten Transferprotokolls umfasst;
das Modul eines nicht standardisierten Transferprotokolls an der Client-Einrichtung geladen wird; und
Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll ausgetauscht werden.

Description

TECHNISCHES GEBIET
Die Ausführungsformen der vorliegenden Erfindung betreffen allgemein die Telematik, und einige Ausführungsformen betreffen insbesondere das Realisieren eines mobilen Servers zum Übermitteln von Daten zwischen einer Client-Einrichtung und einem Computer-Modul in einem Fahrzeug.
HINTERGRUND DER ERFINDUNG
Ein Telematiksystem liefert Informationen an eine oder von einer mobilen Quelle (z. B. ein Fahrzeug) und stellt oftmals Fahrzeugsysteme dar, die GPS- und Zellulartechnologien mit fahrzeugeigener Elektronik kombinieren, was einem Fahrzeug ermöglicht, einer entfernt angeordneten Client-Einrichtung eine Information zu liefern oder auf zahlreiche Telematikdienste zuzugreifen, die einer entfernt angeordneten Client-Einrichtung bereitgestellt werden. Die Telematikdienste können Sicherheits-, Kommunikations-, Fahrzeugdiagnose- und Unterhaltungsmerkmale umfassen.
In der DE 102 37 715 A1 wird ein Verfahren zum Fernzugriff von einem sever- oder providerseitigen Teil auf ein Fahrzeugsteuersystem über eine drahtlose Verbindung beschrieben. Der serverseitige Teil stellt eine externe Infrastruktur dar, die aus Serviceprovider, Callcenter und Datenbanken bestehen kann. Dabei ist ein fahrzeugseitiges Endgerät, welches ein GSM-, GPRS- oder UMTS-Funkmodem ist, mit dem Gateway-Steuergerät verbunden, welches wiederum über einen Fahrzeug-Bus an mehrere Steu ergeräte des Kraftfahrzeugs angebunden ist. Die beschriebene Konfiguration wird in Verbindung mit Funktionen zur Fernwirkung, Ferndiagnose, Fernwartung oder Softwaredownload eingesetzt. Dabei sind Protokolle, die zur Diagnose, zur Fernwirkung, zur Statusabfrage und/oder zur Umprogrammierung von einzelnen Steuergeräten im Kraftfahrzeug benötigt werden, unabhängige Applikationen, die auf der Gateway-Plattform ablaufen und die unabhängig über die Funkstrecke ladbar sind.
Erwünschte Merkmale und Eigenschaften der vorliegenden Erfindung werden aus der nachfolgenden detaillierten Beschreibung und den beigefügten Ansprüchen in Verbindung mit den begleitenden Zeichnungen und dem vorstehenden technischen Gebiet und Hintergrund ersichtlich.
ZUSAMMENFASSUNG DER ERFINDUNG
Es wird ein Verfahren zum Übertragen von Daten zwischen einer Client-Einrichtung und einem Fahrzeug bereitgestellt. Gemäß diesem Verfahren sendet ein Server, der an einem fahrzeuginternern Kommunikations-Gateway-Modul gehostet ist, eine Software-Komponente, die ein Modul eines nicht standardisierten Transferprotokolls umfasst, in Ansprechen auf eine Anforderung von der Client-Einrichtung an eine Browser-Anwendung, die an der Client-Einrichtung gehostet ist. Standard-Ports an dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung werden geschlossen, und Daten werden zwischen dem Server und der Browser-Anwendung gemäß dem nicht standardisierten Transferprotokoll ausgetauscht. Optional können die empfangenen Daten dann von dem fahrzeuginternen Kommunikations-Gateway-Modul an ein Computer-Modul in dem Fahrzeug übertragen werden.
Es wird ein fahrzeuginternes Kommunikations-Gateway-Modul bereitgestellt, das einen Server umfasst, der entworfen ist, um eine Software-Komponente, die ein Modul eines nicht standardisierten Transferprotokolls umfasst, in Ansprechen auf eine Anforderung von der Client-Einrichtung an eine Browser-Anwendung zu übertragen, die an einer Client-Einrichtung gehostet ist. Nach dem Übertragen der Software-Komponente schließt das fahrzeuginterne Kommunikations-Gateway-Modul einen Standard-Port. Das fahrzeuginterne Kommunikations-Gateway-Modul umfasst auch ein Kommunikationsmodul, das entworfen ist, um Daten mit einem Computer-Modul in dem Fahrzeug auszutauschen, und um die Daten zwischen dem Server und der Browser-Anwendung gemäß dem nicht standardisierten Transferprotokoll auszutauschen.
Außerdem wird ein fahrzeuginternes Kommunikations-Gateway-Modul bereitgestellt, das die Merkmale des Anspruches 16 aufweist.
BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird hierin nachfolgend in Verbindung mit den folgenden Zeichnungen beschrieben, bei denen gleiche Bezugszeichen gleiche Elemente bezeichnen, und
1 ein Blockdiagramm eines Telematikkommunikationsnetzes ist, das eine entfernte Client-Einrichtung und ein Fahrzeug umfasst;
2 ein Stapel eines standardisierten Protokolls ist, der zum Austauschen von Daten zwischen der Client-Einrichtung und dem fahrzeuginternen Kommunikations-Gateway-Modul gemäß einem herkömmlichen Ansatz verwendet wird;
3 ein vereinfachtes Nachrichtenflussdiagramm zum Übermitteln von Daten an die entfernte Client-Einrichtung von einem Server an dem fahrzeuginternen Kommunikations-Gateway-Modul gemäß einem herkömmlichen Ansatz ist;
4 ein vereinfachtes Nachrichtenflussdiagramm zum Austauschen von Daten zwischen der Client-Einrichtung und dem fahrzeuginternen Kommunikations-Gateway-Modul, wenn die Client-Einrichtung Daten von einem fahrzeuginternen Computer-Modul anfordert, gemäß einigen Ausführungsformen der Erfindung ist;
5 ein beispielhafter Stapel eines nicht standardisierten Transferprotokolls, das zum Austauschen von Daten zwischen der Client-Einrichtung und dem fahrzeuginternen Kommunikations-Gateway-Modul verwendet wird, gemäß einigen Ausführungsformen der Erfindung ist;
6 ein vereinfachtes Nachrichtenflussdiagramm zum Austauschen von Daten zwischen der entfernten Client-Einrichtung und dem fahrzeuginternen Kommunikations-Gateway-Modul, wenn ein fahrzeuginternes Computer-Modul Daten an die entfernte Client-Einrichtung weiterleitet, gemäß anderen Ausführungsformen der Erfindung ist;
7 ein vereinfachtes Nachrichtenflussdiagramm zum Austauschen von Daten zwischen einer entfernten Server-Einrichtung und einem fahrzeuginternen Kommunikations-Gateway-Modul, wenn ein fahrzeuginternes Computer-Modul Daten von der entfernten Server-Einrichtung anfordert, gemäß einigen Ausführungsformen der Erfindung ist; und
8 ein vereinfachtes Nachrichtenflussdiagramm zum Austauschen von Daten zwischen einem fahrzeuginternen Kommunikations-Gateway-Modul und einer entfernten Client-Einrichtung, wenn die entfernte Client-Einrichtung Daten von einem fahrzeuginternen Computer-Modul anfordert, gemäß anderen Ausführungsformen der Erfindung ist.
BESCHREIBUNG EINER BEISPIELHAFTEN AUSFÜHRUNGSFORM
Vor dem detaillierten Beschreiben von Ausführungsformen, die der vorliegenden Erfindung entsprechen, ist anzumerken, dass die Ausführungsformen primär in Kombinationen von Verfahrensschritten und Vorrichtungskomponenten umfasst sind, die mit dem Übermitteln von Daten zwischen einer Client-Einrichtung und einem Computer-Modul in einem Fahrzeug in Verbindung stehen. Dementsprechend wurden die Vorrichtungskomponenten und die Verfahrensschritte in den Zeichnungen nach Bedarf durch Symbole dargestellt, wobei nur jene spezifischen Details gezeigt sind, die dem Verständnis der Ausführungsformen der vorliegenden Erfindung sachdienlich sind, um die Offenbarung nicht mit Details zu verschleiern, die für Fachleute, welche Nutzen aus dieser Beschreibung ziehen, leicht ersichtlich sind.
In dieser Anmeldung werden relationale Begriffe, wie beispielsweise erste(r/s) und zweiter/s), möglicherweise lediglich verwendet, um eine Entität oder Aktion von einer anderen Entität oder Aktion zu unterscheiden, ohne notwendigerweise irgendeine tatsächliche solche Beziehung oder Reihenfolge zwischen solchen Entitäten oder Aktionen zu fordern oder zu implizieren. Die Begriffe ”umfasst”, ”umfassend” und andere Variationen hiervon sollen eine nicht ausschließende Einschließung abdecken, so dass ein Prozess, ein Verfahren, ein Artikel oder eine Vorrichtung, der, das bzw. die eine Liste von Elementen umfasst, nicht nur jene Elemente einschließt, sondern andere Elemente umfassen kann, die nicht ausdrücklich in Bezug auf solch einen Prozess, solch ein Verfahren, solch einen Artikel oder solch eine Vorrichtung aufgelistet sind oder diesem oder dieser zugehörig sind. Ein Element, dem ein ”umfassend ein(e/n)” folgt, schließt das Vorhandensein zusätzlicher identischer Elemente in dem Prozess, dem Verfahren, dem Artikel oder der Vorrichtung, der, das bzw. die das Element umfasst, ohne weitere Einschränkungen nicht aus.
Es sei angemerkt, dass Ausführungsformen der hierin beschriebenen Erfindung aus einem oder mehreren herkömmlichen Prozessen und eindeutigen gespeicherten Programmanweisungen bestehen können, die den einen oder die mehreren Prozessoren steuern, um in Verbindung mit bestimmten Schaltkreisen, die keinen Prozessor umfassen, einige, die meisten oder alle Funktionen zum Übermitteln von Daten zwischen einer Client-Einrichtung und einem Computer-Modul in einem Fahrzeug wie hierin beschrieben zu realisieren. Die Schaltkreise, die keinen Prozessor umfassen, können einen Funkempfänger, einen Funksender, Signaltreiber, Taktschaltkreise, Stromquellenschaltkreise und Benutzereingabeeinrichtungen umfassen, sind jedoch nicht darauf beschränkt. Somit können diese Funktionen als Schritte eines Verfahrens zum Übermitteln von Daten zwischen einer Client-Einrichtung und einem Computer-Modul in ei nem Fahrzeug interpretiert werden. Alternativ könnten einige oder alle Funktionen durch einen Automaten, in dem keine Programmanweisungen gespeichert sind, oder in einem oder mehreren anwendungsspezifischen integrierten Schaltkreisen (ASICs) realisiert werden, wobei jede Funktion oder einige Kombinationen bestimmter Funktionen als angepasste Logik realisiert sind. Natürlich könnte eine Kombination der beiden Ansätze verwendet werden. Somit wurden hierin Verfahren und Mittel für diese Funktionen beschrieben. Ferner wird erwartet, dass ein Fachmann ungeachtet eines möglicherweise erheblichen Aufwands und vieler Entwurfsauswahlen, die beispielsweise von verfügbarer Zeit, momentaner Technologie und wirtschaftlichen Betrachtungen herrühren, mit einer Führung durch die Konzepte und Prinzipien, die hierin offenbart sind, leicht ermöglichen kann, solche Software-Anweisungen und Programme und ICs mit minimaler Versuchsdurchführung zu erzeugen.
Terminologie
Wie hierin verwendet bezieht sich der Begriff ”Fahrzeug” breit auf einen nicht lebendigen Beförderungsmechanismus. Beispiele für Fahrzeuge umfassen Automobile, wie beispielsweise Busse, Autos, Lastwagen, Geländewagen, Kleinbusse, Fahrzeuge, die nicht auf dem Land fahren, wie beispielsweise mechanische Wasserfahrzeuge, die Wasserfahrzeuge, Luftkissenfahrzeuge, Segelfahrzeuge, Boote und Schiffe umfassen, mechanische Unterwasserfahrzeuge, die Unterseeboote umfassen, mechanische Luftfahrzeuge, die Luftfahrzeuge und Raumfahrzeuge umfassen, mechanische Schienenfahrzeuge, wie beispielsweise Züge, Straßenbahnen und Förderwagen etc. Zusätzlich ist der Begriff ”Fahrzeug” nicht durch irgendeine spezifische Antriebstechnologie, wie beispielsweise Benzin- oder Dieselkraftstoff, beschränkt. Vielmehr umfassen Fahrzeuge auch Hybridfahrzeuge, Batterie-Elektrofahrzeuge, Wasserstofffahrzeuge und Fahrzeuge, die unter Verwendung von verschiedenen anderen alternativen Kraftstoffen arbeiten.
Beispielhaftes Telematiknetz
1 ist ein Blockdiagramm eines Telematikkommunikationsnetzes 100, das eine entfernte Client-Einrichtung 110 und ein Fahrzeug 125 umfasst.
Das Fahrzeug 125 umfasst ein fahrzeuginternes Kommunikations-Gateway-Modul 130 und eine Anzahl von Computer-Modulen 142, 144, 146 in dem Fahrzeug 125. Das fahrzeuginterne Kommunikations-Gateway-Modul 130 kommuniziert mit den anderen Computer-Modulen 142, 144, 146 in dem Fahrzeug 125 über ein internes Fahrzeugnetz. Das fahrzeuginterne Kommunikations-Gateway-Modul 130 kommuniziert mit der entfernten Client-Einrichtung 110 über ein Netz, wie beispielsweise das Internet oder ein anderes IP-Netz.
Eine Client-Einrichtung 110 kann beispielsweise ein Personal Computer, ein Laptop-Computer, ein Handheld-Computer, wie beispielsweise ein persönlicher digitaler Assistent (PDA), oder eine drahtlose Kommunikationseinrichtung, wie beispielsweise ein Mobiltelefon, sein. Während Client-Einrichtungen in Bezug auf den Ort des Fahrzeugs 125 allgemein entfernt angeordnet sind, besteht keine Einschränkung bezüglich des Orts der Client-Einrichtung 110. Der Begriff ”Client-Einrichtung” bezieht sich allgemein auf jede Recheneinrichtung, die über eine Webbrowser-Anwendung 112, wie beispielsweise den Internet Explorer, über ein IP-Netz 120 (z. B. das Internet) kommunizieren kann. Einige Client-Einrichtungen umfassen auch einen Server 114.
Die Computer-Module 142, 144, 146 können allgemein jedes fahrzeuginterne Computer-Modul sein, das Daten empfangen, Daten senden und/oder verarbeiten oder Daten gemäß einer Liste von Anweisungen verändern kann. Nicht einschränkende Beispiele für Computer-Module umfassen beispielsweise ein Antriebsstrang-Controller-Modul, ein Karosseriesteuermodul, ein Türsteuermodul, ein Modul für einen schlüssellosen Eintritt, ein Antiblockiersteuermodul, ein Erfassungs- und Diagnosemodul, ein Armaturenbrettmodul, ein Navigationsmodul, ein Verteilergetriebesteuermodul, ein Radiomodul, ein Airbagmodul, ein Regensensormodul etc.
Das fahrzeuginterne Kommunikations-Gateway-Modul 130 bezieht sich allgemein auf Computer-Hardware- und/oder -Software-Module, die als Gateway für Übermittlungen zu oder von einer oder mehreren entfernten Client-Einrichtungen 110 und für Übermittlungen zu und von einem oder mehreren Computer-Modulen 142, 144, 146 dienen, die sich in dem Fahrzeug 125 befinden. Das fahrzeuginterne Kommunikations-Gateway-Modul 130 kann beispielsweise unter Verwendung eines Kommunikationsmoduls, wie beispielsweise eines Moduls einer flexiblen Computerplattform (FCPM), eines Telematikmoduls, etc. realisiert werden. Neben anderen Funktionen verwaltet das fahrzeuginterne Kommunikations-Gateway-Modul 130 Schnittstellen zu entfernten Client-Einrichtungen 110 und liefert Statusaktualisierungen zwischen den entfernten Client-Einrichtungen 110 und den Computer-Modulen 142, 144, 146 in dem Fahrzeug 125.
Das fahrzeuginterne Kommunikations-Gateway-Modul 130 umfasst auch einen Server 132, der dem fahrzeuginternen Kommunikations-Gateway-Modul 130 ermöglicht, über einen verdrahteten oder drahtlosen Link 122 mit der Client-Einrichtung 110 zu kommunizieren. Der Ziel- oder Ursprungs-HTTP-Server 132 speichert oder erzeugt Ressourcen, wie bei spielsweise HTML-Dateien und -Bilder. Wie hierin verwendet, bezieht sich der Begriff ”Server” auf einen Computer, der dafür verantwortlich ist, Anforderungen von Clients anzunehmen, die als ”Webbrowser” bekannt sind, und ihnen Antworten zusammen mit optimalen Dateninhalten zu liefern, die für gewöhnlich Webseiten wie beispielsweise HTML-Dokumente und verlinkte Objekte (Bilder etc.) oder andere Dateien sind. Es kann verschiedene Vermittler geben, wie beispielsweise Proxies, Gateways und Tunnel zwischen dem HTTP-Client und dem HTTP-Server. Ein Server umfasst typischerweise Hardware, ein Betriebssystem, Server-Software (IIS, Apache, etc.), die Anforderungen von dem Browser verwaltet und in Ansprechen darauf Webseiten (HTML-Dokumente und -Dateien) liefert, FTP-Server-Software zum Herunterladen von Dateien, SMTP-Server-Software für einen Email-Dienst und Seiteninhalt (z. B. Webseiten und andere Dateien). Ein Server führt auch Server-seitige Skripte (CGI-Skripte, JSPs, ASPs, etc.) aus. Wenn der Server intern und nicht von der Öffentlichkeit verwendet wird, kann er als ”Intranet-Server” bezeichnet werden.
Das fahrzeuginterne Kommunikations-Gateway-Modul 130 umfasst auch einen Client mit einer Webbrowser-Anwendung 134, die dem fahrzeuginternen Kommunikations-Gateway-Modul 130 ermöglicht, mit einem Server 114 zu kommunizieren, der an der Client-Einrichtung 110 läuft. Wie hierin verwendet, bezieht sich der Begriff ”Webbrowser” auf eine Software-Anwendung, die einem Benutzer ermöglicht, Text, Bilder und andere Informationen, die sich typischerweise auf einer Webseite an einer Website im Internet oder an einem Local Area Network befinden, anzuzeigen und hiermit in Interaktion zu treten. Beispiele für Webbrowser umfassen Internet Explorer, Mozilla Firefox, Safari, Opera und Netscape. Die Webbrowser kommunizieren mit Servern, um Webseiten von Servern abzurufen und/oder Informationen an Server zu liefern. Der Text und die Bilder auf einer Webseite können Hyperlinks auf andere Webseiten an der glei chen oder an einer anderen Website enthalten. Die Webbrowser ermöglichen einem Benutzer, schnell und leicht auf Informationen zuzugreifen, die auf vielen Webseiten an vielen Websites bereitgestellt werden, indem diese Links durchquert werden. Obwohl Browser typischerweise verwendet werden, um auf das Internet zuzugreifen, können sie auch verwendet werden, um auf Informationen, die durch Server in privaten Netzen bereitgestellt werden, oder Inhalt in Dateisystemen zuzugreifen.
Das fahrzeuginterne Kommunikations-Gateway-Modul 130 kann beispielsweise auch Funktionen einer drahtlosen Konnektivität und Sicherheitsfunktionen ausführen und viele Dienste bereitstellen, wie beispielsweise einen entfernten Reflash, entfernte Diagnosen, einen Medientransfer zu dem Fahrzeug, Wiedergabelisten, Adressbücher, Kartenaktualisierungen, Software-Modul-Aktualisierungen, etc.
Herkömmlicher mobiler Server
Es wurden Telematiksysteme vorgeschlagen, die ermöglichen, dass ein fahrzeuginternes Kommunikations-Gateway-Modul 130 als ein fahrzeugseitiger Server 132 arbeitet, der auch als Telekommunikations-Controller für die fahrzeuginternen Computer-Module 142, 144, 146 fungiert. Beispielsweise offenbart das US-Patent US 5,732,074 A von Cellport Systems das Verwenden eines dedizierten Controllers in einem Fahrzeug als Server. Bei diesem System fungiert der fahrzeugseitige Server 132 als Gateway zu Kraftfahrzeugbussen, die dem Fahrzeug 125 ermöglicht, eine Verbindung zu dem Internet 120 herzustellen, und es werden standardisierte Transferprotokolle verwendet, um Informationen zwischen dem fahrzeugseitigen Server 132 und der entfernten Client-Einrichtung 110 auszutauschen. Wie hierin verwendet bezieht sich der Begriff ”standardisiertes Transferprotokoll” oder ”standardisiertes Internet-Protokoll” auf ein Datenaus tauschprotokoll, das eine HTTP-Schicht über einer TCP-Schicht über einer IP-Schicht (in der Reihenfolge HTTP-über-TCP-über-IP) als Teil eines Protokollstapels zum Austauschen von Daten zwischen einem Client und einem Server realisiert, wie es nun nachstehend in Bezug auf 2 beschrieben wird.
2 ist ein Stapel 200 eines standardisierten Protokolls, der zum Austauschen von Daten zwischen der Client-Einrichtung 110 und dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gemäß einem herkömmlichen Ansatz verwendet wird. Wie hierin verwendet, bezieht sich ein Protokollstapel (manchmal auch als Kommunikationsstapel bezeichnet) auf eine bestimmte Software-Realisierung eines Computer-Netz-Protokollpakets. Das Protokollpaket definiert die Protokolle, und der Protokollstapel ist die Software-Realisierung jener Protokolle.
Wie in 2 gezeigt umfasst der Protokollstapel 200 Anwendungsschichten 205, 210, 215, die eine Browser-Anwendung 205 (z. B. Internet Explorer), eine Darstellungsschicht 210, wie beispielsweise HTML, und eine Sitzungsschicht 215 umfassen, in der das Hyper Text Transfer Protocol (HTTP) realisiert ist. Wie hierin verwendet, bezieht sich der Begriff ”Hyper Text Transfer Protocol (HTTP)” auf ein Anforderung/Antwort-Protokoll zwischen Clients und Servern, das verwendet wird, um Informationen im Internet zu transferieren oder zu übermitteln. RFC 2616 (1999) definiert HTTP/1.1, die heute übliche Version des HTTP. Der Begriff ”Server” bezieht sich auf einen Computer, der verantwortlich ist, um HTTP-Anforderungen von Clients anzunehmen, die als ”Webbrowser” bekannt sind, und ihnen HTTP-Antworten zusammen mit optionalen Dateninhalten zu liefern, die für gewöhnlich Webseiten wie beispielsweise HTML-Dokumente und verlinkte Objekte (Bilder etc.) oder andere Dateien sind. Ein Server umfasst typischerweise Hardware, ein Betriebssystem, eine HTTP-Server- Software (IIS, Apache, etc.), die Anforderungen von dem Browser verwaltet und in Ansprechen darauf Webseiten (HTML-Dokumente und Dateien) liefert.
Der Protokollstapel 200 umfasst auch eine Transportschicht 220, in der das Transmission Control Protocol (TCP) realisiert ist, und eine Internet Protocol-Schicht (IP-Schicht) 230. Das Transmission Control Protocol (TCP)/Internet Protocol(IP)-Protokollpaket ist der Satz von Kommunikationsprotokollen, die den Protokollstapel realisieren, mit dem das Internet und die meisten handelsüblichen Netze laufen. Die Transportschicht 220 antwortet auf Dienstanforderungen von der Anwendungsschicht und gibt Dienstanforderungen an die IP- oder ”Internet”-Schicht 230 aus. Das TCP stellt einen zuverlässigen und effektiven Datentransfer sicher, indem die Information in Stücke aufgeteilt wird und jedem Stück Zieladressen hinzugefügt werden, während das IP die Adresse in jedem Stück verwendet, um das Stück zu einem bestimmten Ziel weiterzuleiten. In dem TCP/IP-Modell ist die Transportschicht für das Übermitteln von Daten zu dem entsprechenden Anwendungsprozess an den Host-Computern verantwortlich. Die Transportschicht steuert die Zuverlässigkeit eines gegebenen Links über eine Flusssteuerung, eine Segmentierung/Desegmentierung und eine Fehlersteuerung. Dies umfasst das statistische Multiplexen von Daten von verschiedenen Anwendungsprozessen, d. h. das Bilden von Datenpaketen, und das Hinzufügen von Quellen- und Zielportnummern in dem Header jedes Transportschicht-Datenpakets. Zusammen mit der Quellen- und Ziel-IP-Adresse bilden die Portnummern einen Netzsockel (z. B. eine Identifikationsadresse der Prozess-Prozess-Kommunikation). Das TCP stellt eine durchgehend zuverlässige Kommunikation bereit (z. B. eine Fehlerbehebung mittels eines Fehlerdetektions-Codes und eines Protokolls einer automatischen Wiederholungsanfrage (ARQ)). Das ARQ-Protokoll stellt auch eine Flusssteuerung bereit, die mit einer Überlas tungsvermeidung kombiniert werden kann. Das TCP wird beispielsweise beim HTTP-Webbrowsen und Email-Transfer verwendet.
Der Protokollstapel 200 umfasst auch eine Verbindungssicherungsschicht 240 und eine physikalische Schicht 250.
Somit wird bei dem Stapel 200 eines standardisierten Protokolls von 2 das HTTP 215 auf dem TCP/IP 220, 230 realisiert. Die Funktion des herkömmlichen HTTP/TCP/IP-Protokollstapels 200 ist Fachleuten weithin bekannt und wird hierin nicht ausführlicher beschrieben.
3 ist ein vereinfachtes Nachrichtenflussdiagramm 300 zum Übermitteln von Daten an die entfernte Client-Einrichtung 110 von einem Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gemäß einem herkömmlichen Ansatz. In Schritt 310 sendet eine Browser-Anwendung 112 (oder ein anderes Benutzerwerkzeug) an der Ursprungs-HTTP-Client-Einrichtung 110 zum Initiieren einer Sitzung eine TCP-Verbindungsanforderung an das fahrzeuginterne Kommunikations-Gateway-Modul 130, und in Schritt 320 stellt die Client-Einrichtung 110 eine TCP-Verbindung mit einem Standard-Port (z. B. Port 80) des fahrzeuginternen Kommunikations-Gateway-Moduls 130 her. Techniken zum Herstellen einer TCP-Verbindung sind in der Technik weithin bekannt und werden hierin nicht weiter beschrieben.
In Schritt 330 liefert das Computer-Modul 142 die angeforderten Daten an den HTTP-Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130, und in Schritt 340 liefert der HTTP-Server 132 die Daten (über den Standard-Port 80 des HTTP-Servers 132) gemäß standardisierten Internet-Protokollen (z. B. HTTP-über-TCP-über-IP) an die entfernte HTTP-Client-Einrichtung 110. Zu Erläuterungszwecken sind die Datenaustauschvorgänge zwischen 142 und 130 und zwischen 110 und 130 jeweils unter Verwendung eines Pfeils dargestellt; es sei jedoch angemerkt, dass in Wirklichkeit jeder der Datenaustauschvorgänge mindestens eine Anforderung und mehrere Antworten und Bestätigungen zwischen jedem Paar von Entitäten umfassen kann. Eine Antwort auf eine einzelne Anforderung kann manchmal auch mehrere Austauschvorgänge zwischen den Entitäten umfassen. Beispielsweise kann das fahrzeuginterne Kommunikations-Gateway-Modul 130, auch wenn in 3 nicht gezeigt, mehrere Datenanforderungen an das Computer-Modul 142 übermitteln, und kann das Computer-Modul 142 dem fahrzeuginternen Kommunikations-Gateway-Modul 130 (über ein fahrzeuginternes Netz) mit den angeforderten Daten antworten.
Bei einem vereinfachten Beispiel des Datenaustauschs 340 sendet der HTTP-Server 132, wenn der HTTP-Server 132 eine Anforderungsnachricht von dem HTTP-Client 110 empfängt, eine Statuszeile, wie beispielsweise ”HTTP/1.1 200 OK”, und eine Nachricht von sich selbst zurück, deren Körper möglicherweise die angeforderte Datei oder eine andere Information umfasst. Zur Vereinfachung der Erläuterung sind diese Austauschvorgänge unter Verwendung eines einzelnen Pfeils gezeigt. Ferner sei angemerkt, dass der Datenaustausch zwischen der Browser-Anwendung 112 der HTTP-Client-Einrichtung 110 und dem HTTP-Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 in vielen Fällen typischerweise eine oder mehrere HTTP-Anforderungsnachrichten (manchmal als HTTP_GET-Nachrichten bezeichnet) von dem HTTP-Client 110 an den HTTP-Server 132 und mehrere HTTP-Antwortnachrichten von dem HTTP-Server 132 an den Browser 112 (manchmal als HTTP_200_OK und HTTP_Continue-Nachrichten bezeichnet, mit Segmenten der angeforderten Daten) und andere Nachrichten, wie beispielsweise Bestätigungen (ACKs) von dem HTTP-Client 110 an den HTTP-Server 132 in Ansprechen auf die HTTP_Continue-Nachrichten, umfasst. Somit werden Fachleute, obwohl der Datenaustausch 340 als Doppelpfeil dargestellt ist, erkennen, dass der Datenaustausch zwischen der Browser-Anwendung 112 der HTTP-Client-Einrichtung 110 und dem HTTP-Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 wahrscheinlich mehrere Austauschvorgänge umfasst.
Sobald der Datenaustausch zwischen der Browser-Anwendung 112 der HTTP-Client-Einrichtung 110 und dem HTTP-Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 abgeschlossen ist, wird die TCP-Verbindung zwischen der entfernten HTTP-Client-Einrichtung 110 und dem fahrzeuginternen Kommunikations-Gateway-Modul 130 in Schritt 350 beendet.
Überblick über beispielhafte Ausführungsformen
Ungeachtet dieser Techniken wäre es erwünscht, alternative Systeme und Verfahren bereitzustellen, die die Verwendung von ”standardisierten Transferprotokollen” oder ”standardisierten Internet-Protokollen” (d. h. eines HTTP-über-TCP-über-IP-Protokollstapels) zum Austauschen von Daten zwischen einem Client und einem Server nicht erfordern.
Gemäß hierin offenbarten Ausführungsformen werden Techniken bereitgestellt, die einer entfernten Einrichtung und einem fahrzeuginternen Kommunikations-Gateway-Modul ermöglichen können, Daten auszutauschen, ohne HTTP-über-TCP-über-IP als das Transferprotokoll zum Austauschen von Daten zwischen jenen Entitäten zu verwenden. Dies ermöglicht die Verwendung von bestimmten, nicht standardisierten Transferprotokollen und Nicht-Standard-Ports während eines Datenaustauschs in einem Telematiknetz.
4 ist ein vereinfachtes Nachrichtenflussdiagramm 400 zum Austauschen von Daten zwischen der Client-Einrichtung 110 und dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gemäß einigen Ausführungsformen der Erfindung, wenn die Client-Einrichtung 110 Daten von einem fahrzeuginternen Computer-Modul 142 anfordert. Das Szenario in 4 wird in Bezug auf ein Szenario beschrieben, bei dem die Client-Einrichtung 110 Daten von dem Computer-Modul 142 in dem Fahrzeug 125 anfordert; es sei jedoch angemerkt, dass der Datenaustausch von 4 nicht auf dieses spezifische Szenario beschränkt ist.
In Schritt 410 sendet die Client-Einrichtung 110 eine TCP-Verbindungsanforderung an das fahrzeuginterne Kommunikations-Gateway-Modul 130, und in Schritt 420 stellen die Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 eine TCP-Verbindung her. Beispielsweise empfängt das fahrzeuginterne Kommunikations-Gateway-Modul 130 bei einer Realisierung eine Anforderung bezüglich eines HTTP-Diensts von der Client-Einrichtung 110 an einem Standard-Port (z. B. HTTP-Port 80) des fahrzeuginternen Kommunikations-Gateway-Moduls 130. Techniken zum Herstellen einer TCP-Verbindung sind in der Technik weithin bekannt und werden hierin nicht weiter beschrieben.
In Schritt 430 sendet die Browser-Anwendung 112 der Client-Einrichtung 110 eine HTTP-Anforderungsnachricht bezüglich einer Software-Komponente an den Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130. Wie es nachstehend beschrieben wird, umfasst die Software-Komponente oder das ”Modul” einen Modulstapel eines bestimmten, nicht standardisierten Transferprotokolls zur Verwendung bei nachfolgenden Datenübermittlungen zwischen der Browser-Anwendung 112 der Client-Einrichtung 110 und dem Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130.
In Schritt 440 sendet das fahrzeuginterne Kommunikations-Gateway-Modul 130 eine HTTP-Antwortnachricht an die Client-Einrichtung 110, die eine Software-Komponente umfasst. Die Software-Komponente umfasst Algorithmen in Form eines ausführbaren Programms, die einen Stapel eines bestimmten, nicht standardisierten Transferprotokolls umfassen. Die ”Software-Komponente” kann beispielsweise unter Verwendung eines von einem Browser herunterladbaren ausführbaren Programms, wie beispielsweise eines Java-Applet, eines Active-X-Steuerelements oder eines kompilierten Programms (falls zuerst heruntergeladen und nachfolgend ausgeführt), realisiert werden.
Somit wird die Server-Anwendung 132 in dem fahrzeuginternen Kommunikations-Gateway-Modul 130 während dieser Sitzungsinitiierungsphase als standardisierte Webschnittstelle verwendet. Wenn beispielsweise ein entfernter Benutzer eine Sitzung initiiert, indem er eine URL, die dem Fahrzeug 125 entspricht, in die Browser-Anwendung 112 eingibt, die an der entfernten Client-Einrichtung 110 läuft (z. B. tippt der Benutzer http://10.11.12.13 in eine Browser-Anwendung 112 ein, wobei die imaginäre 10.11.12.13 das Fahrzeug 125 darstellt), antwortet der Server 132 an dem Fahrzeug 125 mit einer ”Webseite”, die mit dem Herunterladen der Software-Komponente von dem Fahrzeug 125 auf die entfernte Client-Einrichtung 110 beginnt.
Wenn das fahrzeuginterne Kommunikations-Gateway-Modul 130 die Software-Komponente an die entfernte Client-Einrichtung 110 sendet, schließen das fahrzeuginterne Kommunikations-Gateway-Modul 130 und die Client-Einrichtung 110 in Schritt 450 ihre Standard-HTTP-Ports, um die HTTP-Sitzung zu beenden und ihre TCP-Verbindung freizugeben. Auf diese Weise werden keine ”standardisierten” Internet-Protokolle (der herkömmliche HTTP/TCP/IP-Protokollstapel von 2) für den nachfolgenden Informationsaustausch zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Client-Einrichtung 110 verwendet.
In Schritt 451 lädt die Client-Einrichtung 110 die Software-Komponente, die das Modul eines bestimmten, nicht standardisierten Transferprotokolls umfasst, und führt diese aus. Nach der Ausführung durch die entfernte Client-Einrichtung 110 ermöglicht der Stapel eines bestimmten, nicht standardisierten Protokolls der entfernten Client-Einrichtung 110, unter Verwendung des bestimmten, nicht standardisierten Transferprotokolls mit dem fahrzeuginternen Kommunikations-Gateway-Modul 130 zu kommunizieren. Auf diese Weise weiß die entfernte Client-Einrichtung 110, wenn die Browser-Anwendung 112 das ausführbare Programm lädt und ausführt und es an der entfernten Client-Einrichtung 110 laufen lässt, wie gemäß den Regeln des bestimmten, nicht standardisierten Transferprotokolls mit dem fahrzeuginternen Kommunikations-Gateway-Modul 130 kommuniziert werden soll. Wie es nachstehend beschrieben wird, kann der Stapel eines bestimmten, nicht standardisierten Transferprotokolls, der in der Software-Komponente oder dem Modul umfasst ist, in Abhängigkeit von der bestimmten Realisierung stark variieren. Ungeachtet der bestimmten Realisierung wird, wenn ein ”nicht standardisiertes” Transferprotokoll zum Austauschen von Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Einrichtung 110 verwendet wird, der herkömmliche HTTP/TCP/IP-Protokollstapel von 2 nicht von dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Einrichtung 110 verwendet, um während nachfolgender Übermittlungen Daten auszutauschen.
Wenn die Client-Einrichtung 110 den Stapel eines bestimmten, nicht standardisierten Transferprotokolls von der Software-Komponente geladen hat, ist die Client-Einrichtung 110 bereit, gemäß dem bestimmten, nicht standardisierten Transferprotokoll Daten an das fahrzeuginterne Kommunikations-Gateway-Modul 130 zu übermitteln und mit diesem auszutauschen. In Schritt 452 stellen die Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 gemäß dem bestimmten, nicht standardisierten Transferprotokoll eine neue Verbindung her.
In Schritt 456 übermittelt das fahrzeuginterne Kommunikations-Gateway-Modul 130 eine Datenanforderung an das Computer-Modul 142, und das Computer-Modul 142 sendet die angeforderten Daten über ein fahrzeuginternes Netz an das fahrzeuginterne Kommunikations-Gateway-Modul 130. Es sei angemerkt, dass jedes Protokoll zum Austauschen von Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und dem Computer-Modul 142 verwendet werden kann (d. h. es ist nicht notwendig, dem bestimmten, nicht standardisierten Transferprotokoll zu folgen).
In Schritt 460 tauscht der Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 die Daten, die er von dem Computer-Modul 142 empfangen hat, gemäß dem bestimmten, nicht standardisierten Transferprotokoll mit der Browser-Anwendung 112 aus, die an der Client-Einrichtung 110 läuft. Sobald der Datenaustausch abgeschlossen ist (d. h. nachdem die Browser-Anwendung 112, die an der Client-Einrichtung 110 läuft, die Daten empfängt, die sie von dem Computer-Modul 142 angefordert hat), schließen die Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 in Schritt 480 die neue Verbindung.
Nicht standardisiertes Transferprotokoll
Wie oben erwähnt wird die Software-Komponente verwendet, um der Client-Einrichtung 110 den Modulstapel eines bestimmten, nicht standardisierten Transferprotokolls zur Verwendung während nachfolgender Übermittlungen zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Client-Einrichtung 110 bereitzustellen. Der Modulstapel eines bestimmten, nicht standardisierten Transferprotokolls ermöglicht der Client-Einrichtung 110, gemäß dem bestimmten, nicht standardisierten Transfer mit dem fahrzeuginternen Kommunikations-Gateway-Modul 130 zu kommunizieren und umgekehrt.
Wie hierin verwendet bezieht sich der Begriff ”nicht standardisiertes Transferprotokoll” allgemein auf ein anderes Datenaustauschprotokoll als ein standardisiertes Transferprotokoll zum Austauschen von Daten zwischen einem Client und einem Server. Ein Stapel eines nicht standardisierten Transferprotokolls kann allgemein ein(e) oder mehrere Schichten/Protokolle umfassen, die in dem Stapel eines standardisierten Protokolls, der in 2 gezeigt ist, nicht umfasst sind, und diese(s) neue Schicht/Protokoll kann ”anstatt” einer/s oder mehrerer Schichten/Protokolle des Stapels eines standardisierten Protokolls, der in 2 gezeigt ist, und/oder ”zusätzlich zu” einer/m oder mehreren Schichten/Protokollen des Stapels eines standardisierten Protokolls, der in 2 gezeigt ist, realisiert werden, so dass der Stapel eines nicht standardisierten Transferprotokolls HTTP-über-TCP-über-IP nicht als Teil des Transferprotokolls, das zum Austauschen von Daten zwischen einem Client und einem Server verwendet wird, realisiert. Beispielsweise kann der Protokollstapel 200 von 2 bei einer Realisierung eines Stapels eines ”nicht standardisierten” Transferprotokolls derart modifiziert werden, dass er ein(e) oder mehrere neue Schichten oder Protokolle umfasst, die sich von dem herkömmlichen HTTP/TCP/IP-Protokollstapel von 2 unterscheiden und/oder nicht in dem herkömmlichen HTTP/TCP/IP-Protokollstapel 200 von 2 umfasst sind.
Bei einer nicht einschränkenden Realisierung eines Stapels eines nicht standardisierten Transferprotokolls können ein(e) oder mehrere Schichten oder Protokolle zwischen HTTP und TCP oder zwischen TCP und IP etc. realisiert sein, um ein Nicht-HTTP/TCP/IP-Datenaustauschprotokoll zu realisieren.
Bei einer anderen nicht einschränkenden Realisierung kann die HTTP-Schicht, die bei einem standardisierten Transferprotokoll von 2 verwendet wird, durch ein anwendungsspezifisches oder proprietäres Protokoll ersetzt werden, das eine verbindungsorientierte Anforderung/Antwort-Nachrichtenübermittlung mit einer Fehlerdetektion und einem Mechanismus einer automatischen Wiederholungsanfrage (ARQ) unterstützt, um eine durchgehend zuverlässige Kommunikation bereitzustellen (z. B. Fehlerbehebung mittels Fehlerdetektions-Codes und Protokoll einer automatischen Wiederholungsanfrage (ARQ)).
Eine beispielhafte Realisierung des Modulstapels eines bestimmten, nicht standardisierten Transferprotokolls wird nun nachstehend in Bezug auf 5 beschrieben.
Beispielhafter Stapel eines nicht standardisierten Transferprotokolls
5 ist ein beispielhafter Stapel 500 eines nicht standardisierten Transferprotokolls, der zum Austauschen von Daten zwischen der Client-Einrichtung 110 und dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gemäß einigen Ausführungsformen der Erfindung verwendet wird. Der beispielhafte Kommunikationsprotokollstapel 500 umfasst Anwendungsschichten 505, 510, 515, die eine Browser-Anwendung (z. B. Internet Explorer), eine Darstellungsschicht 510 (z. B. HTML) und eine Nicht-HTTP-Anforderung/Antwort-Protokollschicht 515 umfassen; ein Transportschichtprotokoll 520 (wie beispielsweise TCP, UDP, etc.); eine Internet-Schicht 540, die das Internet Protocol (IP) realisiert; eine Verbindungssicherungsschicht 550, die eine Medium Access Control-(MAC-) und eine Link Layer Control-(LLC-)Subschicht (nicht gezeigt) umfassen kann, und die ein beliebiges Verbindungssicherungsschichtprotokoll realisieren kann, das ein Ethernet-Verbindungssicherungsschichtprotokoll, ein IEEE 802.11-Verbindungssicherungsschichtprotokoll, ein Zellular-Verbindungssicherungsschichtprotokoll, ein Satelliten-Verbindungssicherungsschichtprotokoll oder jedes andere Drahtlos-Verbindungssicherungsschichtprotokoll umfasst; und eine physikalische Schicht 560, die jeden Standard einer physikalischen Schicht realisieren kann, umfassend eine physikalische Schicht eines Zellularnetzes (z. B. UMTS, WCDMA, CDMA, AMPS), eine physikalische Schicht für Satellit, Ethernet, IEEE 802.11, IEEE 802.16 (auch als WiMAX bekannt) etc.
6 ist ein vereinfachtes Nachrichtenflussdiagramm 600 zum Austauschen von Daten zwischen der entfernten Client-Einrichtung 110 und dem fahrzeuginternen Kommunikations-Gateway-Modul 130, wenn ein fahrzeuginternes Computer-Modul 142 Daten an die entfernte Client-Einrichtung 110 weiterleitet, gemäß anderen Ausführungsformen der Erfindung. Das Szenario in 6 wird in Bezug auf ein Szenario beschrieben, bei dem das Computer-Modul 142 in dem Fahrzeug 125 Daten an die entfernte Client-Einrichtung 110 überträgt oder ”weiterleitet”; es sei jedoch angemerkt, dass der Datenaustausch von 6 nicht auf dieses spezifische Szenario beschränkt ist. Wie oben erwähnt, kann das fahrzeuginterne Kommunikations-Gateway-Modul 130 als Teil eines Telematikmoduls realisiert sein, das entworfen ist, um Übermittlungen zwischen dem Computer-Modul 142 in dem Fahrzeug 125 und den Client-Einrichtungen 110 zu verwalten. Das fahrzeuginterne Kommunikations-Gateway-Modul 130 kommuniziert mit dem Computer-Modul 142 unter Verwendung eines fahrzeuginternen Netzes. Das fahrzeuginterne Kommunikations-Gateway-Modul 130 hostet eine Server-Anwendung 132, und die entfernte Client-Einrichtung 110 hostet eine Browser-Anwendung 112.
In Schritt 605 überträgt das Computer-Modul 142 Daten, die für die entfernte Client-Einrichtung 110 bestimmt sind, über ein fahrzeuginternes Netz an das fahrzeuginterne Kommunikations-Gateway-Modul 130 oder ”leitet diese weiter”. Mit anderen Worten sendet das Computer-Modul 142 Daten, die für die entfernte Client-Einrichtung 110 bestimmt sind, ohne aufgefordert worden zu sein, diese Daten zu senden. Es sei angemerkt, dass in Schritt 605 jedes Protokoll verwendet werden kann, um Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und dem Computer-Modul 142 auszutauschen (d. h. es ist nicht notwendig, dem bestimmten, nicht standardisierten Transferprotokoll zu folgen).
Während der Initiierung einer Sitzung zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Client-Einrichtung 110 erzeugt die entfernte Client-Einrichtung 110 in Schritt 610 eine TCP-Verbindungsanforderung und sendet sie an einen Standard-Port des fahrzeuginternen Kommunikations-Gateway-Moduls 130. Wenn das fahrzeuginterne Kommunikations-Gateway-Modul 130 die TCP-Verbindungsanforderung empfängt, stellen die entfernte Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 in Schritt 620 eine TCP-Verbindung her.
In Schritt 630 sendet die Browser-Anwendung 134, die an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gehostet ist, eine HTTP-Anforderungsnachricht an den Server 114, der in der entfernten Client-Einrichtung 110 gehostet ist, um eine Software-Komponente von dem Server 114 anzufordern. In Ansprechen auf die HTTP-Anforderungsnachricht bezüglich der Software-Komponente sendet die entfernte Client-Einrichtung 110 in Schritt 652 eine HTTP-Antwort, die die Software-Komponente umfasst, an das fahrzeuginterne Kommunikations-Gateway-Modul 130.
Wenn das fahrzeuginterne Kommunikations-Gateway-Modul 130 die Software-Komponente empfängt, schließen das fahrzeuginterne Kommunikations-Gateway-Modul 130 und die entfernte Client-Einrichtung 110 in Schritt 654 ihre jeweiligen Standard-HTTP-Ports und geben ihre TCP-Verbindung frei. Wie oben erwähnt werden auf diese Weise keine ”standardisierten” Internet-Protokolle (d. h. HTTP-über-TCP-über-IP) für den nachfolgenden Informationsaustausch zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Client-Einrichtung 110 verwendet.
In Schritt 656 lädt die Browser-Anwendung 134 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 die Software-Komponente, die das Modul eines bestimmten, nicht standardisierten Transferprotokolls umfasst, und führt diese aus, und führt ein ausführbares Programm aus, um eine Übermittlung zwischen der entfernten Client-Einrichtung 110 und dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gemäß dem bestimmten, nicht standardisierten Transferprotokoll zu ermöglichen. In Schritt 657 stellen die entfernte Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 gemäß dem bestimmten, nicht standardisierten Transferprotokoll eine neue Verbindung her.
Nach dem Laden des Stapels eines bestimmten, nicht standardisierten Transferprotokolls von der Software-Komponente ist das fahrzeuginterne Kommunikations-Gateway-Modul 130 bereit, um gemäß dem bestimmten, nicht standardisierten Transferprotokoll Daten an die entfernte Client-Einrichtung 110 zu übermitteln und mit dieser auszutauschen. In Schritt 660 tauscht der Server 132 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 die Daten (die er von dem Computer-Modul 142 über das fahrzeuginterne Netz empfangen hat) gemäß dem bestimmten, nicht standardisierten Transferprotokoll mit der Browser-Anwendung 112 aus, die an der entfernten Client-Einrichtung 110 läuft. Sobald der Datenaustausch abgeschlossen ist, schließen die entfernte Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 die Verbindung in Schritt 680.
7 ist ein vereinfachtes Nachrichtenflussdiagramm 700 zum Austauschen von Daten zwischen einer entfernten Server-Einrichtung 110 und einem fahrzeuginternen Kommunikations-Gateway-Modul 130 gemäß einigen Ausführungsformen der Erfindung, wenn ein fahrzeuginternes Computer-Modul 142 Daten von der entfernten Server-Einrichtung 110 anfordert.
In Schritt 705 überträgt das Computer-Modul 142 eine Anforderung bezüglich Daten über ein fahrzeuginternes Netz an das fahrzeuginterne Kommunikations-Gateway-Modul 130. Mit anderen Worten sendet das Computer-Modul 142 eine Anforderung unilateral an das fahrzeuginterne Kommunikations-Gateway-Modul 130, um Daten von der entfernten Server-Einrichtung 110 anzufordern. Es sei angemerkt, dass in Schritt 705 jedes Protokoll verwendet werden kann, um die Anforderung von dem Computer-Modul 142 an das fahrzeuginterne Kommunikations-Gateway- Modul 130 weiterzuleiten (d. h. es ist nicht notwendig, dem bestimmten, nicht standardisierten Transferprotokoll zu folgen).
In Ansprechen auf die Anforderung bezüglich Daten initiiert eine Browser-Anwendung 134 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 eine Sitzung mit der entfernten Server-Einrichtung 110 durch Erzeugen einer TCP-Verbindungsanforderung und übertragen der TCP-Verbindungsanforderung von einem Standard-HTTP-Port des fahrzeuginternen Kommunikations-Gateway-Moduls 130 an die entfernte Server-Einrichtung 110 in Schritt 710. Die entfernte Server-Einrichtung 110 empfängt die TCP-Verbindungsanforderung an einem Standard-HTTP-Port der entfernten Server-Einrichtung 110.
In Schritt 720 stellen die entfernte Server-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 eine TCP-Verbindung her. Somit wird das fahrzeuginterne Kommunikations-Gateway-Modul 130 während der Sitzungsinitiierung als Standard-Webschnittstelle verwendet.
In Schritt 730 sendet die Browser-Anwendung 134 des fahrzeuginternen Kommunikations-Gateway-Moduls 130 eine HTTP-Anforderungsnachricht an die entfernte Server-Einrichtung 110, um die Software von der entfernten Server-Einrichtung 110 anzufordern.
In Ansprechen auf die HTTP-Anforderungsnachricht bezüglich der Software-Komponente sendet die entfernte Server-Einrichtung 110 in Schritt 752 eine HTTP-Antwortnachricht, die die Software-Komponente umfasst, an das fahrzeuginterne Kommunikations-Gateway-Modul 130. Wie oben beschrieben umfasst die Software-Komponente ein Modul eines bestimmten, nicht standardisierten Transferprotokolls.
Wenn das fahrzeuginterne Kommunikations-Gateway-Modul 130 die Software-Komponente von der entfernten Server-Einrichtung 110 empfängt, schließt das fahrzeuginterne Kommunikations-Gateway-Modul 130 in Schritt 754 seinen Standard-HTTP-Port, um die HTTP-Sitzung zu beenden und die TCP-Verbindung freizugeben. Wie oben erwähnt werden auf diese Weise keine ”standardisierten” Internet-Protokolle (der herkömmliche HTTP/TCP/IP-Protokollstapel von 2) für den nachfolgenden Informationsaustausch zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Server-Einrichtung 110 verwendet.
In Schritt 756 lädt die Browser-Anwendung 134 an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 die Software-Komponente, die das Modul eines bestimmten, nicht standardisierten Transferprotokolls umfasst, und führt diese aus, und führt ein ausführbares Programm aus, um eine Kommunikation mit der entfernten Server-Einrichtung 110 gemäß dem bestimmten, nicht standardisierten Transferprotokoll zu ermöglichen. In Schritt 757 stellen die entfernte Server-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 gemäß dem bestimmten, nicht standardisierten Transferprotokoll eine neue Verbindung her, und in Schritt 758 sendet das fahrzeuginterne Kommunikations-Gateway-Modul 130 dann eine Nachricht an die entfernte Server-Einrichtung 110, um einen Datenaustausch mit der entfernten Server-Einrichtung 110 gemäß dem bestimmten, nicht standardisierten Transferprotokoll anzufordern.
In Schritt 760 tauscht die entfernte Server-Einrichtung 110 die angeforderten Daten (ursprünglich über das fahrzeuginterne Netz durch das Computer-Modul 142 angefordert) gemäß dem bestimmten, nicht standardisierten Transferprotokoll mit der Browser-Anwendung 134 aus, die an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 läuft. In Schritt 770 liefert das fahrzeuginterne Kommunikations-Gateway-Modul 130 die angeforderten Daten, die es von der entfernten Server-Einrichtung 110 empfangen hat, an das Computer-Modul 142. Es sei angemerkt, dass dieser Austausch zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Server-Einrichtung 110 die Verwendung des nicht standardisierten Transferprotokolls nicht erfordert.
Sobald der Datenaustausch abgeschlossen ist, schließen die entfernte Server-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 in Schritt 780 die neue Verbindung.
8 ist ein vereinfachtes Nachrichtenflussdiagramm 800 zum Austauschen von Daten zwischen einem fahrzeuginternen Kommunikations-Gateway-Modul 130 und einer entfernten Client-Einrichtung 110, wenn die entfernte Client-Einrichtung 110 Daten von einem fahrzeuginternen Computer-Modul 142 anfordert, gemäß anderen Ausführungsformen der Erfindung. Das Szenario in 8 wird in Bezug auf ein Szenario beschrieben, bei dem die Client-Einrichtung 110 Daten von einem Computer-Modul 142 in dem Fahrzeug 125 anfordert; es sei jedoch angemerkt, dass der Datenaustausch von 8 nicht auf dieses spezifische Szenario beschränkt ist.
In Schritt 810 sendet die entfernte Client-Einrichtung 110 eine TCP-Verbindungsanforderung an das fahrzeuginterne Kommunikations-Gateway-Modul 130, und in Schritt 820 stellen die entfernte Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 eine TCP-Verbindung her. Beispielsweise empfängt das fahrzeuginterne Kommunikations-Gateway-Modul 130 an einem Standard-Port (z. B. HTTP-Port) des fahrzeuginternen Kommunikations-Gateway-Moduls 130 eine Anforderung bezüglich eines HTTP-Diensts von der entfernten Client-Einrichtung 110, und stellen das fahrzeuginterne Kommunikations-Gateway-Modul 130 und die entfernte Client-Einrichtung 110 dann eine TCP-Verbindung her. Techniken zum Herstellen einer TCP-Verbindung sind in der Technik weithin bekannt und werden hierin nicht weiter beschrieben.
In Schritt 830 sendet das fahrzeuginterne Kommunikations-Gateway-Modul 130 eine Anweisung an die entfernte Client-Einrichtung 110, um ihren Standard-HTTP-Port zu schließen und von einem Online-Server 105 eine Software-Komponente zu erhalten (d. h. herunterzuladen), die ein Modul eines bestimmten, nicht standardisierten Transferprotokolls umfasst. In Schritt 832 schließt das fahrzeuginterne Kommunikations-Gateway-Modul 130 seinen Standard-HTTP-Port, um seine TCP-Verbindung mit der entfernten Client-Einrichtung 110 zu beenden. Auf diese Weise werden für den nachfolgenden Informationsaustausch zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Client-Einrichtung 110 keine ”standardisierten” Internet-Protokolle verwendet.
In Ansprechen auf die Anweisung zum Herunterladen der Software-Komponente von dem Online-Server 105 sendet die entfernte Client-Einrichtung 110 in Schritt 834 eine Anforderung bezüglich der Software-Komponente an einen Online-Server 105, und in Schritt 840 sendet der Online-Server 105 die Software-Komponente an die entfernte Client-Einrichtung 110. Wie oben beschrieben umfasst die Software-Komponente das Modul eines bestimmten, nicht standardisierten Transferprotokolls.
In Schritt 851 lädt die entfernte Client-Einrichtung 110 die Software-Komponente, die das Modul eines bestimmten, nicht standardisierten Transferprotokolls umfasst, und führt diese aus. Nachdem die entfernte Client-Einrichtung 110 das Modul eines bestimmten, nicht standardisierten Transferprotokolls von der Software-Komponente geladen und ausgeführt hat, ist die entfernte Client-Einrichtung 110 bereit, um gemäß dem bestimmten, nicht standardisierten Transferprotokoll Daten an das fahrzeuginterne Kommunikations-Gateway-Modul 130 zu übermitteln und mit diesem auszutauschen. An dieser Stelle wird das nicht standardisierte Transferprotokoll während nachfolgender Übermittlungen zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und der entfernten Client-Einrichtung 110 verwendet.
In Schritt 852 stellen die entfernte Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 gemäß dem bestimmten, nicht standardisierten Transferprotokoll eine neue Verbindung her.
Das fahrzeuginterne Kommunikations-Gateway-Modul 130 übermittelt die Datenanforderung an das Computer-Modul 142, und in Schritt 858 tauschen das Computer-Modul 142 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 die Daten über ein fahrzeuginternes Netz aus. Es sei angemerkt, dass in Schritt 858 jedes Protokoll verwendet werden kann, um Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul 130 und dem Computer-Modul 142 auszutauschen (d. h. es ist nicht notwendig, dem Modulstapel eines bestimmten, nicht standardisierten Transferprotokolls zu folgen).
In Schritt 860 sendet der Server 132, der an dem fahrzeuginternen Kommunikations-Gateway-Modul 130 gehostet ist, die Daten, die er von dem Computer-Modul 142 empfangen hat, gemäß dem bestimmten, nicht standardisierten Transferprotokoll an die Browser-Anwendung 112, die an der entfernten Client-Einrichtung 110 läuft. Sobald der Datenaustausch abgeschlossen ist, schließen die entfernte Client-Einrichtung 110 und das fahrzeuginterne Kommunikations-Gateway-Modul 130 in Schritt 880 die Verbindung.
Somit wurden zahlreiche Ausführungsformen beschrieben, die einer entfernten Einrichtung und einem fahrzeuginternen Kommunikations-Gateway-Modul ermöglichen können, Daten auszutauschen, ohne HTTP-über-TCP-über-IP als Protokoll zum Austauschen von Daten zwischen diesen Entitäten zu verwenden. Dies ermöglicht die Verwendung von bestimmten, nicht standardisierten Transferprotokollen und Nicht-Standard-Ports während eines Datenaustauschs in einem Telematiknetz.

Claims

Verfahren zum Übertragen von Daten von einer Client-Einrichtung an ein Computer-Modul in einem Fahrzeug, wobei das Verfahren umfasst, dass eine Anforderung bezüglich einer Software-Komponente von der Client-Einrichtung über einen Standard-Port an dem fahrzeuginternen Kommunikations-Gateway-Modul empfangen wird, wobei die Software-Komponente ein Modul eines nicht standardisierten Transferprotokolls umfasst; das Modul eines nicht standardisierten Transferprotokolls an der Client-Einrichtung geladen wird; und Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll ausgetauscht werden.
Verfahren nach Anspruch 1, das ferner umfasst, dass die Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und dem Computer-Modul ausgetauscht werden.
Verfahren nach Anspruch 2, das ferner umfasst, dass die Software-Komponente in Ansprechen auf die Anforderung von einem Server, der an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, an eine Browser-Anwendung, die an der Client-Einrichtung gehostet ist, gesendet wird.
Verfahren nach Anspruch 3, das ferner umfasst, dass eine Verbindung zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll hergestellt wird.
Verfahren nach Anspruch 4, das ferner umfasst, dass der Standard-Port des fahrzeuginternen Kommunikations-Gateway-Moduls und ein Standard-Port der Client-Einrichtung geschlossen werden.
Verfahren nach Anspruch 5, wobei der Schritt des Schließens des Standard-Ports des fahrzeuginternen Kommunikations-Gateway-Moduls und eines Standard-Ports der Client-Einrichtung umfasst, dass der Standard-Port an dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung geschlossen werden, sodass keine standardisierten Internet-Protokolle für den nachfolgenden Informationsaustausch zwischen der Server-Anwendung, die an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, und der Browser-Anwendung, die an der entfernten Client-Einrichtung gehostet ist, verwendet werden.
Verfahren nach Anspruch 1, das ferner umfasst, dass in Ansprechen auf die Anforderung eine Herunterladeanforderung von einem Server, der an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, an eine Browser-Anwendung, die an der Client-Einrichtung gehostet ist, gesendet wird, wobei die Herunterladeanforderung anfordert, dass die Client-Einrichtung eine Software-Komponente von einem Online-Server herunterlädt; von der Client-Einrichtung in Ansprechen auf die Herunterladeanforderung eine Software-Komponenten-Anforderungsnachricht bezüglich der Software-Komponente an den Online-Server gesendet wird; und die Software-Komponente in Ansprechen auf die Software-Komponenten-Anforderungsnachricht von dem Online-Server an eine Browser-Anwendung, die an der Client-Einrichtung gehostet ist, gesendet wird.
Verfahren nach Anspruch 1, wobei die Software-Komponente verwendet wird, um das nicht standardisierte Transferprotokoll für Übermittlungen zwischen dem Server, der an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, und der Browser-Anwendung, die an der entfernten Client-Einrichtung gehostet ist, herzustellen, und wobei die Software-Komponente umfasst: ein ausführbares Programm, das das Modul eines nicht standardisierten Transferprotokolls umfasst, das der Browser-Anwendung, die an der entfernten Client-Einrichtung gehostet ist, ermöglicht, mit dem Server, der an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, gemäß dem nicht standardisierten Transferprotokoll zu kommunizieren.
Verfahren nach Anspruch 8, wobei die Browser-Anwendung entworfen ist, um das ausführbare Programm auszuführen, um eine Übermittlung zwischen der entfernten Client-Einrichtung und dem fahrzeuginternen Kommunikations-Gateway-Modul gemäß dem nicht standardisierten Transferprotokoll zu ermöglichen.
Verfahren nach Anspruch 8, wobei die Software-Komponente ein kompiliertes Programm und/oder ein Java-Applet und/oder ein Active-X-Steuerelement umfasst.
Fahrzeuginternes Kommunikations-Gateway-Modul, umfassend: einen Server, der entworfen ist, um eine Anforderung von einer Browser-Anwendung, die an einer Client-Einrichtung an einem Standard-Port gehostet ist, zu empfangen, und in Ansprechen auf die Anforderung eine Software-Komponente über den Standard-Port an eine Client-Einrichtung zu übertragen, wobei die Software-Komponente ein Modul eines nicht standardisierten Transferprotokolls umfasst; und ein Kommunikationsmodul, das entworfen ist, um Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll auszutauschen.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 11, wobei das Kommunikationsmodul ferner entworfen ist, um die von der Client-Einrichtung empfangenen Daten mit einem Computer-Modul in dem Fahrzeug auszutauschen.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 12, wobei das fahrzeuginterne Kommunikations-Gateway-Modul entworfen ist, um den Standard-Port nach dem Übertragen der Software-Komponente zu schließen, sodass für einen nachfolgenden Informationsaustausch zwischen der Server-Anwendung, die an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, und der Browser-Anwendung, die an der entfernten Client-Einrichtung gehostet ist, keine standardisierten Internet-Protokolle verwendet werden.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 13, wobei das fahrzeuginterne Kommunikations-Gateway-Modul entworfen ist, um eine Verbindung zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll herzustellen, bevor das fahrzeuginterne Kommunikations-Gateway-Modul Daten mit der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll austauscht.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 14, wobei das fahrzeuginterne Kommunikations-Gateway-Modul entworfen ist, um die Verbindung zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll zu schließen, nachdem das fahrzeuginterne Kommunikations-Gateway-Modul Daten mit der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll ausgetauscht hat.
Fahrzeuginternes Kommunikations-Gateway-Modul, umfassend: einen Server, der entworfen ist, um an einem Standard-Port eine Anforderung von einer Browser-Anwendung, die an einer Client-Einrichtung gehostet ist, zu empfangen, und um in Ansprechen auf die Anforderung eine Herunterladeanforderung über den Standard- Port zu übertragen, die anfordert, dass eine Software-Komponente von einem Online-Server an die Client-Einrichtung gesendet wird, wobei die Software-Komponente ein Modul eines nicht standardisierten Transferprotokolls umfasst; und ein Kommunikationsmodul, das entworfen ist, um Daten zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll auszutauschen.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 16, wobei das Kommunikationsmodul ferner entworfen ist, um die von der Client-Einrichtung empfangenen Daten mit einem Computer-Modul in dem Fahrzeug auszutauschen.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 17, wobei das fahrzeuginterne Kommunikations-Gateway-Modul entworfen ist, um den Standard-Port nach dem Übertragen der Herunterladeanforderung zu schließen, sodass für einen nachfolgenden Informationsaustausch zwischen der Server-Anwendung, die an dem fahrzeuginternen Kommunikations-Gateway-Modul gehostet ist, und der Browser-Anwendung, die an der entfernten Client-Einrichtung gehostet ist, keine standardisierten Internet-Protokolle verwendet werden.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 18, wobei das fahrzeuginterne Kommunikations-Gateway-Modul entworfen ist, um eine Verbindung zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll herzustellen, bevor das fahrzeuginterne Kommunikations-Gateway-Modul Daten mit der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll austauscht, und wobei das fahrzeuginterne Kommunikations-Gateway-Modul entworfen ist, um die Verbindung zwischen dem fahrzeuginternen Kommunikations-Gateway-Modul und der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll zu schließen, nachdem das fahrzeuginterne Kommunikations-Gateway-Modul Daten mit der Client-Einrichtung gemäß dem nicht standardisierten Transferprotokoll ausgetauscht hat.
Fahrzeuginternes Kommunikations-Gateway-Modul nach Anspruch 16, wobei der Server entworfen ist, um in Ansprechen auf die Anforderung eine Herunterladeanforderung über den Standard-Port an die Browser-Anwendung, die an der Client-Einrichtung gehostet ist, zu übertragen, wobei die Herunterladeanforderung anfordert, dass die Client-Einrichtung die Software-Komponente von dem Online-Server durch Senden einer Software-Komponenten-Anforderungsnachricht an den Online-Server erhält, die anfordert, dass der Online-Server die Software-Komponente an die Browser-Anwendung, die an der Client-Einrichtung gehostet ist, überträgt, wobei der Server entworfen ist, um die Herunterladeanforderung an den Online-Server zu übertragen, und wobei die Herunterladeanforderung anfordert, dass der Online-Server die Software-Komponente an die Client-Einrichtung sendet.