DE102011075066A1

DE102011075066A1 - Verfahren und Systeme zum Herstellen einer Schnittstelle mit einem Fahrzeugdatenverarbeitungssystem über mehrere Datentransportkanäle

Info

Publication number: DE102011075066A1
Application number: DE201110075066
Authority: DE
Inventors: Michael Raymond Westra
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2010-05-27
Filing date: 2011-05-02
Publication date: 2011-12-01
Also published as: CN102347971A; US9094436B2; US20110296037A1

Abstract

Bei einer oder mehreren Ausführungsformen können zwei oder mehr Einrichtungen über mehrere Kommunikationskanäle eine Schnittstelle mit einem Datenverarbeitungssystem herstellen. Eine Verbindung kann zwischen einem Datenverarbeitungssystem und zwei oder mehr Einrichtungen, die Daten unter Verwendung verschiedener Kommunikationsprotokolle übermitteln, hergestellt werden. Das Kommunikationsprotokoll der zwei oder mehr Einrichtungen kann bestimmt werden und ein allgemeines Transportprotokoll zum Übermitteln von Daten mit den zwei oder mehr Einrichtungen auf Basis der jeweiligen Kommunikationsprotokolle kann dem Kommunikationsprotokoll der zwei oder mehr Einrichtungen auferlegt werden. Daten können auf Basis des allgemeinen Transportprotokolls mit den zwei oder mehr Einrichtungen übermittelt werden. In dem Fahrzeugdatenverarbeitungssystem oder den zwei oder mehr Einrichtungen kann auf Basis der Daten ein Ereignis durchgeführt werden.

Description

