DE102005027378B3

DE102005027378B3 - Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose

Info

Publication number: DE102005027378B3
Application number: DE200510027378
Authority: DE
Inventors: Martin Dipl.-Ing. Konieczny; Harald Dipl.-Math. Renninger
Original assignee: DaimlerChrysler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2005-06-14
Filing date: 2005-06-14
Publication date: 2006-11-16
Anticipated expiration: 2025-06-15
Also published as: WO2006133865A1

Abstract

Die Erfindung betrifft ein Diagnosesystem, das zunächst durch Systemabfragen und durch Verarbeitung der abgefragten Systemmeldungen oder Systemzustände mit einem Diagnoseprogramm eine Fehlerkandidatenmenge erzeugt. Die Fehlerkandidaten in dieser Fehlerkandidatenmenge sind vorzugsweise bereits hinsichtlich Fehlerwahrscheinlichkeit priorisiert. Diese Priorisierung kann beim Aufbau eines Prüfschrittbaumes berücksichtigt werden und hilft, in dem jeweiligen fehlerhaften Systemzustand einen möglichst effizienten Prüfschrittbaum aufzubauen. Grundsätzlich ist die Priorisierung der Fehlerkandidaten jedoch nicht notwendig. Es können zum Beispiel auch alle Fehlerkandidaten der Fehlerkandidatenmenge die gleichen Fehlerwahrscheinlichkeiten aufweisen. Zu den ermittelten Fehlerkandidaten werden über die Prüfdomäne, in der die Relationen zwischen durchzuführenden Prüfungen und zu überprüfenden Fehlerkandidaten modelliert ist, die für die Überprüfung der Fehlerkandidaten relevanten Prüfungen per Computer ermittelt und mittels eines Programmmoduls für die Prüfschrittpriorisierung einer Bewertung unterzogen. Die Bewertung erfolgt hierbei mit einer Entscheidungsfunktion, die die einzelnen Prüfungen hinsichtlich ihres Informationsgehaltes für das aktuelle Diagnoseproblem in Form der aktuellen Fehlerkandidatenmenge bewertet.

Description

Werkstattdiagnose ist ein wichtiges Element im Lebenszyklus eines Fahrzeugs. Der Fahrzeugkunde erwartet eine schnelle und kostengünstige Abhilfe im Falle eines Defekts. Der Servicetechniker in der Werkstatt muss bei modernen Fahrzeugen bei dieser Aufgabe unterstützt werden. Dabei ist es nur noch mit Computerunterstützung möglich, die große Menge an anfallenden Informationen zu verarbeiten und den Prüfablauf effizient zu gestalten. Darüber hinaus muss ein Diagnosesystem echtzeitfähig und aus Entwicklungssicht handhabbar und pflegbar sein. Das erfindungsgemäße Diagnosesystem arbeitet mit einem Entscheidungsverfahren basierend auf Entropie- und Kostenbewertungen von Prüfungen, mit dem Ziel dem Servicetechniker zu jedem Zeitpunkt einer Diagnosesitzung optimale Prüfungen vorschlagen zu können. Die Prüfdomäne, die Relationen zwischen Prüfungen und zu prüfenden Komponenten kann mit einer regelbasierten Wissensbasis, einem mathematisch physikalischen Modell der Systemdiagnose oder mit Bayes Netzen modelliert werden und in ein ablauffähiges Computerprogramm compiliert werden. Der Schwerpunkt dieser Erfindung liegt hierbei bei der Ermittlung der Fehlerkandidaten und in der Konstruktion der Entscheidungsfunktion zur Prüfschrittauswahl.

Ein Beispiel für eine Systemdiagnose ist in der deutschen Patentanmeldung DE 195 23 483 A1 offenbart. Kennzeichen der Systemdiagnose ist das Abbilden des zu diagnostizierenden Systems in mindestens ein physikalisch-mathematisches Modell, das rechnergestützt implementiert und verarbeitet werden kann. In der DE 195 23 483 A1 umfasst die Modellbildung ein Strukturmodell und ein Wirkungsmodell, das oft auch als Verhaltensmodell bezeichnet wird. Mit dem Strukturmodell werden die physikalischen Zusammenhänge der einzelnen Komponenten des technischen Systems abgebildet und mit dem Verhaltensmodell werden die Funktionen der einzelnen Komponenten des Systems abgebildet. In einer Wissensbasis, die im Wesentlichen eine Regeltabelle aus Wenn/dann Konditionen, die sich wiederum auf Datentupel abbilden lassen, ist, ist das für die Systemdiagnose relevante Diagnosewissen abgespeichert. Mit der Systemdiagnose kann eine Fehlererkennung und durch Rückgriff auf die Wissensbasis eine rechnergestützte Fehlersuche durchgeführt werden.

Die Systemdiagnose hat zwei entscheidende Nachteile. Die Modellbildung ist für größere technische Systeme, wie z.B. ein Kraftfahrzeug äußerst aufwendig, wenn alle möglichen Fehlerursachen von dem System beherrscht werden sollen. Noch schwieriger zu handhaben sind in der Systemdiagnose mehrdeutige Systemzustände, wenn z.B. ein aufgenommener Fehlercode mehrere Ursachen haben kann, die mangels ausreichender Fehlerumgebungsdaten oder mangels ausreichender Informationen über den aktuellen Systemzustand, von der Systemdiagnose nicht weiter verarbeitet werden können. Die Systemdiagnose bricht dann an dieser Stelle ohne Diagnoseergebnis ab. Ein weiterer Nachteil der Systemdiagnose ist ihre prinzipielle Nichteignung für die Verarbeitung von Erfahrungswissen des Servicetechnikers. Ebenso wenig können Kundenangaben zu defekten Funktionen oder zu intakten Funktionen in den Diagnoseprozess einfließen.

Diagnosesysteme der vorgenannten Art haben den weiteren Nachteil, dass sie sehr schnell sehr komplex werden und der notwendige Modellierungsaufwand, Bedatungsaufwand und Berechnungsaufwand für größere technische Systeme exponentiell mit der Anzahl der Fehlermöglichkeiten der einzelnen Komponenten des Gesamtsystems zunimmt. Außerdem müssen für die Diagnose alle möglichen Prüfungen in einen statischen Prüfschrittbaum abgebildet werden. In der Realität ergibt sich bei Systemen mit mehreren von einander abhängigen Komponenten eine Unmenge von Möglichkeiten, in welcher Reihenfolge einzelne Teilprüfungen von einzelnen Komponenten durchgeführt werden können. Bei 5 Komponenten ergeben sich bereits theoretisch 5 Fakultät unterschiedliche Prüfabläufe, die alle durch einen statischen Prüfbaum abgebildet werden müssten. Die Effizienz der Diagnoseverfahren nimmt daher mit Anzahl der Fehlermöglichkeiten drastisch ab.

Man hat deshalb nach effizienteren Möglichkeiten gesucht, ein Diagnosesystem aufzubauen.

Eine Möglichkeit den Diagnoseablauf zu verbessern ist in der europäischen Patentschrift EP 1 069 487 B1 beschrieben. Parallel zum Reparaturfortschritt kann von einem Servicetechniker an entscheidenden Stellen des Prüfschrittbaumes gesichertes Wissen, so genannte Evidenz, abgefragt werden und in das Diagnosesystem eingerechnet werden. Damit müssen nicht mehr alle Fehlermöglichkeiten und Prüfmöglichkeiten berechnet werden. Das Diagnoseverfahren kann umso effizienter werden je mehr Abfragen an geeigneter Stelle des Diagnoseablaufs systemseitig vorgesehen sind. Die Eingabe des evidenten Wissens erfolgt über eine Benutzer Schnittstelle, die durch ein Display und ein Eingabemenü gebildet wird.

Wünschenswert für die Fehlersuche mit zukünftigen Diagnosesystemen in Werkstätten ist die Kosteneffizienz der durchzuführenden Prüfungen stärker zu berücksichtigen. Ein schneller und effizienter Prüfungsablauf ist somit eine wünschenswerte Vorgabe an diese zukünftigen Diagnosesysteme.

