DE112017005163T5

DE112017005163T5 - Systeme und verfahren zur vorausschauenden ausfalldetektion in fahrzeugen

Info

Publication number: DE112017005163T5
Application number: DE112017005163.0T
Authority: DE
Inventors: Greg Bohl; Nikhil Patel
Original assignee: Harman International Industries Inc
Current assignee: Harman International Industries Inc
Priority date: 2016-10-12
Filing date: 2017-10-12
Publication date: 2019-07-25
Also published as: GB201905075D0; WO2018069853A1; US11847873B2; GB2569262B; KR20190069421A; KR102322838B1; JP7203021B2; JP2020500351A; US20230186697A1; US11605252B2; CN109844666A; GB2569262A; US20200051347A1; CN109844666B

Abstract

Systeme und Verfahren zum vorausschauenden Detektieren eines Fahrzeugausfalls auf Grundlage von Diagnose-Fehlercodes werden bereitgestellt. In einem Beispiel wird ein Verfahren bereitgestellt, umfassend Bestimmen einer Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs auf Grundlage von einem oder mehreren Diagnose-Fehlercodes (DTCs); und Angeben für einen Bediener des Fahrzeugs, dass der Ausfall als Reaktion darauf, dass die Wahrscheinlichkeit einen Schwellenwert überschreitet, wahrscheinlich erfolgt.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung Nr. 62/407,359 mit dem Titel „SYSTEMS AND METHODS FOR IN-VEHICLE PREDICTIVE FAILURE DETECTION“, eingereicht am 12. Oktober 2016, deren gesamter Inhalt hiermit durch Bezugnahme für sämtliche Zwecke aufgenommen sind.
GEBIET
Die vorliegende Offenbarung betrifft das Gebiet von analytischen Modellen, die verwendet werden, um Auswirkungen vorherzusagen, insbesondere, um zukünftige Kraftfahrzeugausfälle und Reparaturen für Produkte (Fahrzeuge) eines Kraftfahrzeug-Originalgeräteherstellers (Original Equipment Manufacturer - OEM) vorherzusagen, während sie sich in der Werksgarantie befinden.
HINTERGRUND
Kraftfahrzeug-OEMs streben kontinuierlich danach, bessere Produkte herzustellen und die Anzahl an Reparaturen, die während der Betriebsdauer des Fahrzeugs erforderlich sind, zu reduzieren. Um das Vertrauen der Verbraucher zu stärken, wird eine Garantie bei jedem neuen Fahrzeug bereitgestellt. Jedoch verringert sich die Wahrnehmung von Qualität, ob echt oder nicht, auch bei einer Garantie mit der Anzahl an Malen, die ein Fahrzeug für eine Garantiereparatur zurückgegeben wird.
KURZDARSTELLUNG
Durch das Verwenden eines vorausschauenden Analysemodells an einer Fahrzeugmarke und einem Fahrzeugmodell kann ein OEM die Gesamtanzahl an Malen, die ein Fahrzeug zur Reparatur gebracht wird, reduzieren, das Produkt verbessern, bevor eine Reparatur in großem Umfang benötigt wird, und möglicherweise Rückrufe in großem Umfang vermeiden. Diesbezüglich gibt es eine Verwendung für ein System, welches in der Lage ist, Fahrzeugausfälle vorherzusagen, bevor sie passieren; durch das vorausschauende Detektieren von Fahrzeugausfällen können unerwünschte Konsequenzen, wie etwa Störungen und Pannenhilfe, vermieden werden, wodurch die Wahrnehmung des Verbrauchers von der Fahrzeugqualität und das Vertrauen des Verbrauchers verbessert werden. Ferner können vorausschauende Analysen dem OEM ermöglichen, Ausfalltrends zu beobachten, wenn sie auftreten, wodurch kostenintensive und unangenehme Rückrufe in großem Umfang verhindert werden. Noch andere Vorteile werden in der folgenden Beschreibung ersichtlich.
Die vorstehenden Ziele können mit einem vorausschauenden Ausfalldetektionssystem im Fahrzeug gemäß einem oder mehreren Aspekten dieser Offenbarung erreicht werden. Diese Offenbarung stellt sowohl ein statistisches Modell als auch ein Verfahren bereit, das die Zuordnung zwischen bestehenden Garantieansprüchen und dem Diagnose-Fehlercode (diagnostic trouble code - DTC), der von einem Fahrzeug gebildet wird, sowie den kausalen Zusammenhang zwischen den DTCs selbst festlegt. Bei Umsetzung in einem vorausschauenden Rahmen kann dies die Ausgaben für Garantie und unvorhergesehene Probleme reduzieren. Ein vorausschauendes Modell gemäß dieser Offenbarung kann eine frühe Warnung vor einem Ausfall auf Grundlage der Detektion eines Musters von DTCs bereitstellen.
Die vorstehend genannten Ziele können durch ein Verfahren erreicht werden, umfassend Bestimmen einer Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs auf Grundlage von einem oder mehreren Diagnose-Fehlercodes (DTCs); und Angeben für einen Bediener des Fahrzeugs als Reaktion darauf, dass die Wahrscheinlichkeit einen Schwellenwert überschreitet, dass der Ausfall wahrscheinlich erfolgt. Das Bestimmen kann auf dem Vergleichen des einen oder der mehreren DTCs für ein oder mehrere trainierte Modellobjekte beruhen. Die trainierten Modellobjekte können unter Verwendung von maschinellen Lernalgorithmen, die anhand von historischen DTC-Daten ausgeführt werden, erzeugt werden. Das Bestimmen kann ferner auf einer Vielzahl von Betriebsbedingungen beruhen, die einen Kilometerstand und eine Batteriespannung umfassen.
In einigen Beispielen kann das Angeben Anzeigen einer Textnachricht über einen Bildschirm beinhalten, wobei die Textnachricht Anweisungen beinhaltet. Die Anweisungen können eine empfohlene Anzahl an Tagen beinhalten, innerhalb derer eine Werkstatt oder eine Servicestation aufgesucht werden sollte. Die empfohlene Anzahl an Tagen kann auf der Wahrscheinlichkeit beruhen, wobei eine größere Anzahl an Tagen für eine geringere Wahrscheinlichkeit empfohlen wird und eine kleinere Anzahl an Tagen für eine höhere Wahrscheinlichkeit empfohlen wird; und wobei die Anzahl an Tagen ferner auf einem Fahrzeugteilsystem beruht, das die DTCs erzeugt. Der Schwellenwert kann auf Grundlage eines Fahrzeugteilsystems, das die DTCs erzeugt, ausgewählt werden.
In anderen Beispielen können die vorstehend genannten Ziele durch ein System erreicht werden, umfassend ein Fahrzeug, eine Vielzahl von Fahrzeugteilsystemen, eine Steuerung mit maschinenlesbaren Anweisungen, die in nichttransitorischem Speicher gespeichert sind, für Folgendes: Empfangen von einem oder mehreren Diagnose-Fehlercodes (DTCs) von den Fahrzeugteilsystemen, Erzeugen einer Wahrscheinlichkeit eines Ausfalls des Fahrzeugs durch Vergleichen des einen oder der mehreren DTCs mit einem oder mehreren trainierten Modellobjekten, und Angeben für einen Bediener des Fahrzeugs, dass der Ausfall wahrscheinlich ist, wenn die Wahrscheinlichkeit einen Schwellenwert überschreitet.
Zusätzlich oder alternativ können diese Ziele durch ein Verfahren erreicht werden, umfassend Empfangen eines Diagnose-Fehlercodes (DTC) und eines Motorbetriebsparameters; Vergleichen des DTC und des Motorbetriebsparameters mit einem trainierten Modellobjekt, um eine Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs und eine Anweisung zu erzeugen; und als Reaktion darauf, dass die Wahrscheinlichkeit eines Ausfalls einen Schwellenwert überschreitet, Anzeigen der Anweisung für einen Bediener des Fahrzeugs auf einem Bildschirm.
Figurenliste
Die Offenbarung kann nach Lektüre der folgenden Beschreibung von nicht einschränkenden Ausführungsformen in Bezug auf die angehängten Zeichnungen besser nachvollzogen werden, wobei nachstehend Folgendes gilt:

1 zeigt eine beispielhafte elektronische Vorrichtung, die einen oder mehrere Aspekte des vorausschauenden Ausfalldetektionssystems gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung ausführt;
2 zeigt ein beispielhaftes Verfahren zur vorausschauenden Ausfalldetektion in Fahrzeugen;
3 zeigt ein beispielhaftes Verfahren zum Erzeugen von trainierten Modellobjekten zur Verwendung in vorausschauenden Ausfalldetektionssystemen und/oder -verfahren in Fahrzeugen;
4 zeigt ein Verfahren zum Sortieren von Sitzungsarten in Ausfall- und Nicht - Ausfallsitzungen;
5 zeigt ein beispielhaftes Workflowdiagramm für Muster-Mining;
6A und 6B zeigen die Neigung zu Ausfällen der wichtigsten 5 identifizierten Symptommuster gemäß dem Muster-Ranking mit Bayes-Theorem in den Intervallen Juli 2015 - Dezember 2015 bzw. Januar 2016 - Juni 2016;
7 zeigt ein Empfindlichkeits- und Spezifitätsdiagramm;
8 zeigt beispielhafte Empfindlichkeits- und Spezifitätskurven gemäß einem Beispiel;
9 zeigt Modellleistungsmetriken gemäß einer bestimmten Wahrscheinlichkeitsgrenze;
10 zeigt einen Konflikt bei wahren positiven Raten bei verschiedenen Wahrscheinlichkeitsgrenzwerten;
11 zeigt ein Diagramm eines beispielhaften Datenvorbereitungsworkflows zur Modellvalidierung;
12 zeigt ein beispielhaftes Daten-Binning-Entscheidungsverzeichnis;
13 zeigt die Verteilung von Ausfall- und Nichtausfallmodi in verschiedenen Datensätzen;
14 zeigt die häufigsten DTCs von Ausfallsitzungen;
15 zeigt die Frequenz von Ausfall- vs. Nichtausfallsitzungen bezogen auf die Anzahl von DTCs;
16 zeigt das Ausfallverhältnis bezogen auf die Anzahl von DTCs in einer Sitzung;
17 zeigt die Batteriespannungsverteilung für Ausfall- und Nichtausfallsitzungen;
18A-D zeigen Modellgenauigkeitsergebnisse unter Verwendung verschiedener Eingabeparametern;
19 zeigt die Verteilung von DTC-Altern;
20A und 20B zeigen Modellleistungsmetriken für Datensätze im Mai und Juni 2016; und
21A und 21B zeigen Modellleistungsmetriken mit und ohne Einbeziehung von Batteriespannung und Kilometerstand.

DETAILLIERTE BESCHREIBUNG

Wie vorstehend angemerkt, werden Systeme und Verfahren für vorausschauende Ausfalldetektionssysteme und -verfahren in Fahrzeugen bereitgestellt. Im Folgenden findet sich eine Tabelle, die Definitionen von Ausdrücken im vorliegenden Zusammenhang beinhaltet:

DTC	Diagnose-Fehlercode - Einheit der Analyse für diesen Bericht
Voll-DTC	Beschreibung des Modul-DTC-Typs
DID	Datenbezeichner - detailliertere Daten, wie Batteriespannung, Kilometerstand
Sitzung	Sammlung von DTCs, die von dem Auto erhalten wurden, durch Einstecken in einen SDD zum Zeitpunkt des Service oder der Reparatur. Die Sitzung kann verschiedene Typen aufweisen:
	• Pannenhilfe
	• Diagnose
	• Kpmp
	• PDI
	• Servicemaßnahme
	• Servicefunktion
	• Service-Shortcuts
	• Toolbox
Ausfallsitzung	Fall einer Pannenhilfe
Nichtausfallsitzung	Serviceautos mit Sitzungstyp „Servicefunktion“

