DE102020102539A1

DE102020102539A1 - Verteilter entfernter datenanforderungsoperator

Info

Publication number: DE102020102539A1
Application number: DE102020102539.4A
Authority: DE
Inventors: Benjamin M. Rocci; Mark Anthony ROCKWELL
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2019-02-02
Filing date: 2020-01-31
Publication date: 2020-08-06
Also published as: CN111526174A; US20200250252A1

Abstract

Diese Offenbarung stellt einen verteilten entfernten Datenanforderungsoperator bereit. Diagnoseerfordernisse, die Fahrzeugdatenerfordernisse konkretisieren, werden von Anforderervorrichtungen empfangen. Fahrzeuge und Zeiträume zum Sammeln von Diagnosedaten von den Fahrzeugen werden anhand der Diagnoseerfordernisse identifiziert. Die Diagnosedaten werden periodisch von den Fahrzeugen gemäß der Identifizierung gesammelt. Die Diagnosedaten werden zusammengestellt, um zusammengestellte Daten entsprechend den Diagnoseerfordernissen zu erzeugen. Die zusammengestellten Daten werden an die Anforderervorrichtungen gesendet.

Description

GEBIET DER TECHNIK
Aspekte der Offenbarung betreffen im Allgemeinen einen hochgradig verteilten entfernten Datenanforderungsoperator.
ALLGEMEINER STAND DER TECHNIK
Automobildiagnosedaten, wie etwa Diagnosefehlercodes (Diagnostic Trouble Codes - DTCs), bilden kompakte, informative Nachrichten. Die Diagnosedaten sind dazu ausgelegt, den Fahrzeugsteuerungen zu ermöglichen, einen Systemfehler und/oder einen Reparaturbedarf anzugeben.
KURZDARSTELLUNG
In einem oder mehreren veranschaulichenden Beispielen beinhaltet ein System einen Server mit einem Hardwareprozessor Der Prozessor ist dazu programmiert, Diagnoseerfordernisse, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen zu empfangen, anhand der Diagnoseerfordernisse Fahrzeuge und Zeiträume zum Sammeln von Diagnosedaten von den Fahrzeugen zu identifizieren, periodisch die Diagnosedaten von den Fahrzeugen gemäß der Identifizierung zu sammeln, die Diagnosedaten zusammenzustellen, um zusammengestellte Daten entsprechend den Diagnoseerfordernissen zu erzeugen, und die zusammengestellten Daten an die Anforderervorrichtungen zu senden.
In einem oder mehreren veranschaulichenden Beispielen beinhaltet ein Verfahren Empfangen von Diagnoseerfordernissen, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen; periodisches Senden von Diagnoseanforderungen an Fahrzeuge bezogen auf die Diagnoseerfordernisse, wobei die Fahrzeuge dahingehend identifiziert werden, dass sie mit Fahrzeugauswahlkriterien übereinstimmen, die in den Diagnoseanforderungen beinhaltet sind, wobei der Zeitraum zum Sammeln von Daten von den Fahrzeugen gemäß einer Zählung der Fahrzeuge und einer zu erfassenden Datenmenge, die durch die Diagnoseerfordernisse konkretisiert ist, identifiziert werden; periodisches Empfangen, von den Fahrzeugen, einer Vielzahl von Diagnosedatennachrichten, von denen jede einen Teil der gemäß den Diagnoseanforderungen angeforderten Informationen beinhaltet; Zusammenstellen von Daten entsprechend den Diagnoseerfordernissen zu zusammengestellten Daten; und Senden der zusammengestellten Daten an die Anforderervorrichtungen.
In einem oder mehreren veranschaulichenden Beispielen umfasst ein computerlesbares Medium Anweisungen, die bei Ausführung durch einen Prozessor eines Fahrzeugdatenservers den Prozessor dazu veranlassen, Diagnoseerfordernisse, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen zu empfangen; periodisch Diagnoseanforderungen an Fahrzeuge bezogen auf die Diagnoseerfordernisse zu senden, wobei die Fahrzeuge dahingehend identifiziert werden, dass sie mit Fahrzeugauswahlkriterien übereinstimmen, die in den Diagnoseanforderungen beinhaltet sind, wobei der Zeitraum zum Sammeln von Daten von den Fahrzeugen gemäß einer Zählung der Fahrzeuge und einer zu erfassenden Datenmenge, die durch die Diagnoseerfordernisse konkretisiert ist, identifiziert werden; periodisch von den Fahrzeugen eine Vielzahl von Diagnosedatennachrichten zu empfangen, von denen jede einen Teil der gemäß den Diagnoseanforderungen angeforderten Informationen beinhaltet; Daten entsprechend den Diagnoseerfordernissen zu zusammengestellten Daten zusammenzustellen; und die zusammengestellten Daten an die Anforderervorrichtungen zu senden.
Figurenliste

1 veranschaulicht ein beispielhaftes System, das einen verteilten entfernten Datenanforderungsoperator umsetzt;
2 veranschaulicht ein beispielhaftes Diagramm des Betriebs des entfernten Datenanforderungsdienstes zum Erfassen von Diagnosedaten über eine Vielzahl von Zeiträumen; und
3 veranschaulicht einen beispielhaften Prozess zum Zusammenstellen von Daten von Fahrzeugen unter Verwendung eines entfernten Datenanforderungsdienstes.