Man hat deshalb z.B. in der europäischen Patentschrift EP 0410632 B1 vorgeschlagen die Prüfungskosten bereits bei der Erstellung der Wissensbasis für das Diagnosesystem zu berücksichtigen. Es wird vorgeschlagen, zweistufig vorzugehen. Indem mit einem ersten modellbasierten Regelsatz das zu diagnostizierende technische System in eine mögliche erste Zerlegung aufgeteilt wird und für diese erste Zerlegung die Kostenberechnung einer Überprüfung durchgeführt wird. Dann werden weitere mögliche Zerlegungen des Systems berechnet und für jede Zerlegung wieder eine Kostenrechnung für eine Überprüfung des Systems durchgeführt. Die wirtschaftlichste Überprüfung des Systems soll wohl diejenige sein, dessen Zerlegung die geringsten Kosten ergibt. Liegt die günstigste Zerlegung des Systems fest, liegt zumindest prinzipiell auch ein Vorschlag für die Überprüfung des Systems, wenn man so will ein Prüfplan, fest.

Das vorgenannte System hat allerdings aus Sicht der hier vorliegenden Erfindung mehrere gravierende Nachteile:

– Es müssen stets mehrere mögliche Zerlegungen des technischen Systems berechnet und bewertet werden. Damit wird eine Feingliederung des technischen System oft nicht beherrschbar, da hier die Zerlegungsmöglichkeiten und insbesondere die damit verbundenen Kosten der Überprüfung sehr schnell sehr rechenintensiv werden und die Gefahr besteht das die Berechnungen NP-hard, also länger dauern als die Lebenserwatung eines Menschen ist, werden.
– Gelingt es eine bevorzugte Zerlegung mit den geringsten Prüfkosten zu berechnen, so muss der Techniker trotzdem stets das gesamte modellierte System überprüfen. Es wird zu keiner Zeit der Versuch gemacht einen Fehler zu bestimmen, zu identifizieren oder gar auf eine Komponente einzugrenzen.
– Es werden lediglich die statistischen Ausfallwahrscheinlichkeiten von Systembestandteilen berücksichtigt. Informationen über tatsächlich vorliegende Fehler oder Fehlfunktionen können mit dem System nicht verarbeitet werden.
– Das Design des Systems geht davon aus, dass die Zerlegung stets so erfolgen kann und auch erfolgt, dass die einzelnen Komponenten der Zerlegung keinen Einfluss auf den Fehlerzustand der mit Ihnen verbundenen Komponenten hätte. Anders gesagt, es wird vorausgesetzt dass die Zerlegungen hinsichtlich des Fehlerzustandes des Systems gleichwertig sind. Dies ist jedoch eine Annahme, die nur auf wenige Systeme, vielleicht Telefonnetze, zutrifft. Bei den meisten vernetzten Systemen verursacht der Ausfall einer Komponente auch Fehlfunktionen in den übrigen Bestandteilen des Systems. Bei Systemen, die nicht nur statistische Ausfallwahrscheinlichkeiten berücksichtigen, sondern auch festgestellte Fehlermeldungen verarbeiten, ist der Ansatz der gleichwertigen Zerlegungen nicht kompatibel.
– Es bleibt völlig unklar, welche Systeme sich überhaupt sinnvoll in verschiedene Zerlegungen zerlegen lassen. Bei fast allen, vernetzten Systemen gibt es nur eine tatsächliche Vernetzung, bei der auch der Fehler gefunden werden muss und es bleibt unklar inwieweit eine rechnerisch mögliche, abweichende Zerlegung hier eine belastbare Aussage liefern kann, die einen nachvollziehbaren Vorteil oder Erkenntnisgewinn liefert.

Bei allen möglichen Zerlegungen bleibt die Fehlersuche und Fehlerlokalisation dem Servicetechniker überlassen und der Servicetechniker erhält auch keine Hinweise, wie er die Fehlersuche am effektivsten durchführt. Kostenabschätzungen sind keine Effektivitätsaussagen.

In der nach veröffentlichten DE 10 2004 024 262 A1 wurde zum ersten Mal darüber nachgedacht, nicht nur einen Fehlerbaum aufzubauen, sondern parallel zu dem Fehlerbaum und während die Fehlerhypothesen abgearbeitet werden, auch mit dem Diagnosefortschritt einen dynamischen Prüfschrittbaum dem Fortgang der Diagnosesitzung anzupassen. Insofern ist das nach veröffentlichte Dokument ein Beleg für die der Erfindung zugrunde liegenden Diagnosesysteme. Allerdings kann die Neuheit der hier zu beurteilenden Erfindung hierdurch nicht in Frage gestellt werden, da die Merkmale des Kennzeichens von Anspruch 1 nicht in dem nachveröffentlichten Dokument enthalten sind.

In einer älteren, nachveröffentlichten Anmeldung der Anmelderin beim Deutschen Patent und Markenamt mit dem amtlichen Aktenzeichen DE 102005015664.9 ist ein selbstständiges Diagnosesystem beschrieben, das mit der hier beschriebenen Erfindung weiterentwickelt wird. Der Offenbarungsgehalt dieser älteren Anmeldung wird ausdrücklich per Referenz mit seinem ganzen Umfang in den Offenbarungsgehalt der hier beschriebenen Erfindung integriert. Diese ältere Anmeldung der Anmelderin enthält hauptsächlich ein interaktiv arbeitendes Diagnoseprogramm, bei dem der Servicetechniker, innerhalb eines von dem Diagnoseprogramm zunächst aufgespannten Fehlersuchraumes der als möglicherweise defekt identifizierten Komponenten oder Funktionen, einen Fokus für die weitere, automatisierte Fehlersuche durch das Diagnoseprogramm setzen kann. Das Setzen des Fokus kann hierbei durch Einschränkung auf einen Fehlercode oder durch Einschränkung auf eine Funktion erfolgen. Nach Setzen des Fokus wird eine eingeschränkte Fokusmenge, der zu dem gewählten Fokus möglichen Fehlerkandidaten ausgewählt. Die einzelnen Fehlerkandidaten erfahren hierbei, – durch Verrechnung von verschiedenen Wahrscheinlichkeiten für das Auftreten eines Fehlercodes, für die Ausfallwahrscheinlichkeit einer Komponente oder einer Funktion und gegebenenfalls für das Vorliegen eines Fehlerbildes –, eine Gewichtung.

In einer vorteilhaften Ausführungsform des älteren Diagnosesystems verfügt das Diagnosesystem über die zusätzliche Möglichkeit Fehlerbilder zu verarbeiten. Fehlerbilder sind hierbei Kombinationen mehrerer Fehlercodes, die spezifisch sind für den Ausfall einer bestimmten Komponente und so einen direkten Hinweis auf die defekte Komponente liefern können. Die Fehlerbilder können hierbei aus einer Kombination von aktiven und nicht aktiven Fehlercodes gebildet werden. Hierbei können die nicht aktiven Fehlercodes besonders wertvolle Hinweise auf nicht defekte Komponenten liefern und so die Menge der möglichen Fehlerkandidaten einschränken.

In einer weiteren vorteilhaften Ausführungsform des älteren Diagnosesystem kann, wenn die Überprüfung der Fehlerkandidaten in der Fokusmenge ergeben hat, dass keine der untersuchten Komponenten defekt war, ein neuer Fokus durch den Servicetechniker gesetzt werden und damit eine neue Fokusmenge mit gewichteten Fehlerkandidaten erzeugt werden.

Zusammenfassend lässt sich somit festhalten, dass es zwar Diagnosesysteme mit Fehlerlokalisation gibt, und dass es Überlegungen zu kostenoptimierten Prüfabläufen bei Diagnosesystemen ohne Fehlerlokalisation gibt. Jedoch gibt es bisher keine Diagnosesysteme die den Servicetechniker dahingehend unterstützen, die notwendigen Überprüfungen nach dem Gesichtpunkt der Effektivität durchzuführen.

Es stellt sich somit die erfindungsgemäße Aufgabe für eine Menge bereits gewichteter und identifizierter Fehlerkandidaten eine Prüfschrittabfolge aufzustellen, mit der die vorausgewählten Fehlerkandidaten möglichst effektiv untersucht werden können.