1 ist ein Blockdiagramm einer beispielhaften elektronischen Vorrichtung 100, das einen oder mehrere Aspekte eines vorausschauenden Ausfalldetektionssystems oder -verfahrens, wie vorliegend offenbart, beinhalten kann. Die elektronische Vorrichtung 100 kann einen Satz von Anweisungen beinhalten, der ausgeführt werden kann, um die elektronische Vorrichtung 100 dazu zu veranlassen, eine(s) oder mehrere der offenbarten Verfahren oder computerbasierten Funktionen auszuführen, wie etwa Empfangen von einem oder mehreren DTCs, die von Fahrzeugteilsystemen ausgegeben wurden, Empfangen von einer oder mehreren Betriebsbedingungen von einer Vielzahl von Fahrzeugsensoren, Vergleichen der DTCs und/oder Betriebsbedingung(en) mit einer oder mehreren Regeln oder trainierten Modellobjekten, Erzeugen einer Wahrscheinlichkeit eines Ausfalls auf Grundlage der DTCs, der Betriebsbedingungen und der trainierten Modellobjekte, und Ausgeben einer Nachricht an einen Bediener auf Grundlage der Wahrscheinlichkeit eines Ausfalls. Die elektronische Vorrichtung 100 kann als eine eigenständige Vorrichtung betrieben werden oder kann mit anderen Computersystemen oder Peripherievorrichtungen verbunden werden, wie etwa unter Verwendung eines Netzwerks. Insbesondere kann es sich bei der elektronischen Vorrichtung um eine eigenständige Vorrichtung handeln, die mit einem Fahrzeug verbunden ist, oder kann als computerlesbare Anweisungen in bereits bestehenden Fahrzeugsystemen, wie etwa als eine ECU, instanziiert werden.
In dem Beispiel eines Netzwerkeinsatzes kann die elektronische Vorrichtung 100 in der Funktion eines Servers oder als ein Client-Benutzercomputer in einer Server-Client-Benutzernetzwerkumgebung, als ein Peercomputersystem in einer Peer-to-Peer(oder verteilten)-Netzwerkumgebung oder in verschiedenen anderen Arten und Weisen betrieben werden. Die elektronische Vorrichtung 100 kann auch als verschiedene elektronische Vorrichtungen umgesetzt oder darin integriert werden, wie etwa Desktop- und Laptop-Computer, Handheld-Vorrichtungen, wie etwa Smartphones und Tablet-Computer, tragbare Medienvorrichtungen, wie etwa Aufnahme-, Wiedergabe- und Spielvorrichtungen, Kraftfahrzeugelektronik, wie etwa Haupteinheiten und Navigationssysteme, oder andere Maschinen, die in der Lage sind, einen Satz von Anweisungen (sequentiell oder anderweitig) auszuführen, die zu Maßnahmen führen, die von dieser Maschine auszuführen sind. Die elektronische Vorrichtung 100 kann unter Verwendung von elektronischen Vorrichtungen umgesetzt werden, die Sprach-, Audio-, Video- und/oder Datenkommunikation bereitstellen. Während eine einzelne elektronische Vorrichtung 100 veranschaulicht ist, kann der Ausdruck „Vorrichtung“ eine Sammlung von Vorrichtungen oder Teilvorrichtungen beinhalten, die einzeln oder gemeinsam einen Satz, oder mehrere Sätze, von Anweisungen ausführen, um eine oder mehrere elektronische Funktionen des vorausschauenden Ausfalldetektionssystems auszuführen, wie nachfolgend ausführlicher ausgeführt.
Die elektronische Vorrichtung 100 kann einen Prozessor 102, wie etwa eine zentrale Verarbeitungseinheit (central processing unit - CPU), eine Grafikverarbeitungseinheit (graphics processing unit - GPU) oder beides, beinhalten. Der Prozessor 102 kann eine Komponente in einer Vielzahl von Systemen sein. Zum Beispiel kann der Prozessor 102 Teil einer Haupteinheit oder ECU in einem Fahrzeug sein. Außerdem kann der Prozessor 102 einen oder mehrere allgemeine Prozessoren, digitale Signalprozessoren, anwendungsspezifische integrierte Schaltkreise, feldprogrammierbare Gate-Arrays, Server, Netzwerke, digitale Schaltkreise, analoge Schaltkreise, Kombinationen davon oder andere jetzt bekannte oder später entwickelte Vorrichtungen zum Analysieren und Verarbeiten von Daten beinhalten. Der Prozessor 102 kann ein Softwareprogramm, wie etwa Code, der manuell erzeugt oder programmiert wurde, umsetzen.
Die elektronische Vorrichtung 100 kann Speicher, wie etwa einen Speicher 104, beinhalten, der über einen Bus 110 kommunizieren kann. Der Speicher 104 kann ein Hauptspeicher, ein statischer Speicher oder ein dynamischer Speicher sein oder diesen beinhalten. Der Speicher 104 kann eine nichttransitorische Speichervorrichtung beinhalten. Der Speicher 104 kann auch computerlesbare Speichermedien beinhalten, wie etwa verschiedene Arten von flüchtigen und nichtflüchtigen Speichermedien, einschließlich Direktzugriffsspeicher, Nur-Lese-Speicher, programmierbarer Nur-Lese-Speicher, elektrisch programmierbarer Nur-Lese-Speicher, elektrisch löschbarer Nur-Lese-Speicher, Flash-Speicher, ein magnetisches Band oder eine magnetische Disk, optische Medien und dergleichen, beinhalten. Außerdem kann der Speicher ein nichttransitorisches materielles Medium beinhalten, auf dem Software gespeichert ist. Die Software kann elektronisch als ein Bild oder in einem anderen Format (wie etwa durch einen optischen Scan) gespeichert, dann kompiliert oder interpretiert oder anderweitig verarbeitet werden.
In einem Beispiel beinhaltet der Speicher 104 einen Cache- oder Direktzugriffsspeicher für den Prozessor 102. In alternativen Beispielen kann der Speicher 104 getrennt von dem Prozessor 102 sein, wie etwa ein Cache-Speicher eines Prozessors, der Systemspeicher oder ein anderer Speicher. Der Speicher 104 kann eine externe Speichervorrichtung oder Datenbank zum Speichern von Daten sein oder diese beinhalten. Beispiele beinhalten eine Festplatte, eine Compact Disk („CD“), eine Digital Video Disk („DVD“), eine Speicherkarte, einen Speicherstick, eine Floppy-Disk, eine Speichervorrichtung in Form eines Universal Serial Bus („USB“) oder eine andere Vorrichtung, die Daten speichern kann. Zum Beispiel kann die elektronische Vorrichtung 100 auch eine Disk oder eine optische Laufwerkeinheit beinhalten. Die Laufwerkeinheit kann ein computerlesbares Medium beinhalten, in dem ein oder mehrere Sätze von Software oder Anweisungen, wie etwa die Anweisungen 124, integriert sein können. Der Prozessor 102 und der Speicher 104 können auch ein computerlesbares Medium mit Anweisungen oder Software beinhalten.
Der Speicher 104 kann Anweisungen speichern, die durch den Prozessor 102 ausführbar sind. Die Funktionen, Maßnahmen oder Aufgaben, die in den Figuren veranschaulicht oder beschrieben sind, können von dem programmierten Prozessor 102, der die Anweisungen ausführt, die in dem Speicher 104 gespeichert sind, durchgeführt werden. Die Funktionen, Maßnahmen oder Aufgaben können von dem bestimmten Typ von Anweisungssätzen, Speichermedien, Prozessor oder Verarbeitungsstrategie unabhängig sein und können von Software, Hardware, integrierten Schaltkreisen, Firmware, Mikrocode und dergleichen, die alleine oder in Kombination arbeiten, durchgeführt werden. Gleichermaßen können die Verarbeitungsstrategien Multiprocessing, Multitasking, parallele Verarbeitung und dergleichen beinhalten.
Die Anweisungen 124 können eine(s) oder mehrere der vorliegend beschriebenen Verfahren oder Logiken ausführen, einschließlich Aspekten der elektronischen Vorrichtung 100 und/oder eines beispielhaften vorausschauenden Ausfalldetektionssystems. Die Anweisungen 124 können während der Ausführung durch die elektronische Vorrichtung 100 vollständig oder teilweise im Speicher 104 oder im Prozessor 102 verbleiben. Zum Beispiel können Software-Aspekte des vorliegend offenbarten vorausschauenden Ausfalldetektionssystems Beispiele der trainierten Modellobjekte, die nachfolgend ausführlicher erörtert sind, beinhalten, die während der Ausführung durch die elektronische Vorrichtung 100 vollständig oder teilweise im Speicher 104 oder im Prozessor 102 verbleiben können.
Ferner kann die elektronische Vorrichtung 100 ein computerlesbares Medium beinhalten, das die Anweisungen 124 beinhaltet oder die Anweisungen 124 empfängt und ausführt, und zwar als Reaktion auf ein verbreitetes Signal, sodass eine Vorrichtung, die mit einem Netzwerk 126 verbunden ist, Sprach-, Audio-, Bild- oder andere Daten über das Netzwerk 126 kommunizieren kann. Die Anweisungen 124 können über einen Kommunikationsanschluss oder eine Kommunikationsschnittstelle 120 oder unter Verwendung eines Busses 110 über das Netzwerk 126 übertragen oder empfangen werden. Der Kommunikationsanschluss oder die Kommunikationsschnittstelle 120 kann Teil des Prozessors 102 sein oder kann eine separate Komponente sein. Der Kommunikationsanschluss oder die Kommunikationsschnittstelle 120 kann in Software erstellt werden oder kann eine physische Verbindung in Hardware sein. Der Kommunikationsanschluss oder die Kommunikationsschnittstelle 120 kann dazu konfiguriert sein, mit dem Netzwerk 126, externen Medien, einer oder mehreren Eingabevorrichtungen 132, einer oder mehreren Ausgabevorrichtungen 134, einem oder mehreren Fahrzeugteilsystemen 136 oder anderen Komponenten in der elektronischen Vorrichtung 100 oder Kombinationen davon verbunden zu werden. Die Verbindung mit dem Netzwerk 126 kann eine physische Verbindung sein, wie etwa eine drahtgebundene Ethernet-Verbindung, oder kann drahtlos errichtet werden. Bei den zusätzlichen Verbindungen mit anderen Komponenten der elektronischen Vorrichtung 100 kann es sich um physische Verbindungen handeln oder sie können drahtlos errichtet werden. Das Netzwerk 126 kann alternativ direkt mit dem Bus 110 verbunden werden.
Das Netzwerk 126 kann drahtgebundene Netzwerke, drahtlose Netzwerke, Ethernet-AVB-Netzwerke, einen CAN-Bus, einen MOST-Bus oder Kombinationen davon beinhalten. Das drahtlose Netzwerk kann ein zelluläres Telefonnetzwerk, ein 802.11-, 802.16-, 802.20-, 802.1Q- oder WiMax-Netzwerk sein oder beinhalten. Das drahtlose Netzwerk kann auch ein drahtloses LAN beinhalten, das über WiFi- oder BLUETOOTH-Technologien umgesetzt wird. Ferner kann das externe Netzwerk 126 ein öffentliches Netzwerk, wie das Internet, ein privates Netzwerk, wie ein Intranet, oder Kombinationen davon sein oder beinhalten und eine Vielzahl von Netzwerkprotokollen, die jetzt verfügbar sind oder später entwickelt werden, nutzen, einschließlich TCP-/IP-basierter Netzwerkprotokolle. Eine oder mehrere Komponenten der elektronischen Vorrichtung 100 können miteinander über oder durch das Netzwerk 126 kommunizieren.
Die elektronische Vorrichtung 100 kann auch eine oder mehrere Eingabevorrichtungen 132 beinhalten, die dazu konfiguriert sind, einem Benutzer zu ermöglichen, mit den Komponenten der elektronischen Vorrichtung zu interagieren. Die eine oder mehreren Eingabevorrichtungen 132 können ein Tastenfeld, eine Tastatur und/oder eine Zeigersteuerungsvorrichtung, wie etwa eine Maus, oder einen Joystick beinhalten. Außerdem können die eine oder mehreren Eingabevorrichtungen 132 eine Fernbedienung, eine Touchscreen-Anzeige oder eine andere Vorrichtung beinhalten, die mit der elektronischen Vorrichtung 100 interagieren kann, wie etwa eine Vorrichtung, die als eine Schnittstelle zwischen der elektronischen Vorrichtung und einem oder mehreren Benutzern und/oder elektronischen Vorrichtungen wirken kann.
Die Eingabevorrichtungen 132 können auch einen oder mehrere Sensoren beinhalten. Der eine oder die mehreren Sensoren können einen oder mehrere Näherungssensoren, Bewegungssensoren oder Kameras (wie in einer mobilen Vorrichtung zu finden ist) beinhalten. Funktionell können der eine oder die mehreren Sensoren einen oder mehrere Sensoren beinhalten, die Bewegung, Temperatur, Magnetfelder, Schwerkraft, Luftfeuchtigkeit, Feuchtigkeit, Schwingung, Druck, elektrische Felder, Schall oder andere physikalische Aspekte in Verbindung mit einem potentiellen Benutzer oder einer Umgebung, die den Benutzer umgibt, detektieren oder messen. Die Eingabevorrichtungen 132 können außerdem eine oder mehrere Kameras beinhalten, die dazu konfiguriert sind, Bilder aufzunehmen und zu erzeugen. Die eine oder mehreren Kameras können digitale Kameras oder Ladungserfassungsvorrichtungen (charge-capture device - CCD) sein, die dazu konfiguriert sind, digitale Bilder einer Umgebung der elektronischen Vorrichtung 100 zu erzeugen. Die eine oder mehreren Kameras können optische Kameras, die auf visuelles Licht reagieren, Infrarot-Kameras, Ultraviolett-Kameras oder andere Kameras, die für die Anwendung geeignet sind, umfassen.
Die elektronische Vorrichtung kann eine oder mehrere Ausgabevorrichtungen 134 beinhalten. Die Ausgabevorrichtungen 134 können dazu konfiguriert sein, für einen Benutzer Nachrichten anzuzeigen, Geräusche zu reproduzieren, Lampen einzuschalten oder andere Maßnahmen zum Zweck des Kommunizierens von Informationen in Bezug auf einen internen Zustand des Fahrzeugs und/oder der elektronischen Vorrichtung 100 zu ergreifen. Ausgabevorrichtungen können eines oder mehrere von einem Bildschirm, einer Anzeigelampe, einem Lautsprecher, einer haptischen Rückkopplungsvorrichtung oder einer anderen geeigneten Vorrichtung beinhalten. Ein Bildschirm kann in einem Beispiel einen Touchscreen umfassen, der Teil eines Infotainmentsystems im Fahrzeug bildet. In einem anderen Beispiel kann es sich bei dem Bildschirm um eine von anderen Systemen im Fahrzeug getrennte Komponente handeln. Der Bildschirm kann dazu konfiguriert sein, eine Text- oder visuelle Nachricht für einen Benutzer zu erzeugen. Der Lautsprecher kann Teil eines Stereosystems oder eines Surround-Sound-Systems sein, das einen oder mehrere Audiokanäle beinhaltet. Insbesondere kann ein Lautsprecher eine Anordnung von Lautsprechern umfassen. Die Lautsprecher können Hupentreiberlautsprecher, elektromechanische Lautsprecher, wie etwa Magnettreiberwoofer, und/oder piezoelektrische Lautsprecher umfassen. Anzeigelampen können LED oder Glühlampen umfassen, die in eine oder mehrere Fahrzeugkomponenten integriert sind, wie etwa eine Motorprüflampe oder eine andere geeignete Lampe, die in einer Konsole, einem Armaturenbrett oder an anderer Stelle angeordnet ist. Eine haptische Rückkopplungsvorrichtung kann eine Vorrichtung umfassen, die dazu konfiguriert ist, ein spürbares Signal zu einer Fahrzeugkomponente, wie etwa einem Lenkrad, zu senden, um eine Nachricht an einen Bediener zu kommunizieren. Eine oder mehrere der Ausgabevorrichtungen 134 können in ein Fahrzeug integriert oder daran gekoppelt sein; in anderen Beispielen können eine oder mehrere der Ausgabevorrichtungen 134 einen Teil eines separaten mechanischen Systems bilden, wie etwa eines Smartphones oder einer Diagnosevorrichtung, die kommunikativ an die elektronische Vorrichtung 100 gekoppelt ist. Zum Beispiel kann die Ausgabevorrichtung den Touchscreen eines Smartphones umfassen, der über eine drahtlose Verbindung, wie etwa die Netzwerkverbindung 126, drahtlos mit dem Bus 110 verbunden ist, der einen CAN-Bus umfassen kann. Es sind noch andere Variationen möglich.
Die elektronische Vorrichtung 100 kann ein oder mehrere Fahrzeugteilsysteme 136 beinhalten. Die Fahrzeugteilsysteme 136 können einen Teil eines Fahrzeugs umfassen und können kommunikativ an den Bus 110 gekoppelt sein, der in einem Beispiel einen CAN-Bus umfassen kann. Die Fahrzeugteilsysteme können ein oder mehrere Elemente eines Fahrzeugs beinhalten und können zum Beispiel ein Antriebsstrangteilsystem, ein Fahrgestellteilsystem, ein Karosserieteilsystem und ein Netzwerkteilsystem gemäß den Fahrzeugteilsystemkategorien, die von den OBD-II-Spezifikationen zum Diagnose-Fehlercode bereitgestellt werden, beinhalten. In anderen Beispielen können andere Teilsystemkategorisierungsschemata verwendet werden. Fahrzeugelemente können gemäß funktionellen, strukturellen und/oder prozeduralen Berücksichtigungen gruppiert werden. In einem Beispiel können Fahrzeugteilsysteme Motorsysteme, Betankungssysteme, Verdunstungssysteme, Zündsysteme, elektrische Systeme, HLK-Systeme, Aufhängungssysteme und so weiter beinhalten.
Die Fahrzeugteilsysteme 136 können eine oder mehrere ECU 137 und Sensoren 138 beinhalten. Nicht einschränkende Beispiele von Sensoren 138 beinhalten MAP-/MAF-Sensoren, UEGO, HEGO, Temperatursensoren, Drucksensoren, Luftfeuchtigkeitssensoren, Motordrehzahlsensoren, Hall-Effekt-Sensoren, Klopfsensoren und andere. In einigen Beispielen können die Sensoren 138 eine oder mehrere der Eingabevorrichtungen 132 umfassen, wie vorstehend erörtert. Die Sensoren können in Motorsystemen, einem Ansaugkrümmer, einem Abgaskrümmer, einem Kraftstofftank, einem Fahrzeugreifen, einem Kühlmittelkanal, einem AGR-Kanal, einer Fahrzeugkabine, einer Fahrzeugkarosserie und an anderen geeigneten Stellen angeordnet sein. Die ECU 137 kann dazu konfiguriert sein, Signale von einem oder mehreren der Sensoren 138 zu empfangen. Die ECU 137 kann die Signale überwachen und bewerten und kann dazu konfiguriert sein, einen oder mehrere DTCs auszugeben, wenn die Bedingungen es gewährleisten. Die DTCs können beispielsweise gemäß den OBD-II-Standards erzeugt werden. Zusätzliche oder alternative Standards oder proprietäre DTC-Erzeugungsschemata können eingesetzt werden.
Die elektronische Vorrichtung 100 kann somit dazu konfiguriert sein, einen oder mehrere Aspekte eines vorausschauenden Ausfalldetektionssystems und/oder - Verfahrens in Fahrzeugen umzusetzen. Weiter bei 2 ist ein Beispiel für ein vorausschauendes Detektionsverfahren veranschaulicht.
Verfahren 200 beginnt bei 210, wo der Prozessor bestimmt, ob eine Anforderung zur Aktualisierung der Testregeln, die in dem Verfahren verwendet werden, um einen Ausfall vorherzusagen, vorliegt oder nicht. Diese Regeln können ein oder mehrere trainierte Modellobjekte umfassen, die durch maschinelle Lerntechniken erzeugt werden, wie etwa die, die in Verfahren 300 gegeben sind, wie nachfolgend erörtert. Die Regeln können einen Satz von mathematischen und/oder statistischen Beziehungen, Entscheidungsbäume, Datenstrukturen und/oder Heuristiken zum Bestimmen einer Wahrscheinlichkeit eines Ausfalls auf Grundlage von einer oder mehreren Betriebsbedingungen, wie etwa DTCs, Kilometerstand oder Batteriespannung umfassen. Die Regeln können Anweisungen oder vorgeschlagene Maßnahmen, die zu ergreifen sind, auf Grundlage der Betriebsbedingungen spezifizieren. In einem Beispiel kann das Verfahren 200 anfordern, dass die Testregeln zu aktualisieren sind, wenn das vorausschauende Ausfallbestimmungssystem zum ersten Mal betrieben wird. In anderen Beispielen kann das Verfahren 200 eine Anforderung zur Aktualisierung der Testregeln aus der Ferne, zum Beispiel durch eine Netzwerkverbindung, empfangen. Alternativ kann das Verfahren 200 eine Aktualisierung der Testregeln anfordern, nachdem eine vorbestimmte Zeit seit der vorherigen Aktualisierung verstrichen ist; zum Beispiel kann das Verfahren eine Regelaktualisierung einmal pro Monat, in einem anderen vorbestimmten Intervall oder bei jedem Start des Fahrzeugs anfordern. Wenn eine Aktualisierung angefordert wird, geht die Verarbeitung zu 215 über. Wenn keine Aktualisierung angefordert wird, geht die Verarbeitung zu 220 über.
Bei 215 geht das Verfahren 200 zur Aktualisierung der Testregeln über. Dies kann Senden einer Anforderung für neue Regeln und Empfangen von neuen Regeln umfassen. Die Anforderung kann an einen lokalen oder entfernten Server, an ein Netzwerk oder eine andere Datenquelle gesendet werden. Die neuen Regeln können von der gleichen oder einer anderen Quelle empfangen werden. In einem Beispiel kann die Datenquelle einen vollständigen Satz von Testregeln senden, um den aktuellen Satz von Testregeln zu ersetzen. In einem anderen Beispiel kann die Datenquelle nur Regeln senden, die neu sind oder sich seit der letzten Aktualisierungsanforderung verändert haben. Sobald die aktualisierten Regeln empfangen wurden, geht die Verarbeitung zu 220 über.
Bei 220 geht das Verfahren dazu über, Betriebsbedingungen zu überwachen. Dies kann Überwachen von Betriebsbedingungen eines Fahrzeugs beinhalten, in dem die elektronische Vorrichtung 100 angeordnet ist, beispielsweise einschließlich des Überwachens der Signale, die durch einen oder mehrere Sensoren erzeugt werden, wie etwa die Sensoren 138 und/oder Eingabevorrichtungen 132. Dies kann Überwachen eines Kilometerstandes und/oder eines Batteriespannungssignals beinhalten. Andere nicht einschränkende Beispiele für Betriebsbedingungen, die überwacht und in der folgenden Verarbeitung eingesetzt werden können, beinhalten Motordrehzahl, -last, Drehmomentanforderung, Abgastemperatur, Luft-Kraftstoff-Verhältnis, Kühlmitteltemperatur, MAF/MAP, Geschwindigkeit, Luftfeuchtigkeit, Bremsanforderung, Zündzeitpunkt, Ventilsteuerung oder andere geeignete Bedingungen. Die Verarbeitung geht dann zu 230 über.
Bei 230 überwacht das Verfahren Diagnose-Fehlercodes. Die DTCs können durch eine oder mehrere ECUs 136 erzeugt werden. Der Prozessor kann auch ein Alter der erzeugten DTCs überwachen. Dies kann Überwachen von allen DTCs oder nur einem Teilsatz von DTCs, wie etwa DTCs, die von einem bestimmten Fahrzeugteilsystem erzeugt wurden, oder DTCs eines bestimmten Alters, beinhalten. Zum Beispiel kann das Überwachen von DTCs nur Überwachen von DTCs unter einem Schwellenalter beinhalten. In einem Beispiel kann es sich bei dem Schwellenalter um eine Anzahl an Tagen, wie etwa 1 Tag, 3 Tage, 5 Tage, oder eine andere geeignete Anzahl handeln. In diesem Beispiel kann das Verfahren alle DTCs ignorieren, die älter als das Schwellenalter sind. Es versteht sich jedoch, dass das Verfahren in einigen Beispielen keine DTCs ignorieren kann und alle DTCs verwenden kann, die durch die Fahrzeugteilsysteme in den nachfolgenden Verarbeitungsschritten erzeugt wurden. Die Verarbeitung geht dann zu 240 über.
Bei 240 beinhaltet das Verfahren Vergleichen der DTCs und der Betriebsbedingungen mit einer oder mehreren Regeln oder einem oder mehreren trainierten Modellobjekten. Dies kann Vergleichen der DTCs und Bedingungen mit einer oder mehreren statistischen oder mathematischen Beziehungen, Entscheidungsbäumen, Datenstrukturen oder anderen Objekten beinhalten. Ein Beispiel für ein trainiertes Modellobjekt kann eine Regel beinhalten, die spezifiziert, dass, wenn der Satz von beobachteten DTCs {B11FF, U2100} beinhaltet, die Wahrscheinlichkeit eines Ausfalls bei 80 % innerhalb der nächsten fünf Tage angegeben ist. Trainierte Modellobjekte können weitere Beziehungen beinhalten: Unter Fortsetzung des vorherigen Beispiels kann das trainierte Modellobjekt eine weitere Regel beinhalten, die spezifiziert, dass die Wahrscheinlichkeit eines Ausfalls mit der Kilometerleistung in einer vorhersagbaren Art und Weise zunimmt, und kann spezifizieren, dass die Ausgangswahrscheinlichkeit von 80 % auf Grundlage des Kilometerstandes modifiziert wird, um mit größeren beobachteten Kilometerständen zuzunehmen und mit geringeren Kilometerständen abzunehmen.
In anderen Beispielen können die trainierten Modellobjekte dynamische Regeln beinhalten, die gemäß einer Betriebsbedingung des Fahrzeugs variieren können. Zum Beispiel können die Regeln spezifizieren, dass DTCs {P2459, U0128} eine Wahrscheinlichkeit eines Ausfalls von 74 % angeben, dass aber die Wahrscheinlichkeit eines Ausfalls gemäß der Motorlast weiter dynamisch variiert. Die Wahrscheinlichkeit eines Ausfalls kann bei höheren Motorlasten zunehmen und bei geringeren Motorlasten abnehmen. Die trainierten Modellobjekte können auch Regeln beinhalten, die Anweisungen oder Empfehlungen auf Grundlage der beobachteten DTCs und/oder einer oder mehreren Betriebsbedingungen spezifizieren, wie nachfolgend unter Bezugnahme auf Block 270 erörtert. Sobald die DTCs und Betriebsbedingungen mit den trainierten Modellobjekten und/oder Regeln verglichen wurden, geht die Verarbeitung zu 250 über.
Bei 250 bestimmt das Verfahren eine Wahrscheinlichkeit eines Ausfalls. In einem Beispiel kann dies durch eine direkte Anwendung einer Regel oder eines trainierten Modellobjekts erreicht werden. Auf Grundlage der Vergleiche, die in dem vorherigen Schritt durchgeführt wurden, kann die Regel oder das trainierte Modellobjekt eine Wahrscheinlichkeit eines Ausfalls liefern. In anderen Beispielen kann mehr als eine Regel oder mehr als ein trainiertes Modellobjekt eingesetzt werden. Wenn beispielsweise die Muster von DTCs und/oder andere beobachtete Parameter durch mehrere Regeln umfasst werden, kann das Verfahren Kombinieren der Wahrscheinlichkeiten in einer geeigneten Weise beinhalten. Zum Beispiel kann das Verfahren die geringste Wahrscheinlichkeit, die höchste Wahrscheinlichkeit oder eine arithmetische Kombination auswählen. Insbesondere kann das Verfahren aufgrund einer Vielzahl von Regeln R₁...R_n, die eine Vielzahl von Wahrscheinlichkeiten eines Ausfalls P₁...P_n bereitstellt, eine gesamte Wahrscheinlichkeit P eines Ausfalls gemäß $P = 1 - (1 - P_{1}) (1 - P_{2}) \dots (1 - P_{n})$
berechnen. Nachdem die Wahrscheinlichkeit eines Ausfalls bestimmt wurde, geht die Verarbeitung zu 260 über.
Bei 260 beinhaltet das Verfahren optional Vergleichen der vorher erzeugten Wahrscheinlichkeit mit einem Schwellenwert. Alternativ kann der Schwellenwertvergleich als Teil des Modellerzeugungsprozesses durchgeführt werden, wie nachfolgend unter Bezugnahme auf Verfahren 300 beschrieben. Insbesondere kann bei Block 380 eine optimale Grenzwahrscheinlichkeit definiert werden. Die Vorgänge, die nachfolgend unter Bezugnahme auf Block 380 erörtert sind, können alternativ als Teil des Verfahrens 200 bei Block 260 durchgeführt werden. Somit kann bei 260 die Wahrscheinlichkeit mit einem Schwellenwert verglichen werden. Der Schwellenwert kann vorbestimmt und konstant sein oder kann auf Grundlage von Betriebsbedingungen bestimmt werden. Zum Beispiel kann das Verfahren einen geringeren Wahrscheinlichkeitsschwellenwert während Bedingungen mit hoher Drehzahl und/oder Last und einen höheren Wahrscheinlichkeitsschwellenwert während Bedingungen mit geringer Drehzahl und/oder Last auswählen. Dies kann beispielsweise eine dynamische Steuerung des Verfahrens gemäß einer erhöhten oder verringerten Möglichkeit eines Ausfalls unter verschiedenen Fahrbedingungen ermöglichen. Als ein anderes Beispiel können verschiedene Wahrscheinlichkeitsschwellenwerte ausgewählt werden, gemäß denen Fahrzeugteilsysteme an den DTCs beteiligt sind, die von dem Prozessor empfangen werden. Zum Beispiel kann das Verfahren einen geringeren Wahrscheinlichkeitsschwellenwert für DTCs, die an Motorteilsystemen beteiligt sind, und höhere Wahrscheinlichkeitsschwellenwerte für DTCs, die an elektrischen oder HLK-Systemen beteiligt sind, auswählen. Es sind noch andere Variationen möglich. Wenn bestimmt wird, dass die Wahrscheinlichkeit eines Ausfalls geringer ist als die Schwellenwahrscheinlichkeit, kehrt das Verfahren zu 220 zurück und fährt damit fort, die Betriebsbedingungen und DTCs zu überwachen. Wenn bestimmt wird, dass die Wahrscheinlichkeit eines Ausfalls größer ist als die Schwellenwahrscheinlichkeit, geht das Verfahren zu 270 über.
Bei 270 erzeugt das Verfahren Anweisungen auf Grundlage der DTCs, Betriebsbedingungen und/oder trainierten Modellobjekte. Es kann beabsichtigt sein, dass die erzeugten Anweisungen an einen menschlichen Bediener geliefert und von diesem verstanden werden. Beispielhafte Anweisungen können relativ einfache Anweisungen, wie etwa „Motor prüfen“ oder „Fahrzeug bald warten lassen“, beinhalten. In anderen Beispielen kann das Verfahren spezifischere Anweisungen erzeugen, wie etwa „Fahrzeug innerhalb von X Tagen warten lassen“, wobei X auf Grundlage der DTCs, der Betriebsbedingungen und/oder der trainierten Modellobjekte bestimmt wird. Die Anweisungen können auch „Fahrzeug so schnell wie möglich warten lassen“ beinhalten. In Fällen, in denen das Verfahren beurteilt, dass ein Ausfall bevorsteht, können die erzeugten Anweisungen „sofort anhalten“ beinhalten. Das Verfahren kann zusätzlich oder alternativ Anweisungen für den Bediener für spezifische Fahrverhalten erzeugen, die die Wahrscheinlichkeit eines Ausfalls minimieren sollen. Nicht einschränkende Beispiele dieser Art von Anweisungen können „Geschwindigkeit reduzieren“ oder „Klimaanlage ausschalten“ beinhalten.
Die spezifischen Anweisungen können auf Grundlage der DTCs, Betriebsbedingungen und/oder trainierten Modellobjekte erzeugt werden. Die Anweisungen können auch auf der vorstehend bestimmten Wahrscheinlichkeit beruhen. Wenn beispielsweise das Verfahren eine Anweisung „Fahrzeug innerhalb von X Tagen warten“ erzeugt, kann X auf Grundlage der Wahrscheinlichkeit bestimmt werden. Die Anzahl an Tagen kann in umgekehrter Beziehung zu der Wahrscheinlichkeit stehen, wobei eine größere Wahrscheinlichkeit eines Ausfalls einer geringeren Anzahl an Tagen entspricht und umgekehrt. Anweisungen, wie etwa „Fahrzeug so schnell wie möglich warten lassen“ und „sofort anhalten“ können auf Grundlage einer sehr hohen Ausfallwahrscheinlichkeit erzeugt werden, wie etwa einer Ausfallwahrscheinlichkeit, die größer ist als ein zweiter Schwellenwert, der höher als der in Block 260 eingesetzte Wahrscheinlichkeitsschwellenwert ist. In einigen Beispielen können die spezifischen Anweisungen in den trainierten Modellobjekten beinhaltet sein. Zum Beispiel kann ein trainiertes Modellobjekt, welches einen Fehler im HLK-System auf Grundlage von DTCs, die von der HLK-ECU erzeugt wurden, diagnostiziert, die Anweisung „Klimaanlage ausschalten“ beinhalten, wenn die Wahrscheinlichkeit des Fehlers größer als ein Schwellenwert ist. Das Verfahren kann einen oder mehrere Sätze von Anweisungen auf Grundlage der vorstehenden Berücksichtigungen erzeugen. Nachdem die Anweisungen erzeugt wurden, geht die Verarbeitung zu 280 über.
Bei 280 geht das Verfahren durch Anzeigen der Anweisungen für den Bediener weiter. Dies kann unter Verwendung von einer oder mehreren der Ausgabevorrichtungen 134 durchgeführt werden. Anweisungen können durch Beleuchten einer Motorprüflampe, durch Ausgeben einer Textnachricht auf einen Bildschirm, durch Reproduzieren einer akustischen Nachricht über Lautsprecher oder in einer anderen geeigneten Weise angezeigt werden. Nachdem die Anweisungen dem Bediener angezeigt wurden, kehrt das Verfahren 200 zurück.
Unter Bezugnahme auf 3 ist ein Verfahren 300 zum Erzeugen von trainierten Modellobjekten oder Regeln zur Verwendung in dem vorstehend beschriebenen vorausschauenden Ausfalldetektionssystem in Fahrzeugen gezeigt. Das Verfahren 300 kann eine oder mehrere Computerlerntechniken einsetzen, um Regeln oder trainierte Modellobjekte zu erzeugen. Diese Regeln oder trainierten Modellobjekte können in der elektronischen Vorrichtung 100 und/oder dem Verfahren 200 zur Verwendung beim vorausschauenden Bestimmen einer Wahrscheinlichkeit eines Ausfalls und/oder beim Erzeugen von Bedieneranweisungen eingesetzt oder instanziiert werden. Übergeordnet werden die folgenden Schritte durchgeführt:

1. Verstehen, Reinigen und Verarbeiten der Daten
2. Datenspeicherstrategie zum Speichern der Daten in der optimalsten Weise in Hadoop Map-Reduce-Datenbank zum Erleichtern eines schnelleren Modellaufbaus und einer schnelleren Datenextraktion
3. Vorausschauende Leistung der DTCs und anderer abgeleiteter Variablen beim Vorhersagen von Ausfällen
4. Daueranalyse von DTC-Daten zur Überprüfung von Vorankündigungen vor dem tatsächlichen Ausfall
5. Assoziationsregel-Mining zum Detektieren von DTC-Mustern, die Ausfälle verursachen
6. Regel-Ranking-Methodologie zum Einstufen von DTC-Mustern durch die zugehörige Neigung, Ausfälle zu verursachen
7. Vorausschauende Modelle, die DTC-Muster, die Ausfälle verursachen, anhand von Trainingsdaten identifizieren
8. Modellvalidierung beim Identifizieren von Ausfällen aus Probendaten durch Verwenden von Verwirrungsmatrizen

Auf Grundlage der nachfolgend erörterten Verfahren und Experimente wurden die folgenden Ergebnisse erlangt:

• DTCs, die viel öfter zu Ausfällen als zu Nichtausfällen führen, können mit hinreichender Genauigkeit und ausreichender Vorankündigung vor der tatsächlichen Störung festgestellt werden;
• DTC-Muster können anhand von Daten festgestellt werden, die dabei helfen, Ausfälle mit einer Genauigkeit von mehr als 65 % unter Verwendung von Daten mindestens einen Tag vor dem tatsächlichen Ausfall vorherzusagen, d. h., Ausfälle können mindestens einen Tag vor der tatsächlichen Störung mit einer Genauigkeit von mehr als 65 % vorhergesagt werden.
• Die Hinzunahme von mehr Daten zu den DTC-Mustern, wie Kilometerstand und/oder Batteriespannung, kann die Vorhersagegenauigkeit der Störung auf bis zu 75 % erhöhen;
• eine Genauigkeit von mehr als 65 % wird erreicht.

