-
Die vorliegende Erfindung betrifft ein Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug, insbesondere ein Verfahren, bei dem die Fehlerursache des Fahrzeugs über Onlinedienste in einem Server außerhalb des Fahrzeugs automatisch bestimmt wird. Die vorliegende Erfindung betrifft ferner einen Server, welcher zur Durchführung des Verfahrens eingerichtet ist.
-
Bei einem Fahrzeug, beispielsweise einem Personenkraftwagen oder einem Lastkraftwagen, können Fehlermeldungen von Steuergeräten und Sensoren beispielsweise über eine sogenannte On-Board-Diagnosefunktion gemeldet werden. Wenn eine derartige Fehlermeldung im Fahrzeug auftritt, ist jedoch die eigentliche Ursache häufig nicht bekannt. Wenn beispielsweise als Fehler eine erhöhte Kühlmitteltemperatur gemeldet wird, können die Fehlerursachen vielfältig sein, beispielsweise ein Mangel an Kühlflüssigkeit aufgrund einer Undichtigkeit im Kühlsystem, ein mangelnder Flüssigkeitsdurchsatz aufgrund von Dampfblasen oder einer defekten Kühlmittelpumpe, oder eine Überhitzung aufgrund einer vorherigen Fahrzeugbelastung und klimatischen Bedingungen. Eine Möglichkeit zur Ermittlung der Fehlerursache ist beispielsweise ein Anruf bei einem Callcenter, wo sogenannte Fehlerbäume hinterlegt sind, welche über Fragen abgearbeitet werden. Dies kann jedoch personal- und zeitintensiv sein.
-
In diesem Zusammenhang offenbart die
DE 10 2014 105674 A1 ein System mit einem Fahrzeugsteuergerät, welches einen Prozessor aufweist und mit einer Kommunikationseinrichtung und einer Fahrzeuganzeige kommuniziert. Das Steuergerät ist konfiguriert, eine Sensoreingabe zu empfangen, die einen Fehlerauslöser und/oder während des Fehlerauslösers erfasste kontextabhängige Daten enthält. Das Steuergerät kann den Fehlerauslöser über den Prozessor analysieren, um ein Fehlerereignis zu bestimmen. Das Steuergerät kann eine geeignete Werkstatt bestimmen und das Fehlerereignis und die kontextabhängigen Daten über die Kommunikationseinrichtung an die Werkstatt übertragen. Das Steuergerät kann konfiguriert sein, um einen Analysebericht und eine Terminanfrage zu empfangen und den Analysebericht und die Terminanfrage an eine Fahrzeuganzeigeeinrichtung auszugeben.
-
Die
EP 2 731 085 A1 betrifft ein Telekommunikationsendgerät und ein Verfahren zur Unterstützung der Wartung oder Reparatur von Fahrzeugen. Ein Fahrzeug weist eine Diagnoseschnittstelle auf und dem Fahrzeug ist eine Fahrzeugidentifikationsinformation zugeordnet, welche optisch detektierbar ist. Die Diagnoseschnittstelle weist eine Drahtlosschnittstelle auf und das Telekommunikationsendgerät weist eine weitere Drahtlosschnittstelle auf und ist derart konfiguriert, eine über die Diagnoseschnittstelle abrufbare sowie den Fahrzeugzustand betreffende Information zu verarbeiten. Das mobile Telekommunikationsendgerät weist eine Kameraeinrichtung auf. Die Diagnoseschnittstelle, die Drahtlosschnittstelle und die weitere Drahtlosschnittstelle sind konfiguriert, die wenigstens eine den Fahrzeugzustand betreffende Information zum Telekommunikationsendgerät zu übertragen. Die Kameraeinrichtung des Telekommunikationsendgeräts ist konfiguriert, die Fahrzeugidentifikationsinformation zu erfassen. Mittels einerseits der den Fahrzeugzustand betreffenden Information und andererseits der Fahrzeugidentifikationsinformation ist wenigstens eine Maßnahme zur Wartung oder Reparatur des Fahrzeugs definierbar.
-
Die
US 2014/0277902 A1 betrifft ein sogenanntes Crowdsourcing von fahrzeugbezogenen Analysen, beispielsweise eine Massenabfrage von fahrzeugbezogenen Analysen. Fahrzeuge weisen typischerweise einen Computer auf, welcher Diagnosefehlercodes (englisch: Diagnostic Trouble Codes, DTC) ausgibt, welche Fehlerzustände in einem Fahrzeug anzeigen. Diagnosefehlercodes (DTCs) weisen auf ein spezielles Problem mit einem speziellen Bauteil hin, wie zum Beispiel, dass ein Zylinder in einem Motor eine Fehlzündung aufweist, stellen jedoch keine Hinweise für den Grund des Problems bereit und schlagen keine Lösungen zum Lösen des Problems vor. Es werden daher Systeme offenbart, welche DTCs und andere Telemetriedaten unter Verwendung von Crowdsourcing-Prinzipien analysieren, um eine Fahrzeugwartung und andere Lösungen zu empfehlen.
-
Die
DE 10 2011 076 037 A1 betrifft ein System zum Bereitstellen eines Fahrzeug-Diagnoseservice, welches eine Diagnoseeinheit und eine Steuerungseinheit umfasst. Die Diagnoseeinheit ist eingerichtet, um einen kumulativ gespeicherten Diagnosefehlercode (Diagnostic Trouble Code, DTC) zu analysieren, um eine Problemhistorie für ein bestimmtes Fahrzeug zu analysieren. Die Steuerungseinheit vergleicht einen von einer Telematikvorrichtung eines Fahrzeugs empfangenen DTC mit der Problemhistorie, um zu bestimmen, ob es ein Problem in dem Fahrzeug gibt oder nicht, benachrichtigt einen Fahrer über Probleminformationen, wenn bestimmt wird, dass das Fahrzeug ein Problem aufweist, erzeugt ein Steuerungssignal zum Einstellen einer Diagnosedauer für einen mit dem Problem verbundenen Gegenstand, und übertragt das Steuerungssignal an die Telematikvorrichtung des Fahrzeugs.
-
Die
DE 102 35 525 A1 offenbart ein Zustandsüberwachungssystem, welches während der Lebensdauer des Fahrzeugs Aggregatdaten von vielen Fahrzeugen erfasst und archiviert. Diese Vorgeschichte kann aus der Fahrzeugidentifikationsnummer, Zeitstempeln, Lastkollektiven, Histogrammen, Datenverläufen über der Zeit oder aus Kenntnissen bestehen, die aus On-Board-Diagnose- und Datenanalysefunktionen abgeleitet werden. Zusätzlich erfasst die Zustandsüberwachung Diagnose- und Wartungsdaten von Telematik-Service-Zentralen, Werkstätten (Diagnosedaten, Reparaturen, Wartungszustand) und technischen Prüfabteilungen. Muster für „normales Fahrzeugverhalten“ und „problematisches Fahrzeugverhalten“ werden durch Verarbeiten der kombinierten Daten unter Verwendung von Verfahren des maschinellen Lernens und des Data Mining abgeleitet. Zum Beispiel werden die Geschwindigkeit, die Motordrehzahl, die Motortemperatur, das Motordrehmoment, Umgebungstemperatur, der Kraftstoffverbrauch und Emissionswerte analysiert, um ein normales und abnormales Verhalten zu erkennen. Mit diesen Mustern werden On-Board-Systemdiagnosealgorithmen angepasst und personalisiert und sie ermöglichen eine Analyse außerhalb des Fahrzeugs für vielfältige Anwendungen, wie zum Beispiel die Vorhersage bevorstehender Fahrzeugprobleme und die Bestimmung des Fahrzeug-Wartungsstatus.
-
Die
US 8 560 165 B2 zeigt ein zusammenwirkendes Diagnosesystem zum Erzeugen einer Prognose wenigstens einer Komponente in einem Fahrzeug, wobei das System umfasst: eine Diagnoseeinheit innerhalb des Fahrzeugs, die dazu eingerichtet ist, jedes Mal, wenn ein Auftreten einer Bedingung ausgelöst wird, eine Qualitätsminderungssignatur der wenigstens einen Komponente zu bestimmen, und eine Diagnoseeinheit außerhalb des Fahrzeugs, die dazu eingerichtet ist, die Qualitätsminderungssignatur zu empfangen und die einen Funktionszustand der wenigstens einen Komponente als eine Funktion der Qualitätsminderungssignatur zu bestimmen, wobei die bestimmte Qualitätsminderungssignatur der wenigstens einen Komponente bei dem Auftreten der ausgelösten Bedingung drahtlos an die Diagnoseeinheit außerhalb des Fahrzeugs übertragen wird.
-
Aus der
US 2012 / 0 041 637 A1 ist ein Diagnosesystem für ein Fahrzeug bekannt, das Fahrzeugbetriebsdaten während des Auftretens eines Fehlercodes bereitstellt. Das Diagnosesystem umfasst ein Onboard-Diagnosesystem und ein Motorsteuermodul. Das Onboard-Diagnosesystem ist zum Erzeugen von Fahrzeugdiagnosecodes konfiguriert, wenn das Fahrzeug außerhalb vorbestimmter Betriebsparameter betrieben wird. Die
US 2013 / 0 184 929 A1 zeigt ebenfalls ein Verfahren zur Bestimmung der Fehlerursache bei einem Fahrzeug.
-
Aufgrund der steigenden Komplexität der Fahrzeugtechnik besteht daher ein großer Bedarf an einer schnellen und zuverlässigen Fehlerursachenbestimmung, wenn ein Fehler an einem Fahrzeug auftritt.
-
Diese Aufgabe wird gemäß der vorliegenden Erfindung durch ein Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug nach Anspruch 1 und einen Server nach Anspruch 8 gelöst. Die abhängigen Ansprüche definieren bevorzugte und vorteilhafte Ausführungsformen der Erfindung.
-
Bei einem Verfahren gemäß der vorliegenden Erfindung zur Bestimmung einer Fehlerursache bei einem Fahrzeug empfängt ein Server außerhalb des Fahrzeugs eine Fehlermeldung von dem Fahrzeug. Die Fehlermeldung wird in dem Fahrzeug in Abhängigkeit von einem Fehlerzustand des Fahrzeugs erzeugt. Die Fehlermeldung kann beispielsweise einen Diagnosefehlercode, einen sogenannten Diagnostic Trouble Code (DTC), umfassen, welcher von einem Steuergerät des Fahrzeugs mit Hilfe von Sensoren des Fahrzeugs erzeugt wird. Ein derartiger Diagnosefehlercode kann beispielsweise von einem Fahrzeugdiagnosesystem, einer sogenannten On-Board-Diagnose (OBD), während des Betriebs des Fahrzeugs bereitgestellt werden. In dem Server wird in Abhängigkeit von der empfangenen Fehlermeldung und Lastkollektivdaten des Fahrzeugs eine Fehlerursache bestimmt. Alternativ oder zusätzlich wird in dem Server die Fehlerursache in Abhängigkeit von der Fehlermeldung und Fahrzeugzustandsgrößen des Fahrzeugs bestimmt.
-
Die Lastkollektivdaten, welche auch Belastungskollektive genannt werden, betreffen die Gesamtheit aller aufgetretenen Belastungen über einen Zeitraum an einem Bauteil oder einer Baugruppe des Fahrzeugs. Beispielsweise kann ein Lastkollektiv eines Verbrennungsmotors des Fahrzeugs anzeigen, über welche Zeiträume der Verbrennungsmotor mit welcher Drehzahl betrieben wurde oder über welche Zeiträume welches Drehmoment von dem Motor abgegeben wurde. Lastkollektive können für verschiedene Baugruppen des Fahrzeugs im Betrieb des Fahrzeugs erfasst werden, beispielsweise für den Verbrennungsmotor, für ein Getriebe, für ein Federungssystem, ein Bremssystem, eine Klimaanlage oder eine Lenkkraftunterstützung. Die Lastkollektivdaten geben somit eine Zusammenfassung von Belastungen eines Bauteils in der Vergangenheit an und werden daher auch als Daten der Fahrzeughistorie bezeichnet. Die Lastkollektivdaten werden insbesondere vor der Erzeugung der Fehlermeldung in dem Fahrzeug bestimmt und werden von dem Fahrzeug zu dem Server übertragen.
-
Die Fahrzeugzustandsgrößen des Fahrzeugs betreffen aktuelle Größen und Messwerte, welche beispielweise von Sensoren des Fahrzeugs erfasst werden. Die Fahrzeugzustandsgrößen können beispielsweise eine Kühlmitteltemperatur, eine Motortemperatur, eine Fahrzeuggeschwindigkeit, eine Motordrehzahl, ein Motordrehmoment, ein eingelegter Gang eines Getriebes des Fahrzeugs usw. umfassen. Der Server überträgt Anforderungen an das Fahrzeug, bestimmte Fahrzeugzustandsgrößen zu ermitteln und zu dem Server zu übertragen. Nach der Ermittlung der gewünschten Fahrzeugzustandsgrößen in dem Fahrzeug können die Fahrzeugzustandsgrößen beispielsweise autonom von dem Fahrzeug zu dem Server übertragen werden oder von dem Server abgerufen werden.
-
Durch die Einbeziehung von Lastkollektivdaten, d.h. vergangener Belastungen des Fahrzeugs, einer sogenannten Fahrzeughistorie, in die Bestimmung der Fehlerursache nach einem Auftreten einer Fehlermeldung, kann die Fehlerursache mit höherer Zuverlässigkeit ermittelt werden. Indem die Lastkollektivdaten automatisch von dem Fahrzeug zu dem Server übertragen werden, kann die Ursachenanalyse zeitnah in dem Server automatisch durchgeführt werden, sodass die Fehlerursache schnell ermittelt und beurteilt werden kann. Indem bei Bedarf zusätzliche Fahrzeugzustandsgrößen des Fahrzeugs von dem Server angeordert werden und bei der Bestimmung der Fehlerursache berücksichtigt werden, kann die Fehlerursache mit hoher Genauigkeit und schnell automatisch in dem Server bestimmt werden. Ferner wird nur ein Minimum an notwendigen Daten übermittelt.
-
Erfindungsgemäß wird bei dem Verfahren ferner eine Fehlerursache in Abhängigkeit von Kundendienstdaten bestimmt. Die Kundendienstdaten können Informationen über das Fahrzeug selbst umfassen, welche bei einem vergangen Werkstattbesuch ermittelt und festgehalten wurden, wie zum Beispiel durchgeführte Reparaturen, ausgetauschte Teile sowie Beschwerden oder Beobachtungen des Kunden. Die Kundendienstdaten können ferner Informationen über fremde Fahrzeuge umfassen, welche bei Werkstattbesuchen dieser Fremdfahrzeuge ermittelt und festgehalten wurden. Insbesondere können Kundendienstdaten von baugleichen oder bauähnlichen Fahrzeugen oder Fahrzeugen mit einem ähnlichen Baujahr berücksichtigt werden. Die Kundendienstdaten können ferner Fehlerursachen bei gegebenen Fehlermeldungen, Lastkollektivdaten und/oder Fahrzeugzustandsgrößen umfassen. Die Kundendienstdaten werden von dem Server aus einer Kundendienstdatenbank in Abhängigkeit von der Fehlermeldung abgerufen. Dadurch wird eine schnelle und präzise Ermittlung der Fehlerursache unterstützt.
-
Erfindungsgemäß werden die zuvor genannten Schritte zur Bestimmung der Fehlerursache des Fahrzeugs in folgender Reihenfolge durchgeführt. Zunächst wird eine Fehlerursache in Abhängigkeit von den Kundendienstdaten, welche in Abhängigkeit von der Fehlermeldung aus der Kundendienstdatenbank abgerufen werden, bestimmt. Dann wird eine Fehlerursache in Abhängigkeit von der Fehlermeldung und Lastkollektivdaten des Fahrzeugs bestimmt. Schließlich wird eine Fehlerursache in Abhängigkeit von der Fehlermeldung und Fahrzeugzustandsgrößen des Fahrzeugs bestimmt. Nach jedem dieser Schritte zum Bestimmen der Fehlerursache kann jeweils ein aktueller Gütewert für die jeweilige Fehlerursache bestimmt werden. Der Gütewert gibt beispielsweise an, wie hoch die Wahrscheinlichkeit ist, dass die bestimmte Fehlerursache die tatsächliche Fehlerursache ist und somit das Fahrzeug durch Beheben der bestimmten Fehlerursache wieder vollständig oder zumindest hinreichend instandgesetzt werden kann. Ein Bestimmen der Fehlerursache in der oben beschriebenen Reihenfolge wird in Abhängigkeit von dem Gütewert der zuvor durchgeführten Fehlerursachenbestimmung durchgeführt. Wenn beispielsweise für die Fehlerursache in Abhängigkeit von Kundendienstdaten bereits eine sehr hohe Güte für die Fehlerursache bestimmt wurde, können die Schritte zum Bestimmen der Fehlerursache in Abhängigkeit von der Fehlermeldung und den Lastkollektivdaten sowie die Bestimmung der Fehlerursache in Abhängigkeit von der Fehlermeldung und den Fahrzeugzustandsgrößen weggelassen werden. Ist der Gütewert der Fehlerursache in Abhängigkeit von den Kundendienstdaten jedoch nicht hinreichend groß, wird die Fehlerursache in Abhängigkeit von der Fehlermeldung und den Lastkollektivdaten bestimmt. Sollte auch hier der Gütewert für die bestimmte Fehlerursache nicht hinreichend groß sein, so wird die Fehlerursache in Abhängigkeit von der Fehlermeldung und den Fahrzeugzustandsgrößen bestimmt. Durch diese sequenzielle Vorgehensweise kann die Kommunikation zwischen dem Fahrzeug und dem Server, einem sogenannten Backend, minimiert werden. Ob der aktuelle Gütewert für die jeweilige Fehlerursache bereits ausreichend ist oder nicht, kann beispielsweise mittels eines Entscheiders automatisch durch Vergleichen des Gütewertes mit einem vorgegebenen Schwellenwert ermittelt werden. Die somit zuletzt bestimmte Fehlerursache, d.h. die Fehlerursache, welche einen Gütewert aufweist, welcher hinreichend groß ist, wird von dem Server zu dem Fahrzeug übertragen, um in dem Fahrzeug ausgegeben zu werden, beispielsweise an einen Fahrer des Fahrzeugs. Die Fehlerursache kann beispielsweise über einen Bildschirm des Fahrzeugs an den Fahrer ausgegeben werden und zusätzliche Informationen umfassen, wie zum Beispiel einen Schweregrad des Fehlers, woraus sich beispielsweise ergibt, ob eine Weiterfahrt möglich ist oder ob das Fahrzeug baldmöglichst in eine Werkstatt zu geben ist oder sogar am besten zu der Werkstatt geschleppt wird, um weitere Schäden an dem Fahrzeug zu vermeiden.
-
Ferner kann in einer Ausführungsform aus den Kundendienstdaten in Abhängigkeit von der bestimmten Fehlerursache automatisch ein Reparaturmuster erzeugt werden. Das Reparaturmuster umfasst beispielsweise eine Aufstellung von benötigten Ersatzteilen zur Behebung der Fehlerursache und der zum Austausch der Ersatzteile erforderlichen Arbeitspositionen. Ferner kann das Reparaturmuster eine Schätzung der Kosten für die Reparatur umfassen. Anhand des Reparaturmusters kann eine Werkstatt beispielsweise eine Reparatur des Fahrzeugs frühzeitig einplanen.
-
Ferner können zumindest einige Informationen des Reparaturmusters an den Fahrer ausgegeben werden, sodass der Fahrer einen Überblick über Kosten und Zeitumfang der Reparatur erhält.
-
Bei einer nicht erfindungsgemäßen Ausführungsform werden die zuvor genannten Schritte zur Bestimmung der Fehlerursache, d.h., das Bestimmen einer Fehlerursache in Abhängigkeit von Kundendienstdaten, das Bestimmen einer Fehlerursache in Abhängigkeit von der Fehlermeldung und Lastkollektivdaten des Fahrzeugs und das Bestimmen einer Fehlerursache in Abhängigkeit von der Fehlermeldung und Fahrzeugzustandsgrößen des Fahrzeugs, zeitlich parallel durchgeführt und eine resultierende Fehlerursache in Abhängigkeit von den in den jeweiligen Schritten bestimmten Fehlerursachen bestimmt. Wenn mehrere unterschiedliche Fehlerursachen in den einzelnen Schritten bestimmt wurden, kann die resultierende Fehlerursache beispielsweise mit Hilfe eines Mehrheitsentscheids oder durch Gewichten der Fehlerursachen bestimmt werden. Indem alle der zuvor beschriebenen Schritte zur Bestimmung einer Fehlerursache zumindest teilweise zeitlich parallel durchgeführt werden, kann die resultierende Fehlerursache mit großer Zuverlässigkeit und Genauigkeit bestimmt werden. Durch das zeitlich parallele Ausführen kann die resultierende Fehlerursache in kurzer Zeit ermittelt werden.
-
Bei einer weiteren Ausführungsform der vorliegenden Erfindung umfasst die Fehlermeldung einen Diagnosefehlercode und ein Fahrzeugidentifikationskennzeichen. Der Diagnosefehlercode ist dem Fehlerzustand zugeordnet und beinhaltet beispielsweise eine Kennziffer zur Identifikation von Fehlfunktionen, die während des Betriebs eines Fahrzeugs auftreten können. Der Diagnosefehlercode wird auch als Diagnostic Trouble Code (DTC) bezeichnet. Das Fahrzeugidentifikationskennzeichen gibt beispielsweise einen Fahrzeugtyp des Fahrzeugs und darüber hinaus gegebenenfalls Ausstattungsmerkmale des Fahrzeugs an. Das Fahrzeugidentifikationskennzeichen kann beispielsweise eine fahrzeugindividuelle Nummer umfassen, beispielsweise ein Fahrzeug-Identifizierungsnummer (englisch Vehicle Identification Number, VIN), mit welcher ein Fahrzeug eindeutig identifizierbar ist. Mit Hilfe des Fahrzeugidentifikationskennzeichens können Informationen zu dem Fahrzeug oder zu ähnlichen Fahrzeugen aus der Kundendienstdatenbank auf einfache Art und Weise ermittelt werden.
-
Bei einer weiteren Ausführungsform werden beim Bestimmen einer Fehlerursache in Abhängigkeit von der Fehlermeldung und Lastkollektivdaten des Fahrzeugs die Lastkollektivdaten des Fahrzeugs mit Lastkollektivdaten von einem anderen Fahrzeug verglichen, bei welchem der gleiche Fehlerzustand aufgetreten ist. Wenn bei dem anderen Fahrzeug für diesen Fehlerzustand eine Fehlerursache ermittelt wurde, liegt eine gleiche oder ähnliche Fehlerursache mit hoher Wahrscheinlichkeit auch bei dem Fahrzeug vor, von welchem die Fehlermeldung empfangen wurde. Da Belastungen des Fahrzeugs in der Vergangenheit einen maßgeblichen Einfluss auf eine Fehlerursache haben können, kann durch Berücksichtigen der Lastkollektivdaten von anderen Fahrzeugen bei entsprechenden Fehlermeldungen mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass die gleiche Fehlerursache vorliegt, sodass die Fehlerursache mit hoher Zuverlässigkeit bestimmt werden kann.
-
Die Fehlermeldungen, die Lastkollektivdaten sowie die Fahrzeugzustandsgrößen können über eine Funkverbindung zwischen dem Fahrzeug und dem Server übertragen werden. Durch Verwenden einer Funkverbindung kann bereits während der Fahrt des Fahrzeugs in dem Server eine Bestimmung der Fehlerursache durchgeführt werden, sodass eine Fehlerursache frühzeitig bestimmt werden kann und dadurch können beispielsweise ein Liegenbleiben des Fahrzeugs oder Folgefehler in dem Fahrzeug vermieden werden.
-
Bei einer weiteren Ausführungsform der vorliegenden Erfindung wird beim Bestimmen der Fehlerursache in Abhängigkeit von der Fehlermeldung und den Fahrzeugzustandsgrößen ein Prüfplan in Abhängigkeit von der Fehlermeldung erzeugt. Der Prüfplan ist derart ausgestaltet, dass in Abhängigkeit von den Zustandsgrößen des Fahrzeugs eine Fehlerursache aus einer vorgegebenen Menge von Fehlerursachen iterativ bestimmt werden kann. Die benötigten Fahrzeugzustandsgrößen werden in Abhängigkeit von dem Prüfplan angefordert. Der Prüfplan kann beispielsweise automatisch in dem Server abgearbeitet werden. Der Server kann die Fahrzeugzustandsgrößen sukzessive in Abhängigkeit von dem Prüfplan von dem Fahrzeug anfordern. Dadurch kann der Kommunikationsaufwand zwischen dem Server und dem Fahrzeug minimiert werden.
-
Ferner wird ein nicht erfindungsgemäßes Fahrzeug bereitgestellt, welches eine Verarbeitungsvorrichtung und eine Übertragungsvorrichtung zum Übertragen von Daten zwischen dem Fahrzeug und einem Server außerhalb des Fahrzeugs umfasst. Die Verarbeitungsvorrichtung ist in der Lage, eine Fehlermeldung in Abhängigkeit von einem Fehlerzustand des Fahrzeugs zu erzeugen und die Fehlermeldung zu dem Server zu übertragen. Die Fehlermeldung kann beispielsweise einen Diagnosefehlercode (Diagnostic Trouble Code, DTC) umfassen, welcher von einer Steuervorrichtung des Fahrzeugs über beispielsweise eine sogenannte On-Board-Diagnose bereitgestellt wird. Die Verarbeitungsvorrichtung ist ferner in der Lage, Lastkollektivdaten insbesondere vor der Erzeugung der Fehlermeldung in dem Fahrzeug zu bestimmen und von dem Fahrzeug zu dem Server zu übertragen. Die Lastkollektivdaten können beispielsweise kontinuierlich in dem Fahrzeug bestimmt und gesammelt werden. Alternativ oder zusätzlich ist die Verarbeitungsvorrichtung ferner in der Lage, Fahrzeugzustandsgrößen aufgrund von Anforderungen von dem Server an das Fahrzeug in dem Fahrzeug zu ermitteln und von dem Fahrzeug zu dem Server zu übertragen. Dadurch ist das Fahrzeug in der Lage, in Verbindung mit einem Server das zuvor beschriebene Verfahren oder eine seiner Ausführungsformen durchzuführen. Dadurch kann eine Ursache eines Fehlers in dem Fahrzeug zuverlässig und schnell bestimmt werden.
-
Das nicht erfindungsgemäße Fahrzeug kann ferner eine Ausgabeeinheit umfassen, welche mit der Verarbeitungsvorrichtung gekoppelt ist. Die Verarbeitungsvorrichtung kann eine von dem Server bestimmte Fehlerursache von dem Server mittels der Übertragungsvorrichtung empfangen und über die Ausgabeeinheit an einen Fahrzeugbenutzer ausgeben. Dadurch kann der Fahrzeugbenutzer innerhalb sehr kurzer Zeit nach einem Auftreten eines Fehlers in dem Fahrzeug über eine mögliche Fehlerursache informiert werden.
-
Gemäß der vorliegenden Erfindung wird weiterhin ein Server bereitgestellt, welcher eine Verarbeitungsvorrichtung und eine Übertragungsvorrichtung zum Übertragen von Daten zwischen dem Server und einem Fahrzeug umfasst. Die Verarbeitungsvorrichtung ist in der Lage, eine Fehlermeldung von dem Fahrzeug über die Übertragungsvorrichtung zu empfangen. Die Fehlermeldung wurde in dem Fahrzeug in Abhängigkeit von einem Fehlerzustand des Fahrzeugs erzeugt. Die Verarbeitungsvorrichtung ist ferner in der Lage, eine Fehlerursache in Abhängigkeit von der Fehlermeldung und Lastkollektivdaten des Fahrzeugs zu bestimmen. Die Lastkollektivdaten werden vor der Erzeugung der Fehlermeldung in dem Fahrzeug bestimmt und von dem Fahrzeug zu dem Server übertragen, beispielsweise aufgrund einer Anforderung von dem Server. Alternativ oder zusätzlich kann die Verarbeitungseinheit die Fehlerursache in Abhängigkeit von der Fehlermeldung und Fahrzeugzustandsgrößen des Fahrzeugs bestimmen. Dazu fordert der Server die Fahrzeugszustandgrößen von dem Fahrzeug an. In dem Fahrzeug werden die angeforderten Fahrzeugzustandsgrößen ermittelt und als Antwort zu dem Server übertragen. Der Server ist somit zur Durchführung des zuvor beschriebenen Verfahrens oder einer seiner Ausführungsformen eingerichtet und umfasst daher auch die zuvor beschriebenen Vorteile.
-
Obwohl die zuvor beschriebenen Merkmale des Verfahrens, des Fahrzeugs und des Servers in verschiedenen Ausführungsformen beschrieben wurden, können diese Ausführungsformen beliebig miteinander kombiniert werden.
-
Die vorliegende Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnungen im Detail beschrieben werden.
- 1 zeigt ein nicht erfindungsgemäßes Fahrzeug und einen Server gemäß einer Ausführungsform der vorliegenden Erfindung.
- 2 zeigt schematisch ein Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug gemäß einer Ausführungsform der vorliegenden Erfindung.
- 3 zeigt schematisch ein Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug gemäß einer weiteren Ausführungsform der vorliegenden Erfindung.
- 4 zeigt Details eines Verfahrensschritts zur Bestimmung einer Fehlerursache in Abhängigkeit von Kundendienstdaten.
- 5 zeigt Details eines Verfahrensschritts zum Erzeugen von Reparaturmustern aus Kundendienstdaten.
- 6 zeigt Details eines Verfahrensschritts zum Bestimmen einer Fehlerursache in Abhängigkeit von Lastkollektivdaten des Fahrzeugs.
- 7 zeigt Details eines Verfahrensschritts zum Bestimmen einer Fehlerursache in Abhängigkeit von Fahrzeugzustandsgrößen.
- 8 zeigt schematisch ein Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug sowie zur Prognose von Fehlerfällen in Fahrzeugen gemäß einer Ausführungsform der vorliegenden Erfindung.
-
1 zeigt ein Fahrzeug 10, einen Server 20 und eine Kundendienstdatenbank KDDB 40. Das Fahrzeug 10 steht über einer Funkverbindung 30 in Verbindung mit dem Server 20. Die Funkverbindung 30 kann beispielsweise über ein Telekommunikationsnetz realisiert werden, beispielsweise GSM oder LTE. Das Fahrzeug 10 umfasst eine Verarbeitungsvorrichtung 11, beispielsweise einen Mikroprozessor oder einen Controller, eine Übertragungsvorrichtung 12 und eine Ausgabeeinheit 13. Die Übertragungsvorrichtung 12 kann beispielsweise eine Sende- und Empfangsvorrichtung umfassen, welche in der Lage ist, die Funkverbindung 30 mit dem Server 20 aufzubauen, um Daten zwischen dem Fahrzeug 10 und dem Server 20 zu übertragen. Die Ausgabeeinheit 13 kann beispielsweise eine Anzeige in einem Armaturenbrett des Fahrzeugs 10 umfassen, insbesondere einen Bildschirm, beispielsweise einen Bildschirm eines Navigationssystems oder eines Unterhaltungssystems des Fahrzeugs 10. Die Verarbeitungsvorrichtung 11 ist mit der Übertragungsvorrichtung 12 und der Ausgabeeinheit 13 gekoppelt. Die Verarbeitungsvorrichtung 11 ist ferner über beispielsweise über einen Fahrzeugbus 17 mit Steuergeräten des Fahrzeugs 10 verbunden, beispielsweise mit einem Motorsteuergerät 14, welches einen Antriebsmotor 15 des Fahrzeugs 10 steuert. Über den Fahrzeugbus 17 kann die Verarbeitungsvorrichtung 11 mit weiteren Steuervorrichtungen und Sensoren des Fahrzeugs 10 gekoppelt sein, um insbesondere Diagnoseinformationen von dem Fahrzeug 10, sogenannte On-Board-Diagnoseinformationen, zu erhalten. Die Verarbeitungsvorrichtung 11 ist ferner mit einer Speichervorrichtung 16 gekoppelt, in welcher Daten gesammelt werden können, welche die Verarbeitungsvorrichtung 11 während eines Betriebs des Fahrzeugs 10 sammelt. Die in der Speichervorrichtung 16 gespeicherten Daten können beispielsweise sogenannte Lastkollektivdaten umfassen, welche Benutzungs- und Belastungsprofile des Fahrzeugs 10 umfassen. Beispielsweise können die Lastkollektivdaten angeben, über welchen Zeiträumen der Antriebsmotor 15 des Fahrzeugs 10 mit welchen Drehzahlen oder Drehmomenten betrieben wurde.
-
Der Server 20 umfasst eine Verarbeitungsvorrichtung 21 und eine Übertragungsvorrichtung 22. Die Übertragungsvorrichtung 22 ist geeignet, Daten zwischen dem Fahrzeug 10 und dem Server 20 zu übertragen. Der Server 20 ist mit der Kundendienstdatenbank 40 gekoppelt, in welcher Kundendienstinformationen gespeichert sind, welche bei einem Werkstattbesuch des Fahrzeugs 10 oder anderer Fahrzeuge erfasst wurden. Die Kundendienstdaten können beispielsweise Informationen umfassen, welche Teile an dem Fahrzeug 10 wann ausgetauscht wurden und welche Fehler an dem Fahrzeug 10 wann behoben wurden. Beispielsweise kann in der Kundendienstdatenbank 40 gespeichert sein, dass bei dem Fahrzeug 10 aufgrund eines Auftretens einer bestimmten Fehlermeldung eine bestimmte Fehlerursache ermittelt wurde und daraufhin bestimmte Teile des Fahrzeugs 10 ausgetauscht wurden.
-
Die Arbeitsweise des Fahrzeugs 10 in Verbindung mit dem Server 20 und der Kundendienstdatenbank 40 wird nachfolgend anhand verschiedener Beispiele unter Bezugnahme auf die 2 bis 8 im Detail beschrieben werden.
-
Eine Bestimmung einer Fehlerursache eines Fehlers in dem Fahrzeug 10 wird außerhalb des Fahrzeugs 10 in dem Server 20 durchgeführt. Dies wird durch die zunehmende Vernetzung von Fahrzeugen ermöglicht, beispielsweise über die Funkverbindung 30. Ferner werden Informationen des Fahrzeugs 10 selbst, welche vor dem Eintritt des Fehlers gesammelt wurden, Informationen aus der Kundendienstdatenbank 40 sowie aktuelle Informationen des Fahrzeugs 10, welche beispielsweise von Sensoren erfasst werden, berücksichtigt. In Verbindung mit 2 wird dazu ein sequenzieller oder iterativer Prozess vorgeschlagen. Zusammengefasst umfasst dieser Prozess die Schritte der Analyse von Kundendienstdaten, der Analyse der Lastkollektivdaten, welche auch als Fahrzeughistorie bezeichnet werden, und eine geführte Online-Fehlersuche. Die Reihenfolge der Prozessschritte richtet sich dabei nach dem Umfang an Daten, die zwischen dem Fahrzeug 10 und dem Server 20 übertragen werden müssen. Wenn ein Prozessschritt keine eindeutige Fehlerursache identifizieren kann, startet der nächste Prozessschritt und weitere dazu notwendige Daten werden von dem Fahrzeug 10 abgefragt.
-
Als erstes sendet das Fahrzeug 10 eine Fehlermeldung, beispielsweise einen Diagnosefehlercode (Diagnostic Trouble Code, DTC) zusammen mit einem Fahrzeugidentifikationskennzeichen (Vehicle Identification Number, VIN) an den Server 20. Die Fehlermeldung wurde in dem Fahrzeug 10 in Abhängigkeit von einem Fehlerzustand des Fahrzeugs 10 erzeugt. Beispielsweise kann die Fehlermeldung von dem Motorsteuergerät 14 erzeugt werden und über die Verarbeitungsvorrichtung 11 und die Übertragungsvorrichtung 12 zu dem Server 20 übertragen werden.
-
In dem Server 20 findet in einem ersten Schritt 201 eine Analyse von Kundendienstdaten zu dieser Fehlermeldung statt. Dazu werden Kundendienstdaten von der Kundendienstdatenbank 40 abgefragt und die Kundendienstdaten werden von der Kundendienstdatenbank 40 zu dem Server 20 gesendet. Wenn auf der Grundlage der Analyse der Kundendienstdaten eine Fehlerursache gefunden werden konnte, wird diese Fehlerursache im Schritt 204 an das Fahrzeug 10 übertragen und beispielsweise auf der Ausgabeeinheit 13 angezeigt. Wenn keine Ursache aufgrund der Analyse der Kundendienstdaten gefunden werden konnte oder die Ursache nicht mit ausreichender Sicherheit festgestellt werden konnte, was beispielsweise mit Hilfe eines Entscheiders in dem Server 20 bestimmt wird, wird in dem Server 20 eine Analyse der Fahrzeughistorie im Schritt 202 in Bezug auf die empfangene Fehlermeldung durchgeführt. Dazu fragt der Server 20 die Fahrzeughistorie von dem Fahrzeug 10 ab. Die Fahrzeughistorie, sogenannte Lastkollektivdaten, welche in dem Fahrzeug 10 in dem Datenspeicher 16 gesammelt wurden, werden daraufhin von der Verarbeitungsvorrichtung 11 über die Übertragungsvorrichtung 12 an den Server 20 gesendet. Auf der Grundlage der Fahrzeughistorie wird in dem Server 20 nach einer Ursache für den gemeldeten Fehler gesucht. Wenn eine Fehlerursache hinreichend genau bestimmt wurde, was beispielsweise von einem entsprechenden Entscheider festgelegt wird, wird die Fehlerursache im Schritt 204 zu dem Fahrzeug 10 übertragen und dort beispielsweise auf der Anzeigeeinheit 13 ausgegeben. Konnte auch im Schritt 202 auf der Grundlage der Fahrzeughistorie keine geeignete Ursache für die Fehlermeldung bestimmt werden, wird in dem Server 20 im Schritt 203 eine geführte Fehlersuche online angestoßen. Die geführte Fehlersuche kann beispielsweise anhand eines Prüfplans durchgeführt werden, welche in Abhängigkeit von der Fehlermeldung in dem Server 20 ausgewählt oder erzeugt wird. Der Prüfplan ermöglicht, in Abhängigkeit von aktuellen Zustandsgrößen des Fahrzeugs 10 eine Fehlerursache aus einer vorgegebenen Menge von Fehlerursachen iterativ zu bestimmen. Dazu werden verschiedene Messgrößen von dem Fahrzeug 10 abgefragt, welche in dem Fahrzeug 10 bestimmt und von dem Fahrzeug 10 zu dem Server 20 gesendet werden. Dieses Abfragen und Senden von Messgrößen kann mehrfach hintereinander für verschiedene Schritte des Prüfplans durchgeführt werden. Ein Entscheider kann wiederum feststellen, ob die mit Hilfe der geführten Fehlersuche bestimmte Fehlerursache eine hinreichende Qualität oder Güte aufweist, um an den Fahrzeugbenutzer oder Kunden im Schritt 204 ausgegeben zu werden. Wurde wiederum keine Fehlerursache eindeutig oder mit hinreichender Güte bestimmt, wird das Verfahren im Schritt 205 fortgesetzt, worin beispielsweise über eine entsprechende Ausgabe an den Fahrer die Empfehlung ausgegeben wird, ein Callcenter anzurufen oder einen Werkstatttermin zu vereinbaren.
-
3 zeigt ein alternatives Beispiel zur Bestimmung einer Fehlerursache auf der Grundlage von Kundendienstdaten, Fahrzeughistorie und geführter Fehlersuche. Bei dem in 3 gezeigten nicht erfindungsgemäßen Beispiel werden die drei Prozessschritte 201 bis 203 nicht abhängig voneinander nacheinander durchgeführt, sondern parallel durchgeführt. Dazu werden die Daten des Fahrzeugs 10 als Eingangsdaten 301 komplett gesammelt und in dem Server 20 verarbeitet. In dem Server 20 läuft die geführte Fehlersuche, die Analyse der Kundendienstdaten und die Analyse der Fahrzeughistorie parallel ab und es werden aus jedem dieser Schritte 201 bis 203 gegebenenfalls entsprechende Fehlerursachen ermittelt. Ein Entscheider 302 kann beispielsweise mit einer Gewichtung der ermittelten Fehlerursachen eine gesamte Fehlerursache bestimmen, welche im Schritt 204 an das Fahrzeug 10 zur Ausgabe an den Fahrzeugbenutzer oder Kunden übertragen wird. Wenn der Entscheider 302 keine eindeutige Fehlerursache finden konnte, wird im Schritt 205 eine Empfehlung an den Fahrzeugbenutzer ausgegeben, ein Callcenter anzurufen oder einen Werkstatttermin zu vereinbaren.
-
4 zeigt Details zur Bestimmung einer Fehlerursache unter Berücksichtigung einer Analyse von Kundendienstdaten, wie sie beispielsweise im Schritt 201 der 2 und 3 verwendet werden kann. Das Fahrzeug 10 sendet eine Fehlermeldung an den Server 20, welche beispielsweise einen Diagnosefehlercode oder Fehlerspeichereintrag (DTC) und ein Fahrzeugidentifizierungskennzeichen, beispielsweise eine Fahrzeugidentifikationsnummer (VIN) umfasst. Diese Übertragung der Fahrzeugidentifikationsnummer und des Fehlerspeichereintrags startet in dem Server 20 eine Online-Analyse zur Identifikation von möglichen Lösungen der Fehlersituation durch eine Analyse der Kundendienstdaten. Dazu fordert der Server 20 Kundendienstdaten zu einem gleichen DTC von der Kundendienstdatenbank 40 an. Die Kundendienstdatenbank 40 sendet die Kundendienstdaten zu dem Server 20 und der Server 20 generiert Lösungshypothesen basierend auf Ähnlichkeiten in Kundenaussagen und Werkstattaussagen unter Verwendung des DTC, VIN und weiteren Kundendienstdaten. Beispielsweise können innerhalb der Kundendienstdaten Ähnlichkeiten zwischen der aktuellen Fehlersituation und bereits aufgetretenen Fehlerfällen identifiziert werden, um auf dieser Basis Lösungshypothesen zu der aktuellen Fehlersituation zu generieren. Anschließend wird die Güte der Lösungshypothese, d.h. die Güte der bestimmten Fehlerursache, bewertet und entschieden, ob tatsächlich die Fehlerursache erkannt wurde oder ob die Fehlerursache nicht erkannt wurde. Die Hypothesenbildung für verschiedene Fehlermeldungen (DTC1, DTC2 usw.) wird in 5 im Detail dargestellt. Zu jeder Hypothese gehören entsprechende Fahrzeugdaten, wie zum Beispiel Fahrzeugtyp, Fahrzeugausstattung, Alter des Fahrzeugs usw., Kundenaussagen, welche Fehlerzustände beschreiben, sowie Werkstattaussagen, wie zum Beispiel welche Bauteile potentiell defekt sein können und daher auszutauschen sind. Als Ergebnis einer jeden Hypothese können sogenannte Reparaturmuster erstellt werden, worin die zur Reparatur der Fehlerursache benötigten Ersatzteile und Arbeitspositionen enthalten sind. Auf der Grundlage der Reparaturmuster kann eine Werkstatt beispielsweise einen Kostenvoranschlag erstellen oder eine Reparatur des Fahrzeugs zeitlich einplanen. Die Reparaturmuster können, sofern eine der Hypothesen als wahrscheinliche Fehlerursache erachtet wird, an das Fahrzeug übertragen werden und dort von dem Fahrzeugbenutzer bei der Vereinbarung eines Werkstatttermins verwendet werden.
-
6 zeigt die Analyse der Fahrzeughistorie des Schritts 202 der 2 und 3 im Detail. In dem Fahrzeug 10 können Lastzustände, wie zum Beispiel Motordrehzahlen, Motordrehmomente, Bremswerte, Schaltzustände und dergleichen gesammelt werden, und in Form von Lastkollektiven in der Speichervorrichtung 16 abgelegt werden. Anders ausgedrückt werden bestimmte Merkmalswerte des Fahrzeugs im Betrieb des Fahrzeugs in Gruppen oder Klassen eingeteilt. Eine derartige Einteilung von Merkmalswerten wird auch als Klassierung bezeichnet. Bezüglich der Motordrehzahl kann beispielsweise als Klassierung oder Lastkollektiv in der Speichervorrichtung 16 gespeichert werden, über welchen Zeitraum der Antriebsmotor 15 des Fahrzeugs 10 in einem Drehzahlbereich von 1000 bis 1500 Umdrehungen betrieben wurde, über welchen Zeitraum hinweg der Antriebsmotor 15 in einem Drehzahlbereich von 1500 bis 2000 Umdrehungen pro Minute betrieben wurde usw. Für die Analyse der Fahrzeughistorie können beispielsweise Klassierungen herausgefiltert werden, welche für die aktuelle Fehlermeldung (DTC) relevant sind. Diese Klassierungen werden von dem Fahrzeug 10 zu dem Server 20 übertragen. Durch die Übertragung von Fahrzeugidentifikationsnummer und dem historischen Fahrzeugverhalten (Klassierungen) ist es möglich, dass der Server 20 Fahrzeuge identifiziert, welche ein ähnliches Fahrzeugverhalten vor einer entsprechenden Fehlersituation aufgewiesen haben. Voraussetzung dafür ist, dass entsprechende Klassierungen und Fehlersituationen anderer Fahrzeuge in dem Server vorhanden sind. Ähnlichkeiten zwischen den Klassierungen des Fahrzeugs 10 und Klassierungen von anderen Fahrzeugen, welche in dem Server 20 gespeichert sind, werden auf einem reduzierten Set an Klassierungen detektiert. Basierend auf der resultierenden Liste an ähnlichen Fahrzeugen lassen sich die Kundendienstdaten unter weiterer Berücksichtigung der Fahrzeugidentifikationsnummer und des Diagnosefehlercodes (DTC) durchsuchen, beispielsweise wie zuvor unter Bezugnahme auf 4 beschrieben wurde. Schließlich wird entschieden, ob eine Fehlerursache erkannt wurde oder nicht.
-
7 zeigt Details der geführten Fehlersuche online des Schritts 203. Auf der Grundlage des von dem Fahrzeug 10 empfangenen Diagnosefehlercodes (DTC) erzeugt der Server 20 einen Prüfplan, welcher Messgrößen des Fahrzeugs nutzt. Die Messgrößen des Fahrzeugs können beispielsweise aktuelle Sensorwerte des Fahrzeugs umfassen, wie zum Beispiel eine aktuelle Drehzahl des Motors 15, eine Kühlmitteltemperatur, eine Umgebungstemperatur, ein Umgebungsluftdruck, ein Ladedruck eines Abgasturboladers des Antriebsmotors 15 usw. Der generierte Prüfplan wird in dem Server beispielsweise sequenziell abgearbeitet, wobei weitere Messgrößen zu berücksichtigen sind. Diese Messgrößen werden von dem Fahrzeug 10 angefordert und das Fahrzeug 10 ermittelt diese Messgrößen und sendet sie an den Server 20 zurück. Dies kann sich mehrfach wiederholen, sodass der Server 20 der Reihe nach eine Vielzahl von Messgrößen von dem Fahrzeug 10 anfordert und diese von dem Fahrzeug 10 zu dem Server 20 übertragen werden. Am Ende des Prüfplans kann eine mögliche Fehlerursache bestimmt werden oder es kann bestimmt werden, dass mit diesem Prüfplan keine Fehlerursache bestimmt werden konnte und daher das Fahrzeug in einer Werkstatt näher zu untersuchen ist.
-
Das zuvor beschriebene Verfahren, bei dem Fehlerspeichereinträge (DTC) und Klassierungen von Fahrzeugen an einen Server übermittelt werden, kann besonders effektiv genutzt werden, wenn diese Informationen von einer Vielzahl von Fahrzeugen gesammelt und zur Verfügung stehen. 8 zeigt schematisch einen Server 20, welcher von einer Fahrzeugflotte 800 Fehlerspeichereinträge und Klassierungen sammelt. Diese Informationen können verwendet werden, um Fehlerursachen zu bestimmen, wie es zuvor unter Bezugnahme auf die 2 bis 7 beschrieben wurde, oder um eine Prognose von Fehlerfällen in Fahrzeugen aufzustellen. Bei der Prognose kann eine Anfrage hinsichtlich der Fehlerwahrscheinlichkeiten eines Fahrzeugs an den Server gesendet werden. Unter Verwendung der Datenbasis kann der historische Kontext des speziellen Fahrzeugs mit der Datenbasis verglichen werden, um Fehlerfälle bei Fahrzeugen mit ähnlichem Verhalten zu bestimmen. Fehler in ähnlichen Fahrzeugen können beispielsweise unter Berücksichtigung der Laufleistung des Fahrzeugs, Symptomen des Fahrzeugs, welche von den Kunden beschrieben wurden, sowie Klassierungen bestimmt werden.
-
Das zuvor beschriebene Verfahren zur Bestimmung von Fehlerursachen ermöglicht eine erhöhte Erkennungsrate von Fehlerursachen sowie eine Online-Erkennung von Fehlerursachen, sodass der Verarbeitungsaufwand im Fahrzeug minimiert werden kann. Ferner kann eine minimale Menge an Daten übertragen werden, indem die Bestimmung der Fehlerursache sequenziell bzw. iterativ durchgeführt wird, wie es beispielsweise unter Bezugnahme auf 2 beschrieben wurde. Die Ergebnisse der Fehlerursachenbestimmung können für eine Vorsteuerung von Werkstätten verwendet werden, wie es beispielsweise unter Bezugnahme auf 5 anhand der Reparaturmuster beschrieben wurde. Ferner können durch die Prognose von Fehlerfällen Fehler vermieden werden, indem entsprechende Vorkehrungen im Rahmen einer Wartung durchgeführt werden oder Fehler durch Konfigurationsänderungen online repariert werden können.
-
Bezugszeichenliste
-
- 10
- Fahrzeug
- 11
- Verarbeitungsvorrichtung
- 12
- Übertragungsvorrichtung
- 13
- Ausgabeeinheit
- 14
- Motorsteuergerät
- 15
- Antriebsmotor
- 16
- Speichervorrichtung
- 17
- Fahrzeugbus
- 20
- Server
- 21
- Verarbeitungsvorrichtung
- 22
- Übertragungsvorrichtung
- 30
- Funkverbindung
- 40
- Kundendienstdatenbank
- 201
- Analyse Kundendienstdaten
- 202
- Analyse Fahrzeughistorie
- 203
- geführte Fehlersuche online
- 204
- Kommunikation an Kunden
- 205
- Callcenteranruf/Werkstatttermin
- 301
- Eingangsdaten
- 302
- Entscheider
- 800
- Fahrzeugflotte