Die Lösung gelingt hauptsächlich mit einem Diagnosesystem, das zunächst durch Systemabfragen und durch Verarbeitung der abgefragten Systemmeldungen oder Systemzustände mit einem Diagnoseprogramm eine Fehlerkandidatenmenge erzeugt. Die Fehlerkandidaten in dieser Fehlerkandidatenmenge sind bereits hinsichtlich Fehlerwahrscheinlichkeit priorisiert. Diese Priorisierung kann beim Aufbau eines Prüfschrittbaumes berücksichtigt werden und hilft in dem jeweiligen fehlerhaften Systemzustand einen möglichst effizienten Prüfschrittbaum aufzubauen. Grundsätzlich ist die Priorisierung der Fehlerkandidaten jedoch nicht notwendig. Es können zum Beispiel auch alle Fehlerkandidaten der Fehlerkandidatenmenge die gleiche Fehlerwahrscheinlichkeiten aufweisen. Zu den ermittelten Fehlerkandidaten werden über die Prüfdomäne, in der die Relationen zwischen durchzuführenden Prüfungen und zu überprüfenden Fehlerkandidaten modelliert ist, die für die Überprüfung der Fehlerkandidaten relevanten Prüfungen per Computer ermittelt und mittels eines Programmmoduls für die Prüfschrittpriorisierung einer Bewertung unterzogen. Die Bewertung erfolgt hierbei mit einer Entscheidungsfunktion, die die einzelnen Prüfungen hinsichtlich ihres Informationsgehaltes für das aktuelle Diagnoseproblem in Form der aktuellen Fehlerkandidatenmenge bewertet.

In einer vorteilhaften Ausführungsform der Entscheidungsfunktion enthält die Entscheidungsfunktion zusätzlich zur Bewertung des Informationsgehalts der einzelnen Prüfungen noch eine Kostenbewertung der einzelnen Prüfungen. Vorteilhafterweise können die beiden Bewertungen zu einer Bewertung hinsichtlich Effizienz der durchzuführenden Prüfung zusammengefasst sein. Die Effizienz der Prüfung bestimmt sich dann aus dem Quotienten aus Informationsgehalt und der Kosten für die Durchführung der einzelnen Prüfung.

In einer bevorzugten Ausführungsform der Entscheidungsfunktion und damit der Prüfschrittpriorisierung enthält die Entscheidungsfunktion eine Bewertung und Auswahl der Prüfschritte hinsichtlich der noch zu erwartenden Kosten der weiteren Diagnose, den hier sogenannten Expected Costs of Diagnosis.

In einer weiteren Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung wird die Prüfdomäne durch ein Bayes Netz modelliert.

In einer anderen Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung wird die Prüfdomäne mit einer regelbasierten Wissensbasis modelliert.

In einer weiteren Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung wird die Prüfdomäne mit einem mathematisch physikalischen Modell des technischen Systems modelliert.

In einer weiteren vorteilhaften Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung erfolgt das Aufspannen des Prüfschrittbaumes automatisch und dynamisch. Automatisch bedeutet hierbei, dass nach der Prüfschrittpriorisierung die durchzuführenden Prüfungen dem Servicetechniker von dem Diagnosesystem angezeigt werden, ohne dass der Servicetechniker die Prüfungen noch heraussuchen müsste. Das dynamische Aufspannen meint hauptsächlich zwei Aspekte. Zum anderen erfolgt die Prüfschrittpriorisierung dynamisch mit der Anzahl der aktuell verdächtigen Fehlerkandidaten und zum zweiten dynamisch mit der Anzahl der bereits durchgeführten und vorgeschlagenen Prüfungen. Hierzu hat das Diagnosesystem eine Feedbackmöglichkeit, mit der der Servicetechniker das Ergebnis der durchgeführten Prüfungen als Evidenz in das Diagnosesystem eingeben kann. Nach Eingabe einer Evidenz wird vom Diagnosesystem die Fehlerkandidatenmenge aktualisiert, falls ein Fehlerkandidat gefunden wurde, und von der Prüfschrittpriorisierung werden die bereits verbrauchten Prüfungen gestrichen. Prüfschrittpriorisierung und Diagnosesystem können so dynamisch an den Fortschritt der Diagnosesitzung nachgeführt werden. Wird nur ein einziger Fehlerkandidat gefunden, endet die Suche und eine Priorisierung erübrigt sich.

In einer vorteilhaften Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung, startet die Prüfschrittpriorisierung mit einer priorisierten Fehlerkandidatenliste, die von einem Diagnosesystem bei einem Diagnoselauf als fehlerhaft verdächtigte Komponenten ermittelt und hinsichtlich ihrer Fehlerwahrscheinlichkeiten priorisiert wurde.

In einer weniger bevorzugten Basisstufe der erfindungsgemäßen Prüfschrittpriorisierung, startet die Prüfschrittpriorisierung mit einer ungewichteten Fehlerkandidatenlist. Diese Basisstufe hat den Vorteil, dass auch handelsübliche Diagnosesysteme, wie sie z.B. im Zusammenhang mit dem vorbekannten Stand der Technik in 1 diskutiert wurden, für die Ermittlung der Fehlerkandidaten eingesetzt werden können.