Das Verfahren beginnt bei 310, wo eine geeignete Datenbank zusammengefasst wird. Die Datenbank kann anhand von Daten zusammengefasst werden, einschließlich DTCs, die von einem oder mehreren Fahrzeugen während eines Zeitraums erzeugt wurden, zusammen mit anderen Informationen, wie etwa Fahrzeugmodell, Laufleistung (Kilometerstand), Batterieladestatus oder beliebigen anderen Betriebsbedingungen, die beispielsweise dann gemessen wurden, als der DTC eingestellt wurde oder als die Sitzung eingeleitet wurde. Eine Fahrzeugfeedbackdatenbank kann zur Datenextraktion verwendet werden. Zusätzlich kann eine Flat-File des Sitzungstyps verwendet werden, um Sitzungsdateinamen den Sitzungstypen zuzuordnen.
Eine Anzahl an Anfragen kann in Abstimmung mit dem Datenbank-Benutzerhandbuch durchgeführt werden, um die Datenbank ausreichend zu verstehen. Zusätzlich kann ein Datenwörterbuch verwendet werden, um jedes Feld der DTC-Daten zu verstehen. Anfragen wurden mit den folgenden Kriterien und Nachbearbeitung an der Datenbank zur finalen Datenextraktion zur Analyse durchgeführt:

• Für DTC-Kriterien (mit Speicherauszug): Juni 2014 - Juni 2016
• Automatisierte Extraktion von der Website unter Verwendung von HTTP-Aufrufen.
• Symptomdaten nur ab Oktober 2014 verfügbar.

Sitzungstypdaten waren für alle Sitzungen von Juni 2014 - Juni 2016 verfügbar. Das Zusammenfassen der Datenbank beinhaltet ferner Sortieren von Sitzungsdaten in Ausfall- und Nichtausfallsitzungen. Ausfallsitzungen können beispielsweise Störungen oder Sitzungen für Pannenhilfe beinhalten, wohingegen Nichtausfallsitzungen beispielsweise routinemäßige Wartung oder Service beinhalten können. Um Ausfallsitzungen von Nichtausfallsitzungen zu unterscheiden, können die folgenden Regeln verwendet werden:

• Ausfallsitzungen sind Sitzungen nur von bestimmten Händlern
• Jede andere Sitzung ist eine Nichtstörungssitzung
• Nichtstörungssitzungen vom Typ „ServiceFunktion“ werden als Nichtausfallsitzungen behandelt

Ein Beispiel für diese Regel ist durch das Diagramm 400 in 4 gezeigt. Sobald eine geeignete Datenbank zusammengefasst wurde, geht die Verarbeitung zu Schritt 320 über.
Bei Schritt 320 beinhaltet das Verfahren Datenreinigung und -vorverarbeitung. Einige Probleme können in den Rohdaten vorhanden sein, die aus der Datenbank extrahiert wurden, die sich auf Duplikation und ungültige Daten beziehen. Importierte Daten können eine Reinigung oder Vorverarbeitung erfordern, um einen zuverlässigen Betrieb der daraus resultierenden trainierten Modellobjekte und des vorausschauenden Ausfalldetektionssystems in Fahrzeugen zu gewährleisten. Zum Beispiel kann eine DTC-Duplikation in einigen Sitzungen festgestellt werden. Duplikat-DTCs können unter Verwendung eines automatisierten Scripts entfernt werden und nur das erste Vorkommen des DTC in der Sitzung kann beibehalten werden, sodass jeder DTC nur einmal pro Sitzung auftritt. Ferner sind einige Sitzungen für Pannenhilfe als Typ „Servicefunktion“ markiert, was nicht möglich ist. Diese Sitzungen werden aus der Analyse entfernt. Die Verarbeitung geht dann zu 330 über.
Bei 330 beinhaltet das Verfahren Durchführen von Muster-Mining an der zusammengefassten Datenbank. Um die Durchführbarkeit des Vorhersagens jedes Ausfalltyps durch sequentielles und nichtsequentielles Muster-basiertes Regel-Mining zu überprüfen, kann eine Analyse zuerst an DTCs und Symptomen von Daten von einem Monat durchgeführt werden. Ein beispielhafter Workflow 500, der diesen Prozess veranschaulicht, ist in 5 zu sehen.

Nichtsequentielles Muster-Mining kann bei 332 als Teil des Muster-Minings 330 durchgeführt werden. Nichtsequentielles Muster-Mining beinhaltet die folgenden Vorgänge. Die Symptomdaten und Speicherauszugdaten für 1 Monat wurden aus Hadoop für Mai 2016 - Juni 2016 mit den bestimmten Filterbedingungen extrahiert. Die Gesamtanzahl an beobachteten Symptomen während dieses Zeitraums betrug 1095. Unter Verwendung dieser Daten werden die wichtigsten Ausfallmodi klassifiziert. Die Frequenz der Ausfallmodi an den 5 Symptomen mit unterschiedlichen Niveaus werden unter Verwendung von Sequenz-Mining geschätzt und die wichtigsten Ausfallmodi werden weiter identifiziert. Die wichtigsten 5 Symptompfade, wobei Niveau 4 als Grenze genommen wird, beinhaltet 40 % der gesamten Störungen, wie in der folgenden Tabelle zu sehen:

Symptommuster	Kumulativ	Frequenz	Ausfallmodus
Elektrik -> Instrumente -> Warnlampen -> Motorfehlfunktionslampe	11,9 %	130	Ausfallmodus 1
Antriebsstrang -> Motorsystem ->Motorleistung -> Motordrehzahl eingeschränkt	22,1 %	112	Ausfallmodus 2
Antriebsstrang -> Motorsystem ->Motorleistung -> Schlechte Beschleunigung und fehlende Leistung	29,3 %	79	Ausfallmodus 3
Elektrik -> Instrumente -> Informations-und Nachrichtencenter -> Nachrichenanzeigebereich	34,5 %	57	Ausfallmodus 4
Antriebsstrang -> Motorsystem -> Startsystem -> Startet nicht	37,7 %	35	Ausfallmodus 5

Wie diese Tabelle veranschaulicht, berücksichtigen die Ausfallmodi, beginnend mit den vier Kategorien „Elektrik -> Instrumente -> Informations- und Nachrichtencenter -> Nachrichtenanzeigebereich“ 57 der 1095 Symptommuster, die während des Testzeitraums beobachtet wurden. Zusammen mit den vorherigen drei Symptompfaden umfassen diese vier Gruppen kombiniert 34,5 % aller beobachteten Ausfallmodi. Diese identifizierten Ausfallmodi werden dann in einem nichtsequentiellen Muster-Mining-Algorithmus weiter verarbeitet.

Muster-Mining 330 kann auch Assoziationsregel-Mining bei 334 beinhalten. Zum Assoziationsregel-Mining werden die wichtigsten 5 Symptompfade als die Hauptausfallmodi identifiziert und die Sitzungsdateinamen, die diesen Ausfallmodi entsprechen, werden von den DTC-Speicherauszugdaten abgebildet, um die DTCs zu identifizieren, die zu dem Ausfallmodus führen. Die beobachteten DTCs werden anhand des Sitzungsdateinamens abgebildet und die Muster (Sätze von DTCs) werden unter Verwendung von Assoziationsregel-Mining (ARM) mit hoher Unterstützung und Zuverlässigkeit geschätzt. Der Ausfallmodus 2 wird durch B11FF und U2100 verursacht, hier wird die Sequenz nicht erfasst. Die Ergebnisse dieser Analyse sind in der folgenden Tabelle wiedergegeben:

Regeln	LHS		Anzahl an DTCs	RHS	Unterstützung	Zuver verlässigkeit	Anstieg
{P0130} => {Ausfallmodus_1} >	P0130		1	Ausfallmodus 1	1 %	1,000	3,256
{B11FFF,U2100} => {Ausfallmodus_2}	B11FF	U2100	2	Ausfallodus 2	2 %	1,000	4,191
{P2459,U0128} => {Ausfallmodus_3}	P2459	U0128	2	Ausfallmodus 3	1 %	0,571	3,631
{P1889} => {Ausfallmodus_4}	P1889		1	Ausfallmodus 4	1 %	1,000	7,880
{B12BE} => {Ausfallmodus_5}	B12BE		1	Ausfallmodus 5	1 %	0,500	6,156

Sequentielles Muster-Mining 336 kann ebenfalls als Teil des Muster-Minings 330 durchgeführt werden. Sequentielles Muster-Mining kann an dem kleinen Datensatz eingesetzt werden, um zu bestimmen, ob die Sequenz der DTCs einen Unterschied bei Zuverlässigkeit, Unterstützung oder Anstieg der bestimmten Regeln ausmachte. Beim sequentiellen Regel-Mining werden die beobachteten DTCs als eine Zeitfolge gegen den Sitzungsschlüssel abgebildet und die Muster (Sätze von DTCs) werden unter Verwendung eines sequentiellen Mining-Algorithmus mit hoher Unterstützung und Zuverlässigkeit geschätzt. Die Ergebnisse des sequentiellen Regel-Minings sind in der folgenden Tabelle gezeigt:

Regeln	LHS			Anzahl an DTCs	RHS	Unterstützung	Zuver verlässigkeit	Anstieg
<{P0130}> => <{Ausfallmodus_1} >	P0130			1	Ausfallmodus 1	1 %	1,000	3,256
<{U3003},{B123B },{U2101}> => < {Ausfallmodus_2}>	U3003	B123B	U2101	3	Ausfallmodus 2	1 %	1,000	4,191
<{U0128},{P2459} > => <{Ausfallmodus_3}>	U0128	P2459		2	Ausfallmodus 3	1,3 %	0,571	3,631
<{P1889}> => <{Ausfallmodus_4}>	P1889			1	Ausfallmodus 4	1%	1,000	7,880
<{B12BE}> => <{Ausfallmodus_5}>	B12BE			1	Ausfallmodus 5	1 %	0,500	6,156

Bei Ausfallmodus 1 identifizierten sowohl sequentielle als auch nichtsequentielle Regeln P0130 als den DTC, der den Ausfall verursacht. Eine weitere Analyse auf Grundlage des DID wurde für die Sitzungen durchgeführt, bei denen dieser DTC aufgetreten ist, um herauszufinden, ob eine Angabe eines Ausfalls vorliegt - d. h., dass beliebige DID-Werte außerhalb des Bereichs liegen. Jedoch lagen alle DID-Werte innerhalb des hohen bis niedrigen Bereichs und deshalb konnte keine Schlussfolgerung anhand der DID-Werte alleine erfolgen.
Sequentielles Muster-Mining kann eine oder mehrere Regeln oder trainierte Modellobjekte (siehe unten) erzeugen, die von einer Reihenfolge oder Sequenz der DTCs abhängig sind. Die Regeln können sich je nach Reihenfolge der DTCs unterscheiden; in einigen Beispielen kann ein Satz von DTCs eine erste Ausfallwahrscheinlichkeit in einer ersten Reihenfolge und eine zweite Wahrscheinlichkeit in einer zweiten Reihenfolge erzeugen, wobei sich die zweite Wahrscheinlichkeit von der ersten unterscheidet. Zum Beispiel kann ein Satz von DTCs, der zwei unterschiedliche DTCs umfasst, eine erste Wahrscheinlichkeit in einer ersten Reihenfolge erzeugen; wenn die DTCs in einer zweiten Reihenfolge detektiert werden, die sich von der ersten unterscheidet, z. B. in der umgekehrten Reihenfolge, kann eine andere sequentielle Regel angewandt werden, die eine zweite Wahrscheinlichkeit erzeugt, die zum Beispiel größer ist als die erste Wahrscheinlichkeit.
In anderen Beispielen können die sequentiellen Regeln andere Anweisungen für den Bediener in Abhängigkeit von der Reihenfolge der DTCs bereitstellen. In einem Beispiel kann ein Satz von DTCs in einer ersten Reihenfolge eine Anweisung „Fahrzeug innerhalb von 5 Tagen warten lassen“ bereitstellen, wohingegen der gleiche Satz von DTCs in einer zweiten, unterschiedlichen Reihenfolge eine Anweisung „sofort anhalten“ bereitstellen kann. In einem anderen Beispiel kann eine erste Reihenfolge der DTCs eine Anweisung, wie etwa „Klimaanlage ausschalten“, bereitstellen, wohingegen eine zweite, andere Reihenfolge der DTCs überhaupt keine Anweisung bereitstellen kann. Es sind noch andere Variationen möglich.
Um diese Analyse fortzusetzen, wurde die Probengröße derart erweitert, dass sie 6 Datenmonate beinhaltete, und es wurde nur nichtsequentielles Muster-Mining durchgeführt, da die Sequenz von DTCs in dieser Untersuchung nicht berücksichtigt werden konnte. Das Verwenden eines größeren Datensatzes und eines ähnlichen Muster-Mining-Ansatzes, wie vorstehend erwähnt, wurde durchgeführt, um nichtsequentielle Muster abzuleiten, die zu den Ausfalltypen führen. Die Symptomdaten und Speicherauszugdaten wurden aus Hadoop DB vom 1. Januar 2016 bis 25. Juni 2016 mit den Filterbedingungen an Markt und Händler extrahiert; die Gesamtanzahl an beobachteten Symptomen betrug 8376.

Die Datenvorbereitung für nichtsequentielles Muster-Mining wird mit der Klassifizierung der wichtigsten Ausfallmodi fortgesetzt: Die Frequenz der Ausfallmodi an den 5 Symptomen mit unterschiedlichen Niveaus wird unter Verwendung von Sequenz-Mining geschätzt und die wichtigsten Ausfallmodi werden weiter identifiziert. Die wichtigsten 6 Symptompfade von Niveau 4 wurden als Grenze genommen. Jede Sitzungsdatei weist das gleiche Symptommuster auf, das mehrere Male protokolliert wurde. Die Gesamtanzahl an Sitzungsdateien, die diese 6 Symptommuster enthielten, beträgt 3057. Diese Muster sind in der folgenden Tabelle veranschaulicht:

Symptommuster	Wahrscheinlichkeit	Frequenz	Sitzungsdateien
Antriebsstrang -> Motorsystem -> Motorleistung -> Motorleistung_eingeschränkt	12,21 %	1023	828
Elektrik -> Instrumente -> Warnlampen - > Motorfehlfunktionslampe	11,40 %	955	915
Antriebsstrang -> Motorsystem -> Motorleistung -> Schlechte_Beschleunigung_und_fehlende_Leistu ng	5,86 %	491	400
Elektrik -> Instrumente -> Informations-_und_Nachrichtencenter -> Nachrichtenanzeigebereich	4,44 %	372	342
Antriebsstrang -> Motorsystem -> Startsystem -> Startet_nicht	3,99 %	334	303
Elektrik -> Batterie -> Ladesystem -> leere Batterie	3,44 %	288	269

Das Verfahren führt dann ein nichtsequentielles DTC-Muster-Mining an den vorbereiteten Daten durch. Die wichtigsten 6 Symptompfade werden als die Hauptausfallmodi identifiziert und die Sitzungsdateinamen, die diesen Ausfallmodi entsprechen, werden von den DTC-Speicherauszugdaten abgebildet, um die DTCs zu identifizieren, die zu dem Ausfallmodus führen. Von 3057 Sitzungsdateien aus den wichtigsten 6 Symptommustern wurden nur 2850 beobachtet, da die anderen Sitzungsdateien in den DTC-Speicherauszugdaten nicht protokolliert wurden. Die Gesamtanzahl der Sitzungen, in denen ein Nichtausfallmodus aufgetreten ist, beträgt 38899. Die aufgetretenen DTCs werden anhand des Sitzungsdateinamens abgebildet und die Muster (Satz von DTCs) werden unter Verwendung von Assoziationsregel-Mining (ARM) mit hoher Unterstützung und Zuverlässigkeit geschätzt. Die Ausfallmodi 2, 3 und 4 werden nicht beobachtet, da die Unterstützung der DTCs, die zu diesen Ausfallmodi führen, weniger als 0,05 % beträgt. Die Ergebnisse von nichtsequentiellem Muster-Mining sind in der folgenden Tabelle zusammengefasst:

Regeln	Unterstützung Ausfall	Sitzungen	Zuverlässigkeit	Anstieg	Unterstützungs-NF	Sitzungen	F-NF-Vergleich
{B 10AD,B 1403,P006A,P0460} => {Ausfallmodus_1}	0,56 %	16	51,6 %	1,91	0,01 %	5	42,68
{B100A,B10AD,B1403,P006A,P0460} => {Ausfallmodus_1}	0,56 %	16	51,6 %	1,91	0,01 %	5	42,68
{B 10AD,B 1403,P006A} => {Ausfallmodus_1}	0,67 %	19	54,3 %	2,01	0,02 %	6	42,22
{B100A,B10AD,B1403,P006A} => {Ausfallmodus_1}	0,63 %	18	52,9 %	1,96	0,02 %	6	39,95
{B100A,P0087,P0460} => {Ausfallmodus_2}	0,70 %	20	52,6 %	1,79	0,02 %	8	33,12
{P0087,P0460} => {Ausfallmodus_2}	0,84 %	24	55,8 %	1,89	0,03 %	13	24,20
{C0064,P1674,U0291} => {Ausfallmodus_6}	0,63 %	18	90,0%	9,87	0,03 %	10	23,57
{B1304,C0064,P1674 ,U0291} => {Ausfallmodus_6}	0,63 %	18	90,0%	9,87	0,03 %	10	23,57
{C0064,P1674,U0291 ,U3001} => {Ausfallmodus_6}	0,63 %	18	90,0%	9,87	0,03 %	10	23,57

Die vorstehende Tabelle veranschaulicht die Ergebnisse des Regel-Minings - konkret vergleicht die letzte Spalte die Unterstützung der gleichen Regel, die zu Ausfallsitzungen sowie Nichtausfallsitzungen führt. Dies motiviert die Ableitung eines Verfahrens zum Einstufen der Regeln, wobei die gleiche Regel sowohl in Ausfall- als auch Nichtausfallsitzungen auftreten kann, um Regeln zu identifizieren, die eine stärkere Neigung dazu haben, Ausfälle als Nichtausfälle zu verursachen.
Auf Grundlage dieser Analyse waren die nächsten vorgeschlagenen Schritte: Gruppieren aller Ausfalltypen in einen einzelnen Modus; Ableiten eines einzelnen Zuverlässigkeitsmaßes, das Ausfall- und Nichtausfallmodi kombiniert, um Regeln zu vergleichen und diese gemäß der zugehörigen Neigung der Regeln, Ausfälle zu verursachen, einzustufen; Verwenden des Modulnamens im Voll-DTC - d. h. Voll-DTC = Beschreibung des Modul-DTC-Typs. Angesichts dieser Berücksichtigungen kann die Bayes-Regel angewandt werden. Nachdem ein nichtsequentielles Muster-Mining abgeschlossen wurde, geht die Verarbeitung zu 340 über.
Bei 340 beinhaltet das Verfahren Muster-Ranking unter Verwendung von Bayes-Theorem. Um die Muster, die vom nichtsequentiellen Muster-Mining abgeleitet wurden, nach der zugehörigen Bedeutung (z. B. relative Wahrscheinlichkeit) beim Verursachen von Ausfällen einzustufen, wird Bayes-Theorem verwendet. Die Muster werden durch die konditionale Wahrscheinlichkeit eines Ausfalls eingestuft, vorausgesetzt, dass das Muster aufgetreten ist: $Pr (F | P_{1}) = \frac{Pr (F) \cdot P r (P_{1} | F)}{Pr (F) \cdot P r (P_{1} | F) + Pr (N F) \cdot P r (P_{1} | N F)}$
Diese Gleichung schätzt die Wahrscheinlichkeit eines Ausfalls F, vorausgesetzt, dass das Muster P1 in einer Sitzung aufgetreten ist - wobei es sich um den Anteil der Unterstützung von P1, einen Ausfall zu verursachen, in der Gesamtunterstützung von P1 handelt.
Jeder Ausdruck in diesem Verfahren wird wie folgt interpretiert und abgeleitet:

Pr(F) - Ausfallwahrscheinlichkeit einer Gesamtmenge. Diese wurde unter Verwendung der Verkaufsdaten von Januar 2013 - Juni 2016 geschätzt, um die Anzahl an Fahrzeugen, die einen Pannenhilfsdienst benötigten (für 3 Jahre), und die tatsächliche Anzahl an Ausfällen zu erhalten, die für den Zeitraum Januar 2016 - Juni 2016 beobachtet wurden. Beispiel für den Zeitraum Januar 2016 - Juni 2016: Pr(F) = (Anzahl an Ausfallsitzungen)/(Gesamtverkäufe von Januar 2013 - Juni 2016)
Pr(NF) - Nichtausfall-Wahrscheinlichkeit der Gesamtmenge, wobei 1 - Pr(F), da F & NF sich gegenseitig ausschließen
Pr(P1\F) - Konditionale Wahrscheinlichkeit von Muster P1, das zu einem Ausfall führt: Pr(P1\F) = (Anzahl an Ausfallsitzungen, die Muster P1 enthalten)/(Gesamtanzahl an Ausfallsitzungen)
Pr(P1\NF) - Konditionale Wahrscheinlichkeit von Muster P1, das zu einem Ausfall führt: Pr(P1\NF) = (Anzahl an Nichtausfallsitzungen, die Muster P1 enthalten)/(Gesamtanzahl an Nichtausfallsitzungen)

6A und 6B zeigen die Ergebnisse des Muster-Rankings mit Bayes-Theorem. 6A zeigt ein Diagramm 600a der Neigung zu einem Ausfall der wichtigsten 5 Muster während des Intervalls Juli 2015 - Dezember 2015. 6B zeigt ein Diagramm 600b der Neigung zu einem Ausfall der wichtigsten 5 Muster während des Intervalls Januar 2016 - Juni 2016.
Ein neues Verfahren zum Validieren des Modells unter Verwendung von Regeln, die von dem Training des Modells aus Probendaten abgeleitet wurden, kann durch Erweitern des Muster-Ranking-Mechanismus auf Grundlage der Bayes-Regel entwickelt werden: $Pr {(F | D T C)}_{v} = \frac{Pr (F) \cdot P r {(D T C | F)}_{t}}{Pr (F) \cdot P r {(D T C | F)}_{t} + Pr (N F) \cdot P r {(D T C | N F)}_{t}}$

Pr(FIDTC)v = Wahrscheinlichkeit eines Fahrzeugausfalls der Validierungssitzung, vorausgesetzt, dass ein Muster detektiert wurde, DTC
Pr(F) = Wahrscheinlichkeit eines Fahrzeugausfalls
Pr(NF) = 1-Pr(F) = Wahrscheinlichkeit eines Nichtausfalls des Fahrzeugs, d. h. keine Störung
Pr(DTC|F)t = Wahrscheinlichkeit des Feststellens von Muster-DTC, vorausgesetzt, dass das Fahrzeug bei Ausfalltrainingsdaten gescheitert ist
Pr(DTC|NF)t = Wahrscheinlichkeit des Feststellens von Muster-DTC, vorausgesetzt, dass das Fahrzeug bei Nichtausfalltrainingsdaten NICHT gescheitert ist

Die vorstehenden Berechnungen können verwendet werden, um die konditionale Wahrscheinlichkeit eines Ausfalls im Validierungssatz (außerhalb der Stichprobe) aus den apriorischen Wahrscheinlichkeiten, die von dem Trainingssatz geschätzt wurden, zu schätzen. Nachdem das Muster-Ranking mit Bayes-Theorem abgeschlossen wurde, geht das Verfahren zu 350 über.
Bei 350 geht das Verfahren dazu über, eine Grenzwahrscheinlichkeit auszuwählen. Die Grenzwahrscheinlichkeit kann ein Wahrscheinlichkeitsschwellenwert sein, wobei, wenn eine bestimmte Wahrscheinlichkeit eines Ausfalls über dem Schwellenwert liegt, einem Bediener ein potenzieller Ausfall angegeben wird, wohingegen, wenn bestimmt wird, dass die Wahrscheinlichkeit eines Ausfalls unter dem Schwellenwert liegt, dem Bediener ein potenzieller Ausfall eventuell nicht angegeben wird. Zusätzlich oder alternativ kann dies als Teil des Verfahrens 200 auftreten, zum Beispiel in den Blöcken 260-280. Dies kann lokales oder nichtlokales Auswählen einer Wahrscheinlichkeit in dem vorausschauenden Ausfalldetektionssystem im Fahrzeug beinhalten, kann eine Vielzahl von verschiedenen Schwellenwerten beinhalten und/oder kann Ausgeben von Anweisungen für einen Bediener auf Grundlage oder in Abhängigkeit von einer Wahrscheinlichkeit eines Ausfalls beinhalten. Diese Funktionen können beispielsweise in Block 260 des Verfahrens 200 beinhaltet sein, wie vorstehend erörtert. In anderen Beispielen jedoch kann die Auswahl eines geeigneten Wahrscheinlichkeitsgrenzschwellenwerts bei 350 als Teil des Verfahrens 300 durchgeführt werden.
Um eine Sitzung als Ausfall oder Nichtausfall zu identifizieren, wird die Grenzwahrscheinlichkeit durch Verwenden der DTC-Musterwahrscheinlichkeit von Ausfall- und Nichtausfallsitzungen abgeleitet. Dieser Prozess beinhaltet Erstellen, für jede Sitzung im Trainingssatz, der {DTCi} enthält, i = 1..n, aller möglichen Muster von DTC (d. h. des Leistungssatzes von {DTCi}). Dann wird, für jedes y in P, Pr(Fly) unter Verwendung von Bayes-Theorem geschätzt, wie vorstehend erörtert. Das Muster y mit dem höchsten Py = Pr(Fly) wird dann als das Muster identifiziert, das tatsächlich den Ausfall verursacht. Die Empfindlichkeits- und Spezifitätskurven für jedes P_y aus verschiedenen Sitzungen werden dann geschätzt. Siehe 7 für eine Veranschaulichung 700 der Empfindlichkeit und Spezifität. Die Ausfallgrenzwahrscheinlichkeit ist der Schnittpunkt dieser zwei Kurven (Empfindlichkeits- und Spezifitätskurve) und dieser Schnittpunkt ergibt die höchste Gesamtklassifizierung für Ausfall- und Nichtausfallsitzungen.
Um die Grenzwahrscheinlichkeit zur Klassifizierung zu verwenden (während der Validierung, wie nachfolgend erörtert), wird die folgende Regel eingehalten: Für jede Sitzung im Validierungssatz wird das P_y wie vorstehend erörtert geschätzt. Wenn P_y größer als oder gleich der Grenzwahrscheinlichkeit ist, wird die Sitzung als Ausfall oder anderenfalls als Nichtausfall klassifiziert.
Als ein Beispiel für diesen Vorgang wird eine Sitzungsdatei betrachtet: Die für die Sitzungsdatei beobachteten DTCs sind ABS-U3006-16, PCM-P0504-62, PCM-P2263-22, PCM-P253F-00. Die Ausfallwahrscheinlichkeit von verschiedenen Kombinationen von Mustern innerhalb der in den Sitzungen beobachteten DTCs werden berechnet und durch Verringern der Reihenfolge durch Anschließen von P(F) = 0.002854989, P(NF)=1-P(F)=0.997145011 sortiert. Die maximale beobachtete Wahrscheinlichkeit wird zum Vorhersagen, ob die Sitzung ein Ausfall oder Nichtausfall ist, berücksichtigt, wobei die Wahrscheinlichkeit von 100 % ausgeschlossen wird, dadurch wird die höchste Wahrscheinlichkeit für {ABS-U3006-16, PCM-P2263-22} = 2,71 % verwendet, um für die Ausfallsitzungen zu trainieren. Ein ähnlicher Vorgang wird für jede Sitzung im Trainingsdatensatz wiederholt. 8 zeigt ein Diagramm 800 der Empfindlichkeits- und Spezifitätskurven, die aus diesem Beispiel dargestellt sind.
In 8 kreuzen die zwei Kurven bei einem x-Wert von 0,0121635, bei dem es sich um die optimale zu verwendende Grenze handelt. Eine Sitzung wird als Ausfall klassifiziert, wenn der P(F|DTC) größer ist als die Grenzwahrscheinlichkeit, und anderenfalls als Nichtausfall. Auf Grundlage der Grenze von 0,0121635 ergeben die Validierungsergebnisse die Gesamtgenauigkeit von 64,47 %, wie in Diagramm 900 aus 9 veranschaulicht. Der Konflikt bei den wahren positiven Raten bei verschiedenen Grenzwerten ist in Diagramm 1000 aus 10 veranschaulicht. Nachdem die Grenzwahrscheinlichkeit ausgewählt wurde, geht das Verfahren zu 360 über.
Bei 360 wird eine Modellvalidierung durchgeführt. Die Modellvalidierung kann Beurteilen des Beitrags von zusätzlichen Bedingungen, wie etwa Batteriespannung und Kilometerstand, zu der Wahrscheinlichkeit eines Ausfalls beinhalten, wie in Block 362. Unter Verwendung von allen Sitzungen für ein Fahrzeugmodell wurden 12 verschiedene Modell für Kombinationen aufgebaut, die aus Folgendem resultieren:

• 3 DTC-Muster - {Voll-DTC, Voll-DTC + Kilometerstand + Anz. DTCs, Voll-DTC + Kilometerstand+ Anz. DTCs + Batteriespannung}
• 4 Mal bis zum Ausfall - {Letzter DTC, 1 Tag seit letztem DTC, 3 Tage seit letztem DTC, 5 Tage seit letztem DTC}

Die Datenvorbereitung und der Workflow zur Modellvalidierung sind in Diagramm 1100 aus 11 veranschaulicht.
Fehlende Werte im Datensatz können gemäß einem geeigneten Vorgang behandelt werden. Bei etwa 25 % der DTCs ist keine Batteriespannung ausgefüllt. Diese werden als eine separate Kategorie „NA“ (nicht zutreffend) betrachtet. Die gesamte Entfernung, die für jede Sitzung protokolliert wurde, wird als der Kilometerstand für diese Sitzung betrachtet. Für den Fall, dass die gesamte Entfernung „null“ beträgt, wird der maximale Wert dieses Parameters für diese Sitzung derart betrachtet, dass der Kilometerstand als fehlender Wert behandelt wird.
Kontinuierliche Variablen, wie etwa Batteriespannung, Kilometerstand und Anz. DTCs werden zur Verwendung in der folgenden Verarbeitung klassifiziert. Ein Entscheidungsbaum, wie etwa der beispielhafte Baum 1200, der in 12 gezeigt ist, kann zur Daten-Binning verwendet werden. Letztendlich wird jeder DTC in der Sitzung in Modulname-DTC-Typenbeschr.-Kilometerstandklassifizierung-Batteriespannungsklassifizierung-Klassifizierung von Anzahl an DTCs als Eingabe für die Modellierungsstufe umgewandelt.
Die Ergebnisse der Modellvalidierung sind in den folgenden Figuren gezeigt. Die Trennung von Ausfall- und Nichtausfallsitzungen in Daten 1300 für Training (Oktober 2014 - April 2016), Test (Mai 2016) und Validierung (Juni 2016) ist in 13 gezeigt. Die Frequenzanzahl der wichtigsten DTCs in Ausfallsitzungen ist in Diagramm 1400 aus 14 gezeigt. Die Frequenzhäufigkeit der Sitzungen nach Anz. DTCs in der Sitzung ist in Diagramm 1500 aus 15 gezeigt. Wenn die Anz. DTCs in der Sitzung zunimmt, nimmt die Wahrscheinlichkeit, dass die Sitzung eine Ausfallsitzung ist, zu, wie in Diagramm 1600 aus 16 gezeigt.
Das Verhältnis der Proportionen für Ausfall- und Nichtausfallsitzungen ist umgekehrt mit der Batteriespannung korreliert - das Verhältnis ist bei geringerer Batteriespannung höher, was angibt, dass bei geringeren Batteriespannungen mehr Möglichkeiten bestehen, eine Ausfallsitzung festzustellen als eine Nichtausfallsitzung. Dies ist in Diagramm 1700 aus 17 veranschaulicht.
Während der Modellvalidierung wurden Assoziationsregeln zwischen Ausfällen und Kombinationen der Eingabevariablen für Folgendes abgeleitet:

• Voll-DTC - Model + DTC + Typenbeschreibung
• Kilometerstand
• Anzahl an DTCs
• Batteriespannung

Die Wirkung von Grenzen an verschiedenen Tagen wurde ebenfalls untersucht, wie in Block 364 - d. h. unter Verwendung von Daten, bis der letzte DTC, 1 Tag, 3 Tage, 5 Tage vor dem letzten DTC aufgetreten ist. Dies ist in der folgenden Tabelle gezeigt:

Grenze Anz. DTCs (nicht einheitlich) % des letzten DTC