DETAILLIERTE BESCHREIBUNG
In der vorliegenden Schrift werden ausführliche Ausführungsformen der vorliegenden Erfindung wie erforderlich offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen für die Erfindung, die in verschiedenartigen und alternativen Formen ausgeführt werden kann, lediglich beispielhaft sind. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Demnach sind in dieser Schrift offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielfältige Verwendung der vorliegenden Erfindung zu lehren.
Fahrzeugdaten via Luftschnittstelle sind kostspielig, wenn sie in unkontrollierten umfangreichen Mengen gesammelt werden. Somit sollte die Größe der via Luftschnittstelle zu sammelnden Daten eingeschränkt werden. Allerdings erfordert das Überprüfen und Ausführen einer Datenanforderung via Luftschnittstelle Zeit und Aufwand. Idealerweise ist eine große Datenprobe pro Ausführungsvorgang der Datenanforderung zu sammeln. Um von der Datensammlung via Luftschnittstelle zu profitieren, ist es für den Ausführungsprozess der Anforderung wünschenswert, hochwertige Daten aus einer statistisch repräsentativen Probengröße zu erhalten.
Eine verbesserte Anwendung für die Datensammlung via Luftschnittstelle kann dazu programmiert sein, die Anforderung von Daten zu automatisieren, um Datenanforderungen via Luftschnittstelle hinsichtlich statistisch zufälliger Proben einer benutzerdefinierten Vielfalt in einer benutzerdefinierten Kadenz und Größe auszuführen In einem Beispiel kann ein Benutzer A 100 Byte Daten von 1.000.000 roten 4x4-Fahrzeugen im Laufe der folgenden 30 Tage anfordern. Diese Datenanforderungsinformationen können einem hochgradig verteilten entfernten Datenanforderungsdienst bereitgestellt werden. Der entfernte Datenanforderungsdienst kann dazu konfiguriert sein, sich in ein Datenauswahl-Tool einzuklinken sowie die Datenanforderung hinsichtlich eines gewünschten Satzes von Fahrzeugen der gewünschten Art jeden Tag durchzuführen. Mit weiterer Bezugnahme auf das Beispiel der 100 Byte Daten von 1.000.000 Fahrzeugen kann das System an jedem Tag eines Monats 100 Byte Daten von 33.333 Fahrzeugen anfordern. Weitere Aspekte werden ausführlich in dieser Schrift erörtert.
1 veranschaulicht ein beispielhaftes System 100, das einen verteilten entfernten Datenanforderungsoperator umsetzt. Wie veranschaulicht, beinhaltet ein Fahrzeug 102 eine Vielzahl von Fahrzeugsteuerungen 104, die über einen oder mehrere Fahrzeugbusse 106 in Kommunikation stehen. Das System 100 beinhaltet zudem einen Fahrzeugdatenserver 126, der dazu konfiguriert ist, von verschiedenen Fahrzeugen 102 empfangene Diagnosedaten 120 zu hinterlegen. Das Fahrzeug 102 beinhaltet ferner eine Telematiksteuereinheit (telematics control unit) 108, die dazu konfiguriert ist, Diagnosedaten 120, einschließlich Diagnoseinformationen, an den Fahrzeugdatenserver 126 zu senden. Die TCU 108 kann eine Datendienstanwendung 130 nutzen, die in der TCU 108 installiert ist, um Diagnoseanforderungen 122, die von dem Fahrzeug 102 abzurufende Daten definieren, zu verarbeiten und die Diagnosedaten 120 an den Fahrzeugdatenserver 126 zu senden. Der Fahrzeugdatenserver 126 kann einen entfernten Datenanforderungsdienst 134 nutzen, um basierend auf Diagnoseerfordernissen 124 zu bestimmen, welche Fahrzeuge 102 welche Diagnoseanforderungen 122 empfangen sollen, sowie um die Diagnosedaten 120 zu empfangen und zusammenzustellen. Es ist anzumerken, dass das System 100 lediglich ein Beispiel darstellt und dass andere Anordnungen oder Kombinationen von Elementen verwendet werden können.
Bei dem Fahrzeug 102 kann es sich um verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländelimousinen (sport utility vehicle - SUV), Trucks, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern handeln. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine angetrieben werden. Als eine weitere Möglichkeit kann es sich bei dem Fahrzeug 102 um ein Hybrid-Elektrofahrzeug (hybrid electric vehicle - HEV) handeln, das sowohl durch eine Brennkraftmaschine als auch durch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (parallel hybrid electrical vehicle - PHEV) oder ein Parallel/Serienhybrid-Elektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV). Da die Art und Konfiguration des Fahrzeugs 102 variieren können, können auch die Fähigkeiten des Fahrzeugs 102 entsprechend variieren. Um einige weitere Möglichkeiten zu nennen, können die Fahrzeuge 102 unterschiedliche Eigenschaften in Bezug auf die Fahrgastkapazität, die Abschleppfähigkeit und -kapazität und den Stauraum aufweisen. Für Titel, Bestand und andere Zwecke können die Fahrzeuge 102 mit einmaligen Kennungen assoziiert werden, wie zum Beispiel FINs.
Das Fahrzeug 102 kann eine Vielzahl von Steuerungen 104 beinhalten, die dazu konfiguriert sind, verschiedene Funktion des Fahrzeugs 102, die von der Batterie und/oder dem Antriebsstrang des Fahrzeugs versorgt werden, durchzuführen und zu verwalten. Wie in der Abbildung sind die beispielhaften Fahrzeugsteuerungen 104 als diskrete Steuerungen 104-A bis 104-G dargestellt. Die Fahrzeugsteuerungen 104 können jedoch physische Hardware, Firmware und/oder Software gemein haben, sodass die Funktionen mehrerer Steuerungen 104 in eine einzelne Steuerung 104 integriert sein können und die Funktionen verschiedener dieser Steuerungen 104 über eine Vielzahl von Steuerungen 104 verteilt sein können.
Um einige nicht einschränkende Beispiele für die Fahrzeugsteuerungen 104 zu nennen: eine Antriebsstrangsteuerung 104-A kann dazu konfiguriert sein, eine Steuerung von Motorbetriebskomponenten (z. B. Leerlaufsteuerkomponenten, Kraftstoffabgabekomponenten, Emissionssteuerkomponenten usw.) und das Überwachen des Status solcher Motorbetriebskomponenten (z. B. Status von Motorcodes) bereitzustellen; eine Karosseriesteuerung 104-B kann dazu konfiguriert sein, verschiedene Leistungssteuerfunktionen, wie etwa Außenbeleuchtung, Innenbeleuchtung, schlüssellosen Zugang, Fernstart und Statusverifizierung von Zugriffspunkten (z. B. Schließstatus der Motorhaube, der Türen oder des Kofferraums des Fahrzeugs 102), zu verwalten; eine Funksendeempfängersteuerung 104-C kann dazu konfiguriert sein, mit Schlüsselanhängern, mobilen Vorrichtungen oder anderen lokalen Vorrichtungen des Fahrzeugs 102 zu kommunizieren; eine Unterhaltungssteuerung 104-D kann dazu konfiguriert sein, Sprachbefehle und BLUETOOTH-Schnittstellen mit dem Fahrer und Fahrermobilvorrichtungen zu unterstützen; eine Klimasteuerverwaltungssteuerung 104-E kann dazu konfiguriert sein, eine Steuerung von Komponenten des Heiz- und Kühlsystems (z. B. Verdichterkupplung, Gebläselüfter, Temperatursensoren usw.) bereitzustellen; eine Steuerung für ein globales Positionsbestimmungssystem (global positioning system - GPS) 104-F kann dazu konfiguriert sein, Fahrzeugstandortinformationen bereitzustellen; und eine Steuerung für eine Mensch-Maschine-Schnittstelle (human-machine interface - HMI) 104-G kann dazu konfiguriert sein, Benutzereingaben über verschiedene Schaltflächen oder andere Steuerungen zu empfangen sowie Fahrzeugstatusinformationen, wie etwa Füllstandinformationen, Motorbetriebstemperaturinformationen und den aktuellen Standort des Fahrzeugs 102, an einen Fahrer bereitzustellen.
Der Fahrzeugbus 106 kann verschiedene Kommunikationsverfahren beinhalten, die zwischen den elektronischen Steuereinheiten (electronic control units - ECUs) 104 des Fahrzeugs sowie zwischen der TCU 108 und den Fahrzeug-ECUs 104 verfügbar sind. Um einige nicht einschränkende Beispiele zu nennen, kann der Fahrzeugbus 106 ein oder mehrere von einem Fahrzeug-Controller-Area-Network (CAN), einem Ethernet-Netzwerk und einem Media-Oriented-System-Transfer-Netzwerk (MOST-Netzwerk) beinhalten. Weitere Aspekte des Layouts und der Anzahl von Fahrzeugbussen 106 werden nachstehend ausführlicher erörtert.
Die TCU 108 kann Netzwerkhardware beinhalten, die dazu konfiguriert ist, die Kommunikation zwischen den Fahrzeug-ECUs 104 und anderen Vorrichtungen des Systems 100 zu ermöglichen. Die TCU 108 kann zum Beispiel ein Mobilfunkmodem 110, das dazu konfiguriert ist, eine Kommunikation mit einem Weitverkehrsnetzwerk 112 zu ermöglichen, beinhalten oder anderweitig auf ein solches zugreifen. Das Weitverkehrsnetzwerk 112 kann ein oder mehrere miteinander verbundene Kommunikationsnetzwerke, wie etwa, als einige nicht einschränkende Beispiele, das Internet, ein Kabelfernsehverteilungsnetzwerk, ein Satellitenverbindungsnetzwerk, ein lokales Netzwerk und ein Telefonnetzwerk, beinhalten. Als ein weiteres Beispiel kann die TCU 108 eines oder mehrere von Vernetzung über ein BLUETOOTH-, Wi-Fi- oder drahtgebundenes USB-Netzwerk nutzen, um eine Kommunikation mit dem Weitverkehrsnetzwerk 112 über die mobile Vorrichtung des Benutzers zu ermöglichen.
Die TCU 108 kann ferner verschiedene Arten von Rechenvorrichtungen zur Unterstützung der Durchführung der Funktionen der in dieser Schrift beschriebenen TCU 108 beinhalten. In einem Beispiel kann die TCU 108 einen oder mehrere Prozessoren 114, die zum Ausführen von Computeranweisungen konfiguriert sind, und ein Speichermedium 116, in dem die computerausführbaren Anweisungen und/oder Daten hinterlegt werden können, beinhalten. Ein computerlesbares Speichermedium (auch als prozessorlesbares Medium oder prozessorlesbarer Speicher 116 bezeichnet) beinhaltet ein beliebiges nichttransitorisches (z. B. greifbares) Medium, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von dem/den Prozessor(en)) ausgelesen werden können. Im Allgemeinen empfängt der Prozessor 114 Anweisungen und/oder Daten, z. B. von dem Speicher 116 usw., in einem Arbeitsspeicher und führt die Anweisungen unter Verwendung der Daten aus, wodurch ein oder mehrere Prozesse, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Prozesse, durchgeführt werden. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder ausgewertet werden, die unter Verwendung einer Reihe von Programmiersprachen und/oder -technologien erzeugt wurden, einschließlich unter anderem und entweder für sich oder in Kombination JAVA, C, C++, C#, FORTRAN, PASCAL, VISUAL BASIC, PYTHON, JAVA SCRIPT, PERL, PL/SQL usw.
Die TCU 108 kann dazu konfiguriert sein, eine oder mehrere Schnittstellen zu beinhalten, von denen Fahrzeuginformationen gesendet und empfangen werden können. In einem Beispiel kann die TCU 108 dazu konfiguriert sein, die Sammlung von DTC-Daten und/oder anderer Fahrzeuginformationen von den Fahrzeugsteuerungen 104 zu ermöglichen, die mit einem oder mehreren Fahrzeugbussen 106 verbunden sind. Wenngleich nur ein einzelner Bus 106 veranschaulicht ist, sollte angemerkt werden, dass in vielen Beispielen mehrere Fahrzeugbusse 106 enthalten sind, wobei ein Teilsatz der Steuerungen 104 mit jedem Bus 106 verbunden ist. Um auf eine bestimmte Steuerung 104 zuzugreifen, kann die TCU 108 dementsprechend dazu konfiguriert sein, eine Zuordnung dafür zu hinterlegen, welche Busse 106 mit welchen Steuerungen 104 verbunden sind, und auf den entsprechenden Bus 106 für eine Steuerung 104 zuzugreifen, wenn eine Kommunikation mit der konkreten Steuerung 104 gewünscht wird.
Die von den Steuerungen 104 über die Fahrzeugbusse 106 abgerufenen gesammelten Informationen können als Diagnosedaten 120 bezeichnet werden. Die TCU 108 kann die gesammelten Diagnosedaten 120 in dem Speicher 116 der TCU 108 oder, in anderen Beispielen, in einem anderen Speicher zur Kommunikation mit der TCU 108 speichern. Die durch die TCU 108 abgerufenen Fahrzeuginformationen können als einige nicht einschränkende Beispiele Gaspedalposition, Lenkradwinkel, Fahrzeuggeschwindigkeit, Fahrzeugstandort (z. B. GPS-Koordinaten usw.), einmalige Kennung des Fahrzeugs (z. B. FIN), Umdrehungen pro Minute (U/min) des Motors und Fahrzeug-HMI-Informationen, wie etwa Informationen bezüglich des Drückens einer Lenkradschaltfläche, beinhalten. Somit können die Diagnosedaten 120 gesammelte DTC-Informationen und/oder andere in dem Speicher 116 der TCU 108 gespeicherte Informationen beinhalten.
Die Diagnoseanforderungen 122 beinhalten Informationen, die von den Fahrzeugen 102 zu erfassende Diagnoseelemente, -codes oder andere Informationen definieren. Die Diagnoseanforderungen 122 können an das Fahrzeug 102 gesendet werden, und das Fahrzeug 102 kann als Reaktion darauf die Diagnosedaten 120 wiedergeben.
Diagnoseerfordernisse 124 können verwendet werden, um Datenanforderungsinformationen zu definieren, welche die Diagnosecodes oder andere Informationen angeben, die über Diagnoseanforderungen 122 von den Fahrzeugen 102 als Diagnosedaten 120 angefordert werden sollen. Die Diagnoseerfordernisse 124 können ferner Fahrzeugauswahlkriterien beinhalten, die Attribute der Fahrzeuge 102 konkretisieren, welche die Diagnosedaten 120 bereitstellen sollten. In einem Beispiel können diese Attribute eines oder mehrere von Folgendem beinhalten: eine Marke eines Fahrzeugs 102, ein Modell eines Fahrzeugs 102, ein Baujahr eines Fahrzeugs 102, eine Fahrzeugidentifikationsnummer (FIN) eines Fahrzeugs 102 oder ein FIN-Bereich des Fahrzeugs 102. Die Diagnoseerfordernisse 124 können zudem Informationen bezüglich der Probengröße beinhalten, die eine Menge der Diagnosedaten 120 und/oder der Fahrzeuge 102, welche die Diagnosedaten 120 bereitstellen sollen, angeben.
Der Fahrzeugdatenserver 126 und eine Anforderervorrichtung 128 können jeweils verschiedene Arten von Rechenvorrichtungen beinhalten, wie etwa eine Computer-Arbeitsstation, einen Server, einen Desktop-Computer, eine virtuelle Serverinstanz, die durch einen Großrechner-Server ausgeführt wird, oder ein(e) andere(s) Rechensystem und/oder -vorrichtung. Ähnlich der TCU 108 beinhalten der Fahrzeugdatenserver 126 und die Anforderervorrichtung 128 im Allgemeinen einen Arbeitsspeicher, in dem computerausführbare Anweisungen hinterlegt werden können, wobei die Anweisungen durch einen oder mehrere Prozessoren (aus Gründen der Eindeutigkeit nicht gezeigt) ausführbar sein können. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert werden. In einem Beispiel kann der Fahrzeugdatenserver 126 dazu konfiguriert sein, die von der TCU 108 des Fahrzeugs 102 über das Netzwerk 112 empfangenen Diagnosedaten 120 zu hinterlegen.
Die Anforderervorrichtung 128 kann verwendet werden, um einem Operator zu ermöglichen, die Diagnoseerfordernisse 124 zu konfigurieren, welche durch den Fahrzeugdatenserver 126 verwendet werden, um die Diagnoseanforderungen 122 zu senden. In einem Beispiel kann ein Benutzer der Anforderervorrichtung 128 einen oder mehrere von einem Satz von Fahrzeugen 102 zu erfassenden Diagnosecodes konkretisieren. Der Benutzer kann zudem konkretisieren, welche Fahrzeuge 102 die Diagnoseanforderungen 122 empfangen sollen (z. B. Marke, Modell, FIN-Bereich usw.), sowie andere Details, wie etwa wie viele Diagnosedaten 120 gesammelt werden sollen, von wie vielen Fahrzeugen 102 die Diagnosedaten 120 gesammelt werden sollen, und über welchen Zeitrahmen die Diagnosedaten 120 gesammelt werden sollen.
Die Datendienstanwendung 130 kann eine Anwendung sein, die in dem Speicher 116 der TCU 108 beinhaltet ist. Die Datendienstanwendung 130 kann Anweisungen beinhalten, die bei Ausführung durch den Prozessor 114 der TCU 108 die TCU 108 dazu veranlassen, Funktionen periodisch und/oder als Reaktion auf den Empfang der Diagnoseanforderungen 122 von dem Fahrzeugdatenserver 126 durchzuführen. Diese Funktionen können periodisches Sammeln von Informationen bezüglich der Diagnosedaten 120 von den Steuerungen 104 (z. B. einschließlich DTC-Informationen) basierend auf von dem Fahrzeugdatenserver 126 empfangenen Diagnoseanforderungen 122; Speichern der Informationen zur Übertragung und Übertragen der Diagnosedaten 120 über das Weitverkehrsnetzwerk 112 an den Fahrzeugdatenserver 126 beinhalten.
Der entfernte Datenanforderungsdienst 134 kann eine Anwendung sein, die im Speicher des Fahrzeugdatenservers 126 beinhaltet ist. Der entfernte Datenanforderungsdienst 134 kann Anweisungen beinhalten, die bei Ausführung durch den Prozessor des Fahrzeugdatenservers 126 den Fahrzeugdatenserver 126 dazu veranlassen, die Informationen bezüglich der Diagnosedaten 120 von Fahrzeugen 102 zu empfangen, Diagnoseerfordernisse 124 von der Anforderervorrichtung 128 zu empfangen, die Diagnoseerfordernisse 124 in Diagnoseanforderungen 122 umzuwandeln und die Diagnoseanforderungen 122 den Fahrzeugen 102 bereitzustellen. Der entfernte Datenanforderungsdienst 134 kann ferner die Diagnosedaten 120 von den Fahrzeugen 102 empfangen und die Gesamtergebnisse zusammenstellen, um die durch die Diagnoseerfordernisse 124 konkretisierten Erfordernisse zu erfüllen.
Der entfernte Datenanforderungsdienst 134 kann dementsprechend diese Informationen gemäß den Diagnoseanforderungen 122 zur Analyse bereitstellen. In einem Beispiel können die zusammengestellten Informationen der Anforderervorrichtung 128 zur Verfügung gestellt werden, wobei die Diagnoseerfordernisse 124, anhand derer die Diagnoseanforderungen 122 generiert wurden, konkretisiert werden.
2 veranschaulicht ein beispielhaftes Diagramm 200 des Betriebs des entfernten Datenanforderungsdienstes 134 zum Erfassen von Diagnosedaten 120 über eine Vielzahl von Zeiträumen 208-1 bis 208-N (zusammen 208). Wie gezeigt, empfängt der entfernte Datenanforderungsdienst 134 Diagnoseerfordernisse 124. Die Diagnoseerfordernisse 124 können Datenanforderungsinformationen 202, Fahrzeugauswahlkriterien 204 und eine Probengröße 206 beinhalten. In einem Beispiel können die Diagnoseerfordernisse 124 von der Anforderervorrichtung 128 empfangen werden.
Die Datenanforderungsinformationen 202 beinhalten Informationen, die angeben, welche Daten von den Fahrzeugen 102 gesammelt werden sollen. In einem Beispiel geben die Datenanforderungsinformationen 202 die Diagnosecodes oder andere Informationen an, die über Diagnoseanforderungen 122 von den Fahrzeugen 102 als Diagnosedaten 120 angefordert werden sollen. In einem anderen Beispiel können die Datenanforderungsinformationen 202 einfach angeben, dass eine bestimmte Menge von Busverkehrsdaten erwünscht ist.
Die Fahrzeugauswahlkriterien 204 beinhalten Informationen, die Attribute der Fahrzeuge 102 konkretisieren, welche die Diagnosedaten 120 bereitstellen sollten. In einem Beispiel können diese Attribute eines oder mehrere von Folgendem beinhalten: eine Marke eines Fahrzeugs 102, ein Modell eines Fahrzeugs 102, ein Baujahr eines Fahrzeugs 102, eine Fahrzeugidentifikationsnummer (FIN) eines Fahrzeugs 102 oder ein FIN-Bereich des Fahrzeugs 102. Ebenfalls verwendet werden können andere Fahrzeugauswahlkriterien 204, die ein oder mehrere Merkmale des Fahrzeugs 102 betreffen, wie etwa Fahrzeugfarbe, ob das Fahrzeug einen 2-Rad- oder Allradantrieb aufweist, ob ein Fahrzeug ein Schiebedach beinhaltet und so weiter.
Die Probengröße 206 beinhaltet Informationen, die eine Menge der Diagnosedaten 120 und/oder der Fahrzeuge 102, welche die Diagnosedaten 120 bereitstellen sollen, angeben. In einem Beispiel kann die Probengröße 206 eine abzurufende Datenmenge in Byte angeben. Zusätzlich oder alternativ dazu kann die Probengröße 206 einen Zeitraum beinhalten, über den die Datenmenge abgerufen werden soll.
Basierend auf der Probengröße 206 bestimmt der entfernte Datenanforderungsdienst 134 einen Satz von Zeiträumen 208, während denen Diagnoseanforderungen 122 für die Datenanforderungsinformationen 202 an das Fahrzeug 102 gesendet werden sollen, das mit den Fahrzeugauswahlkriterien 204 übereinstimmt. Um das Beispiel einer Anforderung für 100 Byte Daten von 1.000.000 roten 4x4-Fahrzeugen im Laufe der nächsten 30 Tage zu verwenden, bestimmt beispielsweise der Datenanforderungsdienst 134 einen Satz von Fahrzeugen 102, die rot sind und 4x4 aufweisen, und identifiziert dann einen Satz von periodischen Zeiträumen 208 im Laufe der nächsten 30 Tage, um die Daten anzufordern. Wenn beispielsweise 33.333 Fahrzeuge 102 identifiziert werden, kann der entfernte Datenanforderungsdienst 134 für jeden Tag eines Monats 100 Byte Daten von den 33.333 Fahrzeugen 102 anfordern. Diese Diagnoseanforderungen 122 können gemäß den Weisungen des entfernten Datenanforderungsdienstes 134 von dem Fahrzeugdatenserver 126 über das Weitverkehrsnetzwerk 112 an die Fahrzeuge 102 gesendet werden. Als ein weiteres Beispiel kann der entfernte Datenanforderungsdienst 134 eine Menge von mit den Diagnoseerfordernissen 124 übereinstimmenden Fahrzeugen 102 identifizieren, von denen periodisch die Diagnosedaten 120 gesammelt werden sollen, einen Zeitraum zum Sammeln einer Gesamtmenge von Daten identifizieren, die durch die Diagnosedaten 120 konkretisiert wird, indem die Gesamtmenge von Daten durch eine durch die Diagnoseerfordernisse 124 konkretisierte Probengröße 206 dividiert und mit der Anzahl von übereinstimmenden Fahrzeugen 102 multipliziert wird, und periodisch die Diagnosedaten 120 von den übereinstimmenden Fahrzeugen 102 gemäß dem Zeitraum unter Verwendung der Probengrößen sammeln, um Diagnosedaten 120 im Umfang der Gesamtdatenmenge zu generieren.
Die Fahrzeuge 102 können die Diagnoseanforderungen 122 empfangen, die durch die Datendienstanwendung 130 der TCU 108 zum Generieren von Diagnosedaten 120 verarbeitet werden können. Diese Diagnosedaten 120 können dann von der TCU 108 über das Weitverkehrsnetzwerk 112 zurück an den Fahrzeugdatenserver 126 zum Sammeln durch den entfernten Datenanforderungsdienst 134 gesendet werden.
3 veranschaulicht einen beispielhaften Prozess 300 zum Zusammenstellen von Daten von Fahrzeugen 102 unter Verwendung eines entfernten Datenanforderungsdienstes 134. In einem Beispiel kann der Prozess 300 durch den Fahrzeugdatenserver 126 durchgeführt werden, der den entfernten Datenanforderungsdienst 134 ausführt.
Bei Vorgang 302 empfängt der Fahrzeugdatenserver 126 Diagnoseerfordernisse 124 von Anforderervorrichtungen 128. In einem Beispiel definieren die Diagnoseerfordernisse 124 die Datenanforderungsinformationen 202, die Fahrzeugauswahlkriterien 204 und die Probengröße 206, die in den Diagnoseanforderungen 122 an die Fahrzeuge 102 konkretisiert werden soll.
Bei 304 identifiziert der Fahrzeugdatenserver 126 Fahrzeuge 102, die mit den Fahrzeugauswahlkriterien 204 der Diagnoseerfordernisse 124 übereinstimmen. In einem Beispiel kann der Fahrzeugdatenserver 126 auf ein Fahrzeugauswahl-Tool oder eine andere Datenbank zugreifen, anhand welcher Attribute der Fahrzeuge 102 hinsichtlich der Übereinstimmung mit den Fahrzeugauswahlkriterien 204 untersucht werden können.
Bei 306 identifiziert der Fahrzeugdatenserver 126 Zeiträume 208 für die Sammlung von Diagnosedaten 120 gemäß den Informationen hinsichtlich der Probengröße 206 der Diagnoseerfordernisse 124. Basierend auf dem Zeitrahmen für die Sammlung von Diagnosedaten 120 und der Menge von Fahrzeugen 102, die bei Vorgang 304 gemäß den Fahrzeugauswahlkriterien 204 identifiziert wurden, identifiziert der Fahrzeugdatenserver 126 in einem Beispiel, wie viele Zeiträume 208 zur Durchführung erforderlich sind. Wenn beispielsweise festgestellt wird, dass 100 übereinstimmende Fahrzeuge 102 jeweils 100 Byte Daten bereitstellen, können zehn Zeiträume 208 verwendet werden, wenn jedoch nur zehn Fahrzeuge 102 gefunden werden, können 100 Zeiträume 208 verwendet werden.
Bei 308 sammelt der Fahrzeugdatenserver 126 über die Zeiträume 208 Diagnosedaten 120 von den Fahrzeugen 102. In einem Beispiel sendet der Fahrzeugdatenserver 126 die Diagnoseanforderungen 122 bezogen auf die Fahrzeugauswahlkriterien 204 und die Probengröße 206 an die Fahrzeuge 102. Zusätzlich dazu empfängt der Fahrzeugdatenserver 126 Diagnosedaten 120 von den Fahrzeugen 102. In einem Beispiel können die Informationen hinsichtlich der Diagnosedaten 120 über das Weitverkehrsnetzwerk 112 empfangen werden, wenn sie durch die Fahrzeuge 102 übertragen werden.
Bei 310 stellt der Fahrzeugdatenserver 126 die Diagnosedaten 120 entsprechend den Diagnoseerfordernissen 124 zusammen. Durch die Verwendung der über die Zeiträume 308 von den Fahrzeugen 102 empfangenen Diagnosedaten 120 kann der Fahrzeugdatenserver 126 die erforderlichen Daten sammeln. Bei 312 sendet der Fahrzeugdatenserver 126 die zusammengestellten Daten an die Anforderervorrichtungen 128. Dementsprechend können die Anforderervorrichtungen 128 auf die Diagnosedaten 120, die durch die Diagnoseerfordernisse 124 konkretisiert wurden, zugreifen oder anderweitig nutzen. Nach dem Vorgang 312 endet der Prozess 300.
Somit reduzieren die offenbarten Systeme und Verfahren den Aufwand zum Ausführen von OTA-Anforderungen erheblich im Vergleich zu Systemen, die eine Datenantwort pro Datenanforderung durchführen. Außerdem können die beschriebenen Systeme und Verfahren automatisch eine benutzerdefinierte Probengröße der Daten wiedergeben, ohne dass die Verwendung vieler einzelner Anforderungen erforderlich ist. Zusätzlich dazu verteilen die beschriebenen Systeme und Verfahren die Datenbeprobung über einen Zeitraum, der eine Kontrolle gegenüber externen Faktoren ermöglicht.
Des Weiteren kann das System Aufzeichnungen darüber hinterlegen, welche Fahrzeuge 102 welche Daten bereitgestellt haben, was den Kunden von OTA-Datensammlungen ermöglicht, eine Datenspur zwecks Nachverfolgung und Verwaltung zu empfangen. Außerdem werden alle Aktivierungseinrichtungen (am Fahrzeug oder in der Cloud), welche die Datensammlung ermöglichen, beim Prüfen dieser Datenspur ersichtlich.
In dieser Schrift beschriebene Rechenvorrichtungen, wie etwa die TCU 108, der Fahrzeugdatenserver 126 und die Anforderervorrichtung 128 beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa den vorstehend aufgelisteten, ausgeführt werden können.
Computerausführbare Anweisungen, wie etwa jene der Datendienstanwendung 130 oder des entfernten Datenanforderungsdienstes 134, können von Computerprogrammen zusammengestellt oder ausgewertet werden, die unter Verwendung einer Vielfalt an Programmiersprachen und/oder -techniken erstellt worden sind, einschließlich unter anderem und entweder einzeln oder in Kombination JAVA™, C, C++, C#, VISUAL BASIC, JAVASCRIPT, PYTHON, JAVASCRIPT, PERL, PL/SQL usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch er einen oder mehrere Prozesse durchführt, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Prozesse. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert und übertragen werden.
Hinsichtlich der in dieser Schrift beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte derartiger Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, derartige Prozesse jedoch mit den beschriebenen Schritten in einer Reihenfolge durchgeführt werden können, die von der in dieser Schrift beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte in dieser Schrift beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt dienen die Beschreibungen von Prozessen in dieser Schrift dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, erschließen sich beim Lesen der vorstehenden Beschreibung. Der Schutzumfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung festgelegt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche unter Hinzunahme des vollständigen Schutzumfangs von Äquivalenten, zu denen solche Patentansprüche berechtigen. Es wird erwartet und ist beabsichtigt, dass es hinsichtlich der in dieser Schrift erörterten Technologien künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutungen zugeordnet sein, wie sie mit den in dieser Schrift beschriebenen Technologien vertrauten Fachleuten bekannt sind, sofern in dieser Schrift kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „einer“, „eine“, „der“, „die“, „das“ usw., dahingehend auszulegen, dass eines oder mehrere der aufgeführten Elemente genannt werden, es sei denn, ein Anspruch enthält eine ausdrücklich gegenteilige Einschränkung.
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Schutzumfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Darüber hinaus geht aus der vorstehenden detaillierten Beschreibung hervor, dass verschiedene Merkmale zum Zwecke der Vereinfachung der Offenbarung in verschiedenen Ausführungsformen zusammengefasst sind. Dieses Offenbarungsverfahren soll nicht dahingehend interpretiert werden, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich in jedem Patentanspruch genannt erforderlich machen. Vielmehr liegt der Gegenstand der Erfindung in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Patentansprüche widerspiegeln. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als separat beanspruchter Gegenstand steht.
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und keine einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden.
Gemäß der vorliegenden Erfindung beinhaltet ein System einen Server mit einem HardwareProzessor, der dazu programmiert ist, Diagnoseerfordernisse, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen zu empfangen, anhand der Diagnoseerfordernisse Fahrzeuge und Zeiträume zum Sammeln von Diagnosedaten von den Fahrzeugen zu identifizieren, periodisch die Diagnosedaten von den Fahrzeugen gemäß der Identifizierung zu sammeln, die Diagnosedaten zusammenzustellen, um zusammengestellte Daten entsprechend den Diagnoseerfordernissen zu erzeugen, und die zusammengestellten Daten an die Anforderervorrichtungen zu senden.
Gemäß einer Ausführungsform beinhalten die Diagnoseerfordernisse Fahrzeugauswahlkriterien, die Attribute der Fahrzeuge konkretisieren, von denen die Daten gesammelt werden sollen.
Gemäß einer Ausführungsform beinhalten die Diagnoseerfordernisse Informationen bezüglich der Probengröße, die eine Datenmenge und einen Zeitraum, über den die Datenmenge gesammelt werden soll, konkretisieren.
Gemäß einer Ausführungsform ist der Prozessor ferner dazu programmiert, zu bestimmen, wie viele Zeiträume zur Sammlung basierend auf den Informationen bezüglich der Probengröße erforderlich sind und wie viele Fahrzeuge mit den Fahrzeugauswahlkriterien übereinstimmen.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner dadurch gekennzeichnet, dass der Prozessor ferner dazu programmiert ist, die Diagnosedaten von den Fahrzeugen zu sammeln, einschließlich Vorgängen zum Senden von Diagnoseanforderungen an die Fahrzeuge über ein Weitverkehrsnetzwerk und Empfangen der Diagnosedaten von den Fahrzeugen über das Weitverkehrsnetzwerk als Reaktion auf die Diagnoseanforderungen.
Gemäß einer Ausführungsform ist der Prozessor ferner zu Folgendem programmiert: Identifizieren einer Menge von mit den Diagnoseerfordernissen übereinstimmenden Fahrzeugen, von denen periodisch die Diagnosedaten gesammelt werden sollen; Identifizieren eines Zeitraums zum Sammeln einer Gesamtmenge von Daten, die durch die Diagnosedaten konkretisiert wird, indem die Gesamtmenge von Daten durch eine durch die Diagnoseerfordernisse konkretisierte Probengröße dividiert und mit der Anzahl von Fahrzeugen multipliziert wird; und periodisches Sammeln der Diagnosedaten gemäß dem Zeitraum unter Verwendung der Probengrößen, um zusammengestellte Daten im Umfang der Gesamtdatenmenge zu generieren.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren Empfangen von Diagnoseerfordernissen, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen; periodisches Senden von Diagnoseanforderungen an Fahrzeuge bezogen auf die Diagnoseerfordernisse, wobei die Fahrzeuge dahingehend identifiziert werden, dass sie mit Fahrzeugauswahlkriterien übereinstimmen, die in den Diagnoseanforderungen beinhaltet sind, wobei der Zeitraum zum Sammeln von Daten von den Fahrzeugen gemäß einer Zählung der Fahrzeuge und einer zu erfassenden Datenmenge, die durch die Diagnoseerfordernisse konkretisiert ist, identifiziert werden; periodisches Empfangen, von den Fahrzeugen, einer Vielzahl von Diagnosedatennachrichten, von denen jede einen Teil der gemäß den Diagnoseanforderungen angeforderten Informationen beinhaltet; Zusammenstellen von Daten entsprechend den Diagnoseerfordernissen zu zusammengestellten Daten; und Senden der zusammengestellten Daten an die Anforderervorrichtungen.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Speichern der zusammengestellten Daten in einer Datenbank.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Identifizieren der Fahrzeuge, die mit den Fahrzeugauswahlkriterien übereinstimmen, indem auf eine Datenbank von Fahrzeugattributen zugegriffen wird.
Gemäß einer Ausführungsform beinhalten die Diagnoseerfordernisse Fahrzeugauswahlkriterien, die Attribute der Fahrzeuge konkretisieren, von denen die Daten gesammelt werden sollen.
Gemäß einer Ausführungsform beinhalten die Diagnoseerfordernisse Informationen bezüglich der Probengröße, die eine Datenmenge und einen Zeitraum, über den die Datenmenge gesammelt werden soll, konkretisieren.
Gemäß einer Ausführungsform ist vorstehende Erfindung ferner gekennzeichnet durch Bestimmen, wie viele Zeiträume zur Sammlung basierend auf den Informationen bezüglich der Probengröße erforderlich sind und wie viele Fahrzeuge mit den Fahrzeugauswahlkriterien übereinstimmen.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Sammeln der Diagnosedaten von den Fahrzeugen durch Senden von Diagnoseanforderungen an die Fahrzeuge über ein Weitverkehrsnetzwerk und Empfangen der Diagnosedaten von den Fahrzeugen über das Weitverkehrsnetzwerk als Reaktion auf die Diagnoseanforderungen.
Gemäß der vorliegenden Erfindung ist ein nichttransitorisches computerlesbares Medium bereitgestellt, das Anweisungen aufweist, die bei Ausführung durch einen Prozessor eines Fahrzeugdatenservers den Prozessor zu Folgendem veranlassen: Empfangen von Diagnoseerfordernissen, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen; periodisches Senden von Diagnoseanforderungen an Fahrzeuge bezogen auf die Diagnoseerfordernisse, wobei die Fahrzeuge dahingehend identifiziert werden, dass sie mit Fahrzeugauswahlkriterien übereinstimmen, die in den Diagnoseanforderungen beinhaltet sind, wobei der Zeitraum zum Sammeln von Daten von den Fahrzeugen gemäß einer Zählung der Fahrzeuge und einer zu erfassenden Datenmenge, die durch die Diagnoseerfordernisse konkretisiert ist, identifiziert werden; periodisches Empfangen, von den Fahrzeugen, einer Vielzahl von Diagnosedatennachrichten, von denen jede einen Teil der gemäß den Diagnoseanforderungen angeforderten Informationen beinhaltet; Zusammenstellen von Daten entsprechend den Diagnoseerfordernissen zu zusammengestellten Daten; und Senden der zusammengestellten Daten an die Anforderervorrichtungen.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen, die zusammengestellten Daten in einer Datenbank zu speichern.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen, die Fahrzeuge, die mit den Fahrzeugauswahlkriterien übereinstimmen, zu identifizieren, indem auf eine Datenbank von Fahrzeugattributen zugegriffen wird.
Gemäß einer Ausführungsform beinhalten die Diagnoseerfordernisse Fahrzeugauswahlkriterien, die Attribute der Fahrzeuge konkretisieren, von denen die Daten gesammelt werden sollen.
Gemäß einer Ausführungsform beinhalten die Diagnoseerfordernisse Informationen bezüglich der Probengröße, die eine Datenmenge und einen Zeitraum, über den die Datenmenge gesammelt werden soll, konkretisieren.
Gemäß einer Ausführungsform ist vorstehende Erfindung ferner gekennzeichnet durch Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen, zu bestimmen, wie viele Zeiträume zur Sammlung basierend auf den Informationen bezüglich der Probengröße erforderlich sind und wie viele Fahrzeuge mit den Fahrzeugauswahlkriterien übereinstimmen.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Anweisungen, die bei Ausführung durch den Prozessor den Prozessor dazu veranlassen, die Diagnosedaten von den Fahrzeugen durch Senden von Diagnoseanforderungen an die Fahrzeuge über ein Weitverkehrsnetzwerk und Empfangen der Diagnosedaten von den Fahrzeugen über das Weitverkehrsnetzwerk als Reaktion auf die Diagnoseanforderungen zu sammeln.