Im Folgenden werden Einzelheiten der Erfindung an Hand von graphischen Darstellungen näher erläutert. Dabei zeigen:
1 Ein typisches Werkstattdiagnosesystem aus dem Stand der Technik;
2 Ein Blockschaltbild eines Diagnosesystems, wie es in der älteren, deutschen Patentanmeldung DE 102005015664.9 beschrieben ist, und das hier als bevorzugtes Diagnosesystem mit der Prüfschrittpriorisierung weiterentwickelt wird;
3 Eine Prinzipskizze der erfindungsgemäßen Prüfschrittpriorisierung;
4 Ein Basisverfahren für die erfindungsgemäße Prüfschrittpriorisierung;
5 Einen Prüfschrittbaum der erfindungsgemäßen Prüfschrittpriorisierung;
In 1 ist eine Situation schematisch dargestellt, wie sie heute in Kraftfahrzeugwerkstätten bekannt ist. Für die Diagnose eines Kraftfahrzeuges wird ein rechnergestützter Diagnosetester 1 über eine genormte Diagnoseschnittstelle 2 an das Kommunikationsnetzwerk 3 für die Steuergeräte 4 im Kraftfahrzeug angeschlossen. Bekannte Diagnosetester sind z. B. das System DAS von DaimlerChrysler oder das System BMWDIS. Die im Kraftfahrzeug verbauten Steuergeräte 4 sind beispielsweise über einen Datenbus miteinander in Kommunikationsverbindung. Ein verbreiteter Datenbus in Kraftfahrzeugen ist hierbei der sog. CAN-Bus (für Control Area Network). Jedes der verbauten Steuergeräte im Kraftfahrzeug verfügt neben den Kommunikationsschnittstellen über die Fähigkeit zur Eigendiagnose. Im Rahmen der Eigendiagnose der Steuergeräte werden mit Hilfe der Diagnoseroutine in den Steuergeräten festgestellte Fehler in kodifizierter Form als sog. Fehlercodes von der Steuergeräte-Software in speziell reservierte Speicherbereiche, sog. Fehlerspeicher, geschrieben. In der schematischen Darstellung der 1 sind diese reservierten, nicht flüchtigen Speicherbereiche als FS (für Fehler-Speicher) bezeichnet. Für die Kommunikation und für den Datenaustausch zwischen einem Diagnosetester und den im Kraftfahrzeug verbauten Steuergeräten hat sich ein Standard etabliert, der unter dem Namen Keyword-Protokoll 2000 bekannt ist und dessen Spezifizierung und Normierung sich in der ISO-Norm 14 230-3 wiederfindet. Mit den im Keyword-Protokoll 2000 verabredeten Steuerbefehlen und Datenformaten ist es möglich, über die Diagnoseschnittstelle die kodifizierten Inhalte der Fehlerspeicher der einzelnen Steuergeräte mit Hilfe des Diagnosetesters auszulesen und in das Rechensystem des Diagnosetesters zu übertragen. Die Norm zu dem Keyword-Protokoll 2000 umfasst hierbei zwei verschiedene Applikationsmöglichkeiten. Zum einen sieht die Norm vor, dass die Kommunikation zwischen Diagnosetester und Steuergeräte über ein Gateway 5, das z. B. den Kraftfahrzeug-CAN-Bus an die Diagnoseschnittstelle 2 anbindet, erfolgt oder aber, dass wie früher üblich, die Fehlerspeicher der Steuergeräte über die sog. K- und L-Leitungen und über die normierte Diagnoseschnittstelle 2 direkt in den Diagnosetester ausgelesen und abgelegt werden können. In der schematischen Darstellung der 1 ist die modernere Form des Zugriffs über einen CAN-Bus und damit über ein Gateway dargestellt. Für die Erfindung von Belang ist lediglich, dass es mindestens eine Möglichkeit gibt, die Fehlerspeicher der Steuergeräte mit einem Diagnosetester auslesen zu können. Im Diagnosetester werden die übertragenen Inhalte der Steuergerätespeicher insbesondere Fehlercodes und Zustandsdaten der Steuergeräte mit einem implementierten Diagnoseprogramm in einer Diagnosesitzung weiterverarbeitet.
Das Diagnoseprogramm umfasst weiterhin die Möglichkeit über einen Bildschirmarbeitsplatz als Mensch-Maschine-Schnittstelle manuell weitere Informationen, die für eine Diagnose wichtig sind einzugeben.
2 zeigt als Blockschaltbild die wichtigsten Programmmodule und mit diesen Programmmodulen realisierten Funktionen eines erfindungsgemäßen Diagnosesystems. Die einzelnen Programmmodule sind hierbei in eine übergeordnete Ablaufsteuerung des gesamten Diagnosesystems integriert. Diese Ablaufsteuerung übernimmt den Aufruf der einzelnen Programmmodule zum jeweils notwendigen Zeitpunkt. Als Eingangsgrößen werden von dem Diagnosesystem Fehlercodes FC und Eingaben durch einen Servicetechniker verarbeitet. Der Service Techniker macht seine Eingaben von einem Bildschirmarbeitsplatz 200, der typischer Weise mit einem Bildschirm und einer Computertastatur ausgestattet ist, die jeweils an das Computersystem 201 des Diagnosesystems angeschlossen sind. Über eine weitere Schnittstelle 202 ist das Computersystem an das zu diagnostizierende Kraftfahrzeug anschließbar. Über die OBD Steckdose (On Board Diagnosis) können die im Kraftfahrzeug enthaltenden Steuergeräte angesprochen werden. Es können dadurch die Fehlerspeicher der Steuergeräte ausgelesen werden, es können die Eigendiagnoseroutinen der Steuergeräte gestartet werden und dadurch Funktionstests der einzelnen Steuergeräte gestartet werden und es können aktuelle Systemzustandsdaten aus dem Kraftfahrzeug abgerufen und ausgelesen werden. Eine Möglichkeit der technischen Realisierung wurde im Zusammenhang mit 1 erörtert.
Die Verarbeitung der Systemdaten und der Ablauf des Diagnoseprogramms weichen jedoch bei der Erfindung entscheidend vom vorbekannten Stand der Technik ab. Die wichtigsten Unterschiede sind hierbei der interaktive Ablauf des Diagnoseprogramms und die damit verbundene Möglichkeit gezielte Diagnoseschwerpunkte zu bilden, in dem für die Fehlersuche ein oder mehrere Schwerpunkte, im Folgenden Fokusse genannt, gesetzt werden können, und damit sowohl die Diagnosequalität als auch die Diagnosedauer verbessert werden können. Auf die programmtechnische Realisierung wird im Folgenden näher eingegangen:
Das auf dem Computersystem implementierte Diagnoseprogramm zeichnet sich unter anderem durch einen modularen Aufbau aus. Hierdurch werden unter anderem die Programmierung und die Bedatung des Diagnosesystems strukturiert. Mit einem ersten Programmmodul 210, entsprechend seiner Funktion genannt Regeltabellenauswertung, werden die aus dem Kraftfahrzeug abgerufenen Daten, wie Fehlercodes und Systemstatusdaten zu den einzelnen im Kraftfahrzeug verbauten Komponenten, eingelesen und weiterverarbeitet. Die Weiterverarbeitung beinhaltet ein Überprüfen von in einer Wissensbasis 211 abgespeicherten Regeltabellen. Die Regeltabellen beinhalten das für das zu diagnostizierende, technische System relevante Diagnosewissen. Dieses Wissen ist beispielsweise in komprimierter Form in Datentupeln abgelegt. Die Datentupel bilden hierbei die Zusammenhänge der in ihnen enthaltenen Informationen ab. Pro Diagnoseregel ist ein Datentupel abgelegt. Ein Datentupel besteht jeweils aus einer Komponentenkennung Ki, einem Fehlercode FCi, einem Symptom Sympi als Hinweis für eine betroffene technische Funktion, und einem Systemstatus Stat. Die Regeltabellenauswertung erfolgt dann derart, das in der Gesamtheit aller abgelegten Datentupel nachgesehen wird, welche Datentupel den oder diejenigen eingelesenen Fehlercodes enthalten und welche Komponenten Ki und Funktionen Sympi in den identifizierten Datentupeln genannt sind und damit von dem beobachteten Fehler FCi betroffen sein können. Die derart aufgefundenen Komponentenkennungen, werden festgehalten und zu einer ersten Fehlerkandidatenmenge zusammengefasst und abgespeichert. Diese Komponentenkennungen Ki geben einen Hinweis, welche Komponente oder auch welche Funktion des technischen Systems für den beobachteten Fehlercode oder für das beobachtete Fehlersymptom ursächlich sein kann. Ergebnis dieses ersten Durchforsten der Wissensbasis ist eine erste Menge verdächtiger Komponenten, die aufgrund der Identifikation über die Fehlercodes FCi ermittelt wurden.
In einem weiteren Verarbeitungsschritt bzw. Programmmodul 213 wird der durch die erste Kandidatenmenge gebildete Fehlersuchraum weiter auf gespannt. In einem zweiten Durchlauf durch die Wissensbasis werden nun die möglichen Fehlerquellen durch die relevanten Funktionen, die im Kraftfahrzeug betroffen sein können, erweitert. Hierzu werden die Regeltabellen nochmals durchsucht, diesmal jedoch nicht nach festgestellten Fehlercodes, sondern nach den bereits über die Fehlercodes möglicherweise betroffenen Komponenten Ki. Zu den Komponenten werden die möglicherweise betroffenen Funktionen Sympi bestimmt. Diese beiden Mengen müssen nicht identisch sein. Denn es ist möglich, dass ein Fehlercode auf eine Komponente verweist, die für mehrere Funktionen relevant ist. Ergebnis dieses zweiten Durchlaufs durch die Wissensbasis ist eine ergänzte Kandidatenliste 214, die nun neben den möglicherweise fehlerhaften Komponenten auch die möglicherweise fehlerhaften Funktionen enthält.
An dieser Stelle angekommen, beginnt nun die Interaktionsmöglichkeit in den weiteren Ablauf des Diagnoseprogramms. Zunächst wird auf dem Bildschirmarbeitsplatz 200 eine Abfrage 215 durchgeführt und angezeigt, ob für die weitere Verarbeitung die bereits ermittelten Fehlercodes oder die ermittelten möglicherweise betroffenen Funktionen angezeigt werden sollen. In beiden Fällen wird in einem weiteren Verfahrensschritt 216 dem Servicetechniker die Möglichkeit geboten, für den weiteren Diagnoseablauf einen Fokus zu setzen. Das Setzen des Fokus erfolgt hierbei je nach ausgewählter Anzeige, indem entweder ein angezeigter Fehlercode oder eine angezeigte, verdächtige Funktion Sympi per graphischer Menüsteuerung ausgewählt wird, und der weiteren Verarbeitung durch das Diagnoseprogramm zugrunde gelegt wird. Ist der Fokus gesetzt, wird die weitere Datenverarbeitung auf diesen Fokus beschränkt. D.h. es werden nicht mehr alle bereits ermittelten Fehlercodes, verdächtige Kandidaten oder verdächtige Funktionen betrachtet, sondern nur noch diejenigen, die unter den gewählten Fokus fallen.
Für die noch innerhalb des Fokus verdächtigen Komponenten Ki werden die einzelnen Fehlerkandidaten in einem weiteren Programmmodul bzw. Verfahrensschritt 217 einer Gewichtung unterzogen.
Für die Gewichtung müssen die Wahrscheinlichkeiten der Fehlercodes FCi, die Wahrscheinlichkeit für das Auftreten von Sympi und ggf. die Wahrscheinlichkeit für das Vorliegen von Fehlerbildern errechnet werden. Dazu müssen Wahrscheinlichkeiten bedatet sein, die angeben, mit welcher Sicherheit eine defekte Komponente bzw. ein Kandidat Ki einen Fehlercode (P(FCi|Kj)), eine Fehlfunktion (P(Sympi|Kj)) oder ein Fehlerbild (P(FBi|Kj)), verursachen. Außerdem wird die relative Fehlergewichtung g(Kj) einer Komponente selbst benötigt. Diese Informationen werden für die Berechnung der priorisierten, bzw. gewichteten Kandidatenliste benötigt. Die bedingten Wahrscheinlichkeiten lassen sich leicht schätzen. Meist sind sie auf „1" gesetzt. Unsichere Symptome oder Fehlercodes können aber mitunter Werte kleiner 1 annehmen.
Die Fehlergewichte g(Kj) können aus Erfahrungswissen z.B. zwischen eins und hundert gewählt werden und stellen eine relative Ausfallkenngröße dar. In einer unten erläuterten vorteilhaften Ausführung kann auch über diese Fehlergewichte g(Kj) das aktuelle Feldgeschehen berücksichtigt werden, indem diese Gewichte über Verrechnung von Fehlerhäufigkeiten adaptiert werden.
Alle Wahrscheinlichkeiten und Fehlergewichte werden bei der Bedatung des Diagnosesystems in einer Datenbank 218 abgelegt. Zweckmäßiger Weise können diese zusammen mit der Komponentenliste, der Funktionen- oder Symptomliste und der Fehlerbildliste abgelegt und bedatet werden. Diese Listen werden bei der Konstruktion eines Kraftfahrzeuges erstellt und brauchen daher nur um das Erfahrungswissen hinsichtlich der bedingten Wahrscheinlichkeiten und der Fehlergewichte ergänzt werden. Zweckmäßigerweise erfolgt die Bedatung baureihenspezifisch. Es können jedoch auch Baureihen übergreifende Datenbanken erstellt und herangezogen werden. Bei Baureihen übergreifenden Datenbanken muss dann jedoch die Möglichkeit einer Baureihen spezifischen Auswahl, z.B. in Form einer vorgeschalteten Mastertabelle vorgehalten werden.
Aus den oben erläuterten Daten berechnen sich die Einzelgrößen wie folgt:
Die drei errechneten Größen werden zur Erstellung der Kandidatenpriorisierung, weiter unten, benötigt.
G ist eine Normierungsgröße und wird in einem Vorbereitungsschritt oder per Bedatung z.B. als Summe aller Gewichte g(Kj) festgelegt.
Nachdem die Wahrscheinlichkeiten der Fehlercodes P(FCi), der Fehlerbilder P(FBi) und der Fehlfunktionen P(Sympi) errechnet wurden und die Fokusmenge der Fehlerkandidaten feststeht, kann die Berechnung einer priorisierten bzw. gewichteten Kandidatenliste 219 angestoßen werden und schließlich auf dem Display des Bildschirmarbeitsplatzes 200 ausgegeben werden.
Die a posteriori Fehlerwahrscheinlichkeit oder Priorität Prio(Ki) einer Komponente Ki ergibt sich aus dem folgenden Produkt:
Wobei gilt: P(FCi|K) = P(FCi) falls der Fehlercode FCi von einer Komponente K unabhängig ist und analog dazu P(Sympk|Ki) = P(Sympk) und P(FBl|Ki) = P(FBl) bei Unabhängigkeit von der jeweiligen Komponente.
Diese Priorität ist noch unnormiert und kann alternativ noch normiert werden indem durch die Summe aller Kandidatenprioritäten geteilt wird.
Das oben erläuterte Diagnosesystem, das zum Offenbarungsgehalt der hier beschriebenen Erfindung gehört, liefert eine priorisierte Kandidatenliste, und ist das bevorzugte Diagnosesystem, mit dem die Prüfschrittpriorisierung durchgeführt werden kann.
Prinzipiell kann die erfindungsgemäße Prüfschrittpriorisierung jedoch mit jedem Diagnosesystem, das als Diagnoseergebnis eine Fehlerkandidatenmenge liefert, durchgeführt werden.
Der letzte Schritt in der Werkstattdiagnose sind Komponentenprüfungen oder funktionale Tests, mit dem Ziel der vollständigen Fehlereingrenzung zur schnellstmöglichen Abhilfe. Bis zu diesem Zeitpunkt werden alle verfügbaren Informationen, wie Fahrzeugeigendiagnosen oder die Kundenbeanstandungen weitgehend automatisiert ausgewertet. Der letzte Schritt, das Prüfen am Fahrzeug, ist aber meist kosten- und zeitintensiv. Ziel ist es daher diese Fahrzeugprüfungen kostenoptimal zu gestalten, indem Fahrzeugprüfungen in Form eines optimierten Prüfbaumes bzw. Entscheidungsbaumes dem Servicetechniker von seinem Werkstattdiagnosesystem vorgeschlagen werden. Der Schwerpunkt der hier beschriebenen erfindungsgemäßen Prüfschrittpriorisierung liegt hierbei in der Erstellung einer optimierten Prüfungsreihenfolge. Die Prüfschrittpriorisierung 220, geht dabei von einer Fehlerkandidatenmenge aus, deren Fehlerkandidaten bereits in einer Vorstufe identifiziert und benannt wurden. Diese Situation verdeutlicht das Blockdiagramm der 3. Aus Fehlercodes 310 und identifizierten Fehlfunktionen oder Fehlersymptomen 320 wird von einem Diagnosesystem in einer Basisversion eine nicht priorisierte Fehlerkandidatenmenge 330 ermittelt. In bevorzugten Ausführungsformen wird von einem Diagnosesystem eine gewichtete Kandidatenliste 340 ermittelt. In jedem Fall wird von dem Softwaremodul 350 der Prüfschrittpriorisierung 220 zu den ermittelten Fehlerkandidaten die in einer Wissensbasis oder in einer Datenbank 360 abgelegten, relevanten Prüfungen, zu Überprüfung der einzelnen verdächtigen Kandidaten ermittelt.
Stehen alle relevanten Prüfungen fest, werden die Einzelprüfungen von der Prüfschrittpriorisierung hinsichtlich Informationsgehalt und/oder Kosten bewertet, priorisiert und in eine Prüfschrittreihenfolge gebracht. Die Priorisierung der Prüfschritte kann hierbei rekursiv und dynamisch an den Fortschritt der Diagnosesitzung nachgeführt werden, indem bereits durchgeführte Prüfungen vom Servicetechniker in das System eingegeben werden und die verbrauchten Prüfungen aus der Prüfschrittreihenfolge gelöscht werden. Der Verbrauch einer vorgeschlagenen Prüfung führt in der Regel zu einer neuen Priorisierung einer gewichteten Prüfschrittliste 370, die jeweils aktuell an den Stand der Diagnosesitzung nachgeführt ist.
Für ein Fahrzeug sind in der Regel viele hundert Prüfungen definiert und z.B. in einer Datenbank hinterlegt. Zum Glück müssen während einer Diagnosesitzung nicht alle Prüfungen bewertet werden, sondern nur die für das aktuelle Problem relevanten. Nach Auswertung aller Fahrzeug- und Kundeninformationen wird von dem Diagnosesystem in einer ersten Stufe eine Liste der verdächtigen Komponenten, die Fehlerkandidatenmenge erstellt. Nun können von dem Diagnoseprogramm diejenigen Prüfungen aus einer Prüfschrittdatenbank ausgewählt werden, die für die Überprüfung der verdächtigen Komponenten relevant sind. D.h. diejenigen Prüfungen, die mindestens einen Verweis auf die verdächtigen Komponenten haben. Die Menge aller in der Datenbank abgespeicherten Prüfungen sei PS. Die relevanten Prüfungen seien ps Element von PS. Die grundsätzliche Leitfrage zur Ermittlung der besten Prüfung zum aktuellen Zeitpunkt ist erfindungsgemäß: Wie gut hilft die Prüfung ps im aktuellen Diagnoseproblem, das aus einer Fehlerkandidatenmenge besteht, weiter? Erfindungsgemäß wird hierzu eine von einem Diagnoseprogramm verarbeitbare Entscheidungsfunktion vorgeschlagen, die die relevanten Prüfungen hinsichtlich ihres jeweiligen Informationsgehalt für das jeweilige Diagnoseproblem bewertet, oder die die relevanten Prüfungen für das jeweilige Diagnoseproblem hinsichtlich der jeweiligen Kosten für das Durchführen der Prüfung bewertet, oder die die für das jeweilige Diagnoseproblem relevanten Prüfungen hinsichtlich Effizienz bewertet, wobei die Effizienz durch den Quotienten aus Informationsgehalt und Kosten gebildet wird.
Der Informationsgehalt eines Prüfschrittes lässt sich z.B. aus seiner Entropie Ent ermitteln. Die Effizienz Eff ist dann das Verhältnis des Informationsgehaltes eines Prüfschrittes ps zu seinen Kosten: Eff(ps): = Ent(ps)/costs(ps)
Dabei wird unter der Entropie eines Prüfschrittes folgende Wahrscheinlichkeitssumme verstanden:
wobei