Letzter DTC 153279 100 %

1 Tag 135255 88 %

3 Tage 131842 86 %

5 Tage 129864 85 %
Die Modellvalidierungsergebnisse unter Verwendung von Grenzen des letzten DTC, 1 Tag, 3 Tagen und 5 Tagen zeigen, dass die gesamte Genauigkeit abnimmt, wenn die Grenze zunimmt, und zwar aufgrund einer geringeren Verfügbarkeit von Daten, wenn der Grenzzeitraum zunimmt. Dies ist in Diagramm 1800a aus 18A veranschaulicht.
Eine ähnliche, jedoch konsistentere Verringerung der Genauigkeit wird festgestellt, wenn eine Kombination aus Voll-DTC, Kilometerstand und Anzahl an DTCs als Eingabe für das Modell verwendet wird. Diese Ergebnisse sind in Diagramm 1800b aus 18B zusammengefasst.
Beim Verwenden der Merkmalskombination aus Voll-DTC, Kilometerstand, Anzahl an DTCs und Batteriespannung wurde festgestellt, dass die Einbeziehung von Batteriespannung tatsächlich die gesamte Genauigkeit verringert, und zwar aufgrund der verzerrten Genauigkeit aus Sitzungen ohne verfügbare Batteriespannung. Dies ist in Diagramm 1800c aus 18C gezeigt.
Das Verwenden der Batteriespannung führt nur zu Ergebnissen, die stark zu den wahren negativen Fällen verzerrt sind, zeigt jedoch bei wahren positiven Fällen eine schlechte Leistung - d. h., sagt die Fälle ohne Ausfall genau vorher, zeigt jedoch eine sehr geringe Genauigkeit beim Vorhersagen von tatsächlichen Ausfällen. Dies ist in Diagramm 1800d aus 18D gezeigt. (Hinweis: Für dieses Ergebnis wurde die minimale Batteriespannung der Sitzung als die abhängige Variable zum Vorhersagen eines Ausfalls verwendet.)
Aus all diesen Kombinationen der Ergebnisse scheinen die Modellergebnisse mit Voll-DTC + Kilometerstand + Anz. DTCs und einer eintägigen Grenze mit ausreichender Vorankündigung eines Ausfalls im Vergleich zu dem Modell mit letztem DTC optimal zu sein, ohne die Genauigkeiten zu sehr zu beeinträchtigen.
Auf Grundlage der beschreibenden Analyse und vorläufigen Modellergebnisse kann Folgendes geschlussfolgert werden:

• DTCs, die viel öfter zu Ausfällen als zu Nichtausfällen führen, können mit hinreichender Genauigkeit und ausreichender Vorankündigung vor der tatsächlichen Störung festgestellt werden. Diagramm 1900 aus 19 zeigt die Verteilung von DTC-Altern in Tagen.
• Muster-Ranking unter Verwendung der Bayes-Regel ist ein effektives Verfahren beim Identifizieren von DTC-Mustern, die vorwiegend Ausfälle als Nichtausfälle verursachen, und ergibt konsistente Ergebnisse in verschiedenen Zeiträumen von mehr als 65 %. Die 20A und 20B zeigen Modellleistungsmetriken für Daten im Mai 2016 und Juni 2016 in den Diagrammen 2000a und 2000b, die diese Konsistenz veranschaulichen.
• Ausfälle können mindestens einen Tag vor der tatsächlichen Störung mit einer Genauigkeit von mehr als 60 % unter Verwendung von Mustern, die von Daten vor dem letzten DTC-Vorkommen abgeleitet sind, und einer Muster-Rankingbasierten Vorhersage vorhergesagt werden. Modellleistungsmetriken auf Grundlage des letzten DTC-Vorkommens sind in Diagramm 2100a aus 21A gezeigt.
• Die Hinzunahme von mehr Daten zu den DTC-Mustern, wie Kilometerstand, Batteriespannung, kann die Vorhersagegenauigkeit der Störung um 8 % für mindestens 1 Tag vor den tatsächlichen Ausfallvorhersagen erhöhen. Modellleistungsmetriken mit zusätzlichen Parametern, einschließlich Kilometerstand und Batteriespannung, sind in Diagramm 2100b aus 21B gezeigt.

370

Bei 370 beinhaltet das Verfahren Erzeugen von einem oder mehreren trainierten Modellobjekten auf Grundlage der vorherigen Prozessschritte. Die trainierten Modellobjekte können eine oder mehrere statistische oder mathematische Beziehungen zwischen DTC-Mustern, Betriebsbedingungen und Ausfallwahrscheinlichkeiten, die in den vorstehenden Prozessblöcken 310-360 erlernt wurden, beinhalten. Die trainierten Modellobjekte können als Datenstrukturen, Entscheidungsbäume oder in anderen geeigneten Formen gespeichert werden. Die trainierten Modellobjekte können als computerlesbare Anweisungen instanziiert werden, die beispielsweise dazu geeignet sind, von der elektronischen Vorrichtung 100 empfangen, gelesen und verwendet zu werden und im Verfahren 200 in den Schritten 240-270 umgesetzt zu werden. Die trainierten Modellobjekte können auch einen oder mehrere Sätze von Anweisungen umfassen. Dabei kann es sich um Anweisungen handeln, die für einen Bediener eines Fahrzeugs angezeigt werden, wenn bestimmte Bedingungen erfüllt sind. Die Eigenschaften von trainierten Modellobjekten werden vorstehend unter Bezugnahme auf die Blöcke 240-270 ausführlicher erörtert. Sobald die trainierten Modellobjekte erzeugt wurden, kehrt das Verfahren 300 zurück.
Die Offenbarung stellt Systeme und Verfahren bereit, die Diagnose-Fehlercodes (DTCs) untersuchen, um eine frühe Fehlererkennung zu unterstützen. Zum Beispiel kann der Fahrzeug- oder Komponentenausfall unter Verwendung von nur DTCs und/oder unter Verwendung von DTCs ohne andere Elemente detektiert werden, um eine frühe Detektion von fehlerhaften Bedingungen bereitzustellen. Durchlaufzeiten (z. B. eine Zeit zwischen Empfang/Detektion eines DTC und einer Ausgabe eines zugehörigen Fehlers) können für jede DTC-/Fehlerzuordnung bestimmt werden, um zu bestimmen, welcher DTC die größte Durchlaufzeit für eine entsprechende zugehörige Fehlervorhersage bereitstellt. Die Genauigkeit (z. B. ein Verhältnis von korrekten Vorhersagen eines Ausfalls zu falsch-positiven Vorhersagen eines Ausfalls) kann ebenfalls für jede DTC-/Fehlerzuordnung bestimmt werden, um zu bestimmen, welcher DTC die genaueste Fehlervorhersage bereitstellt. Unter Verwendung der vorstehend beschriebenen Daten kann ein System einen Teilsatz von DTCs auswählen, um einen bestimmten Fehler zu überwachen, und/oder kann DTC-Status in Bezug auf mögliche Fehlerangaben auf Grundlage der vorstehend beschriebenen Daten abwägen. Ein technischer Effekt der Auswahl und/oder Gewichtung von DTCs besteht darin, dass Rechenressourcen gespart werden können (aufgrund der reduzierten Überwachung von nur den genauesten/frühesten Warn-DTCs) und Komponentenausfälle reduziert werden können (aufgrund der frühen Detektion eines Ausfalls, bevor der Ausfall entweder auftritt oder andere Systeme beeinträchtigt).
Um die DTC-Analyse wie vorstehend beschrieben zu verwenden, können Datenverarbeitungsframeworks im Fahrzeug Signale annehmen, einschließlich der DTCs, die dem System ermöglichen, in ein beliebiges Fahrzeug integriert zu werden, um standardmäßige DTC-Berichtsmechanismen des Fahrzeugs zu verwenden. Auf Grundlage der DTCs können die offenbarten Systeme und Verfahren unter Verwendung von aktuellen Daten für das Fahrzeug, vorher protokollierten Daten für das Fahrzeug, vorher protokollierten Daten für andere Fahrzeuge (z. B. Trends, die gesamtheitlich oder auf andere Fahrzeuge, die eine oder mehrere Eigenschaften mit dem Fahrzeug gemeinsam haben, zielgerichtet sind), Informationen von Originalgeräteherstellern (O-EMs), Rückrufinformationen und/oder anderen Daten benutzerspezifische Berichte erzeugen. In einigen Beispielen können die Berichte zu externen Services (z. B. zu anderen OEMs) gesendet und/oder anderweitig in zukünftigen Analysen von DTCs verwendet werden. DTCs können von Fahrzeugen zu einem zentralisierten Cloud-Service zur Aggregation und Analyse übertragen werden, um ein oder mehrere Modelle zum Vorhersagen von Ausfällen oder einem Abbau von Fahrzeugkomponenten zu erstellen. In einigen Beispielen kann das Fahrzeug Daten (z. B. lokal erzeugte DTCs) zu dem Cloud-Service zur Verarbeitung übertragen und eine Angabe eines potenziellen Ausfalls empfangen. In anderen Beispielen können die Modelle lokal im Fahrzeug gespeichert und verwendet werden, um die Angabe eines potentiellen Ausfalls zu erzeugen, wenn DTCs im Fahrzeug ausgegeben werden. Das Fahrzeug kann einige Modelle lokal speichern und Daten an den Cloud-Service zur Verwendung beim Erstellen/Aktualisieren von anderen (z. B. unterschiedlichen) Modellen außerhalb des Fahrzeugs übertragen. Bei der Kommunikation mit dem Cloud-Service und/oder anderen entfernten Vorrichtungen können die Kommunikationsvorrichtungen (z. B. das Fahrzeug und der Cloud-Service und/oder andere entfernte Vorrichtungen) an einer bidirektionalen Validierung der Daten und/oder des Modells beteiligt sein (z. B. unter Verwendung von Sicherheitsprotokollen, die in das Kommunikationsprotokoll integriert sind, die zum Kommunizieren von Daten verwendet werden, und/oder Sicherheitsprotokollen, die mit den DTCbasierten Modellen assoziiert sind).
Die Offenbarung stellt außerdem ein Verfahren bereit, umfassend Bestimmen einer Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs auf Grundlage von einem oder mehreren Diagnose-Fehlercodes (DTCs) und Angeben für einen Bediener des Fahrzeugs, dass der Ausfall als Reaktion darauf, dass die Wahrscheinlichkeit einen Schwellenwert überschreitet, wahrscheinlich erfolgt. In einem ersten Beispiel des Verfahrens kann das Bestimmen zusätzlich oder alternativ auf dem Vergleichen des einen oder der mehreren DTCs mit einem oder mehreren trainierten Modellobjekte beruhen. Ein zweites Beispiel des Verfahrens beinhaltet optional das erste Beispiel und beinhaltet ferner das Verfahren, bei dem die trainierten Modellobjekte unter Verwendung von maschinellen Lernalgorithmen erzeugt werden, die an historischen DTC-Daten durchgeführt werden. Ein drittes Beispiel des Verfahrens beinhaltet optional eines oder beide des ersten Beispiels und des zweiten Beispiels und beinhaltet ferner das Verfahren, bei dem das Bestimmen ferner auf einer Vielzahl von Betriebsbedingungen beruht, die einen Kilometerstand und eine Batteriespannung umfassen. Ein viertes Beispiel des Verfahrens beinhaltet optional eines oder mehrere des ersten bis dritten Beispiels und beinhaltet ferner das Verfahren, bei dem das Angeben Anzeigen einer Textnachricht über einen Bildschirm beinhaltet, wobei die Textnachricht Anweisungen beinhaltet. Ein fünftes Beispiel des Verfahrens beinhaltet optional eines oder mehrere des ersten bis vierten Beispiels und beinhaltet ferner das Verfahren, bei dem die Anweisungen eine empfohlene Anzahl an Tagen beinhalten, innerhalb derer eine Servicestation aufzusuchen ist. Ein sechstes Beispiel beinhaltet optional eines oder mehrere des ersten bis fünften Beispiels und beinhaltet ferner das Verfahren, bei dem die empfohlene Anzahl an Tagen auf der Wahrscheinlichkeit beruht, wobei eine größere Anzahl an Tagen für eine geringere Wahrscheinlichkeit empfohlen wird und eine kleinere Anzahl an Tagen für eine höhere Wahrscheinlichkeit empfohlen wird; und wobei die Anzahl an Tagen ferner auf einem Fahrzeugteilsystem beruht, das die DTCs erzeugt. Ein siebentes Beispiel beinhaltet optional eines oder mehrere des ersten bis sechsten Beispiels und beinhaltet ferner das Verfahren, bei dem der eine oder die mehreren DTCs eine Vielzahl von DTCs umfassen, und als Reaktion darauf, dass sich die DTCs in einer ersten Reihenfolge befinden, Bestimmen der Wahrscheinlichkeit, ein erster Wert zu sein, als Reaktion darauf, dass sich die DTCs in einer zweiten Reihenfolge befinden, die sich von der ersten Reihenfolge unterscheidet, Bestimmen der Wahrscheinlichkeit, ein zweiter Wert zu sein, der geringer ist als der erste Wert.
Die Offenbarung stellt außerdem ein System bereit, umfassend ein Fahrzeug, eine Vielzahl von Fahrzeugteilsystemen, eine Steuerung mit maschinenlesbaren Anweisungen, die in nichttransitorischem Speicher gespeichert sind, zum Empfangen von einem oder mehreren Diagnose-Fehlercodes (DTCs) von den Fahrzeugteilsystemen, Erzeugen einer Wahrscheinlichkeit eines Ausfalls des Fahrzeugs durch Vergleichen des einen oder der mehreren DTCs mit einem oder mehreren trainierten Modellobjekten und Angeben für einen Bediener des Fahrzeugs, dass der Ausfall wahrscheinlich ist, wenn die Wahrscheinlichkeit einen Schwellenwert überschreitet. In einem ersten Beispiel des Systems kann der Schwellenwert zusätzlich oder alternativ auf dem Fahrzeugteilsystem beruhen, das die DTCs erzeugt. Ein zweites Beispiel des Systems beinhaltet optional das erste Beispiel und beinhaltet ferner das System, bei dem der Schwellenwert geringer ist, wenn die DTCs von einem Antriebsstrangteilsystem empfangen werden, und höher, wenn die DTCs von einem Fahrgestellteilsystem empfangen werden. Ein drittes Beispiel des Systems beinhaltet optional eines oder beide des ersten Beispiels und des zweiten Beispiels und beinhaltet ferner das System, bei dem das Angeben Anzeigen einer Nachricht für den Bediener umfasst, wobei die Nachricht eine oder mehrere Anweisungen beinhaltet und wobei die Anweisungen auf dem Vergleichen der DTCs mit den trainierten Modellobjekten beruhen. Ein viertes Beispiel des Systems beinhaltet optional eines oder mehrere des ersten bis dritten Beispiels und beinhaltet ferner das System, bei dem die Anweisungen auf einem Fahrzeugteilsystem beruhen, das die DTCs erzeugt, wobei eine Anweisung, eine Klimaanlage auszuschalten, als Reaktion darauf erzeugt wird, dass die DTCs durch ein HLK-System erzeugt werden, und wobei eine Anweisung, die Motorlast zu reduzieren, als Reaktion darauf erzeugt wird, dass die DTCs durch ein Motorsystem erzeugt werden. Ein fünftes Beispiel des Systems beinhaltet optional eines oder mehrere des ersten bis vierten Beispiels und beinhaltet ferner das System, bei dem die Anweisungen ferner auf der Wahrscheinlichkeit beruhen, wobei die Anweisungen eine empfohlene Zeit beinhalten, in der eine Servicestation aufzusuchen ist, wobei die empfohlene Zeit umgekehrt auf die Wahrscheinlichkeit bezogen ist. Ein sechstes Beispiel des Systems beinhaltet optional eines oder mehrere des ersten bis fünften Beispiels und beinhaltet ferner das System, bei dem die Steuerung dazu konfiguriert ist, DTCs mit einem Alter über einem Schwellenalter zu ignorieren; wobei die trainierten Modellobjekte auf einem entfernten Server über maschinelle Lernalgorithmen anhand von historischen DTC-Daten erzeugt werden; und wobei die trainierten Modellobjekte am Fahrzeug vom entfernten Server als Reaktion auf eine Aktualisierungsanforderung empfangen werden.
Die Offenbarung stellt außerdem ein Verfahren bereit, umfassend Empfangen eines Diagnose-Fehlercodes (DTC) und eines Motorbetriebsparameters, Vergleichen des DTC und des Motorbetriebsparameters mit einem trainierten Modellobjekt, um eine Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs und eine Anweisung zu erzeugen, und als Reaktion darauf, dass die Wahrscheinlichkeit eines Ausfalls einen Schwellenwert überschreitet, Anzeigen der Anweisung für einen Bediener des Fahrzeugs auf einem Bildschirm. In einem ersten Beispiel des Verfahrens kann das trainierte Modellobjekt zusätzlich oder alternativ eine oder mehrere Beziehungen zwischen DTCs, Motorbetriebsparametern und der Wahrscheinlichkeit eines Ausfalls spezifizieren. Ein zweites Beispiel des Verfahrens beinhaltet optional das erste Beispiel und beinhaltet ferner das Verfahren, ferner umfassend Empfangen des trainierten Modellobjekts von einem entfernten Server als Reaktion auf eine Aktualisierungsanfrage. Ein drittes Beispiel des Verfahrens beinhaltet optional eines oder beide des ersten Beispiels und des zweiten Beispiels und beinhaltet ferner das Verfahren, bei dem das trainierte Modellobjekt unter Verwendung von einer oder mehreren Computerlerntechniken erzeugt wird und bei dem die Computerlerntechniken nicht sequentielles Muster-Mining, Assoziationsregel-Mining und Muster-Ranking mit Bayes-Theorem beinhaltet. Ein viertes Beispiel des Verfahrens beinhaltet optional eines oder mehrere des ersten bis dritten Beispiels und beinhaltet ferner das Verfahren, bei dem die Computerlerntechniken auf historische Daten angewandt werden, die Fahrzeugmodelle, Kilometerstände, Batteriespannungswerte, DTC-Muster und Ausfallzustände umfassen.
Die Beschreibung der Ausführungsformen wurde zum Zwecke der Veranschaulichung und Beschreibung dargelegt. Geeignete Modifikationen und Variationen der Ausführungsformen können angesichts der vorangehenden Beschreibung vorgenommen oder aus dem Durchführen der Verfahren gewonnen werden. Zum Beispiel können eines oder mehrere der beschriebenen Verfahren, sofern nicht anders angegeben, durch eine geeignete Vorrichtung und/oder eine Kombination aus Vorrichtungen durchgeführt werden, wie etwa die elektronische Vorrichtung 100, die in Bezug auf 1 beschrieben ist. Die Verfahren können durch Ausführen gespeicherter Anweisungen mit einer oder mehreren Logikvorrichtungen (z. B. Prozessoren) in Kombination mit einem oder mehreren zusätzlichen Hardware-Elementen, wie etwa Speichervorrichtungen, Speicher, Hardware-Netzwerkschnittstellen/Antennen, Schaltern, Aktoren, Taktschaltungen usw. durchgeführt werden. Die beschriebenen Verfahren und zugehörigen Maßnahmen können zusätzlich zu der in dieser Anmeldung beschriebenen Reihenfolge auch in verschiedenen Reihenfolgen, parallel und/oder gleichzeitig durchgeführt werden. Die beschriebenen Systeme sind von beispielhafter Natur und können zusätzliche Elemente beinhalten und/oder Elemente weglassen. Der Gegenstand der vorliegenden Offenbarung schließt alle neuartigen und nicht naheliegenden Kombinationen und Unterkombinationen der unterschiedlichen Systeme und Konfigurationen und weitere offenbarte Merkmale, Funktionen und/oder Eigenschaften ein.
Wie in dieser Anwendung verwendet, ist ein Element oder ein Schritt, das bzw. der im Singular erwähnt wird und vor dem der Begriff „ein“ oder „eine“ steht, so zu verstehen, dass der Plural dieser Elemente oder Schritte nicht ausgeschlossen ist, es sei denn, ein solcher Ausschluss ist angegeben. Ferner sind Bezugnahmen auf „eine Ausführungsform“ oder „ein Beispiel“ der vorliegenden Offenbarung nicht so zu interpretieren, dass sie das Vorhandensein zusätzlicher Ausführungsformen ausschließen, welche die genannten Merkmale ebenfalls beinhalten. Die Ausdrücke „erste/r/s“, „zweite/r/s“ und „dritte/r/s“ usw. werden lediglich als Kennzeichnungen verwendet und sollen keine numerischen Anforderungen oder eine bestimmte positionsmäßige Reihenfolge der zugehörigen Gegenstände vorschreiben. Die folgenden Ansprüche legen insbesondere den Gegenstand der vorangehenden Offenbarung dar, der als neuartig und nicht naheliegend betrachtet wird.
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