Claims

System, umfassend: einen Server mit einem Hardwareprozessor, der zu Folgendem programmiert ist: Identifizieren von Fahrzeugen und Zeiträumen zum Sammeln von Diagnosedaten von den Fahrzeugen anhand von Diagnoseerfordernissen, periodisches Sammeln der Diagnosedaten von den Fahrzeugen gemäß der Identifizierung, und Zusammenstellen der Diagnosedaten, um zusammengestellte Daten entsprechend den Diagnoseerfordernissen zu erzeugen.
System nach Anspruch 1, wobei die Diagnoseerfordernisse Fahrzeugauswahlkriterien beinhalten, die Attribute der Fahrzeuge konkretisieren, von denen die Daten gesammelt werden sollen.
System nach Anspruch 2, wobei die Diagnoseerfordernisse Informationen bezüglich der Probengröße beinhalten, die eine Datenmenge und einen Zeitraum, über den die Datenmenge gesammelt werden soll, konkretisieren.
System nach Anspruch 3, wobei der Prozessor ferner dazu programmiert ist, zu bestimmen, wie viele Zeiträume zur Sammlung basierend auf den Informationen bezüglich der Probengröße erforderlich sind und wie viele Fahrzeuge mit den Fahrzeugauswahlkriterien übereinstimmen.
System nach Anspruch 1, wobei der Prozessor ferner dazu programmiert ist, die Diagnosedaten von den Fahrzeugen zu sammeln, einschließlich Vorgängen zum Senden von Diagnoseanforderungen an die Fahrzeuge über ein Weitverkehrsnetzwerk und Empfangen der Diagnosedaten von den Fahrzeugen über das Weitverkehrsnetzwerk als Reaktion auf die Diagnoseanforderungen.
System nach Anspruch 1, wobei der Prozessor ferner zu Folgendem programmiert ist: Empfangen der Diagnoseerfordernisse von einer Anforderervorrichtung und Senden der zusammengestellten Daten an die Anforderervorrichtung.
Verfahren, umfassend: Empfangen von Diagnoseerfordernissen, die Fahrzeugdatenerfordernisse konkretisieren, von Anforderervorrichtungen; periodisches Senden von Diagnoseanforderungen an Fahrzeuge bezogen auf die Diagnoseerfordernisse, wobei die Fahrzeuge dahingehend identifiziert werden, dass sie mit Fahrzeugauswahlkriterien übereinstimmen, die in den Diagnoseanforderungen beinhaltet sind, wobei der Zeitraum zum Sammeln von Daten von den Fahrzeugen gemäß einer Zählung der Fahrzeuge und einer zu erfassenden Datenmenge, die durch die Diagnoseerfordernisse konkretisiert ist, identifiziert werden, periodisches Empfangen, von den Fahrzeugen, einer Vielzahl von Diagnosedatennachrichten, von denen jede einen Teil der gemäß den Diagnoseanforderungen angeforderten Informationen beinhaltet; Zusammenstellen von Daten entsprechend den Diagnoseerfordernissen zu zusammengestellten Daten; und Senden der zusammengestellten Daten an die Anforderervorrichtungen.
Verfahren nach Anspruch 7, ferner umfassend Speichern der zusammengestellten Daten in einer Datenbank.
Verfahren nach Anspruch 7, ferner umfassend Identifizieren der Fahrzeuge, die mit den Fahrzeugauswahlkriterien übereinstimmen, indem auf eine Datenbank von Fahrzeugattributen zugegriffen wird.
Verfahren nach Anspruch 7, wobei die Diagnoseerfordernisse Fahrzeugauswahlkriterien beinhalten, die Attribute der Fahrzeuge konkretisieren, von denen die Daten gesammelt werden sollen.
Verfahren nach Anspruch 10, wobei die Diagnoseerfordernisse Informationen bezüglich der Probengröße beinhalten, die eine Datenmenge und einen Zeitraum, über den die Datenmenge gesammelt werden soll, konkretisieren.
Verfahren nach Anspruch 11, ferner umfassend Bestimmen, wie viele Zeiträume zur Sammlung basierend auf den Informationen bezüglich der Probengröße erforderlich sind und wie viele Fahrzeuge mit den Fahrzeugauswahlkriterien übereinstimmen.
Verfahren nach Anspruch 7, ferner umfassend Sammeln der Diagnosedaten von den Fahrzeugen durch Senden von Diagnoseanforderungen an die Fahrzeuge über ein Weitverkehrsnetzwerk und Empfangen der Diagnosedaten von den Fahrzeugen über das Weitverkehrsnetzwerk als Reaktion auf die Diagnoseanforderungen.