-
GEBIET DER TECHNIK
-
Die vorliegende Offenbarung betrifft im Allgemeinen das Erfassen von Fahrzeugprotokollen. Insbesondere betrifft die vorliegende Offenbarung das Erfassen von Fahrzeugprotokollen von mehreren Knoten eines Fahrzeugs.
-
ALLGEMEINER STAND DER TECHNIK
-
Fahrzeuge werden durch die Verwendung mehrerer Steuerungen oder elektronischer Steuereinheiten (electronic control units - ECUs), die miteinander verbunden sind, um verschiedene Merkmale wie etwa Navigation und Kommunikation bereitzustellen, komplexer. Wenn ein Problem auftritt, kann es schwierig sein, die Ursache des Fehlers zu bestimmen, da ein Merkmal durch verschiedene ECUs, die zusammenarbeiten, aktiviert werden kann und sich die Ursache an einer beliebigen damit in Zusammenhang stehenden ECU befinden kann. Zusätzlich dazu kann das Fahrzeug über einen Server aus der Ferne diagnostiziert werden, indem gesendete Protokolldaten auf den Server hochgeladen werden. Wenn beispielsweise ein Benutzer keine Orte von Interesse (points of interests - POls) über ein Fahrzeugnavigationssystem suchen kann, kann der Fehler in einem beliebigen oder mehreren von der Software oder Hardware auf dem Fahrzeugbetriebssystem, der Konnektivität mit der Cloud oder in anderen Komponenten des Fahrzeugs liegen.
-
KURZDARSTELLUNG
-
In einer oder mehreren veranschaulichenden Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Fahrzeug eine erste Steuerung; und eine zweite Steuerung, wobei die erste Steuerung dazu programmiert ist, als Reaktion auf das Erkennen eines Fehlers, ein Fehlerereignis zu erzeugen, die zweite Steuerung als mit dem Fehlerereignis in Zusammenhang stehend zu identifizieren, Protokolle der ersten Steuerung und der zweiten Steuerung als in Zusammenhang mit dem Fehlerereignis stehend zu identifizieren, Protokolle der ersten Steuerung zu sammeln und eine Fehlernachricht, die eine Anforderung für die Protokolle der zweiten Steuerung beinhaltet, an die zweite Steuerung zu übertragen, und wobei die zweite Steuerung dazu programmiert ist, als Reaktion auf das Empfangen der Fehlernachricht von der ersten Steuerung Protokolle der zweiten Steuerung wie angefordert zu sammeln und eine Anforderung für ein Sicherheitstoken an einen Server zu senden sowie als Reaktion auf das Empfangen des Sicherheitstokens von dem Server die Protokolle der zweiten Steuerung, wie sie unter Verwendung des Sicherheitstokens gesammelt wurden, auf den Server hochzuladen und den Sicherheitstoken an die erste Steuerung zu senden, und wobei die erste Steuerung ferner dazu programmiert ist, als Reaktion auf das Empfangen des Sicherheitstokens von der zweiten Steuerung die Protokolle der ersten Steuerung, wie sie unter Verwendung des Sicherheitstokens gesammelt wurden, auf den Server hochzuladen.
-
In einer oder mehreren veranschaulichenden Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Protokollsammelsystem für ein Fahrzeug eine erste Steuerung; eine zweite Steuerung; und eine dritte Steuerung, wobei die erste Steuerung dazu programmiert ist, als Reaktion auf das Erkennen eines Fehlers, ein Fehlerereignis basierend auf einer Analysebibliothek zu erzeugen, die zweite Steuerung und die dritte Steuerung als mit dem Fehlerereignis in Zusammenhang stehend zu identifizieren, Protokolle der ersten Steuerung, der zweiten Steuerung und der dritten Steuerung als in Zusammenhang mit dem Fehlerereignis stehend zu identifizieren, Protokolle der ersten Steuerung zu sammeln und eine Fehlernachricht, die eine Anforderung für die Protokolle der zweiten Steuerung und für die Protokolle der dritten Steuerung beinhaltet, an die zweite Steuerung zu übertragen, und wobei die zweite Steuerung dazu programmiert ist, als Reaktion auf das Empfangen der Fehlernachricht von der ersten Steuerung Protokolle der zweiten Steuerung wie angefordert zu sammeln und eine Anforderung für Protokolle der dritten Steuerung an die dritte Steuerung zu senden, eine Anforderung für ein Sicherheitstoken an einen Server zu senden sowie als Reaktion auf das Empfangen des Sicherheitstokens von dem Server die Protokolle der zweiten Steuerung, wie sie unter Verwendung des Sicherheitstokens gesammelt wurden, auf den Server hochzuladen und den Sicherheitstoken an die erste Steuerung und die dritte Steuerung zu senden, und wobei die dritte Steuerung dazu programmiert ist, als Reaktion auf das Empfangen der Anforderung für Protokolle die Protokolle wie angefordert zu sammeln und die Protokolle der dritten Steuerung, wie sie unter Verwendung des Sicherheitstokens gesammelt wurden, auf den Server hochzuladen, und wobei die erste Steuerung ferner dazu programmiert ist, als Reaktion auf das Empfangen des Sicherheitstokens von der zweiten Steuerung die Protokolle der ersten Steuerung, wie sie unter Verwendung des Sicherheitstokens gesammelt wurden, auf den Server hochzuladen.
-
In einer oder mehreren veranschaulichenden Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Fahrzeugsystem zum Sammeln von Diagnosedaten eine Infotainment-Steuerung; eine Gateway-Steuerung; und eine Telematiksteuereinheit (telematics control unit - TCU), wobei die Infotainment-Steuerung zu Folgendem programmiert ist: als Reaktion auf das Erkennen eines Fehlers, Erzeugen eines Fehlerereignisses basierend auf einer Analysebibliothek und Zuweisen einer globalen Ereignisidentifikation (global event identification - GEID) zu dem Fehlerereignis, Identifizieren der Gateway-Steuerung und der TCU als in Zusammenhang mit dem Fehlerereignis stehend, Identifizieren von Protokollen der Infotainment-Steuerung, der Gateway-Steuerung und der TCU als mit dem Fehlerereignis in Zusammenhang stehend, Sammeln von Protokollen der Infotainment-Steuerung und Zuordnen der Protokolle zu der GEID sowie Übertragen einer Fehlernachricht, welche die GEID, eine Anforderung für die Protokolle der Gateway-Steuerung und für die Protokolle der TCU beinhaltet, an die Gateway-Steuerung, wobei die Gateway-Steuerung dazu programmiert ist, als Reaktion auf das Empfangen der Fehlernachricht von der Infotainment-Steuerung Protokolle der Gateway-Steuerung wie angefordert zu sammeln und die Protokolle der GEID zuzuordnen, die GEID und die Anforderung für Protokolle der TCU an die TCU zu senden, eine Anforderung für ein Sicherheitstoken an einen Server zu senden und als Reaktion auf das Empfangen des Sicherheitstokens von dem Server die Protokolle der Gateway-Steuerung, wie sie der GEID zugeordnet wurden, auf den Server unter Verwendung des Sicherheitstokens hochzuladen sowie das Sicherheitstoken an die Infotainment-Steuerung und die TCU zu senden, wobei die TCU dazu konfiguriert ist, als Reaktion auf das Empfangen der Anforderung für Protokolle die Protokolle wie angefordert zu sammeln und die Protokolle der GEID zuzuordnen sowie die Protokolle der TCU, wie sie der GEID zugeordnet wurden, auf den Server unter Verwendung des Sicherheitstokens hochzuladen, und wobei die Infotainment-Steuerung ferner dazu programmiert ist, als Reaktion auf das Empfangen des Sicherheitstokens von der Gateway-Steuerung die Protokolle der Infotainment-Steuerung, wie sie der GEID zugeordnet wurden, auf den Server unter Verwendung des Sicherheitstokens hochzuladen.
-
Figurenliste
-
Für ein besseres Verständnis der Erfindung und um zu zeigen, wie diese durchgeführt werden kann, werden nun Ausführungsformen davon ausschließlich als nicht einschränkende Beispiele beschrieben, wobei auf die beigefügten Zeichnungen Bezug genommen wird, in denen Folgendes gilt:
- 1 veranschaulicht eine beispielhafte Blocktopologie eines Fahrzeugsystems einer Ausführungsform der vorliegenden Offenbarung;
- 2 veranschaulicht eine beispielhafte schematische Darstellung eines Fahrzeugdiagnosesystems einer Ausführungsform der vorliegenden Offenbarung; und
- 3 veranschaulicht ein beispielhaftes Datenflussdiagramm für einen Diagnoseprozess einer Ausführungsform der vorliegenden Offenbarung.
-
DETAILLIERTE BESCHREIBUNG
-
Nach Bedarf werden in dieser Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen umgesetzt werden kann. Die Figuren sind nicht unbedingt 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 Umsetzung der vorliegenden Erfindung zu lehren.
-
Die vorliegende Offenbarung stellt im Allgemeinen eine Vielzahl von Schaltungen oder anderen elektrischen Vorrichtungen bereit. Alle Bezugnahmen auf die Schaltungen und anderen elektrischen Vorrichtungen und die durch jede davon bereitgestellte Funktionalität sollen nicht darauf beschränkt sein, nur das einzuschließen, was in dieser Schrift veranschaulicht und beschrieben ist. Während den verschiedenen Schaltungen oder anderen elektrischen Vorrichtungen bestimmte Bezeichnungen zugewiesen werden können, können derartige Schaltungen und andere elektrische Vorrichtungen auf Grundlage der bestimmten Art der elektrischen Umsetzung, die gewünscht ist, miteinander kombiniert und/oder auf eine beliebige Weise getrennt sein. Es liegt auf der Hand, dass beliebige in dieser Schrift offenbarte Schaltungen oder andere elektrische Vorrichtungen eine beliebige Anzahl an Mikroprozessoren, integrierten Schaltungen, Speichervorrichtungen (z. B. FLASH, Direktzugriffsspeicher (random access memory - RAM), Festwertspeicher (read only memory - ROM), elektrisch programmierbaren Festwertspeicher (electrically programmable read only memory - EPROM), elektrisch löschbaren programmierbaren Festwertspeicher (electrically erasable programmable read only memory - EEPROM) oder andere geeignete Varianten davon) und Software beinhalten können, die miteinander zusammenwirken, um den bzw. die in dieser Schrift offenbarten Vorgang bzw. Vorgänge durchzuführen. Zusätzlich kann eine beliebige oder können mehrere beliebige der elektrischen Vorrichtungen dazu konfiguriert sein, ein Computerprogramm auszuführen, das in einem nichttransitorischen computerlesbaren Medium ausgeführt ist, das dazu programmiert ist, eine beliebige Anzahl der offenbarten Funktionen durchzuführen.
-
Die vorliegende Offenbarung schlägt unter anderem ein Fahrzeugsystem zum Erfassen von Protokollen von Steuerungen vor. Konkreter gesagt, schlägt die vorliegende Offenbarung ein Fahrzeugsystem zum Sammeln von Datenprotokollen von verschiedenen Steuerungen zu Diagnosezwecken vor.
-
Bei dem aktuellen Diagnose- oder Fehlerbehebungsschema für Fahrzeugkomponenten kann das Fahrzeugprotokoll von einer oder mehreren relevanten ECUs gesammelt und zur Diagnose an einen entfernten Server gesendet werden, wenn ein Fehler erkannt wird. Fahrzeugdatenprotokolle können gemäß einem derartigen Schema unkoordiniert und groß sein. Darüber hinaus kann es für Techniker schwierig sein, durch nicht koordinierte Fahrzeugprotokolle zu navigieren, um die Ursache eines Fehlers zu finden. Die vorliegende Offenbarung schlägt eine flexible Fahrzeugarchitektur vor, welche die Erfassung und Koordination über mehrere Fahrzeug-ECUs zu Diagnosezwecken erleichtert.
-
Jede Steuerung oder ECU kann unter der vorliegenden Architektur als Knoten fungieren. Jeder Knoten kann dazu konfiguriert sein, Fahrzeugprotokolle von einem beliebigen anderen Knoten zu sammeln, um Fehlerursachen zu ermitteln und die Qualität und Effizienz des Fahrzeugsystems zu verbessern. Der Rahmen der vorliegenden Offenbarung kann zwei Schlüsselkomponenten beinhalten - einen Diagnoseagenten und einen Diagnosemaster. Bei dem Diagnoseagenten kann es sich um eine einzelne Instanz handeln, die sich auf jedem Knoten befindet und für die Kommunikation mit dem Master, das Sammeln von Protokollen und das Verarbeiten von knotenspezifischen Informationen verantwortlich ist. Bei dem Diagnosemaster kann es sich um eine einzelne Instanz handeln, die sich auf einem einzelnen Knoten befindet und für die Steuerung dessen verantwortlich ist, was jeder Agent auf seinen jeweiligen Knoten tun soll.
-
Unter Bezugnahme auf 1 ist eine beispielhafte Blocktopologie eines Fahrzeugsystems 100 einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Ein Fahrzeug 102 kann verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländewagen (sport utility vehicle - SUV), Lastwagen, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern beinhalten. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine mit Leistung versorgt werden. Als eine andere Möglichkeit kann das Fahrzeug 102 ein Batterieelektrofahrzeug (battery electric vehicle - BEV), ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV), das sowohl durch eine Brennkraftmaschine als auch durch einen oder mehrere Elektromotoren mit Leistung versorgt wird, wie etwa ein Serienhybridelektrofahrzeug (series hybrid electric vehicle - SHEV), ein Plug-in-Hybridelektrofahrzeug (plug-in hybrid electric vehicle - PHEV) oder ein Parallel-/Serienhybridfahrzeug (parallel/series hybrid vehicle - PSHEV), ein Boot, ein Flugzeug oder eine andere mobile Maschine zum Befördern von Personen oder Gütern sein. Als ein Beispiel kann das System 100 das SYNC-System beinhalten, hergestellt durch The Ford Motor Company in Dearborn, Michigan. Es ist anzumerken, dass das veranschaulichte System 100 lediglich ein Beispiel ist und mehr, weniger und/oder anders angeordnete Elemente verwendet werden können.
-
Wie in 1 veranschaulicht, kann das Fahrzeug 102 eine Vielzahl von Steuerungen oder ECUs beinhalten, wobei jede mit einem einer Vielzahl von Teilnetzen eines fahrzeuginternen Netzwerks 104 verbunden ist, um miteinander zu kommunizieren. Das fahrzeuginterne Netzwerk 104 kann als einige Beispiele unter anderem eines oder mehrere von einem Controller Area Network (CAN), einem Ethernet-Netzwerk und einem medienorientierten Systemtransport (media-oriented system transport - MOST) beinhalten. Als ein Beispiel kann das fahrzeuginterne Netzwerk 104 als ein „Stem“-Netzwerk konfiguriert sein, in dem ein Enhanced Central Gateway (ECG) 106 dazu konfiguriert sein kann, die Datenkommunikation zwischen verschiedenen Knoten als einen zentralen Knoten zu koordinieren, mit dem alle anderen Knoten verbunden sind. Das ECG 106 kann mit einer Rechenplattform 108 verbunden sein, die dazu konfiguriert ist, Anweisungen, Befehle und andere Routinen durchzuführen, um die in dieser Schrift beschriebenen Prozesse zu unterstützen. Die Rechenplattform 108 kann beispielsweise dazu konfiguriert sein, Anweisungen auszuführen, um Merkmale bereitzustellen, wie etwa Navigation, Fahrzeugdatensammlung und Diagnose und Drahtloskommunikation. Die Rechenplattform 108 kann mit verschiedenen Merkmalen bereitgestellt sein, die es den Fahrzeuginsassen/-benutzern ermöglichen, eine Schnittstelle mit der Rechenplattform 108 herzustellen. Zum Beispiel kann die Rechenplattform 108 Eingaben von Steuerungen 110 einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI) empfangen, die dazu konfiguriert sind, eine Interaktion zwischen Insassen und dem Fahrzeug 102 bereitzustellen. Als ein Beispiel kann die Rechenplattform 108 eine Schnittstelle mit einer oder mehreren Tasten (nicht gezeigt) oder anderen HMI-Steuerungen herstellen, die dazu konfiguriert sind, Funktionen auf der Rechenplattform 108 aufzurufen (z. B. Audiotasten am Lenkrad, einer Push-to-Talk-Taste, Steuerungen am Armaturenbrett usw.).
-
Die Rechenplattform 108 kann zudem eine oder mehrere Anzeigen 112 und Kameras 114 antreiben oder anderweitig damit kommunizieren, die dazu konfiguriert sind, eine visuelle Ausgabe und Eingabe für/von Fahrzeuginsassen mittels einer Videosteuerung 116 bereitzustellen. In einigen Fällen kann es sich bei der Anzeige 112 um einen Touchscreen handeln, der ferner dazu konfiguriert ist, Berührungseingaben von Benutzern über die Videosteuerung 116 zu empfangen, wohingegen es sich bei der Anzeige 112 in anderen Fällen lediglich um eine Anzeige ohne Fähigkeiten zur Berührungseingabe handeln kann. Die Rechenplattform 108 kann ferner eine oder mehrere Lautsprecher 118 und Mikrofone 120 steuern oder anderweitig damit kommunizieren, welche dazu konfiguriert sind, eine Audioausgabe und -eingabe für/von Fahrzeuginsassen mittels einer Audiosteuerung 122 bereitzustellen.
-
Die Rechenplattform 108 kann zudem mit Navigations- und Routenplanungsmerkmalen bereitgestellt sein, z.B. über die HMI-Steuerungen 110, und geplante Routen und Anweisungen über den Lautsprecher 118 und die Anzeige 112 ausgeben. Standortdaten, die für die Navigation benötigt werden, können von einer Steuerung 124 eines globalen Navigationssatellitensystems (global navigation satellite system - GNSS) gesammelt werden, die dazu konfiguriert ist, mit mehreren Satelliten zu kommunizieren und den Standort des Fahrzeugs 102 zu berechnen. Die GNSS-Steuerung 124 kann dazu konfiguriert sein, verschiedene derzeitige und/oder zukünftige globale oder regionale Standortsysteme zu unterstützen, wie etwa das globale Positionsbestimmungssystem (global positioning system - GPS), Galileo, Beidou, das globale Navigationssatellitensystem (Global Navigation Satellite System - GLONASS) und dergleichen.
-
Das Fahrzeug 102 kann dazu konfiguriert sein, mit einem entfernten Server (alias Cloud-Server oder Cloud) 126 über einen drahtlosen Sendeempfänger 128 über einen Zugangspunkt 130 zu kommunizieren, wenn verfügbar. Der drahtlose Sendeempfänger 128 kann mit verschiedenen drahtlosen Steuerungen (nicht gezeigt) in Kommunikation stehen, die dazu konfiguriert sind, unterschiedliche Kommunikationsprotokolle zu unterstützen. Beispielsweise kann der drahtlose Sendeempfänger 128 dazu konfiguriert sein, Wi-Fi, Bluetooth, Funkfrequenzidentifikation (radio-frequency identification - RFID) und/oder Nahfeldkommunikation (near-field communication - NFC) zu unterstützen, die mit dem Zugangspunkt 130 kompatibel sind, um Zugang zu dem entfernten Server 126 zu erlangen. Zusätzlich oder alternativ dazu kann das Fahrzeug 102 ferner dazu konfiguriert sein, mit dem entfernten Server 126 über eine TCU 132 über ein drahtloses Netzwerk 134 zu kommunizieren. Das drahtlose Netzwerk 134 kann in Form verschiedener Kommunikationsnetzwerke, z. B. eines Mobilfunknetzes, vorliegen. Es ist anzumerken, dass die Ausdrücke Zugangspunkt und drahtloses Netzwerk in der vorliegenden Offenbarung als allgemeine Ausdrücke verwendet werden und ein beliebiges Rechennetzwerk beinhalten können, das Träger, Router, Computer, Steuerungen oder dergleichen beinhaltet, die dazu konfiguriert sind, Daten zu speichern und Datenverarbeitungsfunktionen durchzuführen und Kommunikation zwischen verschiedenen Entitäten zu erleichtern. Darüber hinaus wird der Ausdruck Server 126 in der vorliegenden Offenbarung auch als allgemeiner Begriff verwendet und kann beliebige Rechenvorrichtungen beinhalten, die mit Verarbeitungs-, Routing- und Speicherfunktionen ausgestattet und dazu konfiguriert sind, mit verschiedenen Entitäten zu kommunizieren und verschiedene Vorgänge durchzuführen.
-
Das ECG 106 kann ferner dazu konfiguriert sein, mit verschiedenen ECUs zu kommunizieren, die dazu konfiguriert sind, verschiedene Merkmale des Fahrzeugs 102 zu betreiben und zu steuern. Beispielsweise kann das ECG 106 mit einem Karosseriesteuermodul in Kommunikation stehen, das dazu konfiguriert ist, Karosserievorgänge, wie etwa Türen und Lichter des Fahrzeugs 102, zu steuern. Das ECG 106 kann ferner dazu konfiguriert sein, mit einer Steuerung 138 eines autonomen Fahrers zu kommunizieren, die dazu konfiguriert ist, Merkmale des autonomen Fahrens des Fahrzeugs 102 zu steuern. Das ECG 106 kann ferner dazu konfiguriert sein, mit einem Antriebsstrangsteuermodul 140 zu kommunizieren, das dazu konfiguriert ist, Antriebsstrangvorgänge, wie etwa Elektromotor und Getriebe des Fahrzeugs 102, zu steuern.
-
Unter Bezugnahme auf 2 ist eine schematische Darstellung für ein Fahrzeugdiagnosesystem einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Unter weiterer Bezugnahme auf 1 sind in dem vorliegenden Beispiel nur drei Knoten an der Diagnose beteiligt, obwohl in anderen Beispielen mehr oder weniger Knoten beteiligt sein können. Darüber hinaus befindet sich der Diagnosemaster im vorliegenden Beispiel auf dem ECG 106. Wie veranschaulicht, beinhalten die drei ECUs, die als Knoten des vorliegenden Beispiels betrieben werden, ein ECG 106, eine Rechenplattform 108 und eine TCU 132. Jeder Knoten kann ein nichtflüchtiges Speichermedium 202 beinhalten, das dazu konfiguriert ist, verschiedene Daten jeder jeweiligen ECU zu speichern. Beispielsweise kann der Speicher 202 dazu konfiguriert sein, Diagnoseereignismetadaten 204, die in Zusammenhang mit einem Diagnoseereignis stehen, zu speichern. Jede ECU kann eine lokale Kopie der Metadaten 204 für jedes von ihr erzeugte Ereignis enthalten. Darüber hinaus kann jede ECU mit einer Analysebibliothek 206 bereitgestellt sein, die als Schnittstelle für Software zum Erstellen und Senden von Analyse- und Diagnoseereignissen konfiguriert ist. Die Bibliothek 206 kann lokal in jede jeweilige ECU verteilt oder alternativ dazu als gemeinsame Bibliothek auf jeder miteinander kommunizierenden ECU bereitgestellt werden.
-
Das ECG 106, in dem sich der Diagnosemaster im vorliegenden Beispiel befindet, kann ferner mit einem Analyseagenten 208 bereitgestellt sein, der dazu konfiguriert ist, durch verschiedene ECUs erzeugte Analyseereignisse zu empfangen und zu verarbeiten und die Analysedaten 210 in dem Speicher 202a zu speichern. Der Analyseagent 208 kann ferner dazu konfiguriert sein, Ereignisse zur weiteren Analyse an den Server 126 zu übertragen. Wie vorstehend erörtert, kann sich ein Diagnoseagent 212 in jedem Knoten des Fahrzeugs 102 befinden, der dazu konfiguriert ist, ECU-spezifische Aufgaben durchzuführen, wie etwa Sammeln von Protokollen von der ECU zum Zeitpunkt oder unmittelbar vor dem Fehler und Speichern der Daten als Diagnosedaten 214 in dem Speicher 202 jeder jeweiligen ECU. Der Diagnoseagent 212 kann ferner dazu konfiguriert sein, einen Satz ECU-spezifischer Metadaten 204 zu sammeln und zu pflegen, die sowohl von der Diagnose als auch von der Analyse verwendet werden, um Ereignisse zu dekorieren, bevor sie an den Server 126 geliefert werden. Jeder Diagnoseagent 212 kann dazu konfiguriert sein, seine jeweiligen erzeugten Diagnoseereignisse auf Anweisung eines Diagnosemasters 216 auf den Server 126 hochzuladen. Es ist anzumerken, dass einige ECUs in Abhängigkeit von der konkreten Konfiguration jeder jeweiligen ECU möglicherweise nicht dazu konfiguriert sind, direkt mit dem Server 126 zu kommunizieren. Daher können die Diagnoseagenten 212 dazu konfiguriert sein, einzeln oder gemeinsam über eine oder mehrere ECUs mit Zugriff auf den Server 126, wie etwa die TCU 132 oder den drahtlosen Sendeempfänger 128, auf den Server 126 hochzuladen. Der Diagnosemaster 216 kann sich zu einem bestimmten Zeitpunkt nur auf einer einzigen ECU befinden, bei der es sich um die gleiche handelt wie der Analyseagent. In dem vorliegenden Beispiel befindet sich der Diagnosemaster 216 auf dem ECG 106. Der Diagnosemaster 216 kann dazu konfiguriert sein, das Hochladen von Ereignissen durch jede ECU zu entscheiden. Der Diagnosemaster 216 kann ferner dazu konfiguriert sein, eine Masterliste aller Diagnoseereignisse, die durch jede ECU erzeugt wurden, und den aktuellen Lieferstatus jedes Ereignisses zu pflegen. Für Konnektivitätssicherheitszwecke kann der Diagnosemaster 216 dazu konfiguriert sein, gemeinsam ein Authentifizierungstoken von dem Server 126 seitens jedes Diagnoseagenten 212 zu erhalten. Das Authentifizierungstoken kann für Authentifizierungen zwischen jedem Diagnoseagenten 212 und dem Server 126 verwendet werden.
-
Die Vorgänge der Ausführungsform, die unter Bezugnahme auf 2 veranschaulicht sind, können auf das folgende Beispiel angewendet werden. Als Reaktion auf das Erkennen eines Ausfalls/Fehlers, der auf dem Navigationssystem aufgetreten ist (z. B. kann nicht nach POIs gesucht werden), kann die Rechenplattform 108 ein Diagnoseereignis auslösen, das Protokolldaten von verschiedenen damit in Zusammenhang stehenden Knoten des Fahrzeugs 102 anfordert. Die Identität damit in Zusammenhang stehender Knoten und angeforderter Protokolle kann in Software oder der Analysebibliothek 206 vordefiniert sein. In dem vorliegenden Beispiel kann es insgesamt drei Knoten/ECUs geben, die mit einem derartigen Navigationssystemfehler in Zusammenhang stehen - die Rechenplattform 108, die dazu konfiguriert ist, die Navigationsfunktion zu betreiben, das ECG 106, das dazu konfiguriert ist, die Kommunikation zwischen den ECUs zu überbrücken, und die TCU 132, die dazu konfiguriert ist, mit dem Cloud-Server 126 zu kommunizieren, da Fehler in einem beliebigen der drei Knoten das vorliegende konkrete Problem auslösen können. Die identifizierten Protokolle können Diagnosedaten 214, die aus Befehlen/Tests bestehen, und/oder Metadaten 204, die aus Rohdaten jeder jeweiligen ECU bestehen, beinhalten. In dem vorliegenden Beispiel befinden sich der Analyseagent 208 und der Diagnosemaster 216 beide auf dem ECG 106. Die Analysebibliothek 206b der Rechenplattform 108 kann hinsichtlich der angeforderten Protokolldaten mit dem Diagnoseagenten 212b kommunizieren. Als Reaktion auf das Empfangen der Kommunikationsnachricht von der Analysebibliothek 206b kann der Diagnoseagent 212b über das fahrzeuginterne Netzwerk 104 mit dem Diagnosemaster 216 kommunizieren, der sich auf dem ECG 106 befindet, indem er alle angeforderten Protokolle auflistet. Anders ausgedrückt kann der Diagnosemaster 216 durch eine Nachricht von dem Diagnoseagenten 212b der Rechenplattform 108 über die Identität von Knoten und Protokollen informiert werden, die mit dem vorliegenden Ereignis in Zusammenhang stehen. Ferner kann in der Nachricht eine GEID für das vorliegende Ereignis beinhaltet sein, die durch den Diagnoseagenten 212b der Rechenplattform 108 - den Ursprungsknoten - erzeugt wurde. Die übergeordnete GEID kann ermöglichen, dass alle Ereignisse über eine übergeordnete/untergeordnete Beziehung zu einem einzelnen Ereignis auf dem Server 126 korreliert werden. Anders ausgedrückt kann es sich bei den von der Rechenplattform 108 erfassten Protokollen um übergeordnete Ereignisse handeln, während es sich bei Protokollen, die in dem vorliegenden Beispiel von dem ECG und der TCU erfasst wurden, um untergeordnete Ereignisse handeln kann.
-
Als Reaktion auf das Empfangen der Nachricht von dem Diagnoseagenten 212b des Ursprungsknotens 108 kann der Diagnosemaster 216 bestimmen, welche Protokollanforderungen an jede ECU gerichtet werden sollten, und eine Protokollanforderungsnachricht über das fahrzeuginterne Netzwerk 104 übertragen, um jeden relevanten Knoten darüber, was zu sammeln ist, zu informieren. In dem vorliegenden Beispiel wird der Diagnoseagent 212c der TCU 132 benachrichtigt, die angeforderten Protokolle zu erfassen und die Protokolle an den Diagnosemaster 216 zu senden. Der Diagnoseagent 212c kann ferner die übergeordnete GEID von dem Diagnosemaster 216 empfangen, um die gesammelten Protokolle der GEID zuzuordnen. Ebenso kann der Diagnoseagent 212a des ECG 106 angewiesen werden, die Protokolle wie angefordert zu sammeln und die Protokolle derselben GEID zuzuordnen. Für die Rechenplattform 108, von der das aktuelle Ereignis stammt, können die angeforderten Protokolle direkt an den Diagnosemaster 216 gesendet werden, ohne dass eine Anforderung empfangen werden muss, da die Protokollanforderungen von demselben Knoten stammen. Die Protokolle von unterschiedlichen Knoten können gemeinsam zur Diagnose über den Diagnosemaster 216 auf den Server 126 hochgeladen werden. Zusätzlich oder alternativ dazu kann jeder Diagnoseagent 212 dazu konfiguriert sein, die Protokolle einzeln, wie angefordert, als Reaktion auf die Nachricht für die Anforderung von Protokollen auf den Server hochzuladen. Nachdem die Ereignisse an den Server 126 übertragen wurden, kann jedes Ereignis die Protokolldaten sowie sowohl die übergeordnete GEID als auch die untergeordnete GEID enthalten, um dem Server 126 zu ermöglichen, die Daten zuzuordnen.
-
Unter Bezugnahme auf 3 ist ein beispielhaftes Flussdiagramm für einen Protokollsammelprozess 300 einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Unter weiterer Bezugnahme auf 1 und 2 erkennt eine Client-Software (z. B. Navigationssoftware) der Rechenplattform 108 bei Vorgang 302 einen Fehler und meldet den Fehler dem Diagnoseagenten 212b, der sich auf der Rechenplattform 108 befindet. Als Reaktion auf das Empfangen des Fehlerberichts bestimmt der Diagnoseaktor 212b alle Knoten und Protokolle von denjenigen Knoten, die für das Fehlerereignis relevant sind, und weist dem Ereignis eine GEID zu. Bei Vorgang 306 meldet der Diagnoseagent 212b das Fehlerereignis über eine Berichtsnachricht an den Diagnosemaster 216. Die Berichtsnachricht kann Informationen über den konkreten Fehler, die angeforderten Knoten und Protokolle, wie sie durch den Diagnoseagenten 212b bestimmt wurden, und die GEID beinhalten. In dem vorliegenden Beispiel befindet sich der Diagnosemaster 216 auf dem ECG 106. Als Reaktion auf das Empfangen der Berichtsnachricht, welche die Knoten und Protokolle identifiziert, sendet der Diagnosemaster 216 eine Anforderung für Protokolle an den Diagnoseagenten 212 dieser Knoten, wie sie bei Vorgang 308 identifiziert wurden. In dem vorliegenden Beispiel handelt es sich bei der TCU 132 um einen der identifizierten Knoten. Die Berichtsnachricht kann ferner identifizieren, dass es sich bei dem Ursprungsknoten - die Rechenplattform 108 - um einen der für das Fehlerereignis relevanten Knoten handelt. Da der Diagnoseagent 212b der Rechenplattform 108 jedoch bereits identifiziert hat, welches der Protokolle zu übermitteln ist, muss der Diagnosemaster 216 keine Anforderung für Protokolle an den Ursprungsknoten zurücksenden. Bei Vorgang 310, 312 und 314 sammelt der Diagnoseagent 212 von jedem relevanten Knoten die identifizierten Protokolle. Die angeforderten Protokolle können Diagnosedaten 214, die aus Befehlen/Tests bestehen, und/oder Metadaten 204, die aus Rohdaten jeder jeweiligen ECU bestehen, beinhalten. Zusätzlich dazu können die Protokolle ferner beliebige andere Informationen beinhalten, die verwendet werden können, um die Diagnose und Fehlerbehebung zu erleichtern, wie etwa ein Bildschirmfoto, eine Audio- oder Videoaufzeichnung. Zum Beispiel kann der Diagnoseagent 212b der Rechenplattform 108 ein Bildschirmfoto der Anzeige 112 zu dem Zeitpunkt sammeln, zu dem der Fehler aufgetreten ist, um ihn einem Techniker auf der Serverseite bereitzustellen. Zusätzlich dazu kann der Diagnoseagent 212b Audioklänge und/oder Videobilder über das Mikrofon 120 bzw. die Kamera 114 zu Diagnosezwecken aufzeichnen.
-
Um die Protokolle an den Server 126 zu senden, benötigt jeder Diagnoseagent 212 ein Sicherheitstoken für Authentifizierungszwecke. Das Sicherheitstoken kann gemeinsam durch den Diagnosemaster 216 erlangt werden. Bei Vorgang 316 sendet der Diagnosemaster 216 eine Anforderung für ein Sicherheitstoken an den Server 126 und empfängt das Sicherheitstoken bei Vorgang 318. Bei Vorgang 320 und 322 sendet der Diagnosemaster 216 das Sicherheitstoken an den Diagnoseagenten 212 des jeweiligen Knotens. Als Reaktion auf das Empfangen des Sicherheitstokens laden die Diagnoseagenten die Protokolle, wie sie gesammelt wurden, auf den Server 126 hoch.
-
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen 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 kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
-
Gemäß einer Ausführungsform ist die erste Steuerung ferner zu Folgendem programmiert: Aufzeichnen eines Audioklangs über ein Mikrofon für eine vordefinierte Zeit als Reaktion auf den Fehler und Speichern des Audioklangs als eines der Protokolle der ersten Steuerung.
-
Gemäß einer Ausführungsform ist die erste Steuerung ferner zu Folgendem programmiert: Aufzeichnen eines Videobilds über eine Kamera für eine vordefinierte Zeit als Reaktion auf den Fehler und Speichern des Videobilds als eines der Protokolle der ersten Steuerung.
-
Gemäß einer Ausführungsform ist die erste Steuerung ferner zu Folgendem programmiert: Erzeugen einer globalen Ereignisidentifikation (GEID) für das Fehlerereignis, Zuordnen von Protokollen der ersten Steuerung zu der GEID als übergeordnete Ereignisse zum Hochladen auf den Server und Senden der GEID an die eine zweite Steuerung in der Fehlernachricht. Die zweite Steuerung ist ferner zu Folgendem programmiert: als Reaktion auf das Empfangen der GEID, Zuordnen der Protokolle der zweiten Steuerung zu der GEID als untergeordnete Ereignisse zum Hochladen auf den Server.
-
Gemäß einer Ausführungsform ist die zweite Steuerung ferner zu Folgendem programmiert: Senden der GEID an die dritte Steuerung, und die dritte Steuerung ist ferner zu Folgendem programmiert: als Reaktion auf das Empfangen der GEID, Zuordnen der Protokolle der dritten Steuerung zu der GEID als untergeordnete Ereignisse zum Hochladen auf den Server.
-
Gemäß einer Ausführungsform ist die Infotainment-Steuerung ferner zu Folgendem programmiert: Aufnehmen eines Bildschirmfotos einer Anzeige innerhalb einer vordefinierten Zeit, nachdem der Fehler erkannt wurde, und Speichern des Bildschirmfotos als eines der Protokolle der Infotainment-Steuerung.
