-
EINLEITUNG
-
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf vernetzte Datensysteme zum Bereitstellen von Informationen für Kraftfahrzeuge. Insbesondere beziehen sich Aspekte dieser Offenbarung auf drahtlose Kommunikationssysteme und Steuerlogik zum Optimieren des Datenaustauschs zwischen Fahrzeugen während eines Peer-to- Peer-(P2P)- Ressourcenentdeckungsprozesses.
-
Die heutigen Serienfahrzeuge, wie das moderne Automobil, sind ursprünglich mit verschiedenen elektronischen Vorrichtungen zum Übertragen von Informationen an, von und innerhalb des Fahrzeugs ausgestattet oder nachgerüstet. In Automobilanwendungen können beispielsweise fahrzeugseitige Vorrichtungen Inhalte austauschen, basierend auf Daten von einer lokalen Vorrichtung, wie beispielsweise einer vernetzten Fahrzeugsteuerung, einem verteilten Sensor oder einer Mensch-Maschine-Schnittstelle (HMI). Residente Fahrzeugkommunikationssysteme können auch Daten mit einem entfernten Knoten austauschen, wie beispielsweise einem Cloud-Computing-Rechenzentrum, einem GPS-Navigationssender-Empfänger oder einem Satellitenübertragungsdienst. Einige Vorrichtungen können Daten von einem verteilten Computernetzwerk - das am weitesten verbreitete ist das globale Internet - über ein Wireless Fidelity (WiFi)-System, ein Mobilfunknetz oder eine andere drahtlose Kommunikationstechnologie empfangen. Daten können auch von einem zentralisierten Serversystem aus einer Gruppe von teilnehmenden Fahrzeugen gesammelt und analysiert werden, um den Verkehrs- und Straßenzustand zur Weitergabe an andere Fahrzeuge innerhalb einer bestimmten Region zu ermitteln. Auch die Erstausrüster (OEM) bewegen sich in Richtung vernetzter „sprechender“ Autos, die über die Fahrzeug-zu-Fahrzeug-Kommunikation (V2V) Informationen untereinander austauschen.
-
Mit der kontinuierlichen Weiterentwicklung der V2V-Kommunikation nutzen die Hersteller Peer-to-Peer-Datenaustauschtechniken, um die beschleunigte Weitergabe von Fahrzeugkalibrierinformationen, Diagnose- und Prognosedaten, Fahrzeugrückrufwamungen usw. zu erleichtern. Ein Trägerfahrzeug, das auf Informationen zugreifen möchte, die in einem anderen Fahrzeug gespeichert sind, kann dem anderen Fahrzeug eine Anforderung zum Zugriff auf die Daten übermitteln. Nach der Authentifizierung der Zugangsdaten des Trägerfahrzeugs für den Zugriff auf die angeforderten Informationen kann das andere Fahrzeug die Daten an das Trägerfahrzeug übertragen, z. B. über ein dediziertes Nahbereichskommunikations-(DSRC)-System. Konnektivitätsbandbreite und -latenz in V2V-Kommunikationssystemen begrenzen jedoch typischerweise die Größe und Übertragungsgeschwindigkeit von Datenpaketen, die zwischen Peers übertragen werden können. Die Übertragung großer Datenpakete über einen kurzen Zeitraum kann die Bandbreite des DSRC-Kanals überlasten. Dieses Problem wird noch verschärft, wenn die übertragenen Daten duplikativ mit Informationen sind, die das anfordernde Fahrzeug bereits im lokalen Speicher gespeichert hat. Darüber hinaus kann die Zeit, in der sich zwei Fahrzeuge in Reichweite befinden, um miteinander zu kommunizieren, begrenzt sein; bei der Übertragung großer Datenmengen können Teile der Daten entweder nicht oder nicht in ihrer Gesamtheit übertragen werden.
-
KURZDARSTELLUNG
-
Hierin offenbart sind automatisierte Fahrzeug-zu-Fahrzeug-(V2V)-Datenaustauschsysteme und zugehörige Steuerlogik, Verfahren zum Betreiben und Konstruieren derartiger Systeme sowie Kraftfahrzeuge, die einen verbesserten Bloom-Filter und eine Hash-Funktion zur Mitgliederidentifikation und zum Versionsnummernvergleich während eines Peer-to-Peer-(P2P)-Datenaustauschs verwenden. Als Beispiel wird ein neuartiges Protokoll zur Unterstützung eines Trägerfahrzeugs (erster Knoten) beim Auffinden verfügbarer Dateien und Dateiversionen von Daten vorgestellt, die auf einem ersten oder zweiten Seederfahrzeug (zweiter Knoten) während eines P2P-Ressourcenerkennungsprozesses gespeichert sind. Die Knoten verwenden einen erweiterten Bloom-Filter mit einer kompakten Datenstruktur und Hash-Funktionszuordnung für Zugehörigkeitstests und den Vergleich von Dateiversionsnummern, um eine weitreichende gemeinsame Nutzung von verteilten Ressourcen zu ermöglichen. Bloom-Filter sind zeit- und platzsparende Datenstrukturen zur probabilistischen Darstellung eines Datensatzes zur Unterstützung von Zugehörigkeitsabfragen (z. B. Test, ob ein bestimmtes Element Zugehöriger zu einem bestimmten Datensatz ist oder nicht). Ein Bloom-Filter kann für Cache-Freigabe, Abfragefilterung und Routing, kompakte Darstellung einer Batch-Datei und andere geeignete Funktionen verwendet werden.
-
Während eines kollaborativen Verteilungsprozesses für die Zertifikatssperrliste (CRL-Certificate Revocation List) implementiert ein Sicherheitszertifikatsmanagementsystem (SCMS) beispielsweise ein Fehlverhaltens-Autoritäts-(MA)-Modul, das periodisch CRL-Dateien erzeugt, um fehlverhaltende Fahrzeuge (z. B. ein Fahrzeug, das versucht, sich unrechtmäßig in das Bordnetz eines anderen Fahrzeugs zu hacken) und beschädigte Fahrzeuge (z. B. ein mit Malware infiziertes Fahrzeug) zu katalogisieren. Eine Untergruppe von Fahrzeugen - gekennzeichnet mit „Seeder-Fahrzeuge aus erster Hand“ - lädt die CRL-Dateien, z. B. über WiFi, LTE oder RSU, aus dem SCMS herunter und verbreitet die Dateien dann über kollaborative V2V-Kommunikation an andere Fahrzeuge. Dieser Prozess trägt dazu bei, dass Fahrzeuge ohne Mobilfunk- oder WiFi-Konnektivität diese CRL-Listen empfangen können, während gleichzeitig die mit der Nutzung von Mobilfunkdaten verbundenen Kosten gesenkt werden, indem die Übertragung von Mobilfunkdaten auf eine begrenzte Gruppe von Fahrzeugen beschränkt wird. CRL-Dateien können ein von einer Public-Key-Infrastruktur (PKI) ausgestelltes digitales Zertifikat enthalten, um eine Vertrauenskette aufzubauen; jedoch kann auf die Dateiverschlüsselung verzichtet werden, um eine breitere und schnellere Verteilung der Dateien zu unterstützen.
-
Die P2P-Dateiverteilung beinhaltet oft den Austausch von Datendateien, die mit verschiedenen Versionen erstellt wurden, oder von Datendateien, die für eine begrenzte Anzahl von Fahrzeugen bestimmt sind (z. B. Fahrzeuge einer bestimmten Marke, eines bestimmten Modells, eines bestimmten geografischen Standorts, usw.). Um sicherzustellen, dass nur relevante, nicht überlappende Daten übertragen werden, kann die P2P-Dateiverteilung mit der ersten Erzeugung eines Bloom-Filters beginnen, der für die Datendateien repräsentativ ist, die zum Abruf aus dem Seederfahrzeug verfügbar sind. Ein Seederfahrzeug kann auf das Empfangen eines Übertragungs-„Hallo“-Signals reagieren, indem es einen Satz von Elementen (d. h. Datei-IDs) mit kodierten Versionsdaten, z. B. als binäre Multibit-Sequenz hinzugefügt, über eine Hash-Funktion eines Multibit-Arrays zuordnet. Diese Bit-Anordnung wird drahtlos vom Seederfahrzeug an ein oder mehrere Trägerfahrzeuge übertragen, um eine schnelle, bandbreitenreduzierte P2P-Ressourcenerkennung zu unterstützen. Das Trägerfahrzeug ruft dann seine eigenen Datei-IDs ab und ordnet jede Datei-ID dem Bloom-Filter unter Verwendung der zugehörigen Hashing-Technik zu, um zu bestimmen, ob eine Datei-ID für eine lokale Datendatei ein Element des Bit-Arrays ist oder nicht (Elementidentifizierung). Für jede lokale Datei-ID, die ein Element ist, ruft das Trägerfahrzeug dann aus dem Bloom-Filter die kodierte Versionsnummer für die Remote-Datei-ID des Gegenstücks ab und bestimmt dann, ob die kodierte Versionsnummer neuer ist als die der lokalen Datei-ID zugeordnete Versionsnummer (Versionsnummernvergleich). Die Verwendung eines Bloom-Filters mit einem Multi-Bit-Array ermöglicht es dem empfangenden Fahrzeug, die verfügbaren Datendateien sowie den jeweiligen Inhalt jeder Datei zu „kennen“. Aus dieser Liste identifiziert das Trägerfahrzeug die Datei(en), die nicht duplikativ, aber für dieses Fahrzeug relevant sind; die Saat- und Trägerfahrzeuge tauschen dann den tatsächlichen Dateiinhalt aus.
-
Aspekte dieser Offenbarung beziehen sich auf V2V-Datenaustauschtechniken und computerausführbare Algorithmen für Kraftfahrzeuge. So wird beispielsweise ein Verfahren zum Ausführen eines V2V-Datenaustauschs zwischen einem ersten (Träger)-Fahrzeug und einem zweiten (Seeder)-Fahrzeug vorgestellt. Im Allgemeinen kann ein einzelnes Fahrzeug sowohl als Seederfahrzeug, d. h. zum Verteilen von Daten an ein anderes Fahrzeug, als auch als Trägerfahrzeug, d. h. zum Empfangen von Daten, die von einem anderen Fahrzeug verteilt wurden, dienen. Umgekehrt können zumindest einige V2V-Systemarchitekturen nur ein ausgewähltes Fahrzeug oder eine Untergruppe von Fahrzeugen als Seeders bezeichnen, während der Rest der Fahrzeuge als Träger bezeichnet wird. Dieses repräsentative Verfahren beinhaltet in beliebiger Reihenfolge und in beliebiger Kombination mit einem der offenbarten Merkmale und Optionen das Bestimmen, ob eine drahtlose Kommunikationsvorrichtung des Trägerfahrzeugs kommunikativ mit einer drahtlosen Kommunikationsvorrichtung des Seederfahrzeugs verbunden ist. Wenn sich das Trägerfahrzeug und das Seederfahrzeug in Reichweite befinden, wird eine Aufforderung vom Trägerfahrzeug zum Seederfahrzeug (oder umgekehrt) gesendet, einen Ressourcenerkennungsprozess einzuleiten, um die über eine residente Speichervorrichtung des Seederfahrzeugs gespeicherten Daten zum Speichern über eine residente Speichervorrichtung des Trägerfahrzeugs abzurufen.
-
Nach Beginn des Ressourcenentdeckungsprozesses kann ein Bloom-Filter über das Seederfahrzeug erzeugt und anschließend vom Seederfahrzeug an das Trägerfahrzeug übertragen werden. Dieser Bloom-Filter beinhaltet einen Satz von entfernten Datei-IDs, die einem Bit-Array zugeordnet sind, z. B. über eine geeignete Hashing-Technik, worin jede entfernte Datei-ID eine entsprechende entfernte Dateiversionsnummer aufweist, die mit dem Bit-Array kodiert ist, z. B. als binäre Multi-Bit-Sequenz. Die residente Fahrzeugsteuerung des Trägerfahrzeugs bestimmt dann, ob eine lokale Datei-ID einer vorhandenen Datei, die über die residente Speichervorrichtung des Trägerfahrzeugs gespeichert ist, ein Element des empfangenen Bloom-Filters ist oder nicht. Die lokale Datei-ID ist ein Element, wenn eine entfernte Datei-ID des Gegenstücks bereits dem Bit-Array des Bloom-Filters zugeordnet ist. Als Reaktion darauf, dass die lokale Datei-ID ein Element des empfangenen Bloom-Filters ist, bestimmt das Trägerfahrzeug, ob die Versionsnummer der entfernten Datei, die mit der entfernten Datei-ID des Gegenstücks kodiert ist, neuer ist als eine lokale Dateiversionsnummer, die der lokalen Datei-ID zugeordnet ist. Als Reaktion darauf, dass die Versionsnummer der entfernten Datei neuer ist als die Versionsnummer der lokalen Datei, sendet das Seederfahrzeug eine Datendatei, die der entfernten Datei-ID des Gegenstücks zugeordnet ist, an das Trägerfahrzeug.
-
Weitere Aspekte der vorliegenden Offenbarung richten sich an Kraftfahrzeuge, die einen verbesserten Bloom-Filter und eine Hash-Funktion zur Zugehörigkeitsidentifikation und zum Vergleich von Versionsnummern während eines V2V-Datenaustauschs verwenden. Ein „Kraftfahrzeug“, wie hierin verwendet, kann jede relevante Fahrzeugplattform, wie z. B. Personenkraftwagen (Verbrennungsmotoren, Hybrid-, vollständig Elektro-, Brennstoffzellenantrieben usw.), Transportfahrzeuge, Industriefahrzeuge, Raupenfahrzeuge, Geländefahrzeuge (ATV), landwirtschaftliche Geräte, Boote, Flugzeuge usw. beinhalten. In einem Beispiel wird ein Kraftfahrzeug dargestellt, das eine Fahrzeugkarosserie mit einem Antriebsstrang, eine residente Speichervorrichtung, eine residente drahtlose Kommunikationsvorrichtung und eine residente Fahrzeugsteuerung beinhaltet, die alle an der Fahrzeugkarosserie montiert sind. Die Fahrzeugsteuerung ist funktionsfähig mit der Speichervorrichtung und der drahtlosen Kommunikationsvorrichtung verbunden.
-
Fortfahrend mit dem vorstehenden Beispiel wird die residente Fahrzeugsteuerung programmiert, um zu bestimmen, ob die residente drahtlose Kommunikationsvorrichtung kommunikativ mit einer drahtlosen Kommunikationsvorrichtung eines Seederfahrzeugs verbunden ist, und eine Aufforderung an das Seederfahrzeug zu senden, einen Ressourcenentdeckungsprozess einzuleiten, um die über eine Speichervorrichtung des Seederfahrzeugs gespeicherten Daten zum Speichern über die residente Speichervorrichtung abzurufen. Die residierende Fahrzeugsteuerung empfängt dann vom Seederfahrzeug über die residente drahtlose Kommunikationsvorrichtung einen Bloom-Filter mit einem Satz von entfernten Datei-IDs, die auf ein Bit-Array abgebildet sind. Jede entfernte Datei-ID weist eine entsprechende Versionsnummer der entfernten Datei auf, die zum Bit-Array kodiert ist. Die residente Fahrzeugsteuerung ist programmiert, um zu bestimmen, ob eine lokale Datei-ID einer vorhandenen Datei, die über die residente Speichervorrichtung gespeichert ist, ein Element des empfangenen Bloom-Filters ist oder nicht, und als Reaktion darauf, dass die lokale Datei-ID ein Element des empfangenen Bloom-Filters ist, um zu bestimmen, ob die Versionsnummer der entfernten Datei, die mit der entfernten Datei-ID des Gegenstücks kodiert ist, neuer ist als eine lokale Dateiversionsnummer, die der lokalen Datei-ID zugeordnet ist. Als Reaktion darauf, dass die Versionsnummer der entfernten Datei neuer ist als die Versionsnummer der lokalen Datei, lädt die residente Fahrzeugsteuerung eine Datendatei auf die residente Speichervorrichtung herunter, die der ID der entfernten Datei des Gegenstücks zugeordnet und in der Speichervorrichtung des Seederfahrzeugs gespeichert ist.
-
Für jede der offenbarten Ausführungsformen kann das Bestimmen, ob eine lokale Datei-ID ein Element eines empfangenen Bloom-Filters ist oder nicht, Folgendes beinhalten: Anwenden einer Hash-Funktion, um die lokale Datei-ID dem Bit-Array des Bloom-Filters zuzuordnen; und Bestätigen, dass die Hash-Funktion die lokale Datei-ID auf die gleiche Array-Position oder Positionen des Bit-Arrays wie die Gegenstelle der entfernten Datei-ID abbildet. Als Reaktion auf die Bestimmung, dass eine lokale Datei-ID nicht Element eines empfangenen Bloom-Filters ist, kann bestimmt werden, ob eine andere lokale Datei-ID einer anderen vorhandenen Datei, die über eine residente Speichervorrichtung eines Trägerfahrzeugs gespeichert ist, Element des empfangenen Bloom-Filters ist. Als Reaktion auf die Bestimmung, dass die Versionsnummer der entfernten Datei nicht neuer als eine Versionsnummer der lokalen Datei ist, bestimmt werden, ob eine andere lokale Datei-ID einer anderen vorhandenen Datei, die über die residente Speichervorrichtung des Trägerfahrzeugs gespeichert ist, ein Element des empfangenen Bloom-Filters ist. Wie vorstehend angegeben, besteht das Bit-Array aus einer Reihe von Multi-Bit-Array-Positionen; jede Versionsnummer der entfernten Datei wird als eine binäre Multi-Bit-Sequenz kodiert, die einer oder mehreren dieser Array-Positionen zugeordnet ist. Eine oder mehrere dieser kodierten binären Multi-Bit-Sequenzen können mehreren dieser Multi-Bit-Array-Positionen zugeordnet werden.
-
Für jede der offenbarten Ausführungsformen kann die Verfahrens-/Programmfahrzeugsteuerung: einen Satz von Datendateien identifizieren, die in einer residenten Speichervorrichtung eines Seederfahrzeugs gespeichert sind; einen Bloom-Filter erzeugen; und jede der entfernten Datei-IDs dem Bit-Array des Bloom-Filters mit der entsprechenden Versionsnummer der entfernten Dateiversion zuordnen, die in dem Bit-Array kodiert ist. Optional können die entfernten Datei-IDs und die entsprechenden verschlüsselten Dateiversionsnummern in Echtzeit erzeugt werden. Das Abbilden einer entfernten Datei-ID auf ein Bit-Array kann das Anwenden einer Hash-Funktion beinhalten, welche die entsprechende kodierte Versionsnummer der entfernten Datei einer oder mehreren bestimmten Array-Positionen des Bit-Arrays zuweist. Jede Versionsnummer der entfernten Datei kann als eine binäre Multi-Bit-Sequenz kodiert werden, die einer oder mehreren der Array-Positionen des Bloom-Filters zugeordnet ist.
-
Für jede der offenbarten Ausführungsformen kann bestimmt werden, ob eine neue Datendatei über die drahtlose Kommunikationsvorrichtung des Seederfahrzeugs empfangen wird. Die neue Datendatei kann von Metadaten begleitet werden (z. B. mit einer neuen Datei-ID und einer neuen Datei-Versionsnummer). Als Reaktion auf das Empfangen der neuen Datendatei kann die entsprechende neue Datei-ID auf das Bit-Array des Bloom-Filters abgebildet werden, wobei die neue Dateiversionsnummer auf das Bit-Array kodiert ist. Eine residente Fahrzeugsteuerung, z. B. eines Trägerfahrzeugs, kann bestehende Dateien einzeln aus einem Satz von bestehenden Dateien auswählen, die über eine residente Speichervorrichtung dieses Fahrzeugs gespeichert sind. Aufforderungen zum Einleiten eines Ressourcenentdeckungsprozesses können vom Trägerfahrzeug zum Seederfahrzeug oder umgekehrt als Reaktion auf den Aufbau einer drahtlosen Verbindung zwischen Trägerfahrzeug und Seederfahrzeug übertragen werden.
-
Die vorstehende Kurzdarstellung soll nicht jede Ausführungsform oder jeden Aspekt der vorliegenden Offenbarung repräsentieren. Vielmehr stellt die vorstehende Kurzdarstellung lediglich einige der neuartigen Konzepte und Merkmale, wie hierin dargelegt, als Beispiel dar. Die vorstehend aufgeführten Merkmale und Vorteile sowie andere Merkmale und Vorteile dieser Offenbarung werden aus der folgenden ausführlichen Beschreibung der veranschaulichten Ausführungsformen und der Arten zum Ausführen der vorliegenden Offenbarung in Verbindung mit den zugehörigen Zeichnungen und den beigefügten Ansprüchen leicht ersichtlich. Darüber hinaus beinhaltet die vorliegende Offenbarung ausdrücklich alle Kombinationen und Teilkombinationen der vorangehenden Elemente und Merkmale, die oben und im Folgenden dargestellt sind.
-
Figurenliste
-
- 1 ist eine schematische Darstellung eines repräsentativen Kraftfahrzeugs mit einem Netzwerk von fahrzeuginternen Steuerungen, Sensoren und Kommunikationsvorrichtungen zum Durchführen eines Fahrzeug-Fahrzeug-Datenaustauschs gemäß den Aspekten der vorliegenden Offenbarung.
- 2 ist eine schematische Darstellung eines repräsentativen Peer-to-Peer-Ressourcenentdeckungs- und Datenaustauschverfahrens, das einen erweiterten Bloom-Filter und ein Multi-Bit-Array gemäß den Aspekten der vorliegenden Offenbarung verwendet.
- 3 ist ein Flussdiagramm für ein Erzeugungsprotokoll für ein Bloom-Filter-Bit-Array, das den Anweisungen entsprechen kann, die von bordeigenen und fernbetätigten Steuerlogikschaltungen, programmierbaren elektronischen Steuereinheiten oder anderen computergestützten Vorrichtungen oder Netzwerken von Vorrichtungen gemäß den Aspekten der offenbarten Konzepte ausgeführt werden.
- 4 ist ein Flussdiagramm für ein Bit-Array-Parsing-Protokoll des Bloom-Filters, das den Anweisungen entsprechen kann, die von bordeigenen und fernbetätigten Steuerlogikschaltungen, programmierbaren elektronischen Steuereinheiten oder anderen computergestützten Vorrichtungen oder Netzwerken von Vorrichtungen gemäß den Aspekten der offenbarten Konzepte ausgeführt werden.
-
Die vorliegende Offenbarung kann ist verschiedenen Modifikationen und alternativen Formen zur Anwendung zugänglich, und einige repräsentative Ausführungsformen werden exemplarisch in den Zeichnungen dargestellt und hierin ausführlich beschrieben. Es versteht sich allerdings, dass die neuartigen Aspekte dieser Offenbarung nicht auf die in den vorstehend aufgeführten Zeichnungen dargestellten besonderen Formen beschränkt sind. Vielmehr umfasst diese Offenbarung alle Modifikationen, Entsprechungen, Kombinationen, Teilkombinationen Permutationen, Gruppierungen und Alternativen, die dem Erfindungsgedanken und dem Umfang der Offenbarung entsprechen, wie sie durch die beigefügten Ansprüche festgelegt sind.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Diese Offenbarung eignet sich für eine Vielzahl von Ausführungsformen. Diese sind in den Zeichnungen dargestellt und hierin in detaillierten repräsentativen Ausführungsformen der Offenbarung beschrieben, mit der Erkenntnis, dass die vorliegende Offenbarung als eine Veranschaulichung der Prinzipien der Offenbarung zu betrachten ist, und nicht als eine Einschränkung der breiten Aspekte der Offenbarung bezüglich der repräsentativen Ausführungsformen. Entsprechend sollten Elemente und Einschränkungen, die beispielsweise in der Kurzdarstellung, der Einführung, der Zusammenfassung und der ausführlichen Beschreibung offenbart, aber nicht explizit in den Patentansprüchen aufgeführt sind, nicht per Schlussfolgerung, Rückschluss oder anderweitig einzeln oder insgesamt in die Patentansprüche integriert werden.
-
Zu Zwecken der vorliegenden ausführlichen Beschreibung, soweit nicht ausdrücklich dementiert: beinhaltet die Singularform die Pluralform und umgekehrt; die Wörter „und“ und „oder“ sind beide verbindend und trennend; die Wörter „alle und jegliche“ bedeuten beide „alles und jedes“; und die Wörter „einschließlich, beinhaltet“ und „umfassend“ und „aufweisen“ bedeuten „einschließlich ohne Einschränkung.“ Darüber hinaus können beispielsweise Wörter für Annäherungen, wie „etwa“, „fast“, „wesentlich“, „ungefähr“ und dergleichen, hierin im Sinne von „bei, nahe oder nahezu“, oder „innerhalb 0-5 % von“ oder „innerhalb akzeptabler Herstellungstoleranzen“ oder jegliche logische Kombination davon verwendet werden. Schließlich sind Richtungsadjektive und Adverbien, wie etwa vorn, achtern, innen, außen, Steuerbord, Backbord, vertikal, horizontal, oben, unten, vorne, hinten, links, rechts usw. in Bezug auf ein Kraftfahrzeug, wie etwa eine Vorwärtsfahrtrichtung eines Kraftfahrzeugs, vorliegen können, wenn das Fahrzeug operativ auf einer normalen Fahroberfläche ausgerichtet ist.
-
Mit Bezug auf die Zeichnungen, worin sich gleiche Bezugszeichen auf gleiche Merkmale in den verschiedenen Ansichten beziehen, wird in 1 ein repräsentatives Fahrzeug, das im Allgemeinen mit 10 bezeichnet wird und hierin zu Zwecken der Erörterung als ein autonomes Personenfahrzeug im Limousinenstil dargestellt. Verpackt in einer Fahrzeugkarosserie 12 des Automobils 10, z.B. verteilt auf die verschiedenen Fahrzeugabteile, ist ein Bordnetz von elektronischen Vorrichtungen, wie beispielsweise die nachfolgend beschriebenen verschiedenartigen Rechenvorrichtungen und Steuerungen. Das dargestellte Automobil 10 - hierin auch kurz als „Kraftfahrzeug“ oder „Fahrzeug“ bezeichnet - ist lediglich eine exemplarische Anwendung, mit der die neuartigen Aspekte und Merkmale dieser Offenbarung praktiziert werden können. Ebenso sollte die Implementierung der vorliegenden Konzepte für die in den Zeichnungen veranschaulichten spezifischen Fahrzeug-zu-Fahrzeug-(V2V)-Systemarchitekturen auch als exemplarische Anwendung der hierin offenbarten Konzepte und Merkmale verstanden werden. Daher ist zu verstehen, dass Aspekte und Merkmale dieser Offenbarung auf andere V2V-Systemarchitekturen angewandt und für jeden logisch relevanten Kraftfahrzeugtyp implementiert werden können. Darüber hinaus wurden nur ausgewählte Komponenten des Fahrzeugs 10 dargestellt und werden hierin ausführlich beschrieben. Dennoch beinhalten die hierin erörterten Kraftfahrzeuge und Netzwerkarchitekturen zahlreiche zusätzliche und alternative Merkmale und andere verfügbare periphere Komponenten, zum Beispiel zum Ausführen der verschiedenen Verfahren und Funktionen dieser Offenbarung. Letztendlich sind die hierin abgebildeten Zeichnungen nicht unbedingt maßstabsgetreu und dienen lediglich Anleitungszwecken. Somit gelten die spezifischen und relativen Maße der Zeichnungen nicht als einschränkend.
-
Das repräsentative Fahrzeug 10 von 1 ist ursprünglich mit einer Fahrzeug-Telekommunikations- und Informationseinheit 14 (umgangssprachlich als „Telematik“ bezeichnet) ausgestattet, die mit einem drahtlosen entfernt gelegenen oder „Off-Board“ Cloud-Computing-System 24 (z. B. Mobilfunkmasten, Basisstationen und/oder mobile Vermittlungsstellen (MSCs) usw.) kommuniziert. Einige der anderen Fahrzeug-Hardwarekomponenten 16, die allgemein in 1 dargestellt sind, beinhalten als nicht einschränkende Beispiele eine Anzeigevorrichtung 18, ein Mikrofon 28, einen Lautsprecher 30 und Eingangssteuerungen 32 (z. B. Tasten, Knöpfe, Schalter, Touchpads, Tastaturen, Touchscreens usw.). Im Allgemeinen ermöglichen diese Hardwarekomponenten 16 dem Benutzer die Kommunikation mit der Telematikeinheit 14 und anderen Systemen und Systemkomponenten innerhalb des Fahrzeugs 10. Das Mikrofon 28 ermöglicht dem Fahrzeuginsassen die Eingabe von verbalen oder anderen auditiven Befehlen; das Fahrzeug 10 kann mit einer integrierten Sprachverarbeitungseinheit mit einer Mensch/Maschine-Schnittstellen-(HMI)-Technologie ausgestattet sein. Umgekehrt kann der Lautsprecher 30 eine verbale Ausgabe für die Fahrzeuginsassen bereitstellen und kann entweder ein eigenständiger Lautsprecher speziell zur Verwendung mit der Telematikeinheit 14 oder Teil der Fahrzeug-Audiokomponente 22 sein. Das Audiosystem 22 ist funktionsfähig mit einer Netzwerkverbindungsschnittstelle 34 und einem Audiobus 20 verbunden, um analoge Informationen über eine oder mehrere Lautsprecherkomponenten zu empfangen und als Ton wiederzugeben.
-
Kommunikativ an die Telematikeinheit 14 angekoppelt ist eine Netzwerkverbindungsschnittstelle 34, zu deren geeigneten Beispielen Twisted Pair/Fiber Optic Ethernet Switch, interner/externer paralleler/serieller Kommunikationsbus, eine lokale Netzwerkschnittstelle (LAN), Controller Area Network (CAN), Media Oriented System Transfer (MOST), Local Interconnection Network (LIN) u.ä. gehören. Andere geeignete Kommunikationsschnittstellen können diejenigen sein, die den ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen. Die Netzwerkverbindungsschnittstelle 34 ermöglicht der Fahrzeughardware 16 das Senden und Empfangen von Signalen untereinander und mit verschiedenen Systemen und Subsystemen sowohl außerhalb als auch „entfernt“ von der Fahrzeugkarosserie 12 und innerhalb oder „resident“ zur Fahrzeugkarosserie 12. Dadurch kann das Fahrzeug 10 verschiedene Fahrzeugfunktionen ausführen, wie beispielsweise das Steuern der Fahrzeuglenkung, das Steuern der Funktion des Fahrzeuggetriebes, das Steuern der Motordrosselklappe, das Ein- und Ausschalten des Bremssystems und andere automatisierte Fahrfunktionen. So empfängt und/oder überträgt die Telematikeinheit 14 beispielsweise Daten zu/von einem Schutzsystem ECU 52, einem Motorsteuergerät (ECM) 54, einem Infotainment-Anwendungsmodul 56, Sensorschnittstellenmodul(en) 58 und verschiedenen anderen Fahrzeugsteuervorrichtungen 60, wie beispielsweise einem Getriebesteuermodul (TCM), einem Klimasteuermodul (CCM), einem Bremssystemmodul (BCM) usw.
-
Mit weiterem Bezug auf 1 ist die Telematikeinheit 14 eine bordeigene Datenverarbeitungsvorrichtung, die sowohl einzeln als auch durch ihre Verbindung mit anderen vernetzten Vorrichtungen eine Mischung von Dienstleistungen bereitstellt. Diese Telematikeinheit 14 besteht im Allgemeinen aus einem oder mehreren Prozessoren 40, von denen jeder als diskreter Mikroprozessor, eine anwendungsspezifische integrierte Schaltung (ASIC) oder ein dediziertes Steuermodul ausgeführt sein kann. Das Fahrzeug 10 kann eine zentralisierte Fahrzeugsteuerung über eine Zentraleinheit (CPU) 36 anbieten, die funktionsfähig mit einer oder mehreren elektronischen Speichervorrichtungen 38 gekoppelt ist, die jeweils in Form einer CD-ROM, Magnetplatte, IC-Vorrichtung, Halbleiterspeicher (z. B. verschiedene Arten von RAM oder ROM) usw. und einer Echtzeituhr (RTC) 42 ausgeführt werden können. Langstrecken-Fahrzeugkommunikationsfähigkeiten mit entfernten, fahrzeugunabhängigen vernetzten Vorrichtungen können über einen oder mehrere oder alle oder einen Mobilfunk-Chipsatz/Komponente, einen Navigations- und Standort-Chipsatz/Komponente (z. B. globales Positionierungssystem (GPS)) oder ein drahtloses Modem bereitgestellt werden, die alle gemeinsam bei 44 dargestellt sind. Die drahtlose Nahbereichsverbindung kann über eine drahtlose Nahbereichskommunikationsvorrichtung 46 (z. B. eine Bluetooth®-Einheit oder einen Nahfeldkommunikations-(NFC)Sender-Empfänger), eine dedizierte Nahbereichskommunikations-(DSRC)-Komponente 48 und/oder eine Doppelantenne 50 bereitgestellt werden. Es ist davon auszugehen, dass das Fahrzeug 10 ohne eine oder mehrere der vorstehend aufgeführten Komponenten implementiert werden kann, oder dass sie je nach Bedarf zusätzliche Komponenten und Funktionen für eine bestimmte Endanwendung beinhalten kann. Die verschiedenen vorstehend beschriebenen Kommunikationsvorrichtungen können konfiguriert werden, um Daten zwischen Fahrzeugen als Teil einer periodischen Signalnachricht auszutauschen, die in einem V2V-Kommunikationssystem oder einem Fahrzeug-zu-Alles-(V2X)-Kommunikationssystem übertragen wird, z. B. Fahrzeug-zu-Infrastruktur (V2I), Fahrzeug-zu-Fußgänger (V2P) oder Fahrzeug-zu-Vorrichtung (V2D).
-
2 ist ein Diagramm eines drahtlosen Fahrzeugkommunikationssystems 100, das ein erstes (Träger)-Fahrzeug 110A darstellt, das in die Nähe eines zweiten (Seeder)-Fahrzeugs 110B fährt und mit diesem „spricht“. Die Kraftfahrzeuge 110A und 110B können jede Art von handelsüblichem Fahrzeug mit V2V-Kommunikationsfähigkeiten sein. Als nicht einschränkendes Beispiel ist vorgesehen, dass jedes der vorstehend offenbarten Merkmale in Bezug auf das Fahrzeug 10 von 1 einzeln oder in beliebiger Kombination in die Fahrzeuge 110A und 110B von 2 integriert werden kann und umgekehrt. Die ersten und zweiten Fahrzeuge 110A, 110B können drahtlose Nachrichten, Daten usw. über ein entsprechendes fahrzeugübergreifendes Kommunikationsnetzwerk (z. B. DSRC) 102 miteinander austauschen. Obwohl ein einzelnes Trägerfahrzeug 110A, das mit einem einzelnen Seederfahrzeug 110B kommuniziert, dargestellt wird, kann jedes Kraftfahrzeug mit einer beliebigen Anzahl von entfernten Fahrzeugen kommunizieren, die sich in Reichweite dieses Fahrzeugs befinden, um Informationen und Daten auszutauschen. Eines oder beide der Fahrzeuge 110A, 110B können über ein oder mehrere drahtlose Kommunikationsnetze 108 kommunikativ mit einem entfernten Host-System 104 oder einem Cloud-Computing-System 106 gekoppelt werden. Das Host-System 104 kann als Hochgeschwindigkeits-Server-Computervorrichtung oder als Großrechner implementiert werden, der in der Lage ist, Massendatenverarbeitung, Ressourcenplanung und Transaktionsverarbeitung durchzuführen. Das Netzwerk 108 kann jede verfügbare Art von Netzwerk sein, einschließlich einer Kombination aus öffentlichen verteilten Computernetzwerken (z. B. Internet) und gesicherten privaten Netzwerken (z. B. lokales Netzwerk, Breitbandnetzwerk, virtuelles privates Netzwerk), und kann drahtlose und drahtgebundene Übertragungssysteme (z. B. Satellit, Mobilfunknetz, terrestrische Netzwerke, usw.) beinhalten.
-
In 2 sind außerdem Beispiele für Datendateien dargestellt, die von jedem Fahrzeug 110A, 110B verwaltet und über die drahtlosen Fahrzeugkommunikationssysteme 100 bereitgestellt werden können. Ein erster Satz von kategorisierten Datendateien 112A wird in einer residenten Speichervorrichtung 114A des ersten (Host)-Fahrzeugs 110A gespeichert, während ein zweiter Satz von kategorisierten Datendateien 112B in einer residenten Speichervorrichtung 114B des zweiten (Seeder)-Fahrzeugs 110B gespeichert wird. Jeder Datensatz von Datendateien 112A, 112B kann Daten über die Fahrzeugposition, die Routenplanung, die Fahrzeugkinematik/-dynamik, Fahrzeugkalibrierinformationen, Diagnose- und Prognosedaten, Fahrzeugrückrufwarnungen, Verkehrsereignisse, Straßenzustände, Kollisionen, aktuelle Bedingungen, die zu einer Kollision führen könnten, usw. beinhalten. Neben der Vorwarnung bei Umgebungsbedingungen kann die Verfolgung von Sichtobjekten, die Nichtverfolgung von Sichtobjekten und die Wegvorhersage über V2V-Kommunikation bestimmt werden. Gesundheitsstatusinformationen, welche die Zuverlässigkeit und/oder Genauigkeit der von den Fahrzeugen erhaltenen Daten angeben, können ebenfalls übermittelt werden. Es ist zu beachten, dass die hierin genannten Datenkategorien rein repräsentativ sind und jedes geeignete Schema zur Kategorisierung, Speicherung und Übertragung dieser Informationen verwendet werden kann.
-
Aufgrund der enormen Menge an Informationen, die in beiden Fahrzeugen 110A, 110B gespeichert sein können, kann die drahtlose Übertragung aller Datendateien und/oder der entsprechenden Metadaten für diese Datendateien an ein anderes Fahrzeug während eines P2P-Ressourcenentdeckungsprozesses durch die Bandbreite, Bitrate, Latenzzeit oder den Transaktionszeitraum des Kommunikationskanals eingeschränkt oder anderweitig beeinträchtigt sein. Um zu gewährleisten, dass alle relevanten, nicht überlappenden Daten während der P2P-Dateiverteilung erfolgreich übertragen werden, kann es vorteilhaft sein, zunächst nur die Informationen zu senden, die für ein Trägerfahrzeug erforderlich sind, um zu ermitteln, welche relevanten und nicht überlappenden Daten, falls vorhanden, in einem bestimmten Seederfahrzeug verfügbar sind. Die hierin beschriebenen V2V-Datenaustauschsysteme, -verfahren und -fahrzeuge verwenden eine Steuerlogik, um zu ermitteln, welche Datensätze zu übertragen sind, ohne zunächst die vollständigen Metadaten oder den gesamten Inhalt der Dateien zu übermitteln. Seederfahrzeuge, ob aus erster Hand oder aus zweiter Hand, können so nur die Datensätze effektiv übermitteln, die den Abfrageanforderungen entsprechen.
-
Unter fortgesetzter Bezugnahme auf die repräsentative drahtlose Fahrzeugkommunikationssystem-100-Architektur von 2 führt jedes Fahrzeug 110A, 110B eine Liste von Metadaten für die derzeit in diesem Fahrzeug vorhandenen Dateien 112A, 112B. Als nicht einschränkendes Beispiel können die Datei-Metadaten Folgendes beinhalten: einen Dateinamen (z. B. „mi_crl“, „oh_crl“ und „il_crl“), der den Inhalt einer Datei anzeigen kann (z. B. eine Zertifikatssperrliste („crl“); eine Dateiversion (z. B. Versionen „1.0“, „2.0“, „2.2“, usw.), eine Dateierstellungszeit (wie „03/18/2018 9am“); eine Dateigröße (wie beispielsweise 12345 Bytes) usw. Wenn ein erstes Fahrzeug 110A auf ein zweites Fahrzeug 110B trifft, können ein oder beide Fahrzeuge 110A, 110B systematisch, responsiv, zufällig und/oder periodisch ein Hallo-Signal oder eine andere Aufforderung senden, um einen Ressourcenentdeckungsprozess einzuleiten. In diesem Prozess kann entweder das Fahrzeug 110A, 110B als Seederfahrzeug oder als Trägerfahrzeug oder beides fungieren; daher werden die Begriffe „Trägerfahrzeug“ und „Seederfahrzeug“ in erster Linie verwendet, um eine Quelle und ein Ziel für einen bestimmten V2V-Dateiaustausch zu verdeutlichen. Tatsächlich kann ein Fahrzeug 110B lokal gespeicherte Dateien mit dem anderen Fahrzeug 110A teilen; in der Zwischenzeit kann dieses Fahrzeug 110B auch Dateien von dem anderen Fahrzeug 110A oder jedem anderen Fahrzeug empfangen, das sich in Kommunikationsreichweite befindet.
-
Nachdem ein erstes Fahrzeug 110A ein neues, benachbartes Fahrzeug 110B entdeckt hat, z. B. durch Empfangen und Akzeptieren des Hallo-Signals des anderen Fahrzeugs, kann das eine oder beide Fahrzeuge 110A, 110B die Zugangsdaten des anderen Fahrzeugs bestätigen und gleichzeitig zustimmen, Daten vom zweiten Fahrzeug 110B, das als Seeder fungiert, an das erste Fahrzeug 110A, das als Träger fungiert, zu übertragen. In diesem Beispiel erzeugt das Seederfahrzeug 110B in Echtzeit einen Bloom-Filter 120, basierend auf den Datendateien 112B, die derzeit in der residenten Speichervorrichtung 114B gespeichert sind. Der Bloom-Filter 120 kann mit einem Bit-Array 122 von m Multi-Bit-Array-Positionen 121-1, 121-2, 121-3 ... 121-m beginnen, die alle zunächst auf Null-Null (00) oder eine andere Nullserie gesetzt werden können, z. B. abhängig von der Anzahl der Bits pro Array-Position. Eine Anzahl von k verschiedenen Hash-Funktionen kann definiert werden, wobei jede Hash-Funktion ein entsprechendes Hash-Element mit einer der m Array-Positionen mit einer einheitlichen Verteilung korreliert. Jede Datei-ID wird dann gemäß ihrer jeweiligen Hash-Funktion(en) dem Bit-Array 122 zugeordnet; die Bits an diesen Positionen werden auf eine binäre Multi-Bit-Sequenz gesetzt, die einer Zeitskala („aktuelle Versionsnummer“) oder einem anderen kodierten Parameter entspricht, der dieser Datei-ID zugeordnet ist. Nachdem der Bloom-Filter 120 vollständig installiert ist, wird er vom Seederfahrzeug 110B an ein oder mehrere Trägerfahrzeuge 110A übertragen.
-
Um zu bestimmen, ob sich eine bestimmte Datendatei innerhalb des Satzes befindet oder nicht, versorgt das Trägerfahrzeug 110A jede der entsprechenden k Hash-Funktionen mit der Datei-ID, um k Array-Positionen zu lokalisieren; wenn alle Bits an diesen Array-Positionen nicht Null-Null (00) sind, dann ist das Element in dem Satz vorhanden. Umgekehrt, wenn eines der Bits an diesen Positionen Null-Null (00) ist, dann ist das Element nicht im Satz vorhanden. Eine Länge des Bit-Arrays (d. h. die Gesamtzahl m von Array-Positionen) kann selektiv geändert werden, um eine gewünschte falsch-positive Wahrscheinlichkeit zu erreichen. Die falsch-positive Wahrscheinlichkeit kann weiter optimiert werden als eine gemeinsame Funktion einer Inhaltsähnlichkeit zwischen dem ersten Fahrzeug 110A und dem zweiten Fahrzeug 110B und einer erwarteten Begegnungszeit der Dauer zwischen den beiden Fahrzeugen. Die Hash-Funktion oder die Hash-Funktionen, die während eines V2V-Dateiaustauschs verwendet werden, können eine gemeinsam vereinbarte Hash-Funktion oder einen Satz von Hash-Funktionen zwischen dem Träger- und dem Seederfahrzeug 110A, 110B beinhalten (oder daraus bestehen). So kann beispielsweise das Seederfahrzeug 110B die Datei-IDs und die entsprechenden Kontextdaten (z. B. Versionsnummer, Freigabedatum, Zuordnungsdaten usw.) für den zweiten Datensatz der Datendateien 112B identifizieren und dann jede Datei-ID des zweiten Satzes unter Verwendung einer gegenseitig identifizierten Hash-Funktion in ein Bloom-Filter-Bit-Array zerlegt. Das Trägerfahrzeug 110A zerlegt beim Empfangen des Bloom-Filters die Datei-ID jeder lokalen Datendatei im ersten Satz von Datendateien 112A mit derselben gegenseitig identifizierten Hash-Funktion in das Bit-Array.
-
Gemäß dem veranschaulichten Beispiel identifiziert das Seederfahrzeug 110B die Kontextinformationen für jede Datendatei 112B, die im residenten Speicher 114B gespeichert ist - in diesem Fall die Zeitskalendaten der Dateien - wandelt die Kontextinformationen in eine entschlüsselbare binäre Multi-Bit-Sequenz um und ordnet diese kodierte Kennung dann anstelle des standardmäßigen Einzel-Ganzzahligen Platzhalters, der für Einzel-Bit-Arrays anderer Bloom-Filter verwendet wird, dem Bit-Array 122 des Bloom-Filters zu. Das Fahrzeugkommunikationssystem 100 kann einen kalibrierten Satz von Zwei-Bit-Identifikatoren verwenden, um die Aktualität der Dateiversion darzustellen: (1) „01“, um eine Datei darzustellen, die vor weniger als 24 Stunden erstellt wurde; (2) „10“, um eine Datei darzustellen, die vor mehr als 24 Stunden, aber weniger als einer Woche erstellt wurde; und (3) „11“, um eine Datei darzustellen, die vor mehr als einer Woche, aber weniger als einem Monat erstellt wurde. Für die Datendatei „il_crl.ver2.2“ von 2 kann das Seederfahrzeug 110B bestimmen, dass die aktuelle Zeit „03/19/18 08:11 Stunden“ ist und die Dateierstellungszeit „03/18/2018 09:30 Stunden“ ist; als solches wurde die Version 2.2 dieser Datei vor weniger als 24 Stunden erstellt und entspricht damit der Kennung „01“. Das Seederfahrzeug 110B kann gleichzeitig bestimmen, dass die Datendatei „mi_crl.ver1.0“ vor etwa 47 Stunden erstellt wurde (entsprechend der Kennung „10“) und die Datendatei „oh_crl.ver2.2“ vor etwa 9 Tagen und 14 Stunden erstellt wurde (entsprechend der Kennung „11“). Die vorgenannten Schritte können gleichzeitig über das Trägerfahrzeug 110A für den ersten Satz von Datendateien 112A durchgeführt werden, die in der residenten Speichervorrichtung 114A gespeichert sind.
-
Für mindestens einige Ausführungsformen kann der kodierte Identifikator mehr als zwei Ganzzahlen umfassen, z. B. um komplexere Kontextinformationen für die gespeicherten Datendateien darzustellen. So kann beispielsweise ein Fahrzeug zwei Datenbanken mit CRL-Dateien verwalten, z. B. eine für die USA und eine für Kanada. Wenn das Fahrzeug in den USA fährt, erzeugt das Fahrzeug einen Bloom-Filter basierend auf CRL-Dateien, die in der US-Datenbank gespeichert sind (z. B. mi_crl, ohio crl, il crl, usw.). Im Gegensatz dazu erzeugt das Fahrzeug, wenn es in Kanada unterwegs ist, einen Bloom-Filter basierend auf CRL Dateien, die in der CA-Datenbank gespeichert sind (Ontario crl, Quebec_crl, Montreal_crl, usw.). Um zu gewährleisten, dass ein Trägerfahrzeug auf die entsprechende Datenbank zugreift, speichern die Multi-Bit-Array-Positionen des Bloom-Filters eine dreistellige binäre Sequenz, die mit „1“ für alle in der US-Datenbank gespeicherten CRL-Dateien und „0“ für alle in der CA-Datenbank gespeicherten CRL-Dateien beginnt.
-
Nach der Kodierung der Kontextinformationen für die einzelnen Dateien, die im zweiten Datensatz 112B enthalten sind, verwendet das Seederfahrzeug 110B eine Hash-Funktion, um zu bestimmen, auf welches Element oder welche Elemente eine Datei im Bit-Array 122 abgebildet werden soll. Angenommen, das Seederfahrzeug 110B verwendet drei Hash-Funktionen für die Datei „mi_crl.ver1.0“: Hash1(‚mi_crl‘)=3, Hash2(‚mi_crl‘)=6, Hash3(‚mi_crl‘)=10; in diesem Fall wird die Dateikennung „10“ auf drei Array-Positionen abgebildet: Element drei, Element sechs und Element zehn. Wie dargestellt, verwendet das Seederfahrzeug 110B für jede Datei eine einzige Hash-Funktion: hash_function(‚mi_crl‘) = 4, sodass die Datei „mi_crl“ dem vierten Element im Bloom-Filter 120 als „10“ abgebildet wird; hash fünction(‚ilcrl‘) = 1, sodass die Datei ‚il_crl‘ dem 1. Element im Bloom-Filter 120 als „01“ zugeordnet ist; und hash_function(‚oh_crl‘) = m-1, sodass die Datei ‚oh_crl‘ dem m-1 Element im Bloom-Filter 120 als „11“ zugeordnet ist. Es ist vorgesehen, dass das Fahrzeug 110B für jede Datei mehr als eine Hash-Funktion verwendet und optional für jede Datei die gleiche oder eine andere Anzahl von Hash-Funktionen verwendet.
-
Nachdem das Trägerfahrzeug 110A den vom Seederfahrzeug 110B erzeugten Bloom-Filter 120 empfangen hat, wiederholt das Trägerfahrzeug 110A seine Liste der Datei-Metadaten, einschließlich der entsprechenden Datei-ID und der Kontextdaten für den Datensatz 112A, und bestimmt, ob das Seederfahrzeug 110B eine neuere Version einer dieser lokal gespeicherten Dateien aufweist oder nicht. In Fortführung des in 2 dargestellten Beispiels bestimmt das Trägerfahrzeug 110A, ob das Seederfahrzeug 110B eine neuere Version für lokal gespeicherte Dateien „mi_crl.ver.1.1“ und „il_crl.ver.2.0“ aufweist oder nicht. Das Trägerfahrzeug 110A führt zunächst ein Verfahren zur Identifizierung von Elementen durch, indem es die entsprechenden Hash-Funktionen verwendet, um jede lokal gespeicherte Datei auf den Bloom-Filter 120 abzubilden. So wird beispielsweise die Datei „mi_crl.ver.1.1“ mit der hash_function(‚mi_crl‘) auf das Bit-Array 122 abgebildet, während die Datei „il_crl.ver.2.0“ mit hash_function(‚il_crl‘) auf das Bit-Array 122 abgebildet wird. Die Multi-Bit-Binärsequenzen, die am ersten und vierten Element des Bit-Arrays 122 gespeichert sind, bestätigen, dass diese beiden lokal gespeicherten Dateien Elemente Mitglieder des Bloom-Filters 120 sind. Der Datensatz 112A kann auch Datendatei „in_crl.ver.3.1“ enthalten, die dem sechsten Element des Bit-Arrays 122 mittels einer Hash_Funktion(‚in_crl‘) abgebildet wird; in diesem Fall bedeutet die im sechsten Element gespeicherte binäre Null-Null (00) Sequenz, dass diese bestimmte lokal gespeicherte Datei kein Element des Bloom-Filters 120 ist. Da die „in_crl“ kein Element ist, kann davon ausgegangen werden, Seederfahrzeug 110B keine Gegenstückdatei in „in_crl“ speichert. Wie vorstehend ausgeführt, kann eine Datei-ID mehrere Hash-Funktionen aufweisen und somit auf mehrere Array-Positionen abgebildet werden; wenn eine einzelne dieser Array-Positionen mit allen Nullen gefüllt wird, wird angenommen, dass die Datei-ID kein Element ist.
-
Nach Abschluss der Zugehörigkeitsidentifikation für den lokal gespeicherten Datensatz 112A führt das Trägerfahrzeug 110A einen Versionsnummernvergleich durch, indem es die Kontextdaten für jede lokal gespeicherte, von der Zugehörigkeit bestätigte Datei mit den Kontextdaten für die entsprechende extern gespeicherte Datei auswertet, um zu bestimmen, welche Version neuer ist. Angenommen, das Trägerfahrzeug 110A weiß, dass die lokal gespeicherte Datendatei „mi_crl.v1.1“ vor etwa 12 Stunden erstellt wurde (entsprechend der Kennung „01“) während die lokal gespeicherte Datendatei „il_crl.v2.0“ vor etwa zwei Monaten erstellt wurde (entsprechend der Kennung „11“). Das Trägerfahrzeug 110A ruft das in der Hash_Funktion(‚mi_crl‘) = 4 gespeicherte Bit-Array 122 auf, welches der Identifikator „10“ ist, und den in der Hash_Funktion („il_crl“) = 1 gespeicherten Zwei-Bit-Identifikator des Bit-Arrays 122, welcher der Identifikator „01“ ist. Nach dem Abrufen stellt das Trägerfahrzeug 110A fest, dass das vierte Element des Bloom-Filters 120, das 10 ist, anzeigt, dass die entfernt gespeicherte Datei eine ältere Version von „mi_crl“ ist als die lokal gespeicherte Version, die einen Aktualitätswert von „01“ aufweist. Aufgrund dieser Bestimmung lädt das Trägerfahrzeug 110A die ältere Version der Datei „mi_crl“ nicht vom Seederfahrzeug 110B herunter. Umgekehrt stellt das Trägerfahrzeug 110A fest, dass das erste Element des Bloom-Filters 120, das 01 ist, anzeigt, dass die entfernt gespeicherte Datei eine neuere Version von „il_crl“ ist als die lokal gespeicherte Version, die einen Aktualitätswert von „10“ aufweist. In diesem Fall kann das Trägerfahrzeug 110A die Inhaltsübertragung vom Seederfahrzeug 110B mit einem Upper-Layer-Protokoll für die neuere Version der Datendatei „il_crl“ einleiten.
-
Unter nunmehriger Bezugnahme auf das Flussdiagramm von 3 wird ein verbessertes Verfahren oder eine verbesserte Steuerstrategie zum Erzeugen eines Bloom-Filter-Bit-Arrays durch ein Seeder-/Senderfahrzeug, wie beispielsweise das Automobil 10 von 1 oder die Kraftfahrzeuge 110A und 110B von 2, im Allgemeinen bei 200 gemäß den Aspekten der vorliegenden Offenbarung beschrieben. Einige oder alle der in 3 veranschaulichten und hierin beschriebenen Vorgänge können repräsentativ für einen Algorithmus sein, was prozessorausführbaren Anweisungen entspricht, die beispielsweise im Haupt- oder Hilfsspeicher gespeichert werden können und beispielsweise durch eine fahrzeugseitige oder fernbetätigte Steuerung, Verarbeitungseinheit, Steuerlogikschaltung oder ein anderes Modul oder eine andere Vorrichtung ausgeführt werden können, um beliebige oder alle der vorstehend oder nachfolgend beschriebenen Funktionen auszuführen, die den offenbarten Konzepten zugeordnet sind. Es sollte angemerkt werden, dass die Reihenfolge bei der Ausführung der veranschaulichten Operationsblöcke geändert, zusätzliche Blöcke hinzugefügt und einige der beschriebenen Blöcke geändert, kombiniert oder eliminiert werden können.
-
Das Verfahren 200 beginnt an der Klemmenleiste 201 mit prozessorausführbaren Anweisungen für eine programmierbare Steuerung oder ein Steuermodul, um ein Initialisierungsverfahren für ein Protokoll zum Steuern eines P2P-Ressourcenerkennungsprozesses zwischen zwei Kraftfahrzeugen aufzurufen. In einem Beispiel kann das Initialisierungsverfahren bei Block 201 jedes Mal eingeleitet werden, wenn ein Kraftfahrzeug auf ein anderes Kraftfahrzeug trifft, das zum Ausführen eines drahtlosen V2V-Datenaustauschs kompatibel ist. Wie vorstehend im Hinblick auf die repräsentative Systemarchitektur von 2 beschrieben, kann ein Senderfahrzeug (z. B. Seederfahrzeug 110B) mit einer oder mehreren lokal gespeicherten Datendateien, die der Übertragung zugeordnet sind, das Verfahren 200 als direkte Reaktion auf die Begegnung mit einem neuen benachbarten Fahrzeug (z. B. dem Trägerfahrzeug 110A) aufrufen und ausführen. Bei Prozessblock 203 durchläuft das filtererzeugende Fahrzeug eine Liste von Metadaten für lokal gespeicherte Dateien, um festzustellen, welche Dateien kodiert und zugeordnet werden sollen. Es kann zumindest für einige Anwendungen wünschenswert sein, die in einem Seederfahrzeug installierte Fahrzeugsteuerung, wie z. B. CPU 36 und/oder Prozessoren 40 des Fahrzeugs 10 von 1, zu verwenden, um einen Satz von Datendateien zu identifizieren, die im residenten Speicher gespeichert sind, wie beispielsweise die Speichervorrichtungen 38, um sie mit einem oder mehreren Trägerfahrzeugen zu teilen. Optional kann das Fahrzeug mit einer Aufruftabelle versehen werden, die eine vorgegebene Liste von Dateien für die gemeinsame Nutzung bei jedem Aufeinandertreffen des Fahrzeugs mit einem anderen Fahrzeug auflistet; das Fahrzeug kann abgerufen und seriell durch die Liste bei Block 203 wiederholt werden.
-
Nachdem bestimmt wurde, welche Dateien gemeinsam genutzt werden dürfen, verarbeitet das Verfahren 200 weiterhin Block 205 mit prozessorausführbaren Anweisungen, um die Kontextdaten jeder Datei in einen Bitwert zum Abbilden auf den Bloom-Filter zu kodieren. Gemäß dem veranschaulichten Beispiel von 2 wandelt das Seederfahrzeug 110B die Zeitskalendaten jeder Datei in eine binäre Multi-Bit-Sequenz um, die auf der aktuellen Zeit (z. B. aus RTC 42 abgerufen) und der Ausgabezeit dieser Datei (z. B. aus den Metadaten der Datei empfangen) basiert. Das Seederfahrzeug 110B von 2 kann beispielsweise jede Datei-ID in Echtzeit kodieren oder alternativ kodierte Dateiinformationen von einer externen Quelle, wie beispielsweise dem entfernten Host-System 104 oder dem Cloud-Computing-System 106, empfangen. Um sicherzustellen, dass während des Datenaustauschs die aktuellsten Inhalte zur Verfügung stehen, kann die residierende Fahrzeugsteuerung des Seederfahrzeugs die entfernten Datei-IDs und die entsprechenden Versionsnummern der entfernten Datei für den Datensatz in Echtzeit erzeugen. Darüber hinaus kann jedes Mal, wenn ein Seederfahrzeug eine neuere Version einer Datei oder einen Ersatz für eine Datei empfängt, die aktuell gespeicherte Datei gelöscht werden, sodass das Seederfahrzeug einen neuen Bloom-Filter erzeugen kann, der nur die neueste Version von Dateien darstellt.
-
Mit weiterem Bezug auf 3 fährt das Verfahren 200 mit dem vordefinierten Operationsblock 207 fort und verwendet einen geeigneten Bloom-Filter-(BF)-Algorithmus, um jede Datei auf ein einzelnes Element oder mehrere Elemente eines Bit-Arrays des Bloom-Filters abzubilden. Es gibt viele Bloom-Filtervarianten und mehrere Bloom-Filteralgorithmen, die vorgesehen sind, um Datei-IDs und die entsprechenden kodierten Dateiversionen auf ein geeignetes Bloom-Filter-Bit-Array abzubilden. So kann beispielsweise eine erste Art von Bloom-Filteralgorithmus verwendet werden, um das Abbilden des kalibrierten Zwei-Bit-Identifikators jeder Datei auf ein einzelnes Element in der Anordnung zu optimieren, während eine zweite Art von Bloom-Filteralgorithmus verwendet werden kann, um das Abbilden jeder Datei-ID auf mehrere Elemente in der Anordnung zu optimieren, wie vorstehend beschrieben. Beim Wechsel zum Verzweigungsflussdiagramm in 3 bestimmt das Verfahren 200 im Entscheidungsblock 209, ob für eine ausgewählte Datei-ID mehr Elemente zu verarbeiten sind oder nicht. So kann beispielsweise eine einzelne Hash-Funktion verwendet werden, um eine ausgewählte Datei-ID einem einzelnen Element zuzuordnen; so gibt es nur ein Element, das für diese Datei-ID verarbeitet werden muss. Im Gegensatz dazu, wenn eine ausgewählte Datei-ID mehrere Hash-Funktionen verwendet, um diese Datei-ID auf mehrere Elemente abzubilden, wird das Verfahren 200 durch jedes Element wiederholt, um sicherzustellen, dass die Datei-ID auf alle entsprechenden Bit-Array-Positionen abgebildet wird. Wenn eine einzelne Hash-Funktion verwendet wird und/oder nur ein letztes Element für mehrere Hash-Funktionen verarbeitet werden soll, bildet das Verfahren 200 den kodierten Bitwert der Dateiversion einer gegebenen Datei-ID auf eine Einzel-/Endarray-Position am Prozessblock 207 ab, bestätigt, dass bei Block 209 (Entscheidungsblock 209 = NEIN) mehr Elemente zu verarbeiten sind, und kehrt dann zum Prozessblock 219 zurück.
-
Wo mehrere Hash-Funktionen für eine gegebene Datei-ID verwendet werden, verwendet das Verfahren 200 eine anfängliche Hash-Funktion (z. B. Hashl(‚mi_crl‘) = 3), um den Bitwert der kodierten Dateiversion (z. B. „10“) für diese Datei-ID (z. B. „mi_crl“) auf die entsprechende Array-Position (Element 3) des Bloom-Filters abzubilden, z. B. bei Prozessblock 207. Als Reaktion auf die Bestimmung, dass mehr Elemente zu verarbeiten sind (Entscheidungsblock 209 = JA), fährt das Verfahren 200 mit dem Prozessblock 211 fort und verwendet eine nachfolgende Hash-Funktion (z. B. Hash2(‚mi_crl‘)=6), um die nächste entsprechende Array-Position (Element 6) für diese Datei-ID (z. B. „mi_crl“) zu identifizieren. Beim Entscheidungsblock 213 bestimmt das Verfahren 200, ob diese Array-Position leer ist (z. B. ist das Element 6 auf Null-Null (00) gesetzt). Wenn diese Array-Position tatsächlich leer ist (Entscheidungsblock 213 = JA), fährt das Verfahren 200 mit dem Prozessblock 215 fort und füllt diese Array-Position (Element 6) mit dem Bitwert der kodierten Dateiversion (z. B. „10“) für die ausgewählte Datei-ID (z. B. „mi_crl“). Umgekehrt fährt das Verfahren 200 als Reaktion auf eine Bestimmung, dass diese Array-Position (Element 6) nicht leer ist (Entscheidungsblock 213 = NEIN), mit dem Entscheidungsblock 217 fort, um zu bestimmen, ob der Bitwert der kodierten Dateiversion der ausgewählten Datei-ID neuer ist als der aktuell an dieser Array-Position gespeicherte Bitwert. Ist dies nicht der Fall (Entscheidungsblock 217 = NEIN), kehrt das Verfahren 200 zum Entscheidungsblock 209 zurück und wiederholt diesen. Wenn jedoch der Bitwert der kodierten Dateiversion neuer ist als der gespeicherte Bitwert (Entscheidungsblock 217 = JA), füllt das Verfahren 200 die Array-Position (Element 6) responsiv mit dem neueren Bitwert der kodierten Dateiversion am Prozessblock 215.
-
Nachdem der Bitwert der kodierten Dateiversion einer gegebenen Datei-ID an allen entsprechenden Array-Positionen, wie vorstehend beschrieben, in das BF-Array eingefügt wurde, fährt das Verfahren 200 mit dem Entscheidungsblock 221 fort, um zu bestimmen, ob noch weitere Dateien vorhanden sind, die mit dem Bloom-Filter zugeordnet werden sollen. Wenn noch Dateien vorhanden sind, die für den Bloom-Filter kodiert werden müssen (Entscheidungsblock 221 = JA), kehrt das Verfahren 200 zum Prozessblock 203 zurück und wiederholt die vorstehend beschriebenen Schritte. Umgekehrt, wenn bestimmt wird, dass keine weiteren Dateien mehr vorhanden sind (Entscheidungsblock 221 = NEIN), fährt das Verfahren 200 mit dem Prozessblock 223 fort und sendet den Bloom-Filter. Das Verfahren 200 kann danach am Klemmenblock 225 enden.
-
Unter nunmehriger Bezugnahme auf das Flussdiagramm von 4 wird ein verbessertes Verfahren oder eine verbesserte Steuerstrategie zum Parsen eines empfangenen Bloom-Filter-Bit-Arrays durch ein Kraftfahrzeug, wie beispielsweise das Automobil 10 von 1 oder die Kraftfahrzeuge 110A und 110B von 2, im Allgemeinen bei 300 gemäß den Aspekten der vorliegenden Offenbarung beschrieben. Einige oder alle der in 4 veranschaulichten und hierin beschriebenen Vorgänge können repräsentativ für einen Algorithmus sein, was prozessorausführbaren Anweisungen entspricht, die beispielsweise im Haupt- oder Hilfsspeicher gespeichert werden können und beispielsweise durch eine fahrzeugseitige oder fernbetätigte Steuerung, Verarbeitungseinheit, Steuerlogikschaltung oder ein anderes Modul oder eine andere Vorrichtung ausgeführt werden können, um beliebige oder alle der vorstehend oder nachfolgend beschriebenen Funktionen auszuführen, die den offenbarten Konzepten zugeordnet sind. Es sollte angemerkt werden, dass die Reihenfolge bei der Ausführung der veranschaulichten Operationsblöcke geändert, zusätzliche Blöcke hinzugefügt und einige der beschriebenen Blöcke geändert, kombiniert oder eliminiert werden können. So können beispielsweise die Verfahren 200 und 300 der 3 und 4 zu einem einzigen Steuerlogikprotokoll kombiniert werden, um einen V2V-Datenaustausch zwischen einem oder mehreren Trägerfahrzeugen und einem oder mehreren Seederfahrzeugen durchzuführen.
-
Das Verfahren 300 beginnt am Klemmenblock 301 mit prozessorausführbaren Anweisungen für eine programmierbare Steuerung oder ein Steuermodul, um ein Initialisierungsverfahren für ein Protokoll zum Einleiten eines P2P-Ressourcenerkennungsprozesses zwischen zwei Kraftfahrzeugen aufzurufen. Rückblickend auf das Beispiel von 2 wird ein erstes (Träger)-Fahrzeug 110A dargestellt, das in die Nähe eines zweiten (Seeder)-Fahrzeugs 110B fährt; das Trägerfahrzeug 110A kann eine Aufforderung an das Seederfahrzeug 110B senden, um eine Kommunikation einzuleiten. Wenn sich die beiden Fahrzeuge 110A, 110B in Übertragungsreichweite befinden, z. B. der jeweiligen DSRC-Komponente 48 des anderen, kann eine residente Fahrzeugsteuerung, wie beispielsweise die CPU 36 von 1, bestimmen, dass eine drahtlose Verbindung zwischen den beiden Fahrzeugen hergestellt wurde. Das Trägerfahrzeug 110A kann daraufhin eine Aufforderung zum Einleiten eines Ressourcenerkennungsprozesses senden, um die über die residente Speichervorrichtung des Seederfahrzeugs gespeicherten Daten zum Speichern über die residente Speichervorrichtung des Trägerfahrzeugs abzurufen.
-
Zeitgleich mit oder nach dem Vervollständigen des Protokolls am Klemmenblock 301 verarbeitet das Verfahren 300 weiterhin den Block 303 mit prozessorausführbaren Anweisungen für ein Empfängerfahrzeug, z. B. das Trägerfahrzeug 110A von 2, zum Empfangen eines Bloom-Filters. Wie vorstehend angegeben, kann eine drahtlose Kommunikationsvorrichtung eines Seederfahrzeugs 110B einen Bloom-Filter an ein Trägerfahrzeug 110A übertragen, z. B. bei Prozessblock 223 von 3. Nach dem Empfangen wählt eine residente Fahrzeugsteuerung des Empfangsfahrzeugs eine Datei-ID für eine vorhandene Datei aus, die Teil eines im residenten Speicher, bei Prozessblock 305, gespeicherten Dateisatzes ist. Wie vorstehend erläutert, verwaltet jedes Fahrzeug eine Liste von Datei-Metadaten (z. B. Dateiname, Dateigröße, Dateiversion, Dateiursprung usw.); das Trägerfahrzeug wählt eine Datei aus der Liste der Datei-Metadaten aus. Nachdem eine lokale Datei ausgewählt wurde, fährt das Verfahren mit dem vordefinierten Operationsblock 307 fort, um zu bestimmen, ob die ausgewählte lokale Datei-ID ein Mitglied des empfangenen Bloom-Filters ist oder nicht (z. B. ist bereits eine entfernte Gegenstück-Datei-ID dem Bit-Array des empfangenen Bloom-Filters zugeordnet) und wenn ja, ob die lokale Datei-ID eine neuere Gegenstück-Datei auf dem Seederfahrzeug gespeichert hat oder nicht.
-
Beim Übergang zum Verzweigungsflussdiagramm in 4 fährt das Verfahren 300 mit dem Prozessblock 309 fort und ruft alle abgebildeten Elemente aus dem empfangenen Bloom-Filter für die entsprechende extern gespeicherte Datendatei ab. Wenn eine einzelne Hash-Funktion für eine ausgewählte Datei-ID verwendet wird, muss nur eine einzige Array-Position identifiziert und der gespeicherte Bitwert für diese ausgewählte Datei-ID abgerufen werden. Wenn jedoch mehrere Hash-Funktionen für eine ausgewählte Datei-ID verwendet werden, müssen mehrere Array-Positionen mit ihren jeweiligen Bitwerten identifiziert werden, die für diese ausgewählte Datei-ID abgerufen werden. Nach dem Abrufen bestimmt das Verfahren 300 beim Entscheidungsblock 311, ob mindestens eines der abgerufenen Elemente leer ist oder nicht. Mit anderen Worten, wenn eine einzelne der im Prozessblock 309 identifizierten Array-Positionen auf Null gesetzt wird, ist die Auswahldatei kein Element des empfangenen Bloom-Filters und somit existiert keine Gegendatei am entfernten (Seeder)-Fahrzeug. Als Reaktion auf eine Bestimmung, dass mindestens ein Element tatsächlich leer ist (Entscheidungsblock 311 = JA), fährt das Verfahren 300 mit dem Operationsblock 313 fort und setzt ein Kennzeichen, um daran zu erinnern, dass die Ergebnisse der Elementidentifikationstests anzeigen, dass ein Gegenstück zur ausgewählten lokalen Datei nicht am entfernten Fahrzeug vorhanden ist. Das Verfahren 300 würde danach zu Prozessblock 323 zurückkehren, ohne eine Gegendatei vom entfernten Fahrzeug abzurufen, dann zu Prozessblock 325 über die Ergebnisse des Zugehörigkeitstests und der Versionsprüfung zu informieren, und dann zu Entscheidungsblock 327, um zu bestimmen, ob noch lokal gespeicherte Dateien vorhanden sind, die den Zugehörigkeitstest und Versionstest für den empfangenen Bloom-Filter abschließen sollten.
-
Wenn das Verfahren 300 bestimmt, dass keines der abgerufenen Elemente leer ist (Entscheidungsblock 311 = NEIN), führt das Fahrzeug die Anweisungen des Prozessblocks 315 aus, um das älteste Element unter allen abgebildeten Elementen zu identifizieren, die im Prozessblock 309 abgerufen wurden. In Fortführung des vorstehenden Beispiels ruft das Trägerfahrzeug 110A von der CPU 36 drei kalibrierte Zwei-Bit-Identifikatoren ab: einen für das Element 3 (z. B. den Wert „01“), einen für das Element 6 (z. B. den Wert „01“) und einen für das Element 10 (z. B. den Wert „10“). Im repräsentativen Fall ist das „älteste“ der abgerufenen Elemente „10“, was eine Datei darstellt, die vor mehr als 24 Stunden, aber weniger als einer Woche erstellt wurde. Bei Entscheidungsblock 317 bestimmt das Verfahren 300, ob die lokale Datei neuer ist als die entfernte Datei, indem es den Bitwert der kodierten Dateiversion für die lokal gespeicherte Auswahldatei mit dem Bitwert vergleicht, der beim Prozessblock 315 abgerufen wurde. Als nicht einschränkendes Beispiel kann die lokale Datei einen Aktualitätswert von 01 aufweisen; in diesem Fall schlussfolgert das Trägerfahrzeug, dass die Aktualitätsnummer 10 der entfernten Fahrzeugdatei eine ältere Dateiversionsnummer ist. Das Verfahren 300 reagiert auf das Bestimmen, dass die lokale Datei nicht neuer als die entfernte Datei ist (Entscheidungsblock 317 = NEIN), indem es ein Kennzeichen bei Prozessblock 319 setzt, um anzuzeigen, dass eine neuere Gegendatei im entfernten Fahrzeug vorhanden ist, zum Prozessblock 323 mit der Anforderung zurückkehrt, die neuere Gegendatei vom entfernten Fahrzeug abzurufen, und dann zu Prozessblock 325 übergeht, um andere Module über die Ergebnisse des Zugehörigkeitstests und des Versionstests zu informieren. Umgekehrt, wenn die lokale Datei nicht neuer ist als die entfernte Datei (Entscheidungsblock 317 = JA), reagiert das Verfahren 300 mit dem Setzen eines Kennzeichens bei Prozessblock 321, um anzuzeigen, dass keine neuere Gegendatei im entfernten Fahrzeug vorhanden ist, kehrt zu Prozessblock 323 zurück, ohne eine Gegendatei vom entfernten Fahrzeug abzurufen, und fährt dann mit Prozessblock 325 fort, um andere Module über die Ergebnisse des Zugehörigkeitstests und des Versionstests zu informieren. Nachdem das Verfahren 300 alle relevanten Dateien des Trägerfahrzeugs (Entscheidungsblock 327 = NEIN) durchlaufen hat, kann das Verfahren 300 am Klemmenblock 329 enden.
-
Aspekte dieser Offenbarung können in einigen Ausführungsformen durch ein computerausführbares Programm von Anweisungen implementiert werden, wie zum Beispiel Programmmodulen, die allgemein als Softwareanwendungen oder Anwendungsprogramme bezeichnet werden, die von einem Fahrzeug-Bordcomputer oder ein verteiltes Netzwerk von residenten und entfernten Rechenvorrichtungen ausgeführt werden. Die Software kann in nicht einschränkenden Beispielen Routinen, Programme, Objekte, Komponenten und Datenstrukturen beinhalten, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Software kann eine Schnittstelle bilden, damit ein Computer entsprechend einer Eingabequelle reagieren kann. Die Software kann auch mit anderen Codesegmenten zusammenarbeiten, um eine Vielzahl von Aufgaben in Reaktion auf Daten zu initiieren, die in Verbindung mit der Quelle der empfangenen Daten empfangen werden. Die Software kann auf einem beliebigen einer Vielzahl von Speichermedien, wie CD-ROM, Magnetplatte, Blasenspeicher und Halbleiterspeicher (z. B. verschiedene Arten von RAM oder ROM), gespeichert sein.
-
Darüber hinaus können Aspekte der vorliegenden Offenbarung mit einer Vielzahl von Computersystem- und Computernetzkonfigurationen einschließlich Mehrprozessorsystemen, Mikroprozessor-basierter oder programmierbarer Unterhaltungselektronik, Minicomputern, Mainframe-Computern und dergleichen durchgeführt werden. Zusätzlich können Aspekte der vorliegenden Offenbarung in Umgebungen mit verteilter Datenverarbeitung ausgeführt werden, bei denen Aufgaben durch Fernverarbeitungsvorrichtungen ausgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Computerumgebung können Programmmodule sowohl auf lokalen als auch entfernten Computerspeichermedien einschließlich Speichergeräten angeordnet sein. Aspekte der vorliegenden Offenbarung können daher in Verbindung mit verschiedener Hardware, Software oder einer Kombination davon in einem Computersystem oder einem anderen Verarbeitungssystem implementiert werden.
-
Jedes der hierin beschriebenen Verfahren kann maschinenlesbare Anweisungen zur Ausführung beinhalten durch: (a) einen Prozessor, (b) eine Steuerung, und/oder (c) jede andere geeignete Verarbeitungsvorrichtung. Jeder hierin offenbarte Algorithmus, jede Software oder jedes Verfahren kann in einer Software enthalten sein, die auf einem greifbaren Medium, wie beispielsweise einem Flash-Speicher, einer CD-ROM, einer Diskette, einer Festplatte, einer Digital Versatile Disk (DVD) oder andere Speichervorrichtungen, gespeichert ist, jedoch werden Fachleute leicht erkennen, dass der gesamte Algorithmus und/oder Teile davon alternativ durch eine andere Vorrichtung als eine Steuerung ausgeführt werden können und/oder in Firmware oder dedizierter Hardware in einer verfügbaren Art und Weise implementiert werden können (z. B. kann er durch einen anwendungsspezifischen integrierter Schaltkreis (Application Specific Integrated Circuit), eine programmierbare Logikvorrichtung (PLD), eine feldprogrammierbare Logikvorrichtung (FPLD), eine diskrete Logik usw. implementiert werden). Obwohl spezielle Algorithmen unter Bezugnahme auf die hier dargestellten Flussdiagramme beschrieben werden, wird der Durchschnittsfachmann leicht erkennen, dass viele andere Verfahren zum Implementieren der exemplarischen maschinenlesbaren Anweisungen alternativ verwendet werden können.
-
Aspekte der vorliegenden Offenbarung wurden im Detail unter Bezugnahme auf die dargestellten Ausführungsformen beschrieben; der Fachmann wird jedoch erkennen, dass viele Änderungen daran vorgenommen werden können, ohne vom Umfang der vorliegenden Offenbarung abzuweichen. Die vorliegende Offenbarung ist nicht beschränkt auf die hierin offenbarte genaue Konstruktion und Zusammensetzung; jegliche und alle Modifikationen, Änderungen und Variationen, ersichtlich aus den vorangehenden Beschreibungen, liegen innerhalb des Umfangs der Offenbarung, wie durch die hinzugefügten Ansprüchen definiert. Darüber hinaus beinhalten die vorliegenden Konzepte ausdrücklich alle Kombinationen und Teilkombinationen der vorangehenden Elemente und Merkmale.