Zi: die möglichen Prüfungsausgänge des Prüfungsschrittes ps, z.B. in Ordnung oder nicht in Ordnung; und
p(ps = zi): die Wahrscheinlichkeit für das Prüfungsergebnis zi sind.

Damit wird der Informationsgehalt eines Prüfschrittes dann am größten, wenn seine Entropie am größten wird. Die Entropie wird am größten, wenn ein Prüfschritt viele Ausgänge, d.h. viele mögliche Prüfergebnisse, hat und wenn die einzelnen Prüfergebnisse einen möglichst ungewissen Ausgang haben. Dies entspricht der Tatsache, dass ich mit derjenigen Prüfung am meisten Informationen gewinne, die gleichzeitig möglichst viele Fehlerkandidaten abprüft und von der ich am wenigsten weiß, wie die Prüfung ausgeht. Umgekehrt hat diejenige Prüfung den geringsten Informationsgehalt, die nur wenige Ausgänge hat und von der ich das Ergebnis mit großer Sicherheit schon weiß.
In einem bevorzugten Ausführungsbeispiel der Prüfschrittpriorisierung wird die Entscheidungsfunktion zur Prüfschrittauswahl durch die zu erwartenden Kosten der nach dem ausgewählten Prüfschritt jeweils verbleibenden Prüfschritte für den jeweiligen Rest der voraussichtlichen Diagnosesitzung gebildet. Dadurch werden die Entscheidungsfunktionen der beiden bereits besprochenen Entscheidungsfunktionen hinsichtlich Entropie und Effizienz durch eine verfeinerte und erweiterte Entscheidungsfunktion ersetzt, die hier als Expected Costs of Diagnosis (ECD) bezeichnet wird. Diese Entscheidungsfunktion enthält ebenfalls das Entropie Kriterium, das jedoch durch eine verfeinerte und erweiterte Kostenbetrachtung und Kostenschätzung ergänzt wird. Die verfeinerte und erweiterte Kostenschätzung berechnet bei jedem aktuellen Prüfschritt die voraussichtlichen Kosten für die noch verbleibende Prüfung, d.h. welche Kosten noch zu erwarten sind, nach dem eine vorhergehende Prüfung bereits durchgeführt wurde. Die Bezeichnung der Entscheidungsfunktion als ECD (Extended Cost of Diagnosis) ist an die Bezeichnung ECR, den Extended Cost of Repair angelehnt, die in der wissenschaftlichen Literatur gelegentlich benutzt wird.
Die bevorzugte Entscheidungsfunktion wird gebildet:
wobei j ein Laufindex und n die Anzahl der nach dem aktuellen Prüfschritt ps noch verbleibenden Prüfungen ist.
Für jede relevante Prüfung ps wird über deren mögliche Prüfungsausgänge (= exits)summiert. Der Summand besteht aus einer Kostenschätzung in den eckigen Klammern EstCosts, die mit der Eintrittswahrscheinlichkeit des betreffenden Prüfungsausgangs P(PS = exit j) multipliziert wird. In der Kostenschätzung werden zum Kostenwert der aktuellen Prüfung ps noch die geschätzten weiteren Kosten addiert. Diese Kosten werden wie folgt geschätzt:
mit p°= p(Diag = Ki/ps = exit j)
Damit bestehen die geschätzten Kosten EstCosts aus der Entropie des verbleibenden Diagnoseproblems, multipliziert mit den durchschnittlichen Prüfkosten AvCosts. Die letzteren sind das arithmetische Mittel der Kosten aller verbleibenden Prüfungen.
Der jeweils anstehende, auszuwählende Prüfschritt wird dann aus den möglichen Prüfschritten ausgewählt, indem jeweils derjenige Prüfschritt ausgewählt wird, der die Expected Costs of Diagnosis der jeweils verbleibenden Diagnosesitzung minimiert.
Die in den Entscheidungsfunktionen benötigten Wahrscheinlichkeiten p(ps) und die daraus abgeleiteten Größen der jeweils relevanten Prüfschritte ps werden aus der Priorisierung der Fehlerkandidatenliste berechnet. Zu den ermittelten Fehlerkandidaten Ki werden die relevanten Prüfschritte ermittelt.
Der Prüfschritt ps prüfe gleichzeitig zwei Kandidaten K1 und K2, wobei der Prüfschritt das Ergebnis „nicht in Ordnung" (niO) hat, wenn einer der beiden Kandidaten sich als fehlerhaft erweist, und das Ergebnis „in Ordnung hat" (iO), wenn beide Kandidaten das Prüfergebnis fehlerfrei liefern. Der wahrscheinliche Prüfungsausgang der relevanten Prüfschritte ergibt sich dann aus den Fehlerkandidatenwahrscheinlichkeiten wie folgt: p(ps = niO) = (p(K1 = iO) + p(K2 = niO))/Normierung p(ps = iO) = (p(K1 = iO) + p(K2 = iO))/Normierung = 1 – p(ps=niO)wobei die Fehlerwahrscheinlichkeiten p(Ki) für die Kandidaten Ki aus der gewichteten Fehlerkandidatenliste genommen werden.
Ein weiteres Kriterium für eine Prüfschrittpriorisierung sind die Kosten für einen durchzuführenden Prüfschritt. Diese Kosten sind als Erfahrungswerte z.B. als so genannte Arbeitswerte bekannt, und werden bei der Erstellung der Prüfschrittdatenbank mit bedatet und den einzelnen Prüfschritten zugeordnet. Dadurch kann die Entscheidungsfunktion für die Prüfschrittpriorisierung gegebenenfalls von einer Entropie hin zu einer Effizienzauswahl oder einer Kostenschätzung entsprechend der Expected Costs of Diagnosis verfeinert werden.
Die Entscheidungsfunktion für die Prüfschrittpriorisierung des Diagnosesystems ist dann entweder eine Prüfschrittpriorisierung anhand des Informationsgehaltes des einzelnen relevanten Prüfschrittes, wobei der Prüfschritt mit dem größten Informationsgehalt die höchste Priorität erhält, oder es wird mit der Entscheidungsfunktion eine Priorisierung der einzelnen Prüfschritte anhand der oben definierten Effizienz durchgeführt, wobei derjenige Prüfschritt die höchste Priorität erhält, der die höchste Effizienz hat, oder es wird eine Kostenschätzung entsprechend der Expected Costs of Diagnosis herangezogen.
Mit jeder der vorgenannten Prüfschrittpriorisierungen lässt sich eine per Computerberechnungen und Computerauswahl automatisiert durchgeführte Prüfschrittreihenfolge aufstellen. Dem Servicetechniker kann eine Prüfschrittreihenfolge vorgeschlagen und auf einem Display eines Diagnosesystems zur Anzeige gebracht werden, die mit dem höchst priorisierten Prüfschritt beginnt und die weiteren Prüfschritte mit jeweils abnehmender Priorisierung anschließt.
Damit lässt sich ein Computer gestütztes Diagnosesystem einrichten, dessen Diagnoseprogramm um das Modul einer Prüfschrittpriorisierung erweitert ist. Der Verfahrensablauf für ein Basissystem mit Prüfschrittpriorisierung ist in dem Blockdiagramm der 4 dargestellt. Startend mit der von dem Diagnosesystem bereitgestellten gewichteten Fehlerkandidatenliste 410 werden von dem erfindungsgemäß ergänztem Diagnoseprogramm in einem anschließenden Verfahrensschritt 420 die relevanten Prüfschritte ermittelt und z.B. mit dem vorgenannten Bewertungsschema hinsichtlich Effizienz, Informationsgehalt oder Kostenschätzung bewertet und priorisiert. In einem folgenden Verfahrensschritt 430 kann der Servicetechniker oder der Monteur aus den angezeigten Prüfschritten einen Prüfschritt z.B. per Menüsteuerung auswählen und am Kraftfahrzeug durchführen. Im folgenden Verfahrensschritt 440 wird das Ergebnis des durchgeführten Prüfschritts in das Diagnosesystem eingegeben und mit der neu gewonnen Erkenntnis eine Neuberechnung der Gewichte der fehlerverdächtigen Kandidaten durchgeführt. Die Neuberechnung führt insbesondere zu einer Streichung aller bereits getesteten und für in Ordnung befundenen Fehlerkandidaten aus der Fehlerkandidatenliste. Die frei werdenden Gewichte wachsen hierbei den noch nicht getesteten Fehlerkandidaten zu. Mit der neu berechneten Fehlerkandidatenliste wird die Prüfschrittpriorisierung ebenfalls neu berechnet und durchgeführt, so dass der Verfahrensablauf für die Prüfschrittpriorisierung rekursiv ist, mit dem Ziel möglichst schnell einen Fehlerkandidaten mit einer Fehlerwahrscheinlichkeit nahe 100% zu erhalten. Verdeutlicht in dem Verfahrensschritt 450 des Blockdiagramms.
Ein Problem bei der Prüfschrittpriorisierung kann die genauere Bestimmung des Informationsgehaltes eines Prüfschrittes sein, wenn man diesen Informationsgehalt auf die aktuell vorliegende Diagnosesitzung anwenden will. Die vorbeschriebene Gleichverteilung der Prüfungsausgänge ist hier nur eine erste Näherung, die jedoch bei näherem Hinsehen mit dem aktuellen Diagnoseproblem variieren kann. Insbesondere können bereits durchgeführte Prüfungen und die daraus gewonnene Erkenntnis den Informationsgehalt und den Wert noch nicht durchgeführter Prüfungen erhöhen oder vermindern. Will man den Informationsgehalt eines Prüfschrittes an den Fortgang der Diagnosesitzung anpassen braucht man hierzu ein flexibles Berechnungstool, das in der Lage ist mit Wahrscheinlichkeiten umzugehen. Hier bieten sich Wahrscheinlichkeitsnetze und insbesondere so genannte Bayes Netze an. Bayesnetze werden seit den 80-iger Jahren erfolgreich in den Themenfeldern Fehlerdiagnose, Entscheidungshilfen, Verlässlichkeitsanalysen, Risikobewertung usw. eingesetzt. Die Bayesnetze dienen hierbei der Repräsentation von Zusammenhängen und Größen, die Unsicherheiten unterworfen sein können oder nur der Wahrscheinlichkeit nach bekannt sind. Darüber hinaus bieten die sogenannten Propagierungsverfahren die Möglichkeit neue Informationen, wie z.B. Prüfungsergebnisse, konsistent zu verarbeiten und dadurch den Einfluss auf andere Größen zu berechnen. Das Bayesnetz dient nun dazu die Relationen zwischen Prüfung und geprüfte Komponenten darzustellen und die für die Prüfschrittpriorisierungen benötigten Wahrscheinlichkeiten genauer zu berechnen und an den Fortgang der Diagnosesitzung anzupassen.
Damit lässt sich ein Verfahren zur Prüfbaumerzeugung einrichten. Startend mit einer gewichteten Fehlerkandidatenliste wird ein Diagnoseknoten eingerichtet, der für jede verdächtige Komponente einen Zustand mit einer Wahrscheinlichkeit, die der Gewichtung der Fehlerkandidaten entspricht, enthält. Nun können diejenigen Prüfungen aus der Prüfschrittdatenbank ausgewählt werden, die relevant sind, d.h. die die verdächtigen Komponenten prüfen. Die ausgewählten Prüfschritte werden mit einer der Entscheidungsfunktionen priorisiert und ausgewählt. Ein Prüfschritt ist noch verfügbar, wenn er nicht schon einmal durchgeführt wurde, bzw. der Prüfungsausgang nicht schon sicher ist. Für die Prüfbaumkonstruktion müssen dann beide Ausgangsmöglichkeiten der Prüfung, Komponente in Ordnung oder Komponente nicht in Ordnung, vorhanden sein. Dann wird für alle relevanten noch nicht verbrauchten Prüfungen rekursiv fort gefahren. Ein solches Verfahren wird als myoptisch oder kurzsichtig bezeichnet, da immer nur der nächste Schritt optimiert wird. Ist der Prüfbaum aufgespannt können die Ergebnisse der durchgeführten Prüfschritte als Evidenz also als gesichertes Wissen in das Bayesnetz eingegeben werden die Auswirkung auf die verbleibenden Komponenten berechnet werden und zu den übrig gebliebenen Komponenten wieder ein Prüfbaum aufgespannt werden, der mit dem vor beschriebenen myoptischen Verfahren jeweils die höchst priorisierten Prüfschritte auswählt.
Ergebnis ist schließlich ein Prüfschrittbaum, der dem Servicetechniker graphisch zur Anzeige gebracht wird. Eine graphische Repräsentation eines derartigen Prüfschrittbaumes ist in 5 dargestellt. In dem Diagnoseknoten liegen die Zustände der ermittelten Fehlerkandidaten in Form von Gewichten vor. Es seien dies die Kandidaten K1, K2, K3, K4, K5. Mit der Entscheidungsfunktion wird für das vorliegende Diagnoseproblem der beste Prüfschritt PS1 gewählt. Je nach Ausgang der Prüfung, wird das Prüfungsergebnis zurückgespiegelt. Das Prüfungsergebnis PS1 = NOK (Prüfungsergebnis Nicht OK) identifiziert den Fehlerkandidaten K1. Bei dem Prüfungsergebnis PS1 = OK (Kandidat K1 ist in Ordnung) wird mit der Entscheidungsfunktion die nächst beste Prüfung ausgewählt. Dies sei der Prüfschritt PS4 zur Überprüfung der Komponente K4. Bei dem Ergebnis PS4 = NOK ist Komponente K4 als fehlerhaft identifiziert. Ergibt die Überprüfung mit Prüfschritt PS4, dass die Komponente K4 in Ordnung ist, wird mit dem nächst besten Prüfschritt PS2 fortgesetzt, der die Komponente K2 überprüft und bei Prüfausgang Nicht OK K2 identifiziert. Ist das Prüfergebnis OK wird wiederum mit dem besten verbleibenden Prüfschritt fortgesetzt. Bei dem gewählten Beispiel sei dies der Prüfschritt PS3 zur Überprüfung der Komponente K3. Hier ist das Prüfungsergebnis nicht mehr so wichtig, da auf alle Fälle noch die letzte verbliebene, verdächtige Komponente K5 untersucht werden muss. Für diese letzte Überprüfung wird in der Regel noch eine Prüfung fällig, die aber in 5 nicht mehr dargestellt ist. Es kann auch sein, dass ein Restart des Diagnosesystems nach den durchgeführten Reparaturen der Komponenten K1 und K4 ergibt, dass damit auch die Fehlerkandidaten K2, K3, K5 nicht mehr verdächtigt werden.
Realistische Prüfprobleme können rund 50 verdächtige Komponenten umfassen. Für jede Komponente liegt mindestens eine Einzelprüfung vor. Darüber hinaus gibt es noch funktionale Prüfungen, die mehr als eine Komponente abdecken. Damit liegt die Anzahl der Prüfungen im Allgemeinen über der Komponentenzahl. Durch die Bewertung über die Effizienz werden die Äste eines Prüfschrittbaumes nach ihrer Entropie und nach den Kosten ausbalanciert. Während einer Diagnosesitzung wächst die Fehlerwahrscheinlichkeit und damit die Gewichtung in der Fehlerkandidatenmenge auf wenigen meist einer Komponente an. Die Fehlerwahrscheinlichkeiten aller bereits in Ordnung getesteter Komponenten wird nämlich zu Null und fließt als Prüfergebnis in das Diagnoseprogramm ein, so dass mit fortschreitender Diagnosesitzung und laufender Aktualisierung der gewichteten Fehlerkandidatenmenge durch rekursive Neuberechnung durch das Diagnoseprogramm der Diagnosefokus immer schärfer wird.
Funktionale Prüfungen prüfen in der Regel viele Kandidaten ab, die zum Teil auch außerhalb der Fehlerkandidatenmenge liegen. Diese mitgeprüften externen Kandidaten müssen bei der Berechnung des Informationsgehaltes eines Prüfschrittes gesondert behandelt werden und dem Servicetechniker ein entsprechender Hinweis gegeben werden. Werden durch das Durchführen der Prüfung die externen Kandidaten als fehlerhaft getestet, kann es zu Widersprüchen mit der Fehlerkandidatenmenge kommen. Ein Update des Prüfschrittbaumes oder der Fehlerkandidatenmenge nach einer positiven Prüfung mit externen Kandidaten darf daher nicht zur vollständigen Entlastung der Kandidaten in der Fehlerkandidatenmenge führen. Dies kann z.B dadurch verhindert werden, dass bei der Fehlerwahrscheinlichkeit zwischen externem p_extern und internem Anteil p_intern unterschieden wird, und bei der Rückspiegelung des Prüfergebnisses in das Diagnosesystem nur derjenige Anteil zu Null wird, der auch getestet wurde. Der nicht getestete Anteil bleibt dann sowohl in der Fehlerkandidatenmenge als auch in der Prüfschrittpriorisierung. Für funktionale Prüfungen, die auch externe Kandidaten prüfen setzt sich daher die Wahrscheinlichkeit als Summe von externer und interner Wahrscheinlichkeit zusammen. p' = pextern + pintern
Der Informationsgehalt oder die Effizienz dieser Verbundprüfungen ist in der Regel sehr hoch, da sie mehrere Komponenten prüfen und daher einen großen Informationsgewinn liefern. Die Verbundprüfungen gehören daher zu den hochpriorisierten Prüfschritten für eine Fehlerkandidatenmenge.
Der Vollständigkeit halber sei noch auf die Möglichkeit von abhängigen Prüfschritten hingewiesen. Manche Prüfschritte bauen aufeinander auf und müssen in einer bestimmten Reihenfolge durchgeführt werden. Diese abhängigen Prüfungen müssen natürlich auch als solche in der Prüfschrittdatenbank strukturiert sein.
Auch wenn mit dem erfindungsgemäßen Diagnosesystem hauptsächlich sowohl die Fehlerkandidatenmenge als auch die Prüfschrittpriorisierung dynamisch an den Fortschritt der Diagnosesitzung nachgeführt werden und sich sowohl die Fehlerkandidatenmenge als auch die Prüfschrittauswahl ändern, so kann trotzdem zu jedem Zeitpunkt der Diagnosesitzung, insbesondere beim Kundengespräch in der Fahrzeugannahme, eine aktuelle Kostenabschätzung für die jeweils verbleibende Diagnosesitzung ermittelt werden. Hierzu wird zur Fehlerkandidatenmenge jeweils der komplette Prüfschrittbaum ermittelt und die Kosten der ermittelten Prüfschritte aufsummiert. Diese Kostensumme gibt dann eine Obergrenze für die Kosten an, mit denen beim vorliegenden Diagnoseproblem möglicherweise höchstens zu rechnen sein wird.
Dem Servicetechniker wird ein kompletter Prüfschrittbaum von dem Diagnosesystem vorgeschlagen, bei dem die einzelnen Prüfschritte hinsichtlich Effizienz, Informationsgehalt oder Expected Costs of Diagnosis priorisiert sind. Es bleibt letztlich dem Servicetechniker überlassen, in welcher Reihenfolge er welchen Prüfschritt durchführt. Der Servicetechniker muss nicht mit der höchst priorisierten Prüfung des Prüfschrittbaumes beginnen.
Mit einer optionalen Protokollfunktion können mit dem Diagnosesystem die durchgeführten Reparaturen mitprotokolliert werden. Über dieses Protokoll können dann Prüfungen oder Prüfschritte vorgeschlagen werden, die sicherstellen, dass die eingebauten Komponenten oder die Reparatur nochmals überprüft werden, um sicher zu stellen, dass die Reparatur erfolgreich war und keine neuen Fehler eingebaut wurden. Außerdem kann mit der Protokollfunktion laufend der aktuelle Verbauzustand des Fahrzeugs in der Reparaturwerkstatt mitprotokolliert werden. Damit kann laufend festgestellt werden, welche Komponenten des Kraftfahrzeugs gerade ausgebaut sind. Die dynamischen Kosten der Diagnosesitzung hängen hierbei auch vom aktuellen Verbauzustand des Fahrzeugs ab, so dass die Protokollfunktion auch für die Kostenschätzung mit herangezogen werden kann. Das Tracking des Verbauzustandes des Fahrzeuges in der Reparatur gelingt hierbei über das Mitprotokollieren welche Prüfschritte mit welchem Prüfungsausgang bereits durchgeführt wurden.