US 62407359 [0001]

Claims

Verfahren, umfassend: Bestimmen einer Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs auf Grundlage von einem oder mehreren Diagnose-Fehlercodes (DTCs); und Angeben für einen Bediener des Fahrzeugs, dass der Ausfall als Reaktion darauf, dass die Wahrscheinlichkeit einen Schwellenwert überschreitet, wahrscheinlich erfolgt.
Verfahren nach Anspruch 1, wobei das Bestimmen auf dem Vergleichen des einen oder der mehreren DTCs mit einem oder mehreren trainierten Modellobjekte beruht.
Verfahren nach Anspruch 2, wobei die trainierten Modellobjekte unter Verwendung von maschinellen Lernalgorithmen, die anhand von historischen DTC-Daten durchgeführt werden, erzeugt werden.
Verfahren nach Anspruch 2, wobei das Bestimmen ferner auf einer Vielzahl von Betriebsbedingungen beruht, die einen Kilometerstand und eine Batteriespannung umfassen.
Verfahren nach Anspruch 1, wobei das Angeben Anzeigen einer Textnachricht über einen Bildschirm beinhaltet, wobei die Textnachricht Anweisungen beinhaltet.
Verfahren nach Anspruch 5, wobei die Anweisungen eine empfohlene Anzahl an Tagen beinhalten, innerhalb derer eine Servicestation aufgesucht werden sollte.
Verfahren nach Anspruch 6, wobei die empfohlene Anzahl an Tagen auf der Wahrscheinlichkeit beruht, wobei eine größere Anzahl an Tagen für eine geringere Wahrscheinlichkeit empfohlen wird und eine kleinere Anzahl an Tagen für eine höhere Wahrscheinlichkeit empfohlen wird; und wobei die Anzahl an Tagen ferner auf einem Fahrzeugteilsystem beruht, das die DTCs erzeugt.
Verfahren nach Anspruch 1, wobei der eine oder die mehreren DTCs eine Vielzahl von DTCs umfassen; und als Reaktion darauf, dass sich die DTCs in einer ersten Reihenfolge befinden, Bestimmen, dass die Wahrscheinlichkeit ein erster Wert ist, als Reaktion darauf, dass sich die DTCs in einer zweiten Reihenfolge befinden, die sich von der ersten Reihenfolge unterscheidet, Bestimmen der Wahrscheinlichkeit, ein zweiter Wert zu sein, der geringer ist als der erste Wert.
System, umfassend: ein Fahrzeug; eine Vielzahl von Fahrzeugteilsystemen; eine Steuerung mit maschinenlesbaren Anweisungen, die in nichttransitorischem Speicher gespeichert sind, für Folgendes: Empfangen von einem oder mehreren Diagnose-Fehlercodes (DTCs) von den Fahrzeugteilsystemen, Erzeugen einer Wahrscheinlichkeit eines Ausfalls des Fahrzeugs durch Vergleichen des einen oder der mehreren DTCs mit einem oder mehreren trainierten Modellobjekten, und Angeben für einen Bediener des Fahrzeugs, dass der Ausfall wahrscheinlich ist, wenn die Wahrscheinlichkeit einen Schwellenwert überschreitet.
System nach Anspruch 9, wobei der Schwellenwert auf dem Fahrzeugteilsystem beruht, das die DTCs erzeugt.
System nach Anspruch 10, wobei der Schwellenwert geringer ist, wenn die DTCs von einem Antriebsstrangteilsystem empfangen werden, und höher, wenn die DTCs von einem Fahrgestellteilsystem empfangen werden.
System nach Anspruch 9, wobei das Angeben Anzeigen einer Nachricht für den Bediener umfasst, wobei die Nachricht eine oder mehrere Anweisungen beinhaltet und wobei die Anweisungen auf dem Vergleichen der DTCs mit den trainierten Modellobjekten beruhen.
System nach Anspruch 12, wobei die Anweisungen auf einem Fahrzeugteilsystem beruhen, das die DTCs erzeugt, wobei eine Anweisung, eine Klimaanlage auszuschalten, als Reaktion darauf erzeugt wird, dass die DTCs durch ein HLK-System erzeugt werden, und wobei eine Anweisung, die Motorlast zu reduzieren, als Reaktion darauf erzeugt wird, dass die DTCs durch ein Motorsystem erzeugt werden.
System nach Anspruch 12, wobei die Anweisungen ferner auf der Wahrscheinlichkeit beruhen, wobei die Anweisungen eine empfohlene Zeit beinhalten, in der eine Servicestation aufzusuchen ist, wobei die empfohlene Zeit umgekehrt auf die Wahrscheinlichkeit bezogen ist.
System nach Anspruch 9, wobei die Steuerung dazu konfiguriert ist, DTCs mit einem Alter über einem Schwellenalter zu ignorieren; wobei die trainierten Modellobjekte auf einem entfernten Server über maschinelle Lernalgorithmen anhand von historischen DTC-Daten erzeugt werden; und wobei die trainierten Modellobjekte am Fahrzeug vom entfernten Server als Reaktion auf eine Aktualisierungsanforderung empfangen werden.
Verfahren, umfassend: Empfangen eines Diagnose-Fehlercodes (DTC) und eines Motorbetriebsparameters; Vergleichen des DTC und des Motorbetriebsparameters mit einem trainierten Modellobjekt, um eine Wahrscheinlichkeit eines Ausfalls eines Fahrzeugs und eine Anweisung zu erzeugen; und als Reaktion darauf, dass die Wahrscheinlichkeit eines Ausfalls einen Schwellenwert überschreitet, Anzeigen der Anweisung für einen Bediener des Fahrzeugs auf einem Bildschirm.
Verfahren nach Anspruch 16, wobei die trainierten Modellobjekte eine oder mehrere Beziehungen zwischen DTCs, Motorbetriebsparametern und der Wahrscheinlichkeit eines Ausfalls spezifizieren.
Verfahren nach Anspruch 16, ferner umfassend Empfangen des trainierten Modellobjekts von einem entfernten Server als Reaktion auf eine Aktualisierungsanforderung.
Verfahren nach Anspruch 16, wobei das trainierte Modellobjekt unter Verwendung von einer oder mehreren Computerlerntechniken erzeugt wird und wobei die Computerlerntechniken nicht sequentielles Muster-Mining, Assoziationsregel-Mining und Muster-Ranking mit Bayes-Theorem beinhaltet.
Verfahren nach Anspruch 19, wobei die Computerlerntechniken auf historische Daten angewandt werden, umfassend Fahrzeugmodelle, Kilometerstände, Batteriespannungsmesswerte, DTC-Muster und Ausfallzustände.