-
Die Erfindung betrifft ein Verfahren zur Aufzeichnung von Fahrzeugdaten.
-
In der
DE 10 2015 015 393 A1 sind ein Verfahren und ein System zur Aufzeichnung einer Fehlermeldung einer in einem Fahrzeug angeordneten Telematikkomponente während einer Testfahrt eines Fahrzeugs bekannt. In diesem Verfahren werden während der Testfahrt Datenfolgen der Telematikkomponente des Fahrzeuges mittels eines prozessorgesteuerten Datenspeichers aufgezeichnet, wobei ein Triggersignal gesetzt wird, wenn ein Fehler auftritt, und die aufgenommene Datenfolge nach dem Triggersignal auf einen Server geladen wird.
-
Der Erfindung liegt die Aufgabe zu Grunde, ein gegenüber dem Stand der Technik verbessertes Verfahren zur Aufzeichnung von Fahrzeugdaten anzugeben.
-
Die Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zur Aufzeichnung von Fahrzeugdaten mit den Merkmalen des Anspruchs 1.
-
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
-
In einem Verfahren zur Aufzeichnung von Fahrzeugdaten werden erfindungsgemäß mittels Datenloggern in allen Fahrzeugen einer Fahrzeugflotte Daten aller Datenbusse der Fahrzeuge aufgezeichnet und an einen zentralen Server gesendet. Datenlogger sind prozessorgesteuerte Speichereinheiten, welche Daten in einem bestimmten Rhythmus über eine Schnittstelle aufnehmen und auf einem Speichermedium ablegen.
-
Bei dieser erfindungsgemäßen Lösung werden insbesondere Datenlogger einer Prototypenfahrzeugflotte eines jeweiligen Fahrzeugherstellers und/oder als Datenlogger genutzte Telematiksteuereinheiten (TCU) verwendet, um ein prädiktives Diagnose-Test-System aufzubauen, das während einer Entwicklungs- und Testphase verwendet werden kann, um Massendaten, auch als Big Data bezeichnet, zu analysieren.
-
Basierend auf den gespeicherten Informationen in den Datenloggern der Fahrzeugflotte und deren späterer Nachbearbeitung im zentralen Server, auch als Cloud bezeichnet, kann nicht nur ein jeweiliger Fahrzeugstandort, wenn ein Fehlercode erstmals auf aktiv oder passiv gesetzt wurde, und eine Umgebung oder ein Kontext bei Auftreten eines Fehlers, ermittelt werden, sondern es können auch entsprechende Informationen aus vorhergehenden Stunden, Tagen und Wochen ermittelt werden. Durch Reverse Engineering, das heißt durch Rekonstruktion oder Nachkonstruktion, kann dann herausgefunden werden, wodurch die Fehlfunktion verursacht wurde. Dies kann auch in einer realen Testvorrichtung erfolgen, in welcher ein Satz von Telematiksteuereinheiten (TCU) die zuvor aufgezeichneten Log-Dateien reproduziert. Der Vorteil der Verarbeitung der riesigen Datenmenge im zentralen Server, der so genannten Cloud, und/oder in einer solchen Testvorrichtung, ist eine Kostenreduzierung im Vergleich zur Datenverarbeitung in der realen Fahrzeugflotte mit vielen Sensoren.
-
Ausführungsbeispiele der Erfindung werden im Folgenden anhand einer Zeichnung näher erläutert.
-
Dabei zeigt:
- 1 schematisch ein Verfahren zur Aufzeichnung von Fahrzeugdaten.
-
Anhand 1 wird im Folgenden ein Verfahren zur Aufzeichnung von Fahrzeugdaten erläutert.
-
Die Erfindung schlägt einen neuen Mechanismus vor, der als Predictive Diagnostics Framework bezeichnet wird und durch den Einsatz von Big Data (Massendaten) den Erstausrüstern (OEM) hilft, die Ursachen von Fahrzeugfehlfunktionen besser zu verstehen, damit diese korrigiert werden können, bevor die Fahrzeuge F auf den Markt kommen. Wenn die Fahrzeuge F bereits im Markt sind, kann vorhergesagt werden, wann die Fehlfunktion auftreten kann und/oder es können Gegenmaßnahmen getroffen werden.
-
Grundsätzlich wird ein Mechanismus vorgeschlagen, um jedes Fahrzeugsignal, das während der Fahrt einer Testfahrzeugflotte in die Fahrzeugdatenbusse (CAN, LIN, Most usw.) gesendet wird, zu speichern und zu verarbeiten, zuzüglich der Verwendung von Diagnoseanfragen, die periodisch durch eine an Bord befindliche Telematiksteuereinheit (TCU) ausgelöst werden.
-
Es werden zwei verschiedene Ansätze vorgeschlagen, wie die aufgezeichnete Datenmenge verarbeitet werden kann: eine cloudbasierte Verarbeitung und zusätzlich eine auf realer Hardware basierte Verarbeitung.
-
Im Allgemeinen vermitteln beide Mechanismen den Erstausrüstern ein besseres Verständnis der Umgebungsvariablen, des Fahrzeugorts usw., die während einer Fehlfunktion aufgetreten sind und/oder die zuvor aufgetreten sind und zu dieser Fehlfunktion führten.
-
In Zukunft wird es auch möglich sein, solange die TCU-Speicherkapazität weiter steigt und/oder die Übertragungskosten zur Cloud sinken, dass die TCUs direkt als Datenlogger agieren könnten, so dass der vorgeschlagene Mechanismus dann von einer Testfahrzeugflotte (mit einer begrenzten Anzahl von Fahrzeugen F) erweitert werden könnte auf eine Kundenfahrzeugflotte (mit einer unbegrenzten Anzahl von Fahrzeugen F).
-
Die Erfindung beruht auf der Verwendung von standardisierten Diagnoseanforderungen wie UDS (Unified Diagnostic Services) und/oder anderen Diagnoseprotokollen (z. B. ISO 14230-3 / KWP2000 oder ISO-15765-3-doCAN, OBD-II usw.), die während der Fahrt von einer TCU (Telematics Control Unit) oder einem externen Diagnose-Auslösegerät periodisch ausgelöst werden.
-
Unified Diagnostic Services (UDS) ist das standardisierte Diagnoseprotokoll, das von den Erstausrüstern (OEM) verwendet wird. Dieses Kommunikationsprotokoll wird mittlerweile in fast allen neuen Steuergeräten (Electronic Control Unit) von Tier-1-Lieferanten von Erstausrüstern (OEM) verwendet.
-
DTC (Data Trouble Codes) sind Fehler, die in jeder elektronischen Steuereinheit (ECU) definiert sind und entweder interne Fehler (z. B. Überhitzung, ECU-Reset usw.) oder externe Fehler (schlechte Verbindung zum Peripherieelement, Fehlen eines CAN-Eingangssignals usw.) sein können. Typischerweise hat ein DTC mindestens zwei verschiedene Status, aktiv, wenn der Grund des Fehlers noch aktiv ist, oder passiv, wenn der Grund nicht mehr besteht.
-
Jede ECU führt eine interne Prüfung/Routine durch, die beim Einschalten der Zündung interne und externe Fehlercodes auslöst. Die interne Prüfung/Routine kann auch durch eine externe Diagnoseanforderung ausgelöst werden.
-
Es gibt verschiedene Arten von Diagnosebefehlen, zusätzlich zum Lesen von DTCs, wie zum Beispiel Lese- und Schreibdienste, Variantencodierung, Routinen, Ein-/Ausgabe-Steuerungen usw.
-
Einer der Hauptvorteile der Verwendung von Datenloggern ist die Möglichkeit, Daten automatisch rund um die Uhr zu erfassen. Nach der Aktivierung werden Datenlogger typischerweise unbeaufsichtigt laufen gelassen, um Informationen für die Dauer des Überwachungszeitraums zu messen und aufzuzeichnen. Dies ermöglicht ein umfassendes und genaues Bild der überwachten Umgebungsbedingungen wie Lufttemperatur und relative Luftfeuchtigkeit. Die Kosten für Datenlogger sind im Laufe der Jahre gesunken während sich die Technologie verbessert hat. Einfache Einkanal-Datenlogger kosten nur 25 US-Dollar. Kompliziertere Logger können Hunderte oder Tausende von Dollar kosten.
-
Erstausrüster (OEM) statten jedes Fahrzeug F ihrer Fahrzeug-Protoype-Flotte mit solchen Datenloggern aus, die im Wesentlichen alle internen Fahrzeugbusse (CAN, LIN, Ethernet usw.) überwachen, einschließlich des Diagnose-CAN, an den die TCU und/oder externe Tester Diagnoseanforderungen/-antworten für die oben erläuterten Fahrzeugferndiagnosedienste senden und von dem sie solche empfangen.
-
Die Übertragung von den Datenloggern im Fahrzeug F zu externen Servern S zur Analyse der Daten kann manuell mit einem PC/Ethernet-Kabel erfolgen, oder automatisch per WLAN zu einem PC-Server S und von dort zur Cloud zur späteren Nachbearbeitung/Analyse.
-
Die Telematiksteuereinheit (TCU) ist ein integriertes Onboard-System, das die drahtlose Verfolgung von und Kommunikation mit dem Fahrzeug F steuert. TCUs werden in der elektronischen Mauterhebung, eCall Crash Notification und Pannenhilfe, Fahrzeugverfolgung, Remote Door Services, Navigation, Verkehrsunterstützung, Concierge-Service, Video- und Audio-Entertainment, Flottenmanagement sowie Diagnose eingesetzt. Die TCU unterstützt viele Schnittstellen einschließlich Audio, LIN, CAN, Bluetooth/WLAN und andere.
-
Typischerweise können diese TCUs unterschiedliche Fahrzeugdiagnose-Scans durchführen, so dass sie eine Broadcast-Anfrage an alle ECUs senden können, zum Beispiel um die gespeicherten DTCs zu lesen (Datenfehlercode oder interner Fehler von dieser ECU), oder um eine Anfrage an eine spezifische ECU zu senden, um eine Diagnoseroutine durchzuführen.
-
Obwohl die TCU in der Regel nicht als Datenlogger arbeitet, könnte die Protokollierungsfunktion durch eine vergrößerte interne Festplatte und die verzögerte Durchführung der Datenübertragung bei stehendem Fahrzeug F (per 5G) oder sogar per WLAN bei gegebener Infrastruktur implementiert werden.
-
Eine mit einem Fahrzeug-CAN-Bus (typischerweise Diagnostic-CAN) verbundene TCU überträgt nur einen reduzierten Datensatz zum Fahrzeugzustand (zum Beispiel Kilometerzähler, Geschwindigkeit, Türzustand, Reifendruck, Sammeldaten usw.). Die Informationen werden nicht kontinuierlich, sondern nur während vordefinierter Ereignisse gesendet, zum Beispiel Zündung an/aus und/oder während der Fahrt mit einer Dauer von beispielsweise zwei Minuten. Einer der Gründe, den Datenfluss vom Fahrzeug F zur Cloud einzuschränken, sind die Datenübertragungskosten. Der andere Grund ist, dass der Hauptzweck des Sendens eines reduzierten Satzes von Fahrzeugstatusdaten an die Cloud Endverbraucherdienste sind, beispielsweise das Anzeigen einiger dieser Fahrzeugstatusdaten in einem Smartphone oder auf einer Website, weshalb die Menge an gesendeten Daten begrenzt ist.
-
Beispielsweise können 7 Stunden Fahrt von Stuttgart nach Düsseldorf ein Datenvolumen zwischen Fahrzeug F und der Cloud von etwa 9 Mbyte erzeugen. Ein vollständiges Protokoll aller Signale, die im selben Diagnose-CAN enthalten sind, mit dem die TCU verbunden ist, kann für die gleiche Fahrt 2,6 GB Daten enthalten, und wenn die restlichen Fahrzeugbusse (Body CAN, Motor CAN, FlexRay, Ethernet) hinzugefügt werden, von denen andere Fahrzeugsignale gesendet, aber nicht an die TCU (angeschlossen an den D-CAN) weitergeleitet werden, kann die Datenmenge auf 30 GByte bis 40 GByte anwachsen. Diese Datenmengen sollten offensichtlich nicht über 3G/4G in die Cloud gesendet werden, sondern nur für herkömmliche Kunden-Commodity-Services. Dafür gibt es keinen Geschäftsfall.
-
In der Entwicklungsphase (wo Fahrzeuge F mit Datenloggern ausgestattet sind, wird die notwendige Infrastruktur, zum Beispiel WLAN, zur Verfügung gestellt) oder für den Einsatz spezieller Flotten/Kunden (Nutzfahrzeuge, LKWs etc.), sind das Sammeln und die Analyse riesiger Datenmengen während der Fahrt ebenso durchführbar.
-
Die Erfindung schlägt einen Mechanismus vor, um die mit Datenloggern und/oder mit TCU (die sich als Datenlogger verhalten kann) ausgestattete OEM-Prototyp-Fahrzeugflotte zu verwenden, um ein prädiktives Diagnosetest-Framework zu bilden, das während der Entwicklungs- und Testphase verwendet werden kann (die typischerweise 1, 2 oder 3 Jahre dauert und Flotten von mehreren hundert Fahrzeugen F, die intensiv betrieben werden), um mittels Massendaten-Analysen (Big Data-Analysen) folgende Funktionen bereitzustellen:
- - Ermittlung des Grundes, der eine Fehlfunktion (z. B. Fehlercode oder DTC) verursacht hat,
- - Bewertung der Algorithmuslogik, um vorherzusagen, wann die nächste Fehlfunktion auftreten kann,
- - Extrahieren, welche Art von Fahrzeugsignalen und Diagnoseskripten zur Weiterleitung an den D-CAN und zum Senden von der TCU an die Cloud erforderlich sind und mit welcher Häufigkeit dieselbe Logik für Endkunden im Feld wiederholt werden muss. Mit anderen Worten: Herausfinden, was fehlt, um vorausschauende Diagnosen durchführen zu können, aber gleichzeitig den generierten Datenfluss im Feld / Zellnetzwerk zu reduzieren.
-
1 zeigt schematisch ein Verfahren zur Aufzeichnung von Fahrzeugdaten (Pooling der Big Data von Datenloggern).
-
Wie bereits erwähnt, zeichnen die Datenlogger während der Fahrtests der Fahrzeugflotte jede CAN-Kommunikation im Fahrzeug F auf. Bislang erfolgt die Übertragung von aufgezeichneten Daten nur für ausgewählte Fahrzeuge F, bei denen während des Fahrtests eine Fehlfunktion aufgetreten ist.
-
Die Erfindung schlägt stattdessen eine nichtselektive Übertragung vor, mit anderen Worten eine automatische Übertragung von Datalogs (zum Beispiel per WLAN) der Fahrzeugbusse aller Fahrzeuge F aus der gesamten Fahrzeugflotte an einen PC-Server S oder eine Cloud. Die oben beschriebenen Datenmengen sind unkomprimierte Daten. Sie können jedoch komprimiert werden, um die Menge der im Server S /Cloud gespeicherten Daten zu reduzieren.
-
In den D-CAN-Protokollen hat das System nun eine Liste aller Anforderungen, die während der Fahrt von der TCU an die ECUs gesendet wurden (zum Beispiel Fahrzeug-ECU-DTC-Abtastung) und die Antworten der ECU an diese. Wenn zum Beispiel angenommen wird, dass ein bestimmter DTC nach 10.000 km ausgelöst wird, kennt das System durch Analysieren des D-CAN das Umgebungsszenario des Fahrzeugstatus, und weiß, wann der DTC zum ersten Mal aufgetreten ist, wann er sich auf aktiv geändert hat, wann/ob er sich auf passiv geändert hat, usw. Die CAN-Verfolgung beinhaltet auch die Geolokalisierung des Fahrzeugs F und die aktuelle GPS-Zeit, da die Head Unit/Navigationssystem diese Informationen mit anderen ECUs teilt. Das bedeutet, dass das System nicht nur weiß, wann der Fehler zuerst aufgetreten ist, sondern auch, wo, wann und ob der Fehler verschwindet. Abhängig davon, wie oft die Diagnoseskripte den Fahrzeugdiagnose-Scan starten, ist die Zeitlücke enger, aber im schlechtesten Fall, wenn die Zündung ein- und ausgeschaltet wird, ist bekannt, wann eine Fehlfunktion auftritt, so dass die Genauigkeit ziemlich hoch ist.
-
All diese Informationen können lediglich aus der Analyse der D-CAN-Protokolle extrahiert werden. Da aber die kompletten Busse des Fahrzeugs F parallel überwacht werden, hat das System ein sehr gutes Bild von dem, was in den verschiedenen Datenbussen vor sich ging (zum Beispiel Motor, Karosserie, Antriebsstrang usw.).
-
Bei einer Diagnose-Anfrage von einem Tester oder TCU (Tx) zu einer ECU (Rx) kann die Verwendung des Transportprotokolls, abhängig von der Länge der Anfrage und der Antwort, wenn sie die 8 Bytes einer CAN-Nachricht überschreiten, die gesamte Kommunikation in verkettete Telegrammen aufteilen.
-
Die Nutzdaten können mit einem Zeitstempel, einer Übermittlungsrichtung, beispielsweise zwischen einem Tester und einer ECU oder umgekehrt, und einer CAN-ID versehen sein und ein oder mehrere Bytes Transportprotokoll-Steuerinformationen sowie optional Diagnosedaten umfassen. Die Nutzdaten können beispielsweise 8 Byte lang sein.
-
Die Nutzdaten und andere Diagnoseanforderungen und -antworten werden in den Datenprotokollen gespeichert, sodass kein Signal verloren geht. Der Datenlogger speichert sowohl Diagnoseanforderungen und -antworten als auch jedes andere CAN-Signal in den verschiedenen Fahrzeugbussen, die zusätzliche wertvolle Informationen enthalten und später für die Analyse großer Datenmengen verwendet werden können.
-
Sobald die Rohdaten der Fahrzeugflotte bereits in die Cloud übertragen wurden, können sie für jedes Fahrzeug F in seine verschiedenen Basen (CAN/LIN/etc.) aufgeteilt werden. Die Dekodierung der Rohdaten in die verschiedenen Fahrzeugsignale erfolgt in der Cloud oder auf einem externen Server mit den entsprechenden OEM-Fahrzeug-Signaldatenbanken. Die Decodierung der Diagnose-Rohdaten in diagnostische Nutzdaten/Signale erfolgt ebenfalls in der Cloud/Server mit der entsprechenden OEM-Diagnosedatenbank.
-
Das Framework enthält eine Anzahl von Knoten oder Blöcken, die virtuell die ECU repräsentieren, die in einem Fahrzeug F vorgesehen sind. Typischerweise kann ein modernes Fahrzeug F als Standard- und optionale Ausrüstung zwischen 30 und 60 ECU oder mehr enthalten. Jeder dieser Steuergerätebausteine weiß anhand der CAN-IDs, welche Diagnose-Kommunikation mit dem Tester/der TCU stattgefunden hat, da eine bidirektionale Kommunikation zwei unterschiedliche CAN-IDs (T/Rx) enthält, die für jedes Steuergerät eindeutig sind. Auf dieser Basis wissen die virtuellen Diagnose-Blöcke, welche Anforderungen die TCU während der Fahrt gesendet hat und welche Antwort das reale ECU gesendet hat, jeweils mit einem entsprechenden Zeitstempel.
-
Dies bedeutet zum Beispiel, dass, wenn eine TCU eine ECU auf Fehlercodes/DTCs abfragt, periodisch bei Zündung ein/aus und/oder während der Fahrt alle 10 Minuten, diese Kommunikation (einschließlich Anforderungen und Antworten) in der im Datenlogger gespeicherten Protokolldatei protokolliert wird, mit dem Zeitpunkt und dem Ort im Fahrzeug F, an dem der DTC zum ersten Mal aufgetreten ist. Zusätzlich wird jedes andere Fahrzeugsignal, das per CAN/LIN/MOST usw. gesendet wird, auch parallel aufgezeichnet.
-
Basierend auf den gespeicherten Informationen im Datenlogger der Fahrzeugflotte und deren späterer Nachbearbeitung in der Cloud kann sowohl erkannt werden, wo der Fahrzeugstandort war als der Fehlercode zuerst auf aktiv/passiv gesetzt wurde, welche die Umgebung oder welcher der Kontext war, als ein Fehler aufgetreten ist, als auch durch Reverse Engineering in den vorherigen Stunden, Tagen und Wochen ermittelt werden, was die Fehlfunktion verursacht hat.
-
Einige Beispiele für Anwendungsfälle:
- • Es wird angenommen, dass das korrekte Verhalten von ECU-1 davon abhängt, dass bestimmte CAN-Eingangssignale von einer anderen ECU-2 gesendet werden, was zu einem DTC in ECU-1 führt. Es wird weiter angenommen, dass ECU-2 manchmal eine interne Fehlfunktion hat, die unter bestimmten Umständen einen internen Reset verursacht und dass daher ECU-2 vorübergehend nicht die erwarteten Signale sendet. Durch Reverse Engineering konnte festgestellt werden, dass der DTC ausgelöst wurde, weil das CAN-Signal fehlte und der Umgebungskontext, wenn ECU-2 ausgefallen ist, konnte ermittelt werden.
-
In einer zweiten Phase kann ein zusätzliches Diagnose-Pooling in der TCU implementiert werden, das periodisch ECU-2 ansteuert (z.B. zur Anforderung von Rechenleistung oder Speicherressourcen), um diese Theorie zu untermauern und den Konstrukteuren zu helfen, ECU-2 korrekt zu entwerfen und/oder vorherzusagen wenn es versagen wird.
- • Ein Cabriodach weist eine Fehlfunktion auf, die das korrekte Öffnen/Schließen von Zeit zu Zeit verhindert. Nur das Datum und die Zeit, zu der der Fehler auftritt, sind bekannt. In diesem Fall wird kein DTC der Fehlfunktion gespeichert, da diese Bedingung nicht berücksichtigt wurde. Aus der Datenanalyse ist ersichtlich, dass die Außentemperatur des Fahrzeugs F bei Auftreten des Fehlers über 40 °C lag. Dies kann ein Hinweis darauf sein, dass die Fehlfunktion durch eine Überhitzung des Dachmechanismus verursacht wurde.
-
In einer zweiten Phase und um die Theorie zu untermauern, kann in der TCU ein zusätzliches Diagnose-Pooling implementiert werden, das periodisch die Dachsteuerungs-ECU auslöst und ihren internen Temperaturwert abfragt. Es kann daher nicht nur der Wert der Fahrzeugaußentemperatur sondern auch der Wert der internen Temperatur der ECU, die für den Mechanismus verantwortlich ist, ermittelt werden.
- • Ein Fahrzeugmotor stoppt während der Fahrt und kann nicht gestartet werden. Es werden keine DTCs ausgelöst. Ein Spezialistenteam definiert die Art der Signale, die zusätzlich helfen könnten, falls der Fehler erneut auftritt. Ein zusätzliches Diagnose-Pooling soll in zwei Motorsteuergeräten implementiert werden. CAN-Signale, die in verschiedenen Bussen zur Verfügung stehen, könnten auch helfen, ein besseres Bild dessen zu erhalten, was aufgetreten ist, bevor der Motor stehenblieb. Die neue Logik wurde in der Fahrzeugflotte implementiert und wartete auf das nächste Auftreten des Fehlers. Als nächstes wurde durch Reverse Engineering herausgefunden, dass die Fahrzeuge F, die die Fehlfunktion zeigten, mit Motoröl oberhalb der empfohlenen Grenzmengen befüllt werden. Da es sich bei den Fahrzeugen F um Sportwagen handelt und diese unter Belastungsbedingungen eingesetzt werden, die in den Logfiles zu sehen sind, führt dies zu einem schnelleren Verbrauch von Motoröl und Stehenbleiben des Motors. Basierend auf den gewonnenen Erkenntnissen werden zusätzliche CAN-Signale und -Skripte in der TCU implementiert, so dass im Falle, dass ein Endkunde das Fahrzeug F unter extremen Bedingungen verwendet, eine Erinnerung an den Kunden zum Ölwechsel vor den empfohlenen Standardintervallen ausgegeben wird, da ansonsten unter den aktuellen Fahrbedingungen der Motor in den nächsten 2 Monaten stehenbleiben könnte.
-
Der Vorteil der Verarbeitung der riesigen Datenmenge in der Cloud sind geringere Kosten gegenüber einer Verarbeitung in der realen Fahrzeugflotte mit mehreren Sensoren. Die für die gesamte Fahrzeugflotte generierten Daten überwachen alles, was in den letzten Monaten in jedem Fahrzeug F aufgetreten ist und/oder können durch Hinzufügen weiterer Diagnoseskripte in der TCU bei bestimmten Fehlfunktionen geändert werden.
-
Typischerweise sollte die Fahrzeugflotte für große Analysen eine bestimmte Anzahl von Fahrzeugen F haben, um den Algorithmus oder die Logik der Kette von Aktionen herausfinden zu können, die zu einer Fehlfunktion führen. Daher kann die Gesamtmenge von Proben (oder Fahrzeugen F) aufgeteilt werden, so dass zum Beispiel 70% davon verwendet werden, um den Algorithmus einer Fehlfunktion herauszufinden, und 30%, um ihn zu beweisen.
-
Der Nachweis eines Algorithmus kann dann auch in der Cloud durchgeführt werden, oder könnte in einer realen Bench oder in einem Test-Schrank durchgeführt werden, wo ein Satz von TCU die zuvor aufgezeichneten Log-Dateien reproduziert. Die Idee besteht darin, den gleichen Mechanismus zu reproduzieren, der bereits für die Cloud beschrieben wurde. Der Hauptunterschied besteht darin, dass die virtuellen Steuergeräte und ihre Antworten nicht in der Cloud, sondern in einer Framework-CAN-Simulation programmiert werden.
-
Die Simulation läuft auf einem Server S, der im Grunde die gesamte Kommunikation wiedergibt, die im D-CAN eines realen Fahrzeugs F erkannt wurde, das zuvor mit einem Datenlogger aufgenommen wurde. Der Server S kann auch mehrere Simulationen oder Instanzen ausführen, die jeweils ein virtuelles Fahrzeug F repräsentieren. Zu jeder dieser Simulationen kann eine TCU angeschlossen werden, die sich dann wie eine echte TCU in einem Fahrzeug F verhält, wobei die während der Fahrt gesehenen Signale (sowohl normale CAN- als auch Diagnosemeldungen) an das Backend/Cloud gesendet werden.
-
Jede Simulation reproduziert/wiederholt einen zuvor aufgezeichneten Datalog, filtert jedoch zuvor alle Diagnoseanforderungen und Antwortnachrichten zwischen der TCU und jedem ECU aus. Die davon nicht betroffenen Diagnose-CAN-Frames (Fahrzeugstatussignale) verbleiben und versorgen die TCU, da keine Synchronisation erforderlich ist.
Für die Diagnosekommandos ist jedoch eine Synchronisation erforderlich: Die tatsächlich angeschlossene TCU löst dann die Diagnoseskripte und Anforderungen entsprechend ihrer vorprogrammierten Auslösemechanismen aus (z. B. durch Zündung ein/aus, bei Fernabfrage, während der Fahrt mit einem periodischen Zyklus usw.), und diese Anfragen müssen synchron verarbeitet und beantwortet werden, wie durch die Diagnose- und Transportprotokolle spezifiziert, so wie es in einem echten Fahrzeug F der Fall ist.
-
Der Server S weiß, wann die Simulation gestartet wurde, und alle CAN-Frames (mit oder ohne Diagnose-Bezug) sind mit einem Zeitstempel versehen. So ist zu jedem Zeitpunkt bekannt, was passiert ist. Das heißt, wenn eine echte TCU eine Diagnoseanforderung an die Simulation sendet, würde sie zu diesem Zeitpunkt in einem echten Fahrzeug F wissen, welche Antwort die reale ECU an die in einem echten Fahrzeug F installierte TCU gab, und kann daher eine Diagnoseantwort senden, die auf sehr genaue Weise in dem CAN-simulierten Fahrzeug F reproduziert, was in einem echten Fahrzeug F aufgetreten ist.
-
Für den Kunden ergeben sich folgende Vorteile:
- - Geringere Konstruktions- oder Fehlfunktionsrate bei der Markteinführung neuer Modellreihen,
- - Wenn sich das Fahrzeug F bereits im Feld befindet, können Erkenntnisse basierend auf dem prädiktiven Framework bei Auftreten einer Störung gewonnen, und Vorschläge entwickelt werden, was getan werden muss, um die Störung zu vermeiden und/oder über mögliche Fehlfunktionen informiert zu sein.
-
Für den Fahrzeughersteller ergeben sich folgende Vorteile:
- - Besseres Verständnis der Ursache von Fahrzeugfehlfunktionen und deren Behebung vor dem Marktstart eines neuen Fahrzeugs F und/oder Festlegung von Gegenmaßnahmen/Hinweisen, um zu vermeiden, dass Fahrzeugfehlfunktionen vor Ort auftreten oder vorherzusagen, wann Fahrzeugfehlfunktionen auftreten können,
- - Hilfe bei der Definition der TCU-Diagnoseskripte und der Zusammenführung von Informationen, welche Fahrzeugsignale mit welcher Häufigkeit für die spätere Verarbeitung vom Fahrzeug F in die Cloud gebündelt werden sollen,
- - Das Big-Data-Pooling kann von Datenloggern in der Testfahrzeugflotte auf TCUs in der Fahrzeugflotte eines Kunden verlagert werden, da die Übertragungskosten zur Cloud und die notwendigen Speicher- und Verarbeitungsressourcen in den kommenden Jahren sinken werden.
-
Bezugszeichenliste
-
- F
- Fahrzeug
- S
- Server
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102015015393 A1 [0002]