Eine oder mehrere Ausführungsformen betreffen eine Schnittstelle zum Übermitteln von Daten zwischen einer Anzahl von Einrichtungen und einem Fahrzeugdatenverarbeitungssystem. Die Anzahl von Einrichtungen kann Daten über verschiedene Kommunikationsprotokolle übermitteln. Bei bestimmten Ausführungsformen kann es sich bei der Anzahl von Einrichtungen um verdrahtete oder drahtlose Einrichtungen handeln.
Es gibt in der Technik verschiedene Beispiele für Werkzeuge zum Ermöglichen der Kommunikation zwischen mehreren Endgeräten über ein Kommunikationsnetzwerk.
Das US-Patent Nr. 7,602,782 für Doviak et al. offenbart eine Vorrichtung und ein Verfahren zum intelligenten Routen von Daten zwischen einer entfernten Einrichtung und einem Hostsystem. Genauer gesagt gewährleisten Doviak et al. transparente Kommunikation zwischen einer entfernten oder mobilen Einrichtung und einem festen Kommunikations-Hostnetzwerk. Eine entfernte Netzwerksteuerung, die logisch zwischen dem Hostnetzwerk und der existierenden Infrastruktur bzw. den existierenden Infrastrukturen residiert, werden verwendet, um Kommunikationsnetzwerkkontakt mit einer oder mehreren entfernten Einrichtungen bereitzustellen. Die entfernte Netzwerksteuerung ist als eine protokollgemäße Kommunikationssteuerung mit dem Hostkommunikationsnetzwerk verbunden, so dass entfernte Einrichtungen dem Hostnetzwerk von den lokal angeschlossenen Einrichtungen ununterscheidbar sind. Jede entfernte Einrichtung kann mit einer asynchronen seriellen Datenschnittstelle ausgestattet sein, um mit einer Mobildatensteuerung zu kommunizieren. Die Mobildatensteuerung gewährleistet in Kombination mit der entfernten Netzwerksteuerung Datenkommunikation von Ende zu Ende dergestalt, dass inkompatible Protokolle der entfernten Einrichtung und dem Hostkommunikationsnetzwerk transparent sind. Es kann ein Router vorgesehen sein, der ein Kommunikationsnetzwerk gemäß benutzerkonfigurierten Parametern auswählt. Der Router kommuniziert über mehrere inkompatible Netzwerke und kann vielfältige verschiedene Protokolle verwenden. Das Umschalten zwischen den mehreren inkompatiblen Netzwerken ist der entfernten Einrichtung und dem Hostkommunikationsnetzwerk transparent.
Die US-Patentanmeldung Publikations-Nr. 2006/0150197 für Werner offenbart eine Verbindung von Clients zur Verwaltung des Systems. Werner offenbart das Erzeugen einer Instanz eines Programmobjekts für ein Client-System, wobei das Client-System von einem Computerplattformtyp ist, wobei das Programmobjekt mit mehreren verschiedenen Computerplattformtypen kompatibel ist. Werner offenbart ferner das Verbinden der Instanz des Programmobjekts mit einer Schnittstelle eines Servers und das Verwaltung einer Anwendung auf dem Server unter Verwendung der Instanz des Programmobjekts.
Die US-Patentanmeldung Publikations-Nr. 2006/0156315 für Wood et al. offenbart ein Verfahren, ein computerlesbares Medium und eine Vorrichtung zum Bereitstellen einer grafischen Benutzeroberfläche in einer Client-Server-Umgebung. Wood et al. offenbaren spezifisch ein Client-Programm in einer Client/Server-Beziehung, das Befehle empfängt, wodurch eine spezifische Implementierung von grafischen Benutzeroberflächenkomponenten erzeugt wird, und empfängt etwaige in den Schnittstellenkomponenten anzuzeigende Daten von dem Serverprogramm. Während der Endbenutzer mit dem Client in Dialog tritt, gibt der Client Ereignisse und Daten zur Verarbeitung an den Server zurück. Die Befehle und Ereignisse konstituieren ein Protokoll, das über eine API publiziert wird. Die Übertragung von Befehlsereignissen zwischen dem Client und dem Server wird ohne Verknüpfung der Programme erreicht. Die spezifische GUI-Implementierung wird durch die Serveranwendung spezifiziert und dem Client nur zur Laufzeit enthüllt.
Ein Aspekt umfasst ein Verfahren zum Bilden einer Schnittstelle von zwei oder mehr Einrichtungen und einem Fahrzeugdatenverarbeitungssystem. Eine Anforderung zum Verbinden mit einem Fahrzeugdatenverarbeitungssystem kann von den zwei oder mehr Einrichtungen empfangen werden, die Daten unter Verwendung verschiedener Kommunikationsprotokolle übermitteln. Die Kommunikationsprotokolle können, aber ohne Beschränkung darauf, Folgendes umfassen: Internet-Protokolle, BLUETOOTH-Protokolle, proprietäre Protokolle, 802.11-Protokolle und Massenspeichereinrichtungsprotokolle.
Die Verbindung, die eine Simultanverbindung sein kann oder auch nicht, kann mit den zwei oder mehr Einrichtungen auf der Basis der Verbindungsanforderung hergestellt werden. Das Verfahren kann ferner das Bestimmen des Kommunikationsprotokolls der zwei oder mehr Einrichtungen umfassen. Dem Kommunikationsprotokoll der zwei oder mehr Einrichtungen kann zum Übermitteln von Daten mit den zwei oder mehr Einrichtungen auf der Basis der jeweiligen Kommunikationsprotokolle ein allgemeines Transportprotokoll auferlegt werden. Ein Datenaustausch kann auf der Basis des allgemeinen Transportprotokolls mit den zwei oder mehr Einrichtungen erreicht werden. Die Daten können, aber ohne Beschränkung darauf, Anweisungen zum Betätigen eines oder mehrerer Anwendungsprogramme, die auf den zwei oder mehr Einrichtungen installiert sind, oder Anweisungen zum Ausführen des Ereignisses auf der Basis eines oder mehrerer Diensttypen umfassen. Diensttypen können, aber ohne Beschränkung darauf, einen Remote Procedure Call, Bulk-Transport oder Medien-Streaming umfassen.
Das Verfahren kann ferner das Ausführen eines Ereignisses in dem Fahrzeugdatenverarbeitungssystem oder den zwei oder mehr Einrichtungen auf der Basis der Daten umfassen.
Bei einer Ausführungsform kann das allgemeine Transportprotokoll transportagnostisch (transport-unabhängig) sein.
Ein anderer Aspekt kann ein System umfassen, das einen Datenprozessor umfasst, der dafür ausgelegt sein kann, sich mit zwei oder mehr Einrichtungen zu verbinden. Die zwei oder mehr Einrichtungen können unter Verwendung verschiedener Kommunikationsprotokolle kommunizieren. Der Datenprozessor kann ferner dafür ausgelegt sein, das Protokoll bzw. die Protokolle der zwei oder mehr Einrichtungen zu bestimmen. Ein allgemeines Protokoll zum Übermitteln von Daten mit den zwei oder mehr Einrichtungen kann auf der Basis ihrer jeweiligen Kommunikationsprotokolle auferlegt werden. Daten können mit der Einrichtung bzw. den Einrichtungen übermittelt werden, um ein Ereignis auszuführen.
Bei einer nichteinschränkenden Ausführungsform kann der Datenprozessor ein Fahrzeugcomputer sein.
Bei bestimmten Ausführungsformen können die zwei oder mehr Einrichtungen dafür ausgelegt sein, nach einer Verbindungsanforderung von dem Datenprozessor zu horchen. Ferner können die zwei oder mehr Einrichtungen simultan mit dem Datenprozessor verbunden sein.
Ein anderer Aspekt umfasst ein in einem computerlesbaren Medium realisiertes Computerprogrammprodukt zum Herstellen einer Schnittstelle von zwei oder mehr Einrichtungen und einem Fahrzeugdatenverarbeitungssystem. Das Computerprogrammprodukt kann Anweisungen zum Herstellen einer Verbindung (die eine Simultanverbindung sein kann oder auch nicht) mit zwei oder mehr Einrichtungen, die Daten unter Verwendung verschiedener Kommunikationsprotokolle übermitteln, umfassen. Das Kommunikationsprotokoll der zwei oder mehr Einrichtungen kann bestimmt werden, und es kann auf der Basis der jeweiligen Kommunikationsprotokolle ein allgemeines Transportprotokoll zum Übermitteln von Daten mit den zwei oder mehr Einrichtungen dem Kommunikationsprotokoll der zwei oder mehr Einrichtungen auferlegt werden.
Das Computerprogrammprodukt kann ferner Anweisungen zum Übermitteln der Daten auf der Basis des allgemeinen Transportprotokolls zum Ausführen eines Ereignisses auf der Basis der Daten umfassen. Ein Ereignis kann, aber ohne Beschränkung darauf, Folgendes umfassen: Wiedergeben von Mediendateien, Ausführen von Fahrzeugdiagnostik, hörbares Ausgeben einer oder mehrerer Nachrichten, Bestätigen einer Existenz einer Anwendungssitzung und Ausführen von auf dem Ort basierenden Diensten.
Bei einer Ausführungsform kann das Computerprogrammprodukt Anweisungen zum Empfangen einer Anforderung zur Verbindung mit dem Fahrzeugdatenverarbeitungssystem von den zwei oder mehr Einrichtungen umfassen.
Bei bestimmten Ausführungsformen können die Daten Anweisungen zum Ausführen des Ereignisses auf der Basis eines oder mehrerer Diensttypen, die eine vordefinierte Priorität aufweisen, umfassen. Das Computerprogrammprodukt kann ferner Anweisungen zum Transportieren der Ereignisanweisungen auf der Basis der Diensttyppriorität umfassen. Ein Diensttyp kann, aber ohne Beschränkung darauf, einen Remote Procedure Call, Bulk-Transportdienst oder einen Heartbeat umfassen.
Diese und andere Aspekte werden im Hinblick auf die beigefügten Zeichnungen und die folgende ausführliche Beschreibung der Erfindung besser verständlich.
Die nachfolgend identifizierten Figuren veranschaulichen bestimmte Ausführungsformen der Erfindung. Die Figuren sind nicht als Beschränkung der in den angefügten Ansprüchen angeführten Erfindung gedacht. Die Ausführungsformen können sowohl hinsichtlich ihrer Organisation als auch ihrer Betriebsweise zusammen mit weiteren Aufgaben und Vorteilen am besten mit Bezug auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen verständlich werden. Es zeigen:
1 eine Blocktopologie für ein Fahrzeugdatenverarbeitungssystem;
2 eine beispielhafte Systemarchitektur, die die Kommunikationsschnittstelle zwischen einem oder mehreren entfernten Endgeräten und dem Fahrzeugdatenverarbeitungssystem von 1 exemplifiziert;
3 ein nichteinschränkendes Beispiel für einen Datenfluss zum Erzeugen eines oder mehrerer Datenpakete zum Austausch durch die Kommunikationsschnittstelle von 2;
4 einen beispielhaften Betrieb zum Herstellen einer Verbindung zwischen einem oder mehreren entfernten Endgeräten und dem Fahrzeugdatenverarbeitungssystem;
5a und 5b nichteinschränkende Beispiele für Datenaustauschszenarien zwischen der Anzahl von entfernten Endgeräten und dem Fahrzeugdatenverarbeitungssystem;
6 einen Aspekt des Betriebs zum Erzeugen einer Nachricht zur Übertragung; und
7 den Betrieb für Nachrichtenübertragung und -austausch zwischen den entfernten Endgeräten und dem Fahrzeugdatenverarbeitungssystem.
Es werden hier ausführliche Ausführungsformen der Erfindung offenbart. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für eine Erfindung sind, die in verschiedenen und alternativen Formen realisiert werden kann. Hier offenbarte spezifische Funktionseinzelheiten sind deshalb nicht als einschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage für die Ansprüche und/oder als repräsentative Grundlage, um Fachleuten zu lehren, die vorliegende Erfindung verschiedenartig einzusetzen.
Einrichtungen wie Personal Computer, in der Hand gehaltene Diagnostikwerkzeuge, Mobiltelefone, Smartphones, Personal Digital Assistants (PDA) und dergleichen können jeweils verschiedene Kommunikationskanäle zum Übermitteln von Daten umfassen. Nichteinschränkende Beispiele umfassen cellular, BLUETOOTH, WiFi, WiMax, Infrarot (IF), HF und dergleichen. Bestimmte Einrichtungen, wie etwa das von THE APPLE CORPORATION hergestellte iPhone können unter Verwendung proprietärer Protokolle Daten übermitteln.
Ferner können auf diesen Einrichtungen Anwendungen oder Programme (im Folgenden als „Anwendungen” bezeichnet) zur Verwendung durch einen Benutzer der Einrichtung installiert sein. Diese Anwendungen können vielfältigen Zwecken für den Benutzer dienen, wie zum Beispiel Korrespondenz, Unterhaltung, Diagnostik und soziale Vernetzung. Ein Benutzer betätigt diese Anwendungen gewöhnlich lokal auf der ortsungebundenen Einrichtung. Diese Anwendungen können dementsprechend mit Anweisungen zum Empfangen von Eingaben und Operationsbefehlen von der lokalen ortsungebundenen Einrichtung programmiert sein, um die Anwendung(en) zu betreiben.
In bestimmten Fällen kann ein Benutzer jedoch diese Anwendungen aus der Ferne betreiben. Als ein Beispiel kann ein Benutzer diese Anwendungen von einem Fahrzeug-Infotainment-System aus betreiben. Ein Beispiel für ein solches Fahrzeug-Infotainment-System ist SYNC von THE FORD MOTOR COMPANY. In solchen Szenarien kann die Anwendung bzw. können die Anwendungen auf der ortsungebundenen Einrichtung installiert sein, aber der Betrieb der Anwendung(en) wird durch das Fahrzeugdatenverarbeitungssystem durchgeführt. Die Anwendung(en) ist bzw. sind jedoch im Allgemeinen nicht dafür programmiert, durch das entfernte Endgerät, wie zum Beispiel das Fahrzeugdatenverarbeitungssystem, betrieben zu werden. Ein Benutzer kann somit ohne eine Möglichkeit von Schnittstellen mit der Funktionalität und Steuerelementen des entfernten Endgeräts möglicherweise nicht in der Lage sein, Funktionalität dieser Anwendungen zu erhalten.
1 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem (VCS) 1 für ein Fahrzeug 31. Es versteht sich, dass die Anordnung von 1 (und der nachfolgenden 2–7) nicht einschränkend ist. Die Offenbarung und Anordnung von 1–7 kann somit modifiziert oder umgeordnet werden, um am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung zu passen.
Ein mit einem fahrzeuggestützten Datenverarbeitungssystem befähigtes Fahrzeug kann eine visuelle Frontend-Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann auch in der Lage sein, mit der Schnittstelle in Dialog zu treten, wenn sie zum Beispiel mit einem berührungsempfindlichen Schirm ausgestattet ist. Bei einer anderen beispielhaften Ausführungsform erfolgt der Dialog durch Tastenbetätigungen, hörbare Sprache und Sprachsynthese.
Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der Prozessor ist in dem Fahrzeug vorgesehen und erlaubt Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nichtpersistentem 5 als auch persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nichtpersistente Speicher Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher.
Der Prozessor ist außerdem mit einer Anzahl von verschiedenen Eingängen ausgestattet, die es dem Benutzer ermöglichen, eine Schnittstelle mit dem Prozessor herzustellen. Bei dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist ein Eingangsselektor 51 vorgesehen, um es einem Benutzer zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Der Eingang sowohl zu dem Mikrofon als auch zu dem Hilfsverbinder wird durch einen Umsetzer 27 von analog in digital umgesetzt, bevor sie zu dem Prozessor weitergeleitet wird.
Ausgaben des Systems können, aber ohne Beschränkung darauf, eine visuelle Anzeige 4 und einen Lautsprecher 13 oder eine Stereosystemausgabe umfassen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Umsetzer 9. Ausgabe kann auch an eine entfernte BLUETOOTH-Einrichtung wie zum Beispiel die PND 54 oder eine USB-Einrichtung wie zum Beispiel die Fahrzeugnavigationseinrichtung 60 entlang der bei 19 bzw. 21 gezeigten bidirektionalen Datenströme erfolgen.
Bei einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Sender/-Empfänger 15 zum Kommunizieren 17 mit der ortsungebundenen Einrichtung 53 (z. B. Mobiltelefon, Smartphone, PDA usw.) eines Benutzers. Die ortsungebundene Einrichtung kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Cellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Die beispielhafte Kommunikation zwischen der ortsungebundenen Einrichtung und dem BLUETOOTH-Sender/-Empfänger wird durch das Signal 14 repräsentiert.
Das Paaren einer ortsungebundenen Einrichtung 53 und des BLUETOOTH-Senders/-Empfängers 15 kann durch eine Taste 52 oder ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der Onboard-BLUETOOTH-Sender/-Empfänger mit einem BLUETOOTH-Sender/-Empfänger in einer ortsungebundenen Einrichtung gepaart werden wird.
Zwischen der CPU 3 und dem Netzwerk 61 können zum Beispiel mit einem Datenplan, Data Over Voice oder DTMF-Tönen, die mit der ortsungebundenen Einrichtung 53 assoziiert sind, Daten übermittelt werden. Als Alternative kann es wünschenswert sein, ein Onboard-Modem 63 vorzusehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übermitteln 16. Die ortsungebundene Einrichtung 53 kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann das Modem 63 zur Kommunikation mit dem Netzwerk 61 Kommunikation 20 mit dem Mast 57 herstellen. Als nichteinschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein, und die Kommunikation 20 kann Mobilfunk-Kommunikation sein.
Bei einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API zur Kommunikation mit Modem-Anwendungssoftware umfasst. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder Firmware in dem BLUETOOTH-Sender/-Empfänger zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sender/-Empfänger (wie etwa dem in einer ortsungebundenen Einrichtung angetroffenen) abzuschließen.
Bei einer anderen Ausführungsform umfasst die ortsungebundene Einrichtung 53 ein Modem zur Sprachband- oder Breitband-Datenkommunikation. Bei der Data-Over-Voice-Ausführungsform kann eine als Frequenzmultiplexen bekannte Technik implementiert werden, wenn der Eigentümer der ortsungebundenen Einrichtung über die Einrichtung sprechen kann, während Daten transferiert werden. Zu anderen Zeiten kann der Datentransfer, wenn der Eigentümer die Einrichtung nicht verwendet, die gesamte Bandbreite (300 Hz bis 3,4 KHz in einem Beispiel) verwenden.
Wenn der Benutzer einen mit der ortsungebundenen Einrichtung assoziierten Datenplan besitzt, ist es möglich, dass der Datenplan Breitbandübertragung erlaubt und das System eine wesentlich größere Bandbreite verwenden könnte (wodurch der Datentransfer beschleunigt wird). Bei einer weiteren Ausführungsform wird die ortsungebundene Einrichtung 53 mit einem Mobilfunk-Kommunikationsgerät (z. B., und ohne Beschränkung darauf, Modem 63) ersetzt, das in dem Fahrzeug 31 installiert wird. Bei einer weiteren Ausführungsform kann die ND 53 eine drahtlose LAN-Einrichtung (LAN = lokales Netzwerk) sein, die zum Beispiel (und ohne Beschränkung) über ein 802.11-Netzwerk (darunter, aber ohne Beschränkung darauf, WiFi and WiMax) und LTE-Netzwerke (Long Term Evolution) kommunizieren kann.
Bei einer Ausführungsform können ankommende Daten über einen Data-Over-Voice- oder Datenplan durch die ortsungebundene Einrichtung, durch den Onboard-BLUETOOTH-Sender/-Empfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf der HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die an das Fahrzeug angeschaltet werden können, wären ein persönliches Navigationsgerät 54, das zum Beispiel eine USB-Verbindung 56 oder eine Antenne 58 aufweist; oder ein Fahrzeugnavigations-gerät 60 mit einem USB 62 oder einer anderen Verbindung, ein Onboard-GPS-Gerät 24 oder Fernnavigationssystem (nicht gezeigt) mit Konnektivität zu dem Netzwerk 61.
Ferner könnte sich die CPU in Kommunikation mit vielfältigen anderen Hilfseinrichtungen 65 befinden. Diese Einrichtungen können durch eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden werden. Außerdem oder als Alternative könnte die CPU zum Beispiel unter Verwendung eines WiFi-Senders/-Empfängers 71 mit einem fahrzeuggestützten drahtlosen Router 73 verbunden werden. Dadurch könnte sich die CPU mit entfernten Netzwerken in der Reichweite des lokalen Routers 73 verbinden.
2 zeigt einen nichteinschränkenden Rahmen, in dem ein Benutzer eine Schnittstelle mehrerer Einrichtungen mit einem Fahrzeugdatenverarbeitungssystem (VCS) 1 herstellen kann. Genauer gesagt kann das System 100 einem Benutzer gestatten, eine Schnittstelle der Anwendungen 103a-f, die auf den Einrichtungen 102a-f installiert sind, mit dem VCS1 zum Betrieb der Anwendungen 103a-f durch das VCS 1 herstellen. Das Betreiben der Anwendungen 103a-f kann, aber ohne Beschränkung darauf, Folgendes umfassen: Aktivieren der Anwendungen 103a-f, Eingeben von Befehlen und Anweisungen (über Sprache, Tastenbetätigungen usw.) und Empfangen von Ausgaben (z. B. visuelle, grafische, textliche, hörbare und andere ähnliche Ausgaben).
Es versteht sich jedoch, dass die Architektur von 2 und die assoziierte Beschreibung nicht einschränkend sind. Zum Beispiel und ohne Beschränkung kann der Betrieb der Anwendungen 103a-f zusätzlich oder als Alternative durch die Einrichtungen 102a-f erfolgen. Zum Beispiel und ohne Beschränkung können die Eingaben, Ausgaben und Befehle an der Einrichtung 102a-f erfolgen.
Ferner versteht sich, dass die verschiedenen in Bezug auf 2 beschriebenen Ausführungsformen zusätzlich oder als Alternative für Telematikunterstützung verwendet werden können. Als nichteinschränkendes Beispiel können die verschiedenen Ausführungsformen beim Austauschen von Fahrzeugintegritätsberichtsdaten verwendet werden. Als weiteres nichteinschränkendes Beispiel können die verschiedenen Ausführungsformen beim Austauschen von Lizenzierungsdaten für eine Anwendung 103a-f verwendet werden. Als weiteres nicht einschränkendes Beispiel können die verschiedenen Ausführungsformen zur Ferntürentriegelung verwendet werden.
Nunmehr mit Bezug auf 2 kann es eine oder mehrere Einrichtungen 102a-f geben, die mit dem VCS 1 eine Schnittstelle herstellen können.
Der Darstellung und Klarheit halber ist 2 jedoch mit mehreren Einrichtungen 102a-f gezeigt. Nichteinschränkende Beispiele für solche Einrichtungen wären Mobiltelefone, in der Hand gehaltene Diagnostikwerkzeuge, Personal Computer, Smartphones, Personal Digital Assistants (PDA), Medieneinrichtungen (z. B. und ohne Beschränkung MP3-Player), tragbare Speichereinrichtungen (z. B. und ohne Beschränkung USB-Thumbdrives, Speicherkarten/-Sticks, SLOTMUSIC-Karten und andere geeignete Speichereinrichtungen) und/oder Adapter zur Aufnahme dieser Speichereinrichtungen und andere Einrichtungen, die jetzt oder später bekannt sein können.
Die Anwendungen 103a-f, die auf den Einrichtungen 102a-f installiert sind, können auf der Einrichtung 102a-f fabrikinstalliert sein oder durch einen Benutzer nach dem Kauf der Einrichtung 102a-f installiert werden. Ein Benutzer kann zum Beispiel, und ohne Beschränkung darauf, die Anwendung von einem computerlesbaren Medium (z. B. einer CD oder einem Thumdrive) aus installieren oder die Anwendung über das Internet (z. B. von einer Site Dritter) herunterladen. Ein Benutzer kann, aber ohne Beschränkung darauf, Folgendes umfassen: einen Verbraucher, einen Fahrzeughändler (und von dem Händler angestellte Personen) oder eine Servicewerkstatt (und von der Servicewerkstatt angestellte Personen). Nichteinschränkende Beispiele für die Anwendungen 103a-f, die in die Einrichtungen 102a-f installiert werden können, können Folgendes umfassen: Fahrzeugdiagnostikanwendungen, Kommunikationsanwendungen (z. B. und ohne Beschränkung E-Mail, VOIP und Textnachrichten), Unterhaltungsanwendungen (z. B. und ohne Beschränkung Multi-medien-Streaming, Videos, Musik, Spiele usw.), Anwendungen zur sozialen Vernetzung, auf dem Ort basierende Anwendungen, auf persönlicher Werbung basierende Anwendungen und andere.
Jede Einrichtung 102a-f kann durch einen oder mehrere Kommunikationskanäle unter Verwendung eines oder mehrerer Kommunikationsprotokolle 104a-f Daten übermitteln. Nichteinschränkende Beispiele für solche Kommunikations-protokolle 104a-f wären das BLUETOOTH-Protokoll, 802.11-Protokolle, TCP/IP, proprietäre Protokolle (wie zum Beispiel, ohne Beschränkung, das iAP-Protokoll von APPLE CORPORATION), Massenspeicherprotokolle (z. B. USB-Protokolle), auf USB basierende Vernetzungsprotokolle (z. B. und ohne Beschränkung USB-Serial oder USB-RNDIS) und andere Protokolle, die jetzt oder später bekannt sind. Es versteht sich, dass die Einrichtungen 102a-f Daten unter Verwendung mehrerer Kommunikationsprotokolle (z. B. und ohne Beschränkung BLUETOOTH und 802.11) übermitteln können. Diese Beziehung zwischen dem VCS 1 und den Einrichtungen 102a-f kann als ein Netzwerk bezeichnet werden. Bei bestimmten Ausführungsformen kann die Beziehung zwischen den Einrichtungen 102a-f und dem VCS 1 ein „ad-hoc”-Netzwerk erzeugen.
Es versteht sich, dass, obwohl die verschiedenen Ausführungsformen mit Bezug auf Kommunikation mit einem Datenverarbeitungssystem in einem Automobil beschrieben werden, es andere Umgebungen geben kann, in denen das Netzwerk implementiert werden kann. Nichteinschränkende Beispiele für solche Umgebungen umfassen eine Wohnung, ein Büro, eine Schule, ein Flugzeug, einen Zug, einen Bus und andere ähnliche Umgebungen.
Wieder mit Bezug auf 2 kann mit Bezug auf BLUETOOTH-fähige Einrichtungen jede Einrichtung außerdem ein oder mehrere BLUETOOTH-Profile umfassen, die definieren, mit welchen Einrichtungen die BLUETOOTH-fähige Einrichtung kommunizieren kann. Profile können Standardprofile sein (wie zum Beispiel A2DP, HFP, SDAP und HSP) oder angepasste Profile. Als nichteinschränkendes Beispiel kann die BLUETOOTH-fähige Einrichtung das SDAP-Profil umfassen, um zu entdecken, welche Dienste auf dem VCS 1 verfügbar sein können. Bei bestimmten Ausführungsformen kann der Entdeckungsprozess auf einer SDAP-Aufzeichnung basieren, die eine universell einzigartige Kennung (UUID) aufweist, die für das SDAP-Profil registriert ist.
Die Einrichtungen 102a-f können unter Verwendung eines oben beschriebenen Kommunikationskanals eine Verbindung mit dem VCS 1 herstellen. Bei einer Ausführungsform kann die Einrichtung 102a-f nach einer Verbindungsanforderung von dem VCS 1 horchen. Bei anderen Ausführungsformen kann das VCS 1 nach Verbindungsanforderungen von den Einrichtungen 102a-f horchen. Wenn eine Verbindung hergestellt wird, kann ein Datentransportmanager 106 (der auf die CPU 3 des VCS 1 als Software implementiert werden kann oder auch nicht) die von der einen oder den mehreren Anwendungen 103a-f (über die Einrichtung 102a-f) übermittelten Nachrichten/Daten empfangen und die Nachrichten/Daten zur weiteren Übertragung verarbeiten.
Bei bestimmten Ausführungsformen können die Einrichtung 102a-f gleichzeitig mit dem VCS 1 verbunden werden. Bei anderen Ausführungsformen kann die Einrichtung 102a-f individuelle und separate (d. h. nicht gleichzeitige) Verbindungen herstellen.
Bei einer Ausführungsform kann der Transportmanager 106 diese Daten zu dem Sicherheitsmanager 108 senden. Dementsprechend kann der Transportmanager 106 die Kommunikation zwischen der Einrichtung 102a-f und dem Sicherheitsmanager 108 ermöglichen. Weitere Einzelheiten des Sicherheitsmanagers werden später beschrieben. Bei bestimmten Ausführungsformen kann der Transportmanager auch mit einem (nicht gezeigten) Datenmanager kommunizieren, der die Daten zu dem Sicherheitsmanager übermitteln kann. Der Datenmanager kann zwischen Anwendungen verfügbare Systemdaten in einer Datenbankstruktur speichern.
Nichteinschränkende Beispiele für die Aufgaben des Transportmanagers 106 wären Abstrahieren (d. h. Standardisieren) der Kommunikationsprotokolle 104a-f und Weiterleiten der folgenden nichteinschränkenden Informationen: Daten, Transportzustandsänderungen, entdeckte Anwendungen und Startanforderungen. Der Transportmanager 106 kann diese Aufgaben als die Schnittstelle zum Verbinden mit einer Einrichtung 102a-f mit einem gegebenen Namen über einen gegebenen Kommunikationskanal 104a-f erfüllen. Insbesondere kann der Transportmanager 106 Daten über eine existierende Sitzung senden und/oder empfangen. Eine Sitzung kann eine logische Verbindung zwischen einer Anwendung 103a-f auf der Einrichtung 102a-f und dem VCS 1 sein. Der Transportmanager kann außerdem dem Protokollmodul 105 (z. B. und ohne Beschränkung einer Verbindung zum Gerät) Benachrichtigungen zuführen. Bei einer Ausführungsform können Benachrichtigungen identifizierende Informationen sein, die ein Ereignis definieren, das die Benachrichtigung auslöst. Ferner kann der Transportmanager 106 verschiedene Verbindungsabbildungen unterhalten, einschließlich einer Abbildung zwischen Verbindungen und allen aktiven Sitzungen über eine gegebene Verbindung und einer Abbildung zwischen Verbindungen und entsprechenden Kommunikationskanälen 104a-f. Eine „Verbindung” kann eine Verbindung zwischen den Transportschichten der Einrichtungen 102a-f und dem VCS 1 sein. Somit kann der Transportmanager 106 transportspezifische Einzelheiten aus den Kommunikationskanälen 104a-f mit dem Datentransportprotokoll (später beschrieben) einpacken. Der Transportmanager 106 kann auch Informationen über die verbundene Einrichtung 102a-f (z. B. den Einrichtungsnamen) und Informationen über die Kommunikationskanäle 104a-f (z. B. den Transportnamen) unterhalten. Dementsprechend kann der Transportmanager den Austausch von Benutzeranweisungen zwischen den Anwendungen 103a-f und dem VCS 1 über ein beliebiges der Kommunikationsprotokolle 104a-f, die zum Übermitteln von Daten zu/von der Einrichtung 102a-f verwendet werden, ermöglichen.
Wie oben beschrieben kann der Transportmanager die Entdeckung der Anwendungen 103a-f und/oder Einrichtungen 102a-f ermöglichen.
Als nichteinschränkendes Beispiel kann die Entdeckung unter Verwendung von Null-Konfigurations-Vernetzung erreicht werden. Bei bestimmten Ausführungsformen kann die Entdeckung jedoch für jedes Kommunikationsprotokoll 104a-f spezifisch sein (z. B. und ohne Beschränkung unter Verwendung des SDP (Service Discovery Protocol) für BLUETOOTH-Einrichtungen).
Bei einer Ausführungsform kann der Datentransportmanager 106 ein Datentransport-Plugin 107 umfassen, das auf der CPU 3 implementiert ist. Das Datentransport-Plugin 107 kann bestimmt werden und die Verbindung für jedes Kommunikationsprotokoll 104a-f verwalten. Zum Beispiel und ohne Beschränkung kann ein Plugin für proprietäre Protokolle, BLUETOOTH-Protokolle, 802.11-Protokolle und dergleichen existieren. Bei bestimmten Ausführungsformen kann das Plugin 107 als eine Dynamic Link Library (DLL) implementiert werden. Dementsprechend können Fähigkeiten für derzeitige und neue Kommunikationskanäle 104a-f vorgesehen werden. Das Plugin 107 kann durch einen OEM oder durch Drittentwickler (wie etwa Wipro Technologies) implementiert werden.
Das Datentransport-Plugin 107 kann eine Schnittstelle zur Verbindung mit einer Einrichtung 102a-f bereitstellen. Bei einer Ausführungsform kann das Plugin 107 auf die ankommenden Verbindungen von der Einrichtung 102a-f warten. Die durch das Plugin 107 hergestellte Verbindung kann das Senden und/oder Empfangen von Daten über eine existierende Verbindung (wie oben definiert) gestatten. Die Schnittstelle kann von dem zugrundeliegenden Kommunikations-transportprotokoll 104a-f unabhängig sein. Bei bestimmten Ausführungsformen kann das Plugin 107 auf der Basis von Informationen, die es empfängt, den Transportmanager 106 über Ereignisse (z. B. und ohne Beschränkung eine Verbindung) benachrichtigen. Bei einer Ausführungsform können Benachrichtigungen identifizierende Informationen sein, die das Ereignis definieren. Bei weiteren Ausführungsformen kann das Plugin 107 über eine Transportverbindung empfangene Daten pullern.
Wie oben beschrieben kann der Transportmanager 106 Daten, die über eine existierende Sitzung (wie oben definiert) gesendet werden, senden und/oder empfangen. Bei einer Ausführungsform können die Nachrichten durch ein Protokollmodul 105 empfangen/gesendet werden, das sich in Kommunikation mit dem Transportmanager 106 befinden kann. Das Protokollmodul 105 kann bei der Ermöglichung der Bedienung der Anwendungen 103a-f durch einen Benutzer von dem VCS 1 aus eine Anzahl von Aufgaben ausführen. Einige nichteinschränkende Aufgaben wären: (1) Initialisierung/Deinitialisierung des Protokollmoduls, (2) Starten/Enden einer Sitzung (oben definiert) über eine gegebene Verbindung (oben definiert), (3) Hinzufügen/Entfernen von neuen und existierenden Diensten (unten definiert) und (4) Senden/Empfangen von Daten über eine existierende Sitzung (oben definiert). Bei einer Ausführungsform kann das Protokollmodul 105 auch Benachrichtigungen bereitstellen. Diese Benachrichtigungen können ausgelöst werden, wenn das Protokollmodul 105 (z. B. von dem Transportmanager 106) ein Datenpaket empfängt.
Das Protokollmodul 105 kann den Typ des Dienstes bestimmen, der von den Anwendungen 103a-f angefordert wird. Ein Dienst kann ein Heartbeat (HB), ein Remote Procedure Call (RPC) oder ein Bulk-Dienst sein. Andere nichteinschränkende Dienste können Medien-Streaming, Verwendung von anwendungsspezifischen Transportprotokollen (z. B. können Anwendungen spezifische Domänenprotokolle aufweisen), Verwendung anderer Protokolle (wie etwa HTTP, FTP, IRC, SOAP und IMAP) und andere geeignete Diensttypen umfassen. Allgemeiner kann ein Dienst den Typ einer Aktion angeben, den eine Anwendung 103a-f anfordern kann. Bei einer Ausführungsform kann jeder Diensttyp in dem Protokollmodul 105 in einer Warteschlange gehalten und gemäß einem Übertragungsmuster gesendet werden. In einem nichteinschränkenden Beispiel kann dieses Übertragungsmuster ein First-In-First-Out-(FIFO)-Übertragungsmuster sein.
Zusätzlich oder als Alternative kann das Protokollmodul 105 eine Priorität an jeden Diensttyp vergeben. Ein Diensttyp mit einer höheren Priorität kann somit vor einem Diensttyp mit einer niedrigeren Priorität gesendet werden. Als nichteinschränkendes Beispiel kann ein Heartbeat-Dienst die niedrigste Priorität, ein RPC ein dazwischenliegende Priorität und ein Bulk-Transfer die höchste Priorität aufweisen. Es versteht sich, dass andere Prioritätsschemata verwendet werden können, ohne von dem Schutzumfang und Gedanken der verschiedenen Ausführungsformen abzuweichen.
Bei einer Ausführungsform kann das Protokollmodul 105 als Alternative oder zusätzlich periodisch Heartbeat-Nachrichten für jede aktive Sitzung senden und/oder nach diesen horchen. Beim Horchen nach Heartbeat-Nachrichten (z. B. von den Einrichtungen 102a-f) kann das Protokollmodul 105 nach einem Heartbeat für einen vorbestimmten Zeitraum und/oder eine vorbestimmte Anzahl von Malen horchen. Wenn kein Heartbeat empfangen wird, kann das Protokollmodul 105 die Sitzung schließen und eine Statusbenachrichtigung zu der Anwendung 103a-f senden. Ferner kann jeder Heartbeat einen vorbestimmten Zeitraum (z. B. und ohne Beschränkung 5 Sekunden) überspannen.
Das Protokollmodul 105 kann auch Nachrichten, die eine bestimmte Nutzinformationsschwelle überschreiten, segmentieren. Das Transport-Plugin 107 kann eine Grenze bezüglich der Menge an Nutzinformationen, die es empfangen kann, aufweisen. Dies kann als maximale Übertragungseinheit (MTU) bezeichnet werden. Dementsprechend kann das Protokoll 105 die ankommende Nachricht segmentieren und die Nachrichten in segmentierter Form senden, um MTU-Regeln des Transport-Plugins zu genügen. Bei der Rückkehr kann das Protokollmodul 105 auch die segmentierten Nachrichten vor dem Senden einer Nachricht zu der Anwendung 103a-f wieder zusammenstellen. Bei einer Ausführungsform kann die Anwendung 103a-f nur wieder zusammengestellte Nachrichten empfangen. Die Segmentierung kann auch vergrößerte Leistungsfähigkeit des Systems 100 gewährleisten, indem eine Verschachtelung der Daten gewährleistet wird. Bei bestimmten Ausführungsformen kann eine Grenze für die Anzahl verschachtelter Interaktionen bestehen. 5A und 5B zeigen nichteinschränkende Beispiele für einen unsegmentierten Datenaustausch (5A) und einen segmentierten Datenaustausch (5B).
Das Protokoll kann in zwei Schichten (z. B. eine höhere Schicht und eine niedrigere Schicht) aufgeteilt werden. Eine höhere Schicht kann die Funktionsaufrufe enthalten, die erforderlich sind, um Einrichtungskommunikation und Systemsteuerfluss zu erzielen. Eine niedrigere Schicht kann die grundlegenden Kommunikationsfunktionen bereitstellen. Diese niedrigere Schicht kann bezüglich der Hardware- und Systemdetails agnostisch sein.
Weitere Einzelheiten der Interaktion zwischen den verschiedenen Komponenten des Systems 100 werden mit Bezug auf 3 beschrieben. Wie oben beschrieben, können die eine oder mehreren Nachrichten (oder Datenpakete), die von der Anwendung 103a-f (wie durch den Pfeil 200 dargestellt) empfangen werden, gemäß einem Datentransportprotokoll gesendet werden. Dieses Datentransportprotokoll kann „transportagnostisch” sein. Auf diese Weise kann das Datentransportprotokoll ein dynamisches Protokoll sein, so dass es Erweiterbarkeit ohne signifikante (oder jegliche) Änderungen an seiner Architektur unterstützen kann. Anweisungen (d. h. Daten) von den Anwendungen 103a-f können somit über das Datentransportprotokoll transportiert werden, gleichgültig welches der Kommunikationsprotokolle 104a-f (d. h. sowohl derzeitige als auch zukünftige Kommunikationsprotokolle) die Einrichtung 102a-f zum Transportieren von Daten verwendet.
Zum Beispiel und ohne Beschränkung kann eine Einrichtung die Anwendung 103a-f unter Verwendung von BLUETOOTH (z. B. unter Verwendung der Protokolle RFComm (Radio Frequency Communication) und L2CAP (Logical Link Control and Adaptation)) betreiben, während eine andere Einrichtung die Anwendungen 103a-f unter Verwendung eines proprietären Protokolls (wie etwa iAP von APPLE) betreiben kann. Das Datentransportprotokoll ermöglicht den Betrieb der Anwendungen auf den jeweiligen Einrichtungen 102a-f von dem VCS 1 aus ohne Rücksicht auf den von jeder Einrichtung verwendeten Datenkommunikationskanal 103a-f. Vom Standpunkt eines Benutzers aus gesehen kann die Anwendung auf einer Einrichtung 102a-f nahtlos verwendet werden. Vom Standpunkt eines Entwicklers der Anwendung 103a-f aus gesehen muss die Anwendung nicht individuell auf der Basis der unterschiedlichen Kommunikationsprotokolle 104a-f entwickelt werden.
Darüber hinaus kann das Datentransportprotokoll 200 bandbreiten- und latenzneutral sein. Somit trifft bei dieser Ausführungsform das Protokoll keine Annahmen hinsichtlich der Geschwindigkeit der Datenverbindung oder Latenzverzögerungen von den Anwendungen 104a-f. Bei bestimmten Ausführungsformen kann ein kleinster gemeinsamer Nenner der Kommunikationskanäle 104a-f die Interaktion bestimmen. Der kleinste gemeinsame Nenner kann relativ sein. Zum Beispiel ist BLUETOOTH auf ungefähr 700 kbs Durchsatz begrenzt, verglichen mit WiFi, das ungefähr 10–20 mbs Durchsatz erhalten kann.
Bei einer Ausführungsform kann das Datentransportprotokoll generische Befehle umfassen. Bei einer solchen Ausführungsform ist möglicherweise keine spezifische Funktionalität zum Interagieren mit dem VCS 1 (wie zum Beispiel für das VCS 1 spezifische Befehle) in das Protokoll programmiert. Stattdessen können allgemeine Datentransportabstraktionen zwischen dem VCS 1 und der Anwendung 103a-f vorgesehen werden.
Wie in 3 dargestellt, können bestimmte Aspekte des Datenaustauschs unidirektional sein (wie z. B. durch den Datenflusspfeil 208 repräsentiert). Zusätzlich oder als Alternative können bestimmte Aspekte bidirektional sein (wie z. B. durch den Datenflusspfeil 200 repräsentiert). Es versteht sich jedoch, dass die Offenbarung und Anordnung von 3 modifiziert oder umgeordnet werden kann, um am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung zu passen.
Es können eine Anwendungskennung („AppID”), Sitzungsinformation („Session”), ein Diensttyp („ServType”) und Anwendungsdaten von der Anwendung 103a-f gesendet werden (Pfeil 200). Anwendungsdaten können, aber ohne Beschränkung darauf, Folgendes umfassen: die Benutzeranweisungen/anforderungen (z. B. und ohne Beschränkung Korrelations-ID zum Binden einer Anforderung mit einer Antwort, auszuführenden Befehlen, abzufeuernden Ereignissen und Statusrückkehrkodes) und Anwendungsskripts (z. B. und ohne Beschränkung umfassend die Grenzen, die definieren, welche Betriebsmittel des VCS 1 die Anwendung 103a-f benutzen darf). Die Anwendungsdaten können auch Symbole, Klangdateien und Grafiken umfassen. Von dem Fahrzeug aus gesehen können die Anwendungsdaten, aber ohne Beschränkung darauf, Klangerfassungen und Fahrzeugdiagnostikerfassungen umfassen. Es versteht sich, dass der Aufbau der Anwendungsdaten offenendig und nichteinschränkend ist, so dass zu ihnen hinzugefügt werden kann und sie anderweitig modifiziert werden können.
Die AppID kann eine einzigartige ID sein, die mit einer Anwendung 103a-f assoziiert ist. Bei bestimmten Ausführungsformen kann sie eine numerische ID, eine benutzerfreundliche Beschreibung, ein Symbol und dergleichen sein. Die AppID kann definieren, dass die Anwendungen 103a-f mit dem VCS 1 operabel sind. Ferner kann, nachdem eine Sitzung hergestellt ist, die AppID verwendet werden, um die Anwendungen 103a-f dem Benutzer in dem Fahrzeug (z. B. auf der Anzeige 4) zu identifizieren.
Bestimmte dieser Daten können in dem Datentransportprotokoll enthalten sein. Zum Beispiel und ohne Beschränkung kann der Diensttyp (z. B. und ohne Beschränkung RPC oder Bulk) mindestens ein Byte des Datenprotokolls umfassen. Zusätzlich kann eine Sitzungs-ID (die die Sitzung identifiziert) ein oder mehr Byte des Datenprotokolls umfassen. Die Daten von den Anwendungen 103a-f können bei Aktivierung oder während des Betriebs der Anwendungen 103a-f gesendet werden. Die nachfolgende Tabelle 1 gibt Definitionen für diese Daten.
Zusätzlicher Inhalt des Datentransportprotokolls kann Folgendes umfassen: einen Rahmentyp (z. B. und ohne Beschränkung einen Steuerrahmen, einzelnen Rahmen, ersten Rahmen oder aufeinanderfolgenden Rahmen), Rahmendaten (die auf dem Rahmentyp basieren können), eine Versionsnummer des Protokolls, ein Komprimierungs-Flag (d. h. die Anwesenheit komprimierter Daten), einen zur Komprimierung verwendeten Algorithmus und die Datengröße (die auf dem Rahmentyp basieren kann). Diese Daten können jeweils ein oder mehr Byte des Datentransportprotokolls umfassen.
Wie in 3 weiter dargestellt, können andere Daten zwischen den Anwendungen 103a-f und dem Transport-Plug-in 107 ausgetauscht werden. Es können verschiedene Befehle von den Anwendungen 103a-f zu dem Transportmanager 106 gesendet werden. Nichteinschränkende Beispiele für bestimmte dieser Befehle werden in Tabelle 1 angegeben. Die AppID (die in einem separaten Datenpaket enthalten sein kann oder auch nicht), ein Protokoll-Header für das Datentransportprotokoll, und Anwendungsdaten (z. B. Benutzeranweisungen/anforderungen, Anwendungsskripts usw.) können auch zu dem Transportmanager 106 gesendet werden (Datenflusspfeil 202). Dieselben Informationen können an das Datentransportprotokollmodul 105 zurückgegeben werden (z. B. wenn der Betrieb in dem VCS 1 durchgeführt wurde) (Datenflusspfeil 202).