Claims

Rechnergestütztes Diagnosesystem, insbesondere für ein Kraftfahrzeug, das mit einem Diagnoseprogramm durch Systemabfragen und durch Verarbeitung der abgefragten Systemmeldungen oder Systemzuständen eine Fehlerkandidatenmenge erzeugt, dadurch gekennzeichnet, dass die zu den Fehlerkandidaten zugehörige Prüfdomäne aus relevanten Prüfschritten aus einer Prüfschrittdatenbank ermittelt wird und mit einer Entscheidungsfunktion die relevanten Prüfschritte bewertet werden und eine Prüfschrittpriorisierung durchgeführt wird.
Rechnergestütztes Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Entscheidungsfunktion die relevanten Prüfschritte hinsichtlich ihres Informationsgehaltes bewertet.
Rechnergestütztes Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Entscheidungsfunktion die jeweils auszuwählenden Prüfschritte jeweils nach den nach der Auswahl des aktuellen Prüfschrittes noch verbleibenden zu erwartenden Kosten der noch verbleibenden Prüfschritte bewertet.
Rechnergestütztes Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Entscheidungsfunktion die relevanten Prüfschritte hinsichtlich Effizienz bewertet.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Prüfdomäne durch ein Bayes Netz modelliert wird.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Prüfdomäne mit einer regelbasierten Wissensbasis modelliert wird.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Prüfdomäne mit einem mathematisch-physikalischen Modell modelliert wird.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass mit der Prüfschrittpriorisierung ein Prüfschrittbaum automatisch und dynamisch aufgespannt und angezeigt wird.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Fehlerkandidatenmenge eine Menge mit gewichteten Fehlerkandidaten ist.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Fehlerkandidatenmenge eine Menge mit ungewichteten Fehlerkandidaten ist.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass mit einer Protokollfunktion die durchgeführten Reparaturmaßnahmen mitprotokolliert werden und über dieses Protokoll Prüfungen für die durchgeführten Reparaturmaßnahmen vorgeschlagen werden.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass der Prüfschrittbaum an den Fortgang der Diagnosesitzung dynamisch angeglichen werden kann.
Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass Verbundprüfungen, die mit einer Prüfung mehrer potentielle Fehlerkandidaten testen, möglich sind.
Rechnergestütztes Diagnosesystem nach Anspruch 11, dadurch gekennzeichnet, dass ein Tracking durchgeführt wird, mit dem der aktuelle Verbauzustand des Fahrzeugs in der Reparatur erfasst wird.