-
TECHNISCHES GEBIET
-
Die vorliegende Erfindung betrifft Fahrzeuge und insbesondere zum Übertragen von Open-Source-Software(OSS)-Lizenzinformationen oder Material an Fahrzeugbesitzer oder sonstige Personen.
-
HINTERGRUND
-
Fahrzeuge beinhalten derzeit verschiedenste Fahrzeugsystemmodule (VSM) oder elektronische Steuervorrichtungen (ECU), die entweder einzeln oder gemeinsam OSS verwenden. OSS ist zunehmend in VSM oder ECU präsent, die verschiedene Aspekte des Fahrzeugbetriebs steuern. Im Gegensatz zu anderen Arten von Software ermöglicht OSS einem Fahrzeugbesitzer, die derzeit in den VSM vorhandene Software zu verwenden und gemäß den definierten Begriffen und Bedingungen zu ändern.
-
Jedoch kann der Fahrzeugbesitzer, der OSS anwendet oder diese verändert, u. U. die Begriffe und Bedingungen nicht kennen, die er oder sie zu befolgen hat. Oder der Fahrzeughalter weiß u. U. nicht, wo er eine Kopie der Lizenzbedingungen erhalten kann. Auch kann sich der Inhalt der OSS-Lizenzbedingungen ändern oder OSS kann dem Fahrzeug hinzugefügt oder aus ihm gelöscht werden. Neue OSS und zugehörige Lizenzinformationen können aus verschiedenen Gründen hinzugefügt werden wie der Einbeziehung neuer VSM oder ECU im Fahrzeug oder Ersatz vorhandener VSM oder ECU, die an dem Fahrzeug installiert sind. In der Vergangenheit mussten die Fahrzeugbesitzer, die nach Konformitätsinformationen für jede OSS suchten, bislang das Material auf unterschiedlichen Webseiten suchen, was es unwahrscheinlich macht, dass der Fahrzeugbesitzer bezüglich der Konformitätsinformationen und/oder Aktualisierungen der Konformitätsinformationen für alle OSS am Fahrzeug auf tagesaktuellem Wissensstand ist.
-
ZUSAMMENFASSUNG
-
Gemäß einer Ausführungsform der Erfindung wird ein Verfahren des Anzeigens von Open-Source-Software(OSS)-Konformitätsinformations-Material in einem Fahrzeug mit Fahrzeugelektronik bereitgestellt. Das Verfahren beinhaltet: das Empfangen einer Anforderung zum Anzeigen von OSS-Konformitätsinformationen; Zugreifen auf die OSS-Konformitätsinformationen aus einer Speichervorrichtung in der Fahrzeugelektronik; und das Anzeigen mindestens eines Teils der OSS-Konformitätsinformationen auf einer optischen Anzeige in dem Fahrzeug.
-
Gemäß einer weiteren Ausführungsform der Erfindung wird ein Verfahren des Anzeigens von Open-Source-Software(OSS)-Konformitätsinformationsmaterial in einem Fahrzeug bereitgestellt, das Empfangen von OSS-Konformitätsmaterial an einem Programmierungs-Mastermodul, das am Fahrzeug gespeichert ist, beinhaltet; Speichern des OSS-Konformitätsmaterials an einem oder mehreren Fahrzeugsystemmodul(en) (VSM) unter Verwendung des Programmierungs-Mastermoduls; Zugreifen auf das gespeicherte OSS-Konformitätsmaterial von einem oder mehreren der VSM; und Anzeigen mindestens eines Teils des OSS-Konformitätsmaterials auf einer Anzeige in dem Fahrzeug.
-
Gemäß noch einer weiteren Ausführungsform der Erfindung wird ein Verfahren des Anzeigens von Open-Source-Software(OSS)-Konformitätsmaterial in einem Fahrzeug bereitgestellt. Das Verfahren beinhaltet folgende Schritte: (A) Zugreifen auf mindestens einen Teil von OSS-Konformitätsmaterial gespeichert an einem oder mehreren Fahrzeugsystemmodulen (VSM); (b) Vergleichen des zugegriffenen OSS-Konformitätsmaterials an dem gespeicherten einen oder mehreren VSM mit entsprechendem OSS-Konformitätsmaterial in einer OSS-Konformitätsmaterial(OCM)-Bibliothek am Fahrzeug; (c) Bestimmen, dass das entsprechende OSS-Konformitätsmaterial in der OCM-Bibliothek anders ist als das zugegriffene OSS-Konformitätsmaterial an dem gespeicherten einen oder mehreren VSM; (d) Anfordern von aktualisiertem OSS-Konformitätsmaterial in Reaktion auf das Ermitteln; (e) Empfangen des aktualisierten OSS-Konformitätsmaterials; (f) Speichern des aktualisierten OSS-Konformitätsmaterials in der OCM-Bibliothek; und danach (g) als Antwort auf eine Anforderung Anzeigen von mindestens einigem des aktualisierten, in der OCM-Bibliothek gespeicherten OSS-Konformitätsmaterials auf einer optischen Anzeige in dem Fahrzeug.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
-
1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, die fähig ist, das hier offenbarte Verfahren zu verwenden;
-
2 ein Blockdiagramm ist, das eine Ausführungsform eines Teils der in 1 dargestellten Autoelektronik darstellt, die fähig ist, das hier offenbarte Verfahren zu verwenden;
-
3 ein Blockdiagramm ist, das eine andere Ausführungsform eines Teils der in 1 dargestellten Autoelektronik darstellt, die fähig ist, das hier offenbarte Verfahren zu verwenden;
-
4 ein Blockschaltbild ist, das eine Ausführungsform eines Verfahrens des Anzeigens von Open-Source-Software(OSS)-Konformitätsmaterial in einem Fahrzeug mit Fahrzeugelektronik darstellt.
-
DETAILLIERTE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)
-
Das nachfolgend beschriebene System und Verfahren speichert lokal Konformitätsmaterial für Open-Source-Software (OSS), die am Fahrzeug verwendet und dort auch angezeigt wird. Die Menge der mit OSS ausgestatteten Fahrzeuge nimmt zu und es kann schwierig für Fahrzeugbesitzer werden, die Begriffe und Bedingungen, unter denen die Software benutzt oder modifiziert werden darf, genau zu kennen. Oft werden unterschiedliche OSS-Pakete oder Produkte durch separate Geschäftseinheiten entwickelt. In der Vergangenheit musste, wenn ein Fahrzeugbesitzer Konformitätsmaterial für unterschiedliche OSS-Pakete erhalten wollte, der Fahrzeughalter zunächst die Softwarepakete identifizieren und den Hersteller des Softwarepaketes herausfinden und dann durch mindestens eine Website navigieren, um das Konformitätsmaterial für die OSS dieses Fahrzeugs zu finden.
-
Anstatt dem Fahrzeugbesitzer das Identifizieren und Navigieren für das Konformitätsmaterial auf Webseiten zu überlassen, kann das Fahrzeug aktuelle Versionen des Konformitätsmaterials für die OSS dieses Fahrzeugs verwalten. Auf Wunsch kann das Fahrzeug visuell das Konformitätsmaterial für die verschiedenen OSS, die in dem Fahrzeug verwendet werden, dem Fahrzeugbesitzer oder einem anderen Fahrzeuginsassen anzeigen. Auch kann die Verwaltung von OSS-Konformitätsmaterial (OCM) das Ermitteln der OSS, die von einem oder mehreren VSM oder anderer Fahrzeugelektronik verwendet wird, beinhalten und dann das Bestätigen, dass das im Fahrzeug verwaltete OCM die neueste Version ist. Je nach Implementierung kann das OCM an einer zentralen Berechnungsvorrichtung wie einer Fahrzeugtelematikeinheit oder einer Fahrzeuganzeige oder bei VSM selbst gespeichert werden. Wie aus der Beschreibung nachstehend ersichtlich ist, kann das OCM von einer Vielzahl von Quellen einschließlich Remote-Vorrichtungen erhalten werden, die mit dem Fahrzeug sowie Service-Zentren drahtlos kommunizieren können, die Wartung wie etwa Ölwechsel und andere Fahrzeugwartungen bereitstellen.
-
Kommunikationssystem –
-
Mit Bezug auf 1 ist eine Betriebsumgebung gezeigt, die ein mobiles Fahrzeugkommunikationssystem 10 umfasst, das verwendet werden kann, um die hier offenbarten Verfahren zu auszuführen. Das Kommunikationssystem 10 beinhaltet im Allgemeinen ein Fahrzeug 12, ein oder mehrere Drahtlosträgersysteme 14, ein Festnetz 16, einen Computer 18 und ein Call-Center 20. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl von unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hier gezeigte Betriebsumgebung einschränkt ist. Auch die Architektur, Konstruktion, Konfiguration und der Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hier nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.
-
Fahrzeug 12 ist in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug einschließlich Motorräder, Lastwagen, Geländewagen (SUV), Campingfahrzeuge (RV), Wasserfahrzeuge, Flugzeuge usw. ebenfalls verwendet werden kann. Etwas von der Fahrzeugelektronikhardware 28 ist generell in 1 gezeigt und umfasst eine Telematikeinheit 30, ein Mikrofon 32, eine oder mehrere Tasten oder andere Steuereingänge 34, ein Audiosystem 36, eine optische Anzeige 38 und ein GPS-Modul 40 sowie eine Anzahl von Fahrzeugsystemmodulen (VSM) 42. Einige dieser Vorrichtungen können direkt mit der Telematikeinheit wie z. B. Mikrofon 32 und der bzw. den Tasten 34 verbunden sein, während andere indirekt unter Verwendung einer oder mehrerer Netzwerkverbindungen wie einem Kommunikationsbus 44 oder einem Entertainmentbus 46 verbunden sind. Beispiele geeigneter Netzwerkverbindungen beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen wie z. B. Ethernet oder andere, die u. a. den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen.
-
Die Telematikeinheit 30 kann eine OEM-installierte (eingebettete) oder eine Aftermarketvorrichtung sein, die in dem Fahrzeug installiert ist und drahtlose Sprach- und/oder Datenkommunikation über das Mobilfunkanbietersystem 14 und über drahtlose Vernetzung ermöglicht. Dies ermöglicht, dass das Fahrzeug mit Call-Center 20, anderen telematikfähigen Fahrzeugen oder einer anderen Entität oder Vorrichtung kommunizieren kann. Die Telematikeinheit verwendet bevorzugt Funkübertragungen, um einen Kommunikationskanal (einen Sprachkanal und/oder einen Datenkanal) mit dem drahtlosen Trägerfrequenzsystem 14 herzustellen, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und empfangen werden können. Durch Bereitstellen von sowohl Sprach- als auch Datenkommunikation ermöglicht die Telematikeinheit 30, dass das Fahrzeug eine Anzahl von unterschiedlichen Diensten anbieten kann, die diejenigen beinhalten, die mit Navigation, Fernsprechen, Nothilfe, Diagnose, Infotainment usw. verbunden sind. Daten können entweder über eine Datenverbindung, wie über Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal unter Verwendung von auf dem Fachgebiet bekannten Techniken, gesendet werden. Für kombinierte Dienste, die sowohl Sprachkommunikation (z. B. mit einem Live-Berater oder einer Sprachausgabeeinheit im Call-Center 20) als auch Datenkommunikation (z. B., um GPS-Ortsdaten oder Fahrzeugdiagnosedaten an den Call-Center 20 bereitzustellen) einschließen, kann das System einen einzelnen Anruf über einen Sprachkanal verwenden und nach Bedarf zwischen Sprach- und Datenübertragung über den Sprachkanal umschalten, und dies kann unter Verwendung von Techniken erfolgen, die dem Fachmann bekannt sind.
-
Gemäß einer Ausführungsform verwendet die Telematikeinheit 30 Mobilfunkkommunikation gemäß entweder den GSM-, CDMA- oder LTE-Standards und beinhaltet daher einen Mobilfunkstandardchipsatz 50 für die Sprachkommunikation wie Freisprechen ein drahtloses Modem für die Datenübertragung, ein elektronisches Verarbeitungsgerät 52, eine oder mehrere Digitalspeichervorrichtungen 54 und eine Dual-Antenne 56. Es versteht sich, dass das Modem entweder durch Software implementiert sein kann, die in der Telematikeinheit gespeichert und durch den Prozessor 52 ausgeführt wird, oder es kann eine separate Hardwarekomponente sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden kann. Das Modem kann mithilfe einer beliebigen Anzahl unterschiedlicher Standards oder Protokolle wie z. B. LTE, EVDO, CDMA, GPRS und EDGE betrieben werden. Die drahtlose Vernetzung zwischen dem Fahrzeug und den anderen vernetzten Vorrichtungen kann auch unter Verwendung der Telematikeinheit 30 erfolgen. Für diesen Zweck kann die Telematikeinheit 30 konfiguriert sein, gemäß einem oder mehreren Protokollen drahtlos zu kommunizieren einschließlich drahtloser Nahbereichskommunikation (SRWC), wie irgendwelche von den IEEE 802.11-Protokollen, WiMAX, ZigBeeTM, Wi-Fi direct, Bluetooth oder Nahfeldkommunikation (NFC). Wenn die Telematikeinheit für paketvermittelte Datenkommunikation wie TCP/IP verwendet wird, kann sie mit einer statischen IP-Adresse konfiguriert oder eingerichtet werden, automatisch eine zugewiesene IP-Adresse von einer anderen Vorrichtung am Netzwerk, wie einem Router oder einem Netzwerkadressenserver, zu empfangen.
-
Der Prozessor 52 kann jede Geräteart sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Er kann ein speziell dafür vorgesehener Prozessor sein, der nur für die Telematikeinheit 30 verwendet wird, oder er kann mit anderen Fahrzeugsystemen geteilt werden. Der Prozessor 52 führt verschiedene Arten von digital gespeicherten Befehlen aus, wie Software- oder Firmwareprogramme, die im Speicher 54 gespeichert sind, welche der Telematikeinheit ermöglichen, eine große Vielfalt von Diensten bereitzustellen. Zum Beispiel kann der Prozessor 52 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des Verfahrens auszuführen, das hierin beschrieben ist.
-
Die Telematikeinheit 30 kann verwendet werden, um eine vielfältige Palette von Fahrzeugdiensten bereitzustellen, die drahtlose Kommunikation zu und/oder von dem Fahrzeug beinhalten. Derartige Dienste beinhalten: Wegbeschreibungen und andere navigationsbezogene Dienste, die in Verbindung mit dem GPS-basierten Fahrzeugnavigationsmodul 40 bereitgestellt sind; Airbagauslösungsbenachrichtigung und andere mit Notruf oder Pannendienst verbundene Dienste, die in Verbindung mit einem oder mehreren Crashsensorschnittstellenmodulen, wie einem Fahrzeugbeherrschbarkeitsmodul (nicht gezeigt), bereitgestellt sind; Diagnosemeldungen unter Verwendung von einem oder mehreren Diagnosemodulen; und mit Infotainment verbundene Dienste, wobei Musik, Internetseiten, Filme, Fernsehprogramme, Videospiele und/oder andere Informationen durch ein Infotainmentmodul (nicht gezeigt) heruntergeladen und für die gegenwärtige oder spätere Wiedergabe gespeichert werden. Die oben aufgelisteten Dienste sind keineswegs eine vollständige Liste aller Fähigkeiten der Telematikeinheit 30, sondern sie sind einfach eine Aufzählung von einigen der Dienste, die die Telematikeinheit anbieten kann. Des Weiteren versteht es sich, dass mindestens einige der vorstehend genannten Module in Form von Softwarebefehlen implementiert sein könnten, die innerhalb oder außerhalb der Telematikeinheit 30 gespeichert sind, sie könnten Hardwarekomponenten sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden, oder sie könnten integriert sein und/oder miteinander oder mit anderen Systemen geteilt zu sein, die sich im Fahrzeug befinden, um nur einige Möglichkeiten zu nennen. Für den Fall, dass die Module als VSM 42 implementiert sind, die sich außerhalb der Telematikeinheit 30 befinden, könnten sie den Fahrzeugbus 44 verwenden, um Daten und Befehle mit der Telematikeinheit auszutauschen.
-
Das GPS-Modul 40 empfängt Funksignale von einer Konstellation 60 von GPS-Satelliten. Von diesen Signalen kann das Modul 40 die Fahrzeugposition bestimmen, die verwendet wird, um Navigation und andere mit der Position verbundene Dienste an den Fahrzeugführer bereitzustellen. Navigationsinformationen können auf der Anzeige 38 (oder einer anderen Anzeige innerhalb des Fahrzeugs) dargestellt oder in verbaler Form präsentiert werden, wie es beispielsweise bei der Wegbeschreibungsnavigation der Fall ist. Die Navigationsdienste können unter Verwendung von einem zugehörigen Fahrzeugnavigationsmodul (das Teil des GPS-Moduls 40 sein kann) bereitgestellt werden, oder einige oder alle Navigationsdienste können über die Telematikeinheit 30 erfolgen, wobei die Positionsinformationen zum Zweck des Ausstattens des Fahrzeugs mit Navigationskarten, Kartenanmerkungen (Sehenswürdigkeiten, Restaurants usw.), Routenberechnungen und dergleichen zu einem entfernten Standort gesendet werden. Die Positionsinformationen können an das Call-Center 20 oder ein anderes Remotecomputersystem wie Computer 18 für andere Zwecke wie Flottenmanagement bereitgestellt werden. Außerdem können neue oder aktualisierte Kartendaten zu dem GPS-Modul 40 von dem Call-Center 20 über die Telematikeinheit 30 heruntergeladen werden.
-
Abgesehen von dem Audiosystem 36 und dem GPS-Modul 40 kann das Fahrzeug 12 andere Fahrzeugsystemmodule (VSM) 42 in der Form von elektronischen Hardwarekomponenten beinhalten, die sich im Fahrzeug befinden und typischerweise eine Eingabe von einem oder mehreren Sensoren empfangen und die erfassten Eingaben verwenden, um Diagnose, Überwachung, Steuerung, Berichterstattung und/oder andere Funktionen auszuführen. Jedes der VSM 42 ist bevorzugt durch den Kommunikationsbus 44 mit den anderen VSM sowie der Telematikeinheit 30 verbunden und kann programmiert werden, Fahrzeugsystem- und Subsystemdiagnosetests auszuführen. So kann beispielsweise ein VSM 42 ein Motorsteuermodul (ECM) sein, das verschiedene Aspekte des Motorbetriebs, wie z. B. Kraftstoffzündung und Zündzeitpunkt steuert, ein weiteres VSM 42 kann ein Antriebsstrangsteuermodul sein, das den Betrieb von einer oder mehreren Komponenten des Fahrzeugantriebsstrangs reguliert, und ein weiteres VSM 42 kann ein Bordnetzsteuermodul sein, das verschiedene im Fahrzeug befindliche elektrische Komponenten wie beispielsweise die Zentralverriegelung des Fahrzeugs und die Scheinwerfer verwaltet. Gemäß einer Ausführungsform ist das Motorsteuergerät mit integrierten Diagnose(OBD)-Funktionen ausgestattet, die unzählige Echtzeitdaten, wie z. B. die von verschiedenen Sensoren, einschließlich Fahrzeugemissionssensoren empfangene Daten bereitstellen, und eine standardisierte Reihe von Diagnosefehlercodes (DTCs) liefern, die einem Techniker ermöglichen, Fehlfunktionen innerhalb des Fahrzeugs schnell zu identifizieren und zu beheben. VSM 42 kann einen Mikroprozessor, eine Speichervorrichtung, Eingangs- und Ausgangsanschlüsse, einen Kommunikationsbus und ein Gehäuse wie in der Technik bekannt beinhalten. Die Speichervorrichtung der VSM sowie jede beliebige andere hier beschriebene Speichervorrichtung kann eine nicht flüchtige Speichervorrichtung wie eine nicht flüchtige Speichervorrichtung sein, die in der Lage ist, die gespeicherten Daten und/oder Firmware oder andere Software in der Vorrichtung selbst bei Fehlen von Betriebsstrom aufrechtzuhalten. Der Begriff VSM kann auch auswechselbar als eine elektronische Steuerung (ECU) bezeichnet werden. Sachverständige auf dem Fachgebiet werden erkennen, dass es sich bei den vorgenannten VSM nur um Beispiele von einigen der Module handelt, die im Fahrzeug 12 verwendet werden können, zahlreiche andere Module jedoch ebenfalls möglich sind.
-
Die Fahrzeugelektronik 28 beinhaltet auch eine Anzahl von Fahrzeugbenutzeroberflächen, die Fahrzeuginsassen mit einem Mittel zum Bereitstellen und/oder Empfangen von Informationen einschließlich Mikrofon 32, Taste(n) 34, Audiosystem 36 und optischer Anzeige 38 ausstattet. Wie hier verwendet, beinhaltet der Begriff „Fahrzeugbenutzeroberfläche” weitgehend jede geeignete Form von elektronischer Vorrichtung, die sowohl die im Fahrzeug befindlichen Hardware- als auch Softwarekomponenten beinhaltet und einem Fahrzeugbenutzer ermöglicht, mit einer oder durch eine Komponente des Fahrzeugs zu kommunizieren. Das Mikrofon 32 stellt eine Audioeingabe an die Telematikeinheit bereit, um dem Fahrer oder anderen Insassen zu ermöglichen, Sprachsteuerungen bereitzustellen und Freisprechen über das Mobilfunkanbietersystem 14 auszuführen. Für diesen Zweck kann es mit einer integrierten automatischen Sprachverarbeitungseinheit verbunden sein, welche die unter Fachleuten auf dem Gebiet bekannte Mensch-Maschinen-Schnittstellen(HMI)-Technologie verwendet. Die Taste bzw. Tasten 34 ermöglichen eine manuelle Benutzereingabe in die Telematikeinheit 30, um drahtlose Telefonanrufe zu initiieren und andere Daten, Antworten oder eine Steuereingabe bereitzustellen. Separate Tasten können zum Initiieren von Notrufen gegenüber regulären Dienstunterstützungsanrufen beim Call-Center 20 verwendet werden. Das Audiosystem 36 stellt eine Audioausgabe an einen Fahrzeuginsassen bereit und kann ein zugehöriges selbstständiges System oder Teil des primären Fahrzeugaudiosystems sein. Gemäß der bestimmten Ausführungsform, die hier gezeigt ist, ist das Audiosystem 36 operativ sowohl mit dem Fahrzeugbus 44 als auch mit dem Entertainmentbus 46 gekoppelt und kann AM-, FM- und Satellitenradio, CD-, DVD- und andere Multimediafunktionalität bereitstellen. Diese Funktionalität kann in Verbindung mit dem vorstehend beschriebenen Infotainmentmodul oder davon unabhängig bereitgestellt werden.
-
Die optische Anzeige 38 ist ein VSM, das eine Grafikanzeige wie z. B. ein Berührungsbildschirm am Armaturenbrett oder eine Warnanzeige, die von der Frontscheibe reflektiert wird und verwendet werden kann, um eine Vielzahl von Eingabe- und Ausgabefunktionen bereitzustellen. Die optische Anzeige 38 kann einen oder mehrere Mikroprozessoren, Speichergeräte, Kommunikationsbusse, Eingangs-/Ausgangsanschlüsse und/oder eine Antenne wie Fachleuten bekannt beinhalten. Die optische Anzeige 38 auch als ein Mitten-Stapel-Modul oder Infotainment-Kopf-Einheit (IHU) bezeichnet werden, das Inhalte in Form von Software, Konformitätsmaterial oder Medienprogrammierung über den Entertainmentbus 44 oder eine Antenne ähnlich der Antenne 56, die von der Fahrzeug-Telematikeinheit 30 benutzt wird, die kurzreichweitige drahtlose Kommunikation ausführen kann. Die optische Anzeige 38 kann dann die empfangenen Medien im Fahrzeug präsentieren oder mit den VSM 42 zum Kommunizieren von Software/Konformitätsmaterial mit den VSM 42 oder der Fahrzeug-Telematikeinheit 30 kommunizieren. in einigen Ausführungsformen kann die optische Anzeige 38 OSS und OCM in seiner eigenen Speichervorrichtung anstatt oder zusätzlich zum Senden der OSS/des OCM auf andere Teile der Fahrzeugelektronik 28 speichern.
-
Verschiedene andere Fahrzeugbenutzeroberflächen können ebenfalls verwendet werden, da die Schnittstellen von 1 nur ein Beispiel einer bestimmten Implementierung sind.
-
Das Mobilfunkanbietersystem 14 ist bevorzugt ein Mobiltelefonsystem, das mehrere Mobilfunkmasten 70 (nur einer gezeigt), eine oder mehrere mobile Vermittlungszentralen (MSC) 72 sowie irgendwelche anderen Netzwerkkomponenten umfasst, die erforderlich sind, um das Mobilfunkanbietersystem 14 mit dem Festnetz 16 zu verbinden. Jeder Mobilfunkturm 70 beinhaltet Sende- und Empfangsantennen und eine Basisstation, wobei die Basisstationen von unterschiedlichen Mobilfunktürmen mit der MSC 72 entweder direkt oder über zwischengeschaltete Geräte, wie z. B. eine Basisstationssteuereinheit, verbunden sind. Das Zellensystem 14 kann jede geeignete Kommunikationstechnik implementieren, die beispielsweise, analoge Technologien wie AMPS oder die neueren Digitaltechnologien wie CDMA (z. B. CDMA2000) oder GSM/GPRS umfasst. Der Fachmann wird erkennen, dass verschiedene Mobilfunkmast/Basisstation/MSC-Anordnungen möglich sind und mit dem drahtlosen System 14 verwendet werden könnten. Zum Beispiel könnten sich Basisstation und Mobilfunkturm an derselben Stelle oder entfernt voneinander befinden, jede Basisstation könnte für einen einzelnen Mobilfunkturm zuständig sein oder eine einzelne Basisstation könnte verschiedene Mobilfunktürme bedienen und verschiedene Basisstationen könnten mit einer einzigen MSC gekoppelt werden, um nur einige der möglichen Anordnungen zu nennen.
-
Abgesehen von dem Verwenden des Drahtlosträgersystems 14 kann ein unterschiedliches Drahtlosträgersystem in der Form von Satellitenkommunikation verwendet werden, um unidirektionale oder bidirektionale Kommunikation mit dem Fahrzeug bereitzustellen. Dies kann unter Verwendung von einem oder mehreren Fernmeldesatelliten 62 und einer aufwärtsgerichteten Sendestation 64 erfolgen. Bei der unidirektionalen Kommunikation kann es sich beispielsweise um Satellitenradiodienste handeln, wobei programmierte Inhaltsdaten (Nachrichten, Musik usw.) von der Sendestation 64 empfangen werden, für das Hochladen gepackt und anschließend zum Satelliten 62 gesendet werden, der die Programmierung an die Teilnehmer ausstrahlt. Bidirektionale Kommunikation kann beispielsweise Satellitentelefoniedienste unter Verwendung der Satelliten 62 sein, um Telefonkommunikationen zwischen dem Fahrzeug 12 und der der Station 64 weiterzugeben. Bei Verwendung kann dieses Satellitenfernsprechen entweder zusätzlich zu dem oder anstatt des drahtlosen Trägerfrequenzsystems 14 verwendet werden.
-
Das Festnetz 16 kann ein konventionelles landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 14 mit dem Call-Center 20 verbindet. So kann beispielsweise das Festnetz 16 ein Fernsprechnetz (PSTN) wie dasjenige sein, das verwendet wird, um festverdrahtetes Fernsprechen, paketvermittelte Datenkommunikationen und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 16 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, von Stromleitungen, anderen drahtlosen Netzwerken wie drahtlose lokale Netzwerke (WLAN) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon implementiert sein. Des Weiteren muss das Call-Center 20 nicht über das Festnetz 16 verbunden sein, sondern könnte Funktelefonieausrüstung beinhalten, sodass er direkt mit einem drahtlosen Netzwerk wie dem Drahtlosträgersystem 14 kommunizieren kann.
-
Der Computer 18 kann einer von einer Anzahl von Computern sein, die über ein privates oder öffentliches Netzwerk wie das Internet zugänglich sind. Jeder solche Computer 18 kann für einen oder mehrere Zwecke, wie einen Webserver verwendet werden, der von dem Fahrzeug über die Telematikeinheit 30 und das Drahtlosträgersystem 14 zugänglich ist. Andere solche zugängliche Computer 18 können beispielsweise sein: Ein Kundendienstzentrumcomputer, wo Diagnoseinformationen und andere Fahrzeugdaten von dem Fahrzeug über die Telematikeinheit 30 hochgeladen werden können; ein Clientcomputer, der von dem Fahrzeugbesitzer oder einem anderen Teilnehmer für solche Zwecke wie das Zugreifen auf oder Empfangen von Fahrzeugdaten oder zum Einstellen oder Konfigurieren von Teilnehmerpräferenzen oder Steuern von Fahrzeugfunktionen verwendet wird; oder ein Drittparteispeicherort, zu dem oder von dem Fahrzeugdaten oder andere Informationen entweder durch Kommunizieren mit dem Fahrzeug 12 oder dem Call-Center 20 oder beiden bereitgestellt werden. Ein Computer 18 kann auch für das Bereitstellen von Internetkonnektivität wie DNS-Dienste oder als ein Netzwerkadressenserver verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 12 eine IP-Adresse zuzuweisen.
-
Das Call-Center 20 ist konzipiert, die Fahrzeugelektronik 28 mit einer Anzahl von unterschiedlichen System-Back-End-Funktionen bereitzustellen, und beinhaltet nach dem hier gezeigten Ausführungsbeispiel im Allgemeinen einen oder mehrere Switches 80, Server 82, Datenbanken 84, Live-Berater 86 sowie ein automatisiertes Sprachausgabesystem (VRS) 88, die alle auf dem Fachgebiet bekannt sind. Diese verschiedenen Komponenten des Call-Centers sind bevorzugt miteinander über ein verdrahtetes oder drahtloses lokales Netzwerk 90 gekoppelt. Der Switch 80, der ein Nebenstellenanlagen(PBX)-Switch sein kann, leitet eingehende Signale weiter, sodass Sprachübertragungen gewöhnlich entweder zu dem Live-Berater 86 über das reguläre Telefon oder automatisiert zu dem Sprachausgabesystem 88 unter Verwendung von VoIP gesendet werden. Das Live-Berater-Telefon kann auch VoIP verwenden, wie angezeigt, durch die gestrichelte Linie in 1. VoIP und andere Datenkommunikation durch den Switch 80 werden über ein Modem (nicht gezeigt) implementiert, das zwischen dem Schalter 80 und Netzwerk 90 verbunden ist. Datenübertragungen werden über das Modem zu dem Server 82 und/oder der Datenbank 84 weitergegeben. Die Datenbank 84 kann Kontoinformationen wie Teilnehmerauthentisierungsinformationen, Fahrzeugbezeichner, Profilaufzeichnungen, Verhaltensmuster und andere entsprechende Teilnehmerinformationen speichern. Datenübertragungen können auch durch drahtlose Systeme wie z. B. 802.11x, GPRS und dergleichen erfolgen. Obwohl die veranschaulichte Ausführungsform beschrieben wurde, als ob sie in Verbindung mit einem bemannten Call-Center 20 verwendet werden würde, das den Live-Berater 86 einsetzt, ist es offensichtlich, dass das Call-Center stattdessen VRS 88 als einen automatisierten Berater verwenden kann, oder eine Kombination von VRS 88 und dem Live-Berater 86 verwendet werden kann.
-
Die Open-Source-Software (OSS) und die OSS-Konformitätsmaterialien (OCM), die im Fahrzeug bereitgestellt werden, können als ein Teil der ersten Herstellung oder bei der Konfiguration des Fahrzeugs vor der Auslieferung an den Kunden eingebaut werden. Mindestens einige der OSS und OCM können anschließend an das Fahrzeug über hinzugefügte oder aufgewertete Fahrzeugsystemmodule (VSM) oder über Software- oder Firmware-Aktualisierungen oder nur als OCM-Daten-Aktualisierungen bereitgestellt werden. Dies geschieht in einigen Implementierungen durch Herunterladen auf das Fahrzeug von einem Remotecomputer wie Computer 18 oder von einem Rechner im Call-Center 20. Dieses Herunterladen geschieht über die Telematikeinheit 30 über das Drahtlosträgersystem 14 und eingeleitet werden im Fahrzeug, am Call-Center oder durch eine andere Anforderung oder Backend-Office-Verfahren.
-
Bezüglich 2 wird ein Teil der Fahrzeugelektronik 28 dargestellt, die verwendet werden kann, um eine Ausführungsform eines Verfahrens 200 des Anzeigens von Open-Source-Software(OSS)-Konformitätsmaterial (OCM) im Fahrzeug 12 auszuführen. OSS kann Implementierungen der offenen Firmware oder anderer Software-Anwendungen beinhalten, die frei verfügbar sind oder aus offenen Quellen stammen. Beispiele für unterschiedliche offene Firmware-Anwendungen beinhalten die Open-Source-Software, die durch das OpenBIOS Projekt gebildet wurde.
-
Generell gesprochen beinhaltet OSS Computersoftware, in der der Softwareprogrammierer eine Benutzerlizenz an einen Benutzer vergeben hat, die die OSS für freie Verwendung, Verteilung oder Veränderung durch einen Benutzer erklärt. Die OCM kann als OCM-Dateien gespeichert werden und kann den Gehalt der dem Benutzer für eine bestimmte OSS-Anwendung in Textformat erteilten Lizenz beinhalten. Die OCM kann eine Anzahl von Datenfeldern beinhalten, die: die OSS, den Besitzer der OSS, die Versionsnummer der Software, das Software-Ausgabedatum, Datei Größe, die Bedingungen identifizieren, unter denen der Benutzer die OSS verwenden darf sowie weitere Informationen zur OSS. In einigen Implementierungen können die Identität der OSS, der Besitzer der OSS, die Versionsnummer der Software, das Software-Ausgabedatum und die Dateigröße in den OCM-Metadaten einzelner OCM-Dateien beinhaltet sein, die die Bedingungen der OSS-Verwendung beinhalten. Die OCM-Metadaten können in den OCM-Dateien enthalten oder separat gespeichert sein und die OCM-Metadaten und/oder die OCM-Dateien können in der OSS enthalten oder als separate Dateien gespeichert sein.
-
Die Größe der OCM-Dateien kann je nach der Größe des Konformitätsmaterials für die Darstellung im Fahrzeug 12 und dem Teil der Fahrzeugelektronik 28 variieren, die die OCM unter Verwendung der OSS beschreibt. Bestimmte Elemente können mehr OSS als andere verwenden und der Anteil von OCM, das der größeren Menge OSS zugeordnet ist, kann ebenso größer sein. Die optische Anzeige 38 kann eine große Anzahl von Multimediafunktionen und als Teil dieser zusätzlichen Eigenschaften eine größere Menge OSS und OCM als andere VSM 42 aufweisen wie Karosserie-Steuervorrichtungen und Motorsteuermodule, die für weniger Fahrzeugfunktionen verantwortlich sind. In einer Implementierung kann die OCM-Dateigröße für die verwendete OSS an der optischen Anzeige 38 1,3 Megabytes (MB) unkomprimiert und 83 Kilobyte (KB) komprimiert betragen, während ein weiteres VSM 42 eine OCM-Dateigröße von 231 KB unkomprimiert und 23 KB komprimiert verwenden kann.
-
Das Verfahren 200 kann durch das Fahrzeug 12 ausgeführt werden. Es beginnt bei Schritt 210 durch Empfangen am Fahrzeug 12 einer Anforderung zum Anzeigen von OSS-Konformitätsmaterial (OCM). Ein Fahrzeuginsasse (d. h. ein Fahrzeugbenutzer wie ein Fahrer oder Eigentümer) kann die Anforderung durch Navigieren durch eine oder mehrere Menüoptionen starten, die auf der optischen Anzeige 38 angezeigt werden kann, bis er eine Auswahl sieht, die dem Fahrzeugbenutzer der Möglichkeit der Ansicht von OCM bietet. Der Fahrzeugbenutzer kann die Möglichkeit durch Drücken des Knopfes 34 oder alternativ Auswählen der Möglichkeit über einen Berührungsbildschirm auf der optischen Anzeige 38 auswählen. Es sollte beachtet werden, dass die Anforderung zum Anzeigen von OCM mittels einer anderen Quelle als ein Fahrzeugbesitzer veranlasst werden kann. Beispielsweise kann die optische Anzeige 38 programmiert werden, um periodisch die OCM an dem Fahrzeug 12 oder in Antwort auf eine Änderung des Gehalts an OCM, die in dem gespeicherten Fahrzeug 12, gespeichert ist, anzuzeigen. Die Addition oder Subtraktion von OSS am Fahrzeug 12 kann dann den Inhalt des in dem Fahrzeug 12 gespeicherten OCM verändern. Der Service, den beispielweise das Fahrzeug 12 erhalten hat, kann Ersetzen, Zufügen oder Entfernen eines der VSM 42 beinhalten. Eine Änderung der VSM 42 kann auch eine Änderung der OSS der VSM 42 bedeuten. So kann das Fahrzeug 12 eine Anforderung zum Anzeigen der OCM in Reaktion auf eine Änderung der OSS in dem Fahrzeug 12 ohne menschliches Zutun anfordern. Das Verfahren 200 fährt dann mit Schritt 220 fort.
-
In Schritt 220 wird auf die OCM an Fahrzeug 12 von dem VSM 42 zugegriffen. Dies kann auf unterschiedliche Weisen erfolgen. In einer Implementierung kann die Fahrzeuganzeige 38 eine oder mehrere VSM bezüglich OCM-Dateien abfragen, die bei den VSM 42 in einer Speichervorrichtung 43 gespeichert sind. Die OCM-Dateien können eine oder mehrere OCM-Bibliotheken beinhalten; beispielsweise eine OCM-Datenbibliothek 202 und eine OCM-Metadatenbibliothek 204, die beide in einer Speichervorrichtung 39 an der Anzeige 38 abgelegt. Die Fahrzeuganzeige 38 kann eine Anweisung über den Kommunikationsbus 44 übertragen mit der Anforderung an das VSM 42, die OCM-Dateien zu der optischen Anzeige 38 zu senden. Eine oder mehrere Anweisungen können über den Kommunikationsbus 44 zu jedem VSM 42 im Fahrzeug 12 übertragen werden. Die Fahrzeuganzeige 38 kann dann unabhängig beliebige OCM-Dateien, die in den VSM am Fahrzeug 12 gespeichert sind, in Reaktion auf die Anweisung(en) empfangen. In dieser Implementierung speichert die optische Anzeige 38 keine OCM-Dateien, sondern benutzt eine verteilte Speicherung der OCM-Dateien auf den VSM 42, sodass, wenn angefordert, sie beliebige gespeicherte OCM liefern. In einigen Implementierungen wird die Anforderung zum Zugriff auf OCM durch den Fahrzeugbenutzer gestartet. Aber es versteht sich weiterhin, dass anstatt Empfangens einer Anforderung zum Anzeigen der OCM durch einen Fahrzeugbenutzer die Anforderung automatisch durch das Fahrzeug 12 basierend auf einem bestimmten Ereignis wie etwa Zündung ein oder Zündung aus gestartet werden kann. Das Ereignis kann die Anforderung zum Anzeigen OCM ohne Wirkung auf den Teil des Fahrzeugbenutzers auslösen. Die Fahrzeuganzeige 38 oder das VSM 42 kann den Zugriff auf OCM-Dateien in Reaktion auf Starten des Fahrzeugs 12 veranlassen.
-
Andere Implementierungen sind ebenfalls möglich. Die optische Anzeige 38 kann beispielsweise OCM-Dateien einschließlich OCM-Daten und OCM-Metadaten für jedes VSM 42 am Fahrzeug 12 aufrecht erhalten. Die OCM-Metadatenbibliothek 204 kann für jede OSS und jedes OCM OSS-Metadaten beinhalten, die beliebige einen oder mehrere der folgenden Typen von Daten beinhalten: VSM-Modulkennung; VSM-Modul-elektronische-Steuerung(ECU)-Kennung; OSS-Name, OSS-Versionsidentifikator, OSS-Dateiinformationen; OCM-Versionsidentifikator und OCM-Dateiinformationen. Die Dateiinformationen können Informationen wie das Software-Ausgabedatum, Dateigröße, Checksumme oder andere Informationen bezüglich der OSS- oder OCM-Datei beinhalten. Und eine besondere Ausführung der OSS und OCM kann unter Verwendung von einem oder mehrerer dieser Metadaten sowie anderer Metadaten, wie des Besitzers der OSS, identifiziert werden. Die OCM-Datenbibliothek 202 kann zum Speichern der Begriffe und Bedingungen zum Verwenden der OSS gespeichert werden; d. h. der aktuellen Lizenzbedingungen und/oder anderen Konformitätsmaterialien, die dem Benutzer angezeigt werden sollen. Und in einigen Implementierungen kann der Inhalt der OCM, die einem Fahrzeugbenutzer wiedergegeben werden sollen, durch die Sprache, in welcher der Inhalt Gehalt am Fahrzeug 12 angezeigt wird, beeinflusst werden. Das Fahrzeug 12 kann Fahrzeugnutzern die Option bieten, Informationen an der optischen Anzeige 38 in einer von einer Anzahl von unterschiedlichen Sprachen wie Englisch, Französisch, Spanisch, Chinesisch usw. anzusehen. Je nach der Identität der durch den Fahrzeugnutzer ausgewählten Sprache kann unterschiedlicher OCM-Inhalt dem Benutzer präsentiert werden. Beispielsweise können OCM-Dateien in verschiedenen Sprachen gespeichert werden und eine OCM-Datei kann basierend auf der am Fahrzeug 12 gewählten Sprache ausgewählt werden. Wenn Englisch ausgewählt am Fahrzeug 12 ausgewählt ist, können OCM-Dateien einschließlich Inhalts in Englisch gewählt werden, wogegen, wenn Französisch ausgewählt ist, OCM-Dateien einschließlich Französisch ausgewählt werden kann. Nach Empfangen einer Anforderung zum Anzeigen von OCM kann die optische Anzeige 38 auf einige oder alle der OCM in der OCM-Datenbibliothek zugreifen und anzeigen. Somit zeigt bei Schritt 230 die optische Anzeige 38 mindestens einen Teil des OSS-Konformitätsmaterials im Fahrzeug 12 an. Die optische Anzeige 38 extrahiert Inhalt aus den OCM-Dateien und zeigt den Inhalt dem Fahrzeugbesitzer oder Benutzer zum Ansehen und Lesen der Benutzungsbedingungen für ein oder mehrere OSS-Pakete an. Auch könnte, während das Verfahren 200 mit Bezug auf eine optische Anzeige 38, die OCM-Dateien aus den VSM 42 speichert und/oder anfordert, beschrieben wurde, ein anderes Element mit Datenverbeitungsfähigkeiten für die optische Anzeige 38 ersetzt werden. Die Aktionen in Bezug zur optischen Anzeige 38 beispielsweise könnten unter Verwendung des Prozessors 52 der Fahrzeug-Telematikeinheit 30 durchgeführt werden. Nach Erhalt der OCM-Dateien könnte die Fahrzeug-Telematikeinheit 30 dann diese an die optische Anzeige 38 über den Kommunikationsbus 44 bereitstellen. Das Verfahren 200 endet dann.
-
Zeitweise kann es notwendig oder wünschenswert sein, die OCM-Dateien zu aktualisieren wie etwa in Reaktion auf ein neu in das Fahrzeug hinzugefügtes VSM oder nach Aktualisieren eines bestehenden VSM. In diesem Fall können die gespeicherten OCM-Dateien durch aktualisierte ersetzt werden. In Ausführungsformen, in denen die OCM-Dateien ausschließlich in der VSM gespeichert sind, kann auf die aktualisierten OCM-Dateien bei Bedarf direkt vom VSM zugegriffen werden. In anderen Ausführungsformen, in denen die OCM-Dateien in einer Datenbank wie den OCM-Bibliotheken 202, 204 gespeichert werden, können die Bibliotheken durch periodisches Herunterladen von einem Remotecomputer an einer zentralen Einheit aktualisiert werden oder auf Anforderung heruntergeladen werden oder können aus den einzelnen VSM erhalten werden, sobald sie installiert oder aktualisiert sind oder eine beliebige Kombination davon. Dies geschieht periodisch oder aufgrund eines Ereignisses wie eines Fahrzeugstarts (z. B. Zündung ein). In einer Ausführungsform kann das Aktualisieren der OCM-Bibliotheken nach dem folgenden Aktualisierungsverfahren erfolgen. Dieses Verfahren wird in einer Ausführungsform verwendet, in der die OCM-Bibliotheken in der optischen Anzeige 38 selbst gespeichert sind, jedoch ist es für Fachleute offensichtlich, dass die Bibliotheken an irgendeiner anderen geeigneten Stelle innerhalb der Fahrzeugelektronik 28 gespeichert werden können. Das Aktualisierungsverfahren beginnt durch Zugreifen auf mindestens einen Teil der OCM, der in einem oder mehreren der VSM gespeichert ist. Beispielsweise kann das System die VSM 42 zum Identifizieren der gespeicherten OCM abfragen. Die Abfrage kann die OCM-Dateien wie die an jedem VSM 42 gespeicherten OCM-Daten und/oder die OCM-Metadaten abfragen. Umgekehrt können die VSM 42 die angeforderten OCM (d. h. die OCM-Daten und/oder OCM-Metadaten) zu der optischen Anzeige 38 über den Kommunikationsbus 44 übertragen. Die optische Anzeige 38 kann die zugegriffenen OCM mit entsprechenden OCM aus der optischen Anzeige vergleichen. Sie kann beispielsweise einige oder alle der OCM-Metadaten mit entsprechenden OCM-Metadaten aus der gespeicherten OCM-Metadatenbibliothek in der optischen Anzeige 38 auf Übereinstimmung vergleichen. Wenn die Version der OCM-Metadaten, die von den VSM 42 erhalten wurden, mit den OCM-Metadaten aus der optischen Anzeige 38 übereinstimmt, kann sie entscheiden, ob die OCM-Dateien aus den VSM 42 aktuell sind. Jedoch, wenn die OCM-Metadaten nicht überein, optische Anzeige 38 bestimmen kann, dass die OCM-Dateien an der VSM 42 out-of-date sind. In diesem Fall kann die optischen Anzeige 38 eine Anforderung für aktualisierte OCM übertragen, die an die zugeordneten VSM (wenn die aktualisierte OCM dort gespeichert ist) oder an eine zentrale Einheit Mechanismus wie Computer 18 gesendet werden können und die neueste Version des OCM unter Verwendung eines Identifikators oder anderer OCM-Metadaten anfordern kann und/oder das OCM identifizieren kann, das als veraltet in Bezug auf Version und Alter bestimmt wurde. Die zentrale Einheit kann bestimmen, ob ein neueres OCM verfügbar ist und, wenn ja, dieses an das Fahrzeug 12 übermitteln; ansonsten kann die zentrale Einheit eine Meldung senden, dass keine neuere Version verfügbar ist. Sobald empfangen, kann die optische Anzeige die OCM-Bibliotheken nach Bedarf durch Speichern der neuen OCM-Datei(en) in Bibliothek 202 und/oder 204 aktualisieren. Danach kann, wenn ein Fahrzeuginsasse Anzeigen des OCM anfordert, von der OCM-Datenbibliothek auf die aktualisierte OCM zugegriffen werden und diese an der optischen Anzeige 38 angezeigt werden.
-
In den 3–4 wird ein anderer Teil der Fahrzeugelektronik 28 dargestellt, der verwendet werden kann, um eine Ausführungsform eines Verfahrens 300 des Anzeigens von OSS-Konformitätsmaterial in dem Fahrzeug 12 auszuführen. Das Verfahren 300 beginnt mit Schritt 310 durch Empfangen von OSS-Konformitätsmaterial an einem Programmierungs-Mastermodul 302 gespeichert am Fahrzeug 12. Das PMM 302 ist ein Softwaremodul, das beauftragt werden kann zum Leiten der Erhalts von OCM-Dateien aus externen Quellen wie Computer 18 oder der Servicestelle (nicht dargestellt) sowie das Speichern von OCM-Dateien auf und das Zugreifen auf OCM-Dateien aus VSM 42. Die PMM 302 kann an der gespeicherten Fahrzeug-Telematikeinheit 30 gespeichert werden wie in 3 oder einem anderen Element im Fahrzeug 12, das Rechen-Verarbeitungskapazität aufweist mit dem Kommunikationsbus 44 verbunden ist. Die PMM 302 kann als ein Gateway-Modul zwischen Einrichtungen außerhalb des Fahrzeugs 12 und Software/Hardware innerhalb des Fahrzeugs 12 dienen.
-
Der Computer 18 kann drahtlose OSS, OCM oder beides zum Fahrzeug 12 über das Drahtlosträgersystem 14 übertragen. Nach Empfangen der OSS- und/oder OCM-Dateien kann die PMM 302 dann ermitteln, worin das Fahrzeug 12 die OSS-/OCM-Dateien speichern sollte und kann die Dateien zu dem geeigneten Ort übertragen. In einer Ausführung kann die PMM 302 eine VSM-Kennung in Form einer Elektronischen-Steuerungs(ECU)-ID zusammen mit den eingehenden OSS-/OCM-Dateien empfangen, die das VSM 42 beim Empfangen jeder Datei identifiziert. In einer anderen Ausführungsform kann die PMM 302 eine VSM-Identität mit allen der OSS in Verbindung mit jeder VSM 42 in einem Firmware-Verzeichnis 304 speichern. Wenn die PMM 302 OSS-/OCM-Dateien aus einer externen Quelle empfängt, kann die PMM 302 das Firmware-Verzeichnis 304 abfragen, das das VSM 42 mit OSS-Dateien, OCM-Dateien oder beiden verknüpft. Das Firmware-Verzeichnis 304 kann als eine Datenbank oder Datenstruktur aufrechterhalten werden, auf deren Inhalt durch die Fahrzeug-Telematikeinheit 30 oder die optische Anzeige 38 zugegriffen werden kann. Das PMM 302 kann das Firmware-Verzeichnis 304 dann zum Verknüpfen empfangener Dateien mit einem speziellen VSM 42 verwenden und dann die Dateien zum besonderen VSM 42 über den Kommunikationsbus 44 übermitteln. In einigen Ausführungen kann das PMM 302 die OCM-Dateien zentral speichern, anstatt die Dateien zum Speichern zum VSM 42 zu senden. Das Verfahren 300 fährt dann mit Schritt 320 fort.
-
In Schritt 320 wird das OCM in einem oder mehreren VSM 42 unter Verwendung des PMM 302 gespeichert und später kann darauf zum Darstellen auf der optischen Anzeige 38 zurückgegriffen werden. Nach dem Übertragen der OSS- oder OCM-Dateien zum VSM 42 durch das PMM 302 werden sie in einer Speichervorrichtung der VSM 42 abgelegt. Das Verfahren 300 fährt dann mit Schritt 330 fort. Auf das gespeicherte OSS-Konformitätsmaterial wird von einem oder mehreren der VSM 42 zugegriffen und mindestens ein Teil des OSS-Konformitätsmaterials wird auf der optischen Anzeige 38 im Fahrzeug 12 dargestellt.
-
Es versteht sich, dass das Vorstehende eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung ist. Die Erfindung ist nicht auf die besondere(n) hierin offenbarte(n) Ausführungsform(en) eingeschränkt, sondern ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder der Definition der in den Patentansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachleute offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.
-
Wie in dieser Spezifikation und den Patentansprüchen verwendet, sind die Begriffe „z. B.”, „beispielsweise”, „zum Beispiel”, „wie z. B.” und „wie” und die Verben „umfassend”, „einschließend” „aufweisend” und deren andere Verbformen, wenn sie in Verbindung mit einer Auflistung von einer oder mehreren Komponenten oder anderen Elementen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung nicht als andere zusätzliche Komponenten oder Elemente ausschließend betrachtet werden soll. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- IEEE 802.11-Protokollen [0017]
- 802.11x [0029]