Der Transportmanager kann auch Transporteigenschaften an das Protokollmodul 105 unterreichen (Datenflusspfeil 214). Gegebenenfalls kann ein Transportstatus von dem Transport-Plugin 107 empfangen werden (Datenflusspfeil 216) und zu dem Protokollmodul gesendet werden (Datenflusspfeil 212). Die Transporteigenschaften und der Transportstatus werden in Tabelle 1 beschrieben. Der Transportmanager 106 kann auch den Protokoll-Header (PH) und Anwendungsdaten zu dem Transport-Plugin 107 senden und von diesem empfangen (Datenflusspfeil 204). Das Transport-Plugin 107 kann einen Transport-Header (TH) erzeugen und ihn mit dem PH und den Anwendungsdaten senden (Datenflusspfeil 206). Bei einer Ausführungsform kann der TH ein optionaler Header sein, der überschüssige Daten hält, die das Datentransportprotokoll nicht halten kann. Daten können auf der Basis von Datengrößenanforderungen als überschüssig betrachtet werden, die durch das zugrundeliegende Kommunikationsprotokoll 104a-f vorgeschrieben werden. Diese Daten können zu dem Sicherheitsmanager 108 gesendet werden. Tabelle 1

Daten/Steuerinformationen	Definition/Beschreibung
AppID	Anwendungs-ID: Parameter, der eine Anwendung in einer gegebenen Einrichtung eindeutig identifiziert
Sitzung-ID	Eine ID zum Identifizieren einer logischen Verbindung zwischen Anwendungen auf den Einrichtungen 102a-f und dem VCS 1
ServType	Dienstyp: z. B. und ohne Beschränkung Remote Procedure Call (RPC), Bulk, Medien-Streaming, Verwendung von anwendungsspezifischen Transporten, Verwendung anderer Transporte (wie etwa HTTP) und andere geeignete Diensttypen
Transporteigenschaften	Informationen bezüglich des Transport-Plugin (z. B. und ohne Beschränkung Transport-Plugin-Name)
Transportstatus	Umfasst Informationen über den Status des Transports (z. B. und ohne Beschränkung initialisiert/deinitialisiert, verbunden/getrennt und Fehler
Befehle	Datentransportbefehle, darunter, aber ohne Beschränkung darauf, initialisiert/deinitialisiert, verbinden/trennen und Nachricht senden
PH	Datentransportprotokoll-Header
TH	Transportierungs-Header: durch das Transport-Plugin hinzugefügte Informationen

Wieder mit Bezug auf 2 kann der Sicherheitsmanager 108 Daten von dem Transportmanager 106 empfangen, um sicherzustellen, dass anwendungsspezifische Richtlinien und/oder Vorgabe-Sicherheitsrichtlinien durchgesetzt werden. Auf diese Weise können die Anwendungen 103a-f keinen größeren Zugang zu den Betriebsmitteln des VCS 1 erhalten, als die Anwendungen 103a-f erfordern. Auf der Basis der Sicherheitsrichtlinien des Sicherheitsmanagers 108 kann ferner jede Anwendung darauf eingegrenzt werden, innerhalb ihrer „Zuteilungs”-parameter zu operieren. Bei einer Ausführungsform kann die Sicherheitsrichtliniendurchsetzung als eine ”Sandbox”-Umgebung betrachtet werden.
Wenn beispielsweise ein Benutzer anfordert, ein Musikprogramm (z. B. PANDORA) von einer Einrichtung 102a-f aus zu betreiben, kann der Sicherheitsmanager 108 die Benutzungsbeschränkungen (d. h. Grenzen) mit Bezug auf die VCS-Betriebsmittel des Musikprogramms auf der Basis der computerlesbaren Anweisungen (z. B. Anwendungsskripts) von der Anwendung 103a-f bestimmen. Genauer gesagt können die Beschränkungen vorgeben, dass das Musikprogramm Zugang zu Grafik und Audio, nicht aber zu Fahrzeugdiagnostik haben darf. Dementsprechend können die Beschränkungen auf der konkreten Funktion der Anwendung basieren.
Dementsprechend kann der Sicherheitsmanager 108 bestimmen, welche Betriebsmittel von einer Anwendung 103a-f angefordert werden, und den Zugang zu anderen Betriebsmitteln herausblockieren. Ferner kann er die für jede ankommende Anforderung von einer Anwendung 103a-f definierten Richtlinien bewerten, um ihren Zugang für das Betriebsmittel, zu dem sie Zugang hat, weiter einzuschränken.
Bei einer Ausführungsform kann der Zugang zu Betriebsmitteln des VCS 1 (z. B. Fahrzeugsteuerelementen 112 und Fahrzeugmodulen 114) durch Anwendungsprogrammierschnittstellen (API) 110 erreicht werden, die auf dem VCS 1 installiert sind. Diese API können von dem Fahrzeug-OEM entwickelt werden. Bei einer Ausführungsform können die API als DLL programmiert und in den Programmiersprachen C oder C++ programmiert werden. Ferner kann jede API ihre eigene Menge von Sicherheitsparametern aufweisen, so dass sie jeweils einzigartige Richtlinienbeschränkungen durchsetzen können.
Nichteinschränkende Beispiele für Fahrzeugsteuerelemente 112 können Funktionalität für Text zu Sprache (TTS), Funktionalität für Sprache zu Text (STT), Sprachsteuerelemente, Tastensteuerelemente (z. B. Lenkradtastensteuerelemente und/oder Mitte-Tastensteuerelemente) und Berührungsschirm-Tastensteuerelemente umfassen. Der Betrieb auf einem oder mehreren Fahrzeugmodulen 114 kann als Reaktion auf die Verwendung eines oder mehrerer Fahrzeugsteuerelemente 112 erreicht werden. Daten können über die Kommunikationsverbindung 115 zwischen den Fahrzeugsteuerelementen 112 und den Fahrzeugmodulen 115 gesendet werden. Bei einer Ausführungsform kann die Kommunikationsverbindung ein Fahrzeugnetzwerk 115 sein. Nichteinschränkende Beispiele für Fahrzeugmodule 114 wären Kraftübertragungs-Steuermodule (PCM), Body-Steuermodule (BCM), ABS-Steuermodule und dergleichen. Bei zusätzlichen der alternativen Ausführungsformen können Daten für hörbare, textliche und/oder grafische Ausgabe zu anderen Fahrzeugmodulen 114 gesendet werden. Diese können, aber ohne Beschränkung darauf, Folgendes umfassen: eine oder mehrere Anzeigen (darunter, aber ohne Beschränkung darauf, die Anzeige 4, (nicht gezeigte) Cluster-Schirmanzeigen oder (nicht gezeigte) rückseitige Unterhaltungsanzeigen, Lautsprecher 13 oder andere ähnliche Ausgabemodule in dem Fahrzeug 31.

Die API können vom OEM entwickelte APIs, von Dritten entwickelte APIs und/oder offene APIs sein. Offene APIs sind, wie in der Technik bekannt ist, APIs, die Interkonnektivität zwischen Websites (z. B. Websites der sozialen Vernetzung) gestatten. Nichteinschränkende Beispiele für APIs und ihre nichteinschränkenden Funktionen, die auf dem VCS 1 installiert sein können, sind in der nachfolgenden Tabelle 2 aufgeführt. Tabelle 2

API	Beschreibung/Funktion
Fahrzeugdialog	Dialog durch Fahrzeugnetzwerkschnittstellenschicht; Dialog mit dem Fahrzeugnetzwerk (z. B. CAN); Diagnostiksysteme, GPS; Zeitgeber; Personalisierung.
Anzeige	Menüdialog; grafischer Widget-Dialog; Dialog mit Tasten; Zugang zu Anzeigeeigenschaften.
Audio	Dialog mit einer Text-zu-Sprache(TTS)Engine; Dialog mit einem Spracherkennungsmodul; Zugang zu Mikrofon-Audiostrom; Digitalaudiowiedergabe; Audiodatei-Push für Wiedergabe.
VCS-Systemverwaltung	Ereignisregistration und Benachrichtigungseinrichtungen; interner Datenbankzugang zu Transienten und persistenten Daten (z. B. Medien- und Telefondatenbanken); zu Systemzustands- und Anwendungszustandsinformationen.
Systemadministration	Erweiterungen zur Bereitstellung von Funktionalität für verschiedene Merkmale des VCS; Sprachenauswahl und Internationalisierung; System konfigurationsparameter; Zugang zu Flash- und externen Dateisystemen.
Vernetzung	Vorgabe-Socket-Zugang, Vernetzungszugang; Ereignisse in Bezug auf Netzwerkverfügbarkeit

4 ist ein Blockdiagramm des Dialogs zwischen den Einrichtungen 102a-f und dem VCS 1, so dass die Anwendungen 103a-f von dem VCS 1 aus betrieben werden können. Die Kommunikation zwischen den Einrichtungen 102a-f und dem VCS 1 kann über beliebige Kommunikationskanäle erfolgen, die jetzt oder später bekannt sind. Der Veranschaulichung und Klarheit halber zeigt 4 jedoch eine über BLUETOOTH 301a, kommunizierende Einrichtung, eine über USB 301b kommunizierende Einrichtung und eine über WiFi 301c kommunizierende Einrichtung. Ferner versteht sich, dass die Kommunikation zwischen einer oder mehreren Einrichtungen erfolgen kann.
Wie oben beschrieben kann bei einer Ausführungsform dieser Dialog in einer ad-hoc-Netzwerkumgebung stattfinden. Die Einrichtungen 103a-f können nach Einrichtungen suchen, mit denen verbunden werden kann, (Block 300). In diesem Fall kann die Einrichtung das VCS 1. Die Suche kann für den Kommunikationskanal 104a-f der Einrichtung 102a-f spezifisch sein. Zum Beispiel und ohne Beschränkung kann eine BLUETOOTH-Einrichtung nach dem Namen des VCS 1 (z. B. „SYNC”) in dem BLUETOOTH-Netzwerk suchen. Dies kann bei dem Paarungsprozess durchgeführt werden. Als weiteres Beispiel kann eine WiFi-befähigte Einrichtung nach einer vordefinierten Internetprotokoll-(IP)-Adresse suchen. Die Einrichtung 102a-f kann eine Verbindungsanforderung (Block 304) zu dem VCS 1 senden. Das VCS 1 kann auf die Verbindungsanforderung von der Einrichtung 102a-f warten (Block 302).
Als Alternative kann das VCS 1 nach Einrichtungen 102a-f suchen, um eine Verbindung zu erzeugen. Bei dieser Ausführungsform können die Einrichtungen 102a-f nach einer Verbindungsanforderung von dem VCS 1 horchen.
Über die hergestellte Verbindung können Daten ausgetauscht werden. Der Kanal, über den die Verbindungsanforderung gesendet wird, kann von dem von der Einrichtung 102a-f benutzten Kommunikationskanal 104a-f abhängen. Als nichteinschränkendes Beispiel kann eine BLUETOOTH-Einrichtung einen SDP-Datensatz für einen SPP-Kanal, über den Daten zu übermitteln sind, publizieren. Als ein weiteres nichteinschränkendes Beispiel kann eine WiFi-Einrichtung die Verbindungsanforderung (Block 304) zu einem spezifischen Port senden, von dem aus das VCS 1 nach der ankommenden Verbindungsanforderung horchen kann und über den nach der Verbindung die Daten übermittelt werden können.
Nachdem eine Verbindung hergestellt ist, kann eine Sitzung (d. h. eine Anwendungsebenenverbindung) in der Einrichtung 102a-f beginnen (Block 306). Das VCS 1 kann auf die Sitzungsanforderung warten (Block 308) und die Sitzung annehmen (Block 310). Dann kann eine Sitzung erzeugt werden. Ferner kann das VCS 1 einen neuen Diensttyp zum Dialog mit der Anwendung über die Sitzung beginnen. Bei einer Ausführungsform können mehrere Sitzungen über dieselbe Einrichtungsebenenverbindung gemultiplext werden.
Wie in den Blöcken 312 bzw. 314 dargestellt, können die Anwendung 103a-f und das VCS 1 Fähigkeiten austauschen. Diese Fähigkeiten können die Betriebsmittel definieren, deren Verwendung das VCS 1 der Anwendung 103a-f gestatten kann. Von der Anwendungsperspektive aus gesehen können die Fähigkeiten die allgemeinen Fähigkeiten der Anwendung 103a-f definieren. Als nichteinschränkendes Beispiel können die Fähigkeiten, die von dem VCS 1 aus ausgetauscht werden können, Sprachenunterstützung, Anzeigetyp und GPS-Unterstützung umfassen. Andere nichteinschränkende Beispiele wären Fähigkeiten für bestimmte Funktionalität und eine Versionsebene VCS 1. Nichteinschränkende Beispiele für Fähigkeiten, die durch die Anwendung 103a-f ausgetauscht werden können, können die Fähigkeit zur Unterstützung von GPS, Fahrzeugdaten und Medienanwendungen umfassen. Anwendungsfähigkeiten können auch die Version des VCS 1 umfassen, die sie unterstützt. Bei einer Ausführungsform kann das VCS 1 auch seine Fähigkeiten anderen Einrichtungen 102a-f publizieren, die sich in dem Netzwerk befinden können (Block 316).
Die Einrichtung 102a-f und das VCS 1 können Daten senden und empfangen (Block 318 und Block 320). Die Daten können zwischen der Einrichtung 102a-f und dem VCS 1 als RPCs oder Bulk-Daten ausgetauscht werden. Es versteht sich, dass die Art des Datenaustauschs ein Beispiel ist und andere Verfahren zum Datenaustausch benutzt werden können, ohne von dem Gedanken und Schutzumfang der verschiedenen Ausführungsformen abzuweichen.
Wie in Block 322 bzw. 324 dargestellt, können die Einrichtung 102a-f und das VCS 1 eine Sitzung abschließen oder terminieren. Die Sitzung(en) kann bzw. können zu einem beliebigen Zeitpunkt während des Datenaustauschprozesses terminieren.
6 zeigt eine Operation zum Erzeugen und Senden eines Datenpakets zum Transport unter Verwendung des Datentransportprotokolls, nachdem eine Verbindung und Sitzung hergestellt wurden. Im Block 400 kann die Anwendung 103a-f eine Anforderung zum Betrieb der Anwendung senden. Die Anforderung kann in dem VCS 1 empfangen werden. Ferner kann der Kommunikationskanal 104a-f empfangen werden, über den die Sitzung hergestellt wurde (Block 402). Wie im Block 404 dargestellt, kann bestimmt werden, ob die Nutzinformationen größer als die MTU sind. Wenn dem so ist, können die Daten segmentiert (Block 406) und die segmentierte Datennachricht zusammengestellt (Block 408) werden. Wenn nicht, kann eine unsegmentierte Datennachricht zusammengestellt werden (Block 410).
Im Block 412, kann die Nachricht zu einer Warteschlange hinzugefügt werden, die dem Diensttyp entspricht, der aus der von der Anwendung 103a-f gesendeten Nachricht identifiziert wird. Bei einer Ausführungsform kann ein Sitzungs-Heartbeat-Timer ausgelöst oder aktiviert werden, um zu prüfen, dass eine aktive Sitzung vorliegt (Block 414). Wie im Block 416 dargestellt, kann der Status der Sitzung auf der Basis des Heartbeat zurückgegeben werden.
7 zeigt einen nichteinschränkenden Betrieb des Prioritätsschemas, das von dem Datentransportprotokoll verwendet wird, um zu bestimmen, welchem Diensttyp Priorität gegeben wird. Um Block 500 wird der auszuführende Dienst (oder die auszuführende Aufgabe) auf der Basis von Benutzeranweisungen von der Einrichtung 102a-f empfangen. Der Dienst kann auf der Basis der Nachricht/Anweisungen von der Anwendung 103a-f empfangen werden. Der Prioritätswert bzw. die Prioritätswerte kann bzw. können in dem Datentransportprotokoll definiert werden (Block 502). Die Prioritäten können in das Datentransportprotokoll vorprogrammiert werden. Zum Beispiel können die Prioritätswerte definieren, welchem Dienst maximale Priorität, dazwischenliegende Priorität und niedrigste Priorität gegeben wird. Als ein anderes nichteinschränkendes Beispiel kann der Prioritätswert nur einen einzigen Prioritätswert oder eine Gruppe der möglichen Prioritätswerte definieren (z. B. welchem Dienst maximale Priorität und welchem Dienst niedrigste Priorität gegeben wird).
Wie im Block 504 dargestellt, kann bestimmt werden, ob eine Warteschlange für irgendwelche der Dienste vorliegt. Jeder Dienst kann seine eigene Warteschlange aufweisen. Bei anderen Ausführungsformen können die verschiedenen Dienste zusammen in einer Warteschlange angeordnet werden (z. B. können sich der RPC- und Bulk-Dienst in einer Warteschlange befinden). Wenn die Warteschlange leer ist, kann eine weitere Bestimmung erfolgen, ob irgendwelche Dienste vorliegen (Block 506). Wenn dem so ist, wird der Dienst, der die nächste Priorität aufweist, untersucht, um den Status seiner Warteschlange zu bestimmen (Block 514). Der Status der Dienstwarteschlange kann bestimmt werden (Block 504). Wenn kein anderer Dienst existiert, kann der Prozess suspendiert werden (Block 510).
Wenn ein Dienst in die Warteschlange aufgenommen wird, kann die Nachricht von der Warteschlange empfangen werden (Block 508). Bei einer Ausführungsform kann der Abruf im FIFO-Prinzip erfolgen. Nachdem die Nachricht abgerufen ist, kann die Nachricht gesendet werden (Block 512). Als nichteinschränkendes Beispiel für dieses Prioritätsschema können mehrere HB und/oder eine RPC-Nachricht gesendet werden, während eine Bulk-Transportdatei läuft.
Obwohl oben beispielhafte Ausführungsformen dargestellt und beschrieben wurden, ist nicht beabsichtigt, dass diese Ausführungsformen alle Möglichkeiten darstellen und beschreiben. Stattdessen sind die in der Beschreibung verwendeten Wörter nicht Wörter der Beschränkung, sondern der Beschreibung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 7602782 [0003]

Claims

Verfahren zum Herstellen einer Schnittstelle zweier oder mehrerer Einrichtungen und eines Fahrzeugdatenverarbeitungssystems, mit den folgenden Schritten: Empfangen einer Anforderung von zwei oder mehr Einrichtungen sich mit einem Fahrzeugdatenverarbeitungssystem zu verbinden, wobei die zwei oder mehr Einrichtungen Daten unter Verwendung verschiedener Kommunikationsprotokolle übermitteln; Herstellen einer Verbindung mit den zwei oder mehr Einrichtungen auf Basis der Verbindungsanforderung; Bestimmen des Kommunikationsprotokolls der zwei oder mehr Einrichtungen; Verwendung eines allgemeinen Transportprotokolls in einem computerlesbaren Medium zum Übermitteln von Daten mit den zwei oder mehr Einrichtungen auf der Basis der jeweiligen Kommunikationsprotokolle auf das Kommunikationsprotokoll der zwei oder mehr Einrichtungen; Übermitteln von Daten mit den zwei oder mehr Einrichtungen auf der Basis des allgemeinen Transportprotokolls; und Ausführen eines Ereignisses in dem Fahrzeugdatenverarbeitungssystem oder den zwei oder mehr Einrichtungen auf der Basis der Daten.
Verfahren nach Anspruch 1, wobei die Verbindung eine gleichzeitige Verbindung ist.
Verfahren nach Anspruch 1, wobei das allgemeine Transportprotokoll gegenüber den Kommunikationsprotokollen der zwei oder mehr Einrichtungen transport-unabhängig ist.
Verfahren nach Anspruch 3, wobei die Kommunikationsprotokolle aus der Gruppe bestehend aus Internetprotokollen, BLUETOOTH-Protokollen, proprietären Protokollen, 802.11-Protokollen und Massenspeichereinrichtungsprotokollen ausgewählt werden.
Verfahren nach Anspruch 1, wobei die Daten Anweisungen zum Betrieb einer oder mehrerer auf den zwei oder mehr Einrichtungen installierter Anwendungsprogramme umfassen.
Verfahren nach Anspruch 5, ferner umfassend: Empfangen von Anwendungssitzungsinformationen über die Verbindung; Herstellen einer oder mehrerer Anwendungssitzungen über die Verbindung auf der Basis der Anwendungssitzungsinformationen.
Verfahren nach Anspruch 6, wobei mehrere Anwendungssitzungen über die Verbindung gemultiplext werden.
Verfahren nach Anspruch 1, wobei die Daten Anweisungen zum Ausführen des Ereignisses auf der Basis des einen oder der mehreren Diensttypen umfassen.
Verfahren nach Anspruch 8, wobei der Diensttyp ein Remote Procedure Call ist.
Verfahren nach Anspruch 8, wobei der Diensttyp ein Bulk-Transportdienst ist.
Verfahren nach Anspruch 8, wobei der Diensttyp Medien-Streaming ist.