-
Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich im Allgemeinen auf computergestützte Diagnoseverfahren
und -systeme, die auf zu diagnostizierende Systeme angewendet werden,
und die unter Umständen
in der Lage sind, Daten von internen Elementen zu erfassen und/oder
Daten mit dem Computer auszutauschen, ohne dass dies zwangsläufig der
Fall sein muss.
-
Hintergrund der Erfindung
-
Infolge
der umfassenden Einbindung von elektronischer und elektrischer Ausrüstung z.
B. in Kraftfahrzeugen zur Steuerung von Motoren, Bremsanlagen und
anderen Bordsystemen kommen immer häufiger computergestützte Diagnoseverfahren
zum Einsatz. So ersetzt die von Kraftfahrzeug-Herstellern und -Zulieferern verwendete
Multiplextechnologie die zahllosen fest verdrahteten elektrischen
Verbindungen zwischen Bauteilen durch Datenbusse. Diese Datenbusse
ermöglichen
die Übertragung
einzelner oder Rundsendenachrichten zu und von allen Komponenten.
-
Der
erste Zweck eines Diagnoseverfahrens besteht darin, den Fehler festzustellen
und die Maßnahme zu
ermitteln, die zu seiner Behebung durchzuführen ist. Je komplexer das
System, für
das eine Diagnose erforderlich ist, desto leistungsfähiger muss
das Diagnoseverfahren sein. Die Verwendung eines leistungsfähigen Verfahrens
führt zu
Zeitersparnis sowie zu Kosteneinsparungen für die auszutauschenden Teile
und die Fachleute, welche die Diagnose durchführen. Der Techniker in einer
Werkstatt verlässt
sich bei der Diagnose in der Regel auf statische Entscheidungsbäume. Er
muss außerdem
Fahrzeugschaltpläne
und Parameterlesegeräte
hinzuziehen, die er mit dem zu diagnostizierenden Fahrzeug verbindet.
Falls der Techniker nicht über besondere
Fachkenntnisse zu einem gegebenen System verfügt, gibt es bei diesem Verfahren
keine Gewähr dafür, dass
das richtige Teil des Systems ausgetauscht wird. Bei komplexen Fehlern
kann der Techniker eine Strategie des systematischen Ausprobierens
verwenden, da er nicht tiefer in die in die Fehleranalyse eindringen
kann.
-
Somit
wird ein genaues und leistungsfähiges
computergestütztes
Verfahren benötigt,
mit dem sich Zeit einsparen lässt
und Kosten für
die auszutauschenden Teile eingespart werden können, während gleichzeitig der Einsatz
von hochqualifizierten Technikern zur Diagnosedurchführung vermieden
werden kann.
-
Heutzutage
stehen computergestützte
Verfahren für
die Fehlerermittlung von Systemen wie beispielsweise DIAG 2000 von
ACTIA, Clip von SAGEN und DIS von Siemens zur Verfügung, die
auf die Fahrzeugdiagnose angewendet werden. Sie werden durchweg
mit einem Datenspeicher realisiert, der Bezugsdaten enthält, sowie
mit einem Gerät,
das Parameter aus dem System auslesen kann, für das eine Diagnose notwendig ist.
Die Verfahren analysieren und berechnen sie anhand von Daten, die
aus dem Bezugsdatenspeicher ausgelesen werden, um so die Fehlerermittlung
vorzunehmen. Je nach Art der im Datenspeicher gespeicherten Daten
und des Gerätealgorithmus
weist das Verfahren unterschiedliche Merkmale hinsichtlich der Genauigkeit und
Leistungsfähigkeit
der Diagnose, des Zeitaufwands bzw. Schwierigkeitsgrads, mit dem
es sich an verschiedene Systeme anpassen lässt, oder auch hinsichtlich
des Wartungsaufwands auf, der im Laufe der Zeit dafür notwendig
ist. Basis-Diagnosesysteme verwenden statische Entscheidungsbäume, die Ähnlichkeit
mit einem Ja-Nein-Baum aufweisen, während fortschrittlichere Systeme
entweder fallbasierte, modellbasierte oder regelbasierte Schlussfolgerungsalgorithmen
verwenden, bei denen es sich um bekannte Ansätze für die Schaffung von Expertensystemen
handelt.
-
Das
Verfahren des fallbasierten Schließens besteht daraus, neue Probleme
mit „Fällen" aus einer Historiendatenbank
zu vergleichen und erfolgreiche Lösungen aus der Vergangenheit
an gegenwärtige
Situationen anzupassen. Das fallbasierte Schließen (Case-Based Reasoning,
CBR) ist ein Paradigma für
die Problemlösung,
das sich in vieler Hinsicht grundsätzlich von anderen bedeutenden
KI-Ansätzen
unterscheidet. Anstelle sich ausschließlich auf die allgemeine Kenntnis
eines Problembereichs zu verlassen oder anhand von allgemeinen Beziehungen
zwischen Problembeschreibern und Schlussfolgerungen Annahmen zu
machen, kann CBR das spezifische Wissen aus vergangenen, konkreten
Problemsituationen (Fällen)
nutzen. Dabei wird ein neues Problem gelöst, indem ein ähnlich gelagerter
Fall aus der Vergangenheit gefunden und in der neuen Problemsituation
wiederverwendet wird. Ein zweiter wichtiger Unterschied besteht
darin, dass CBR auch einen Ansatz für schrittweise erfolgendes,
nachhaltiges Lernen darstellt, da nach jeder Lösung eines Problems eine neue
Erfahrung vorhanden ist, die sofort für künftige Probleme verfügbar ist.
Wenn CBR das Verfahren für
die Diagnoseermittlung verwendet wird, geht der erste Schritt sehr
schnell vonstatten; er besteht darin, eine Momentaufnahme eines
zu analysierenden Systems zu machen, d. h. eine Anzahl von Parametern
zu erfassen, die das System zu einem bestimmten Zeitpunkt kennzeichnen.
Der Nachteil besteht jedoch darin, dass das Ergebnis lediglich ungefähr ist und
sehr weit vom genauen Ergebnis entfernt sein kann, falls das Fehlerproblem
nicht modelliert wurde. Dies kann zu einem Diagnosefehler führen, der
nicht in seinem Ist-Zustand protokolliert wird. Das zweite Problem
bei diesem Verfahren besteht darin, dass sich das Modell im Laufe
der Zeit ändert
und die Modellgenauigkeit nach einer Weile nur noch sehr schwer
beurteilt werden kann. Dies führt
zu Ungenauigkeit einer Diagnoselösung.
-
Beim
modellbasierten Schließen
(Model-Based Reasoning, MBR) wird die Wissensbasis als ein Satz von
Modellen der Welt und nicht als eine sie beschreibende logische
Formel dargestellt. Modelle werden parametriert, und die modellbasierte
Darstellung unterstützt
auf wirksame Art und Weise Schlussfolgerungen bei verschiedenen
Kontextinformationen. Um funktionsfähig zu sein, muss bei Anwendung
von MBR als Diagnoseverfahren jedes Objekt modelliert werden, was äußerst kostenträchtig sein
kann, selbst wenn bekannt ist, dass manche Teile oder Funktionen
nicht als Fehlerursache in Frage kommen. Da bei einem MBR-Diagnoseverfahren
der Modellkontext nachgebildet werden muss, muss der Techniker in
der Werkstatt viele Arbeitsschritte durchführen, um ein bestimmtes Modell
zu prüfen.
Ein bedeutendes Problem bei der Anwendung von MBR auf ein Diagnoseverfahren
besteht darin, dass sich die Modelle im Laufe der Zeit entwickeln
sollten, um sich so an ein sich entwickelndes komplexes System wie
beispielsweise einen Fahrzeugmotor anpassen zu können. In diesem Fall sieht
das Verfahren keine Möglichkeit
für die
Beurteilung der Modelländerungen
vor. Ein modellbasierter Ursachenanalysator wird in der internationalen
Patentanmeldung
WO 03/042769 beschrieben,
die am 22. Mai 2003 veröffentlicht
wurde. Dieses Dokument beschreibt einen computergestützten Analysator,
der eine Ursachenanalyse für
Ereignisse in einer Industrieanlage oder in einem Teilsystem einer Industrieanlage,
z. B. einer Fertigungszelle, einer Maschine, einer Komponente oder
einer Prozessphase durchführt.
Zu diesem Zweck wird ein der Anlage zugehöriges Datenmodell in dem Computer
gespeichert. Das Datenmodell kann – wie in
11 dargestellt – eine hierarchische
Struktur aufweisen und beschreibt alle Funktionen und Teilfunktionen
der Anlage. Das Datenmodell speichert die möglichen Ereignisse, Hypothesen
zu ihren Ursachen und Symptome dieser Hypothesen, wobei diese den
Funktionen und Teilfunktionen der Anlage zugehörig sind. Die Ermittlung der
Ursachen erfolgt automatisch durch eine Einheit, die Hinweise und
Symptome von einer Bedienperson erfasst und eine Liste der wahrscheinlichsten
Ursachen für
das Ereignis kennzeichnet. Eine derartige hierarchische Struktur
eines Systems kann nicht zur Ausführung aufeinanderfolgender Diagnoseprüfungen oder
als Leitfaden für
deren Ausführung
verwendet werden und kann nicht erkennen, welcher Fehler bei welchem
grundlegenden Bestandteil eines Systems vorliegt. Das hierarchische
Strukturmodell dient bei diesem Dokument nach dem Stand der Technik
dazu, die Struktur der Anlage zu verbessern und so künftige Probleme
zu vermeiden.
-
Regelbasierte
Expertensysteme (Rule-Based Reasoning, RBR) werden ebenfalls verwendet.
Anhand eines Satzes von Annahmen, die gemeinsam das „Arbeitsgedächtnis" bilden, und eines
Satzes von Regeln, die angeben, wie ausgehend von dem Annahmesatz
gehandelt werden soll, kann ein regelbasiertes System erzeugt werden.
Regelbasierte Systeme sind vergleichsweise einfach, bestehen aus
wenig mehr als einem Satz von Wenn-dann-Aussagen, stellen jedoch
die Grundlage für
so genannte Expertensysteme bereit, die in vielen Bereichen weit
verbreitet sind. Einem Expertensystem liegt folgender Gedanke zugrunde:
Das Wissen eines Experten wird in Codeform in den Regelsatz aufgenommen.
Wenn dieselben Daten erneut auftreten, führt die KI des Expertensystems ähnliche
Maßnahmen
durch wie der Experte. Das Hauptproblem bei einem RBR-Verfahren
zur Diagnoseermittlung besteht darin, dass die Anzahl der Regeln
so groß ist,
dass die Datenbank schnell zu umfangreich wird, um noch problemlos
verwaltet werden zu können.
Wenn das System beispielsweise 47.000 Teile umfasst, kann die Anzahl
der Regeln bis auf 47.000 multipliziert mit der Anzahl der möglichen
Konfigurationen anwachsen.
-
Somit
wird ein leistungsfähiges,
geleitetes Diagnoseverfahren benötigt,
das genau ist, mit Blick auf die Datenbankgröße praktikabel ist und in das
Inhalte eingegeben und auf Dauer einfach verwaltet werden können.
-
Zusammenfassung der Erfindung
-
Es
ist somit eine Aufgabe der vorliegenden Erfindung, ein Diagnoseverfahren
bereitzustellen, das computergestützt als Ergebnis das kleinste
fehlerhafte und reparierbare/austauschbare Systemteil ermittelt, das
für ein
Problem verantwortlich ist, welches als ein Symptom bei einem gegebenen
zu diagnostizierenden System ausgedrückt wird.
-
Es
ist eine weitere Aufgabe der Erfindung, ein unterstütztes Diagnoseverfahren
bereitzustellen, das mit minimaler Einbeziehung einer technischen
Unterstützung
und innerhalb einer kürzestmöglichen
Zeit ein Ergebnis liefert.
-
Diese
Aufgaben werden gemäß Anspruch
1 bis 11 mit einem System und einem computergestützten Verfahren erreicht, um
ein fehlerhaftes Teil zu diagnostizieren, das einem Symptom in einem
System entspricht, welches in Funktionen und Teilfunktionen zusammengefasste
Elemente umfasst, wobei das Verfahren mit Hilfe eines Bedieners
ausgeführt
wird, der vor Ort Operationen auf dem System durchführt und
die Schnittstelle zum Computer darstellt, wobei das Verfahren die
Schritte des Definierens und Speicherns von Symptombäumen des
Systems umfasst, wobei jeder Symptombaum auf die Verzweigung des
Systems in Funktionen, Teilfunktionen, Elemente, welche die reparierbaren
Einheiten des Systems sind, und Fehlermodi dieser Elemente abgebildet
wird. Die Knoten beinhalten eine Prüfungsbeschreibung, wobei der
Computer die Prüfungen
des Baums so lange durchführt,
bis ein fehlerhafter Knoten gefunden wird.
-
Wahlweise
können
die Knoten Parameterwerte wie beispielsweise den Typ des Systems
oder andere Werte enthalten, welche die spätere Auswahl der Knoten des
Symptombaums ermöglichen,
um in Abhängigkeit
von den Parameterwerten spätere
Wiederholungen der Prüfungsdurchführung zu
ermöglichen.
-
Wenn
das System Steuerungselemente umfasst, die Systemvariablen erfassen
und mit dem Computer Daten austauschen können, können in den Knoten des Symptombaums
automatische Prüfungen
gespeichert sein.
-
Diese
automatischen Prüfungen
werden vor den anderen Prüfungen
durchgeführt.
Wenn sie ein positives Ergebnis erbringen, werden sie mit einer
vom Bediener von Hand durchgeführten
Bestätigungsprüfung bestätigt.
-
Ein
Vorteil des Verfahrens besteht darin, dass es einfach an verschiedene
Systeme anpassbar ist, für welche
die Diagnose durchgeführt
wird.
-
Ein
weiterer Vorteil des Verfahrens besteht darin, dass es unabhängig von
den Diagnosefähigkeiten des
Technikers, der es anwendet, eine geleitete Diagnose bereitstellt.
-
Ein
weiterer Vorteil des Verfahrens lautet, dass sich Inhalte dauerhaft
einfach verwalten lassen.
-
Ein
weiterer Vorteil des Verfahrens besteht darin, dass es auf Systeme
anwendbar ist, die in der Lage sein können, Daten von internen Elementen
zu erfassen und Daten mit dem Computer auszutauschen, ohne dass
dies zwangsläufig
der Fall sein muss.
-
Ein
weiterer Vorteil der vorliegenden Erfindung besteht darin, dass
sie ein Verfahren bereitstellt, das vorhersagbar in dem Sinn ist,
dass es entweder zur Ermittlung eines Fehlers oder zu der Schlussfolgerung führt, dass
der Fehler dem System nicht bekannt ist. Das Verfahren versucht
nicht, fundierte Vermutungen anzustellen.
-
Ein
weiterer Vorteil des Verfahrens besteht darin, dass der Aufwand
für die
Eingabe von Daten in die Datenbank des Diagnoseverfahrens für ein erstes
System mittelhoch und für
die folgenden Systeme gering ist.
-
Ein
weiterer Vorteil des Verfahrens lautet, dass – während das Verfahren nach dem
Stand der Technik Fachleute mit umfassenden Fahrzeugkenntnissen
und sogar mit mathematischem Wissen (von MBR-Verfahren) erforderte – das Verfahren
der vorliegenden Erfindung nur Fahrzeugfachleute, Domänennutzer
und technische Berater erfordert, da das System aufgrund seines „natürlichen" Zerlegung leicht
verständlich
ist.
-
Ein
weiterer Vorteil des Verfahrens der vorliegenden Erfindung lautet,
dass die in der Praxis gewonnene Erfahrung problemlos in die Daten
eingebunden werden kann: dies kann sowohl automatisch über die
Gewichtungen als auch von Hand über
eine strukturierte Funktionszerlegung erfolgen. Bei CBR-Verfahren
wird die Praxiserfahrung auf unstrukturierte Art und Weise eingebunden.
MBR-Verfahren gestatten lediglich eine beschränkte oder auch überhaupt
keine Einbindung der Praxiserfahrung, während bei Verfahren auf Grundlage
eines Entscheidungsbaums eine von Hand erfolgende Einbindung möglich ist,
die jedoch die Neuanordnung der Bäume notwendig machen kann.
-
Das
im Folgenden beschriebene Diagnoseverfahren beruht auf einer funktionsbezogenen
Zerlegung eines Symptoms in Funktionen, Teilfunktionen und austauschbare
Einheiten, die Fehlermodi zugehörig
sind. Die Erzeugung eines Symptombaums erfordert kein Fachwissen über das
Verhalten des zu diagnostizierenden Systems, sondern lediglich Kenntnisse
der Funktionsweise des Systems. Dies ist einfacher als bei dem Verfahren
nach dem Stand der Technik, bei dem für die Erzeugung des Diagnosebaums
Fachwissen über
die Probleme des zu diagnostizierenden Systems benötigt wird.
-
Ein
weiterer Vorteil des Verfahrens ist seine Fähigkeit, eine geleitete Diagnose
für unvollständige Inhalte
bereitzustellen, d. h., zur Durchführung der Diagnose wird keine
vollständige
Zerlegung eines Symptoms in all seine möglichen Ursachen benötigt. Dies
ist ein erheblicher Vorteil.
-
Das
Diagnoseverfahren der vorliegenden Erfindung weist aufgrund der
internen, dynamischen Gewichtungsberechnung und der nichtsequenziellen
Funktionen eine sehr hohe Leistungsfähigkeit auf (so erkennt das
System z. B. einen nicht angeschlossenen Stecker oder einen fehlerhaften
Sensor. Das System kann auf diese Fehler direkt hinweisen, ohne
dass der Anwender aufgefordert wird, eine vollständige sequenzielle Diagnoseprozedur
durchzuführen).
Dies ist CBR-Verfahren, bei denen die Leistung nur dann ansteigt, wenn
die Anzahl der Fälle
erhöht
wird, sowie MBR-Verfahren gegenüberzustellen,
die sehr ausgeprägte
Datenverarbeitungsfähigkeiten
benötigen.
Bei Verfahren auf Grundlage eines Entscheidungsbaums ist die Leistung
aufgrund des sequenziellen Ansatzes in der Regel gering.
-
Die
Datenverarbeitungsanforderungen sind für das Verfahren der vorliegenden
Erfindung gering, für CBR-Verfahren
hoch, für
MBR-Verfahren sehr hoch und für
Verfahren auf Grundlage eines Entscheidungsbaums sehr niedrig.
-
Die
Diagnosekosten sind für
das Verfahren der vorliegenden Erfindung gering, da sich die Operationen und
austauschbaren Einheiten leicht in das System einbinden lassen,
während
dies bei CBR-Verfahren nur schwer möglich ist und eine kombinierte
Faktorzerlegung erfordert. Wenn neue Operationen und Kosten für austauschbare
Einheiten in das System aufgenommen werden, steigt die Komplexität des Modells
bei MBR-Verfahren. Neue Operationen und Kosten für austauschbare Einheiten lassen
sich bei Verfahren auf Grundlage eines Entscheidungsbaums nur schwer
hinzufügen,
da die Entscheidungsbäume
unabhängig
und sequenziell sind.
-
Mit
dem Verfahren der vorliegenden Erfindung wird die Leistungsfähigkeit
der technischen Informationsstelle im Vergleich zu den Verfahren
nach dem Stand der Technik verbessert, da die technische Informationsstelle
anhand der Datenbanken feststellen kann, welche Fahrzeugfunktionen
erfolgreich geprüft
wurden. Mit CBR-Verfahren lässt
sich nur eine geringe Verbesserung der Informationsstelle erzielen.
Mit den MBR-Verfahren gewinnt die technische Informationsstelle
nur schwer ein Verständnis
der Situation, während
die Verfahren auf Grundlage eines Entscheidungsbaums nur von geringem
Nutzen für
sie sind.
-
Die
Gesamtleistungsfähigkeit
des Diagnoseverfahrens der vorliegenden Erfindung ist allgemein
gesprochen sehr hoch im Vergleich zu den Verfahren nach dem Stand
der Technik, die bei CBR-Verfahren eine geringe, bei MBR-Verfahren
eine mittlere und bei Entscheidungsbaumverfahren eine sehr geringe
Leistungsfähigkeit
erzielen.
-
Ein
weiterer Vorteil des Verfahrens besteht bei einer bevorzugten Ausführungsform
darin, dass der Inhaltsverfasser verschiedene Parameter einführen kann,
die austauschbaren. Einheiten wie beispielsweise Ersatzteilen zugeordnet
sind, um so das System dabei zu unterstützen, das optimale auszutauschende
Teil zu ermitteln.
-
Ein
weiterer Vorteil des Verfahrens besteht darin, dass der Werkstatttechniker
keine sehr tiefgehenden Kenntnisse des Systems, für das eine
Diagnose durchgeführt
wird, benötigt,
um das Verfahren zu nutzen.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt
den Überblick über das
Datenverarbeitungssystem für
das Durchführen
des Diagnoseverfahrens gemäß der bevorzugten
Ausführungsform;
-
2 zeigt
die verschiedenen logischen Schichten der Software, die an dem Diagnoseverfahren
der bevorzugten Ausführungsform
beteiligt sind;
-
die 3 und 4 zeigen
die Schritte des Diagnoseverfahrens, die von dem Bediener des automatisierten
Systems ausgeführt
werden;
-
5 ist
ein Beispiel für
einen Baum der Diagnosedatenbank, die von der Diagnose-Einheit gelesen wird;
-
6 zeigt
den logischen Ausdruck der automatischen Prüfungen der Knoten des Baums
aus 5;
-
7 ist
eine Abbildung der Parameter, die den Knoten eines Symptombaums
gemäß der bevorzugten
Ausführungsform
zugehörig
sind;
-
8 ist
das allgemeine Ablaufdiagramm des Verfahrens der Diagnose gemäß der bevorzugten
Ausführungsform.
-
Ausführliche Beschreibung der bevorzugten
Ausführungsform
-
1 zeigt
die Umgebung des Verfahrens der Erfindung gemäß der bevorzugten Ausführungsform, die
ausgehend von den Symptomen eines Problems ermöglicht, die kleinste austauschbare
oder reparierbare Einheit in einem automatisierten System (130)
wie beispielsweise einem Kraftfahrzeug, das prüfbare Komponenten beinhaltet,
von denen manche über
eine Steuereinheit des Systems eindeutig prüfbar sind, zu ermitteln. Wenn
das System ein Kraftfahrzeug ist, befindet sich dieses in der Regel
in einer Werkstatt, und der Techniker verfügt über einen Arbeitsplatzrechner,
der die Client-Seite (120) einer Client-Server-Diagnose-Anwendung
ausführt.
Der Arbeitsplatzrechner ist über
ein Netzwerk (115), bei dem es sich um ein Internet-Netzwerk handeln
kann, mit dem Diagnose-Server (110) verbunden. Der Techniker
wird über
einen Dialog dazu angeleitet, Elemente des Systems zu prüfen oder
in einen Zustand zu versetzen, der dem Diagnose-Server ermöglicht,
die richtigen Daten zu erhalten und Schlussfolgerungen bezüglich der
Lösung
zu ziehen. Dabei verwendet der Diagnose-Server eine Produktionsdatenbank
(100), um Diagnosedaten zu erhalten. Diese Datenbank (100)
ist ein Schatten des letzten betriebsfähigen Zustands der Datenbank
vor der Produktion (150), die auf einem Server (140)
mit einem Autorenwerkzeug erzeugt wird, welcher sich an einem vom Betriebsstandort
entfernten Standort befinden kann. Bei der bevorzugten Ausführungsform
ist das Autorenwerkzeug zur Erzeugung der Datenverarbeitungsumgebung
für die
Produktion eine Client-Server-Anwendung, wobei der Benutzer des
Autorenwerkzeugs in diesem Fall die Client-Anwendung (160)
mit dem Autorenwerkzeug an einem Standort verwendet, der entfernt
sein kann. Fachleute und für
die Wartung zuständige
Personen erhalten eine besondere Berechtigung für den Zugriff auf das Autorenwerkzeug,
um das System gemäß der bevorzugten
Ausführungsform
zu installieren und zu verwalten. Eine besondere Berechtigung für das System
wird einem Administrator (170) übertragen, der auf die Client-Anwendung
mit dem Autorenwerkzeug zugreift und außerdem für die Feinabstimmung der Parameter
der Diagnosedatenbank zuständig
ist, wobei er entscheiden kann, warm von der vorbetrieblichen zur
Betriebsdatenbank gewechselt wird. Der Arbeitsplatzrechner der Informationsstelle
tauscht mit den Endnutzern (den Technikern in den Werkstätten für die Kfz-Diagnose)
Daten aus, um so Unterstützung
bei der Verwendung der Diagnose-Client-Anwendung zu leisten und
die nicht gelösten
Fehler zu erfassen (wobei es grundsätzlich keinen Fall gibt, in
dem der Fehler von dem System nicht gelöst wird und das System nur
eine Näherungslösung nennt).
Die Informationsstelle tauscht mit dem Autorenwerkzeug-Server Daten
aus, um so den nicht gelösten
Fehler wiederzugeben, wobei die Wartungsmitarbeiter in diesem Fall die
Daten – falls
erforderlich mit Hilfe der Fachleute – abändern. Unter Umständen führt die
Informationsstelle die Client-Anwendung mit dem Autorenwerkzeug
nicht selbst aus, wie in 1 dargestellt, sondern der Zugriff auf
die von ihr eingegebenen Daten ist über die Client-Anwendung mit
dem Autorenwerkzeug möglich.
-
2 zeigt
die Softwareschichten in dem System, welches das Verfahren der bevorzugten
Ausführungsform
realisiert. Die Diagnose-Client-Anwendung (120) umfasst
eine erste Schicht, die Übertragungsverwaltungsschicht,
für den
Austausch von Daten mit dem nachgestellten Server. Die Diagnose-Client-Anwendung
(120) umfasst bei der bevorzugten Ausführungsform einen Standardbrowser,
um so über
das Internet-Netzwerk und eine Fahrzeug-Übertragungsverwaltung, die
den Datenaustausch zwischen der Anwendung und dem Pkw (130)
unterstützt,
Daten zu erfassen. Diese Schicht des Übertragungsprotokolls des automatisierten
Systems (130) unterstützt
allgemeiner gesprochen das System, das für die Befehls- und Datenerfassung
durch die Steuereinheit verwendet wird.
-
Auf
der Seite des Diagnose-Servers (110) ermöglicht die
Codier-/Decodiereinheit mit dem Fahrzeug-Übertragungsprotokoll (Vehicle
Communication Protocol, VCP) das Senden/Empfangen von Befehlen und
Daten an die/von der Client-Diagnose-Anwendung, die von dem Kfz
unmittelbar verstanden werden. Die Diagnose-Einheit bildet das Herz des Diagnoseverfahrens;
sie greift auf die Produktionsdatenbank (100) zu und verarbeitet
die Diagnoseregeln. Die Schicht für die Übertragungsverwaltung dient
dem Datenaustausch zwischen der Diagnose-Einheit und dem Diagnose-Client.
-
Die
Client-Anwendung (160) mit dem Autorenwerkzeug umfasst
einen Datenbankeditor für
das Ändern
der abgebildeten Netzwerkknoten und Pfeile der Vorproduktions-Diagnosedatenbank.
Sie umfasst außerdem
einen VCP-Editor für
die Erzeugung von Befehlen und Daten des Fahrzeug-Übertragungsprotokolls, die zur
Ausführung
der Diagnoseprüfungen
durch die Diagnose-Anwendung dienen.
-
3 zeigt
die Diagnoseschritte des Verfahrens, die von dem Bediener ausgeführt werden,
bei dem es sich um einen Werkstatttechniker handelt, welcher die
mit einem Kfz, das ein Fehlersymptom aufweist, verbundene Diagnose-Client-Anwendung
(120) verwendet. Der Bediener bereitet das Fahrzeug für die Diagnose (300)
vor, was bei der bevorzugten Ausführungsform darin besteht, das
Fahrzeug an einen PC anzuschließen, der
die Client-Diagnose-Anwendung ausführt, und den Zündschlüssel zu
drehen. Danach startet der Bediener die Diagnose-Client-Anwendungssitzung
(300). Die Diagnose-Anwendung ermittelt automatisch die
Fahrzeugkonfiguration (300), indem sie die Fahrzeugkennnummer
(Vehicle Identification Number, VIN) liest und anschließend – ausgehend
vom Typ des Fahrzeugs, der über
seine VIN eindeutig erkennbar ist, – eine Liste aller elektronischen
Steuereinheiten (Electronic Control Units, ECU) erzeugt, bei denen
es sich um die Steuereinheiten des Fahrzeugs handelt. Die Diagnose-Anwendung
erkennt automatisch alle ECUs des Fahrzeugs, indem sie eine VCP-Anforderung
sendet und auf eine positive Antwort wartet. Die Diagnose-Anwendung
ruft die Fahrzeugkonfigurationsdaten ab, die in Bord-ECUs verfügbar sind.
Mit Abschluss von Schritt 310 hat das System ein genaues
Bild der Fahrzeugkonfiguration geschaffen, indem es all diese erfassten
Daten miteinander verknüpft.
Darüber
hinaus wird auch die Auslieferungskonfiguration des Fahrzeugs, die
aus der Datenbank der End-Materialaufstellung verfügbar ist,
herangezogen, um die Fahrzeugkonfiguration weiter zu festigen. Dabei ist
zu beachten, dass es sich bei dieser Datenbank um eine Standarddatenbank
handelt, die von allen Fahrzeugherstellern unterhalten wird.
-
Über eine
grafische Benutzeroberfläche
seines Arbeitsplatzrechners wird der Techniker (120) zur
Auswahl des Fehlersymptoms (320) aufgefordert. Diese Eingabe
ist geleitet, da das Symptom zu einer Kategorie/Unterkategorie von
Symptomen gehört.
Auch wenn dies in 3 aus Gründen der Übersichtlichkeit nicht erwähnt ist,
ist zu beachten, dass der Techniker, wenn ein derartiges Symptom
nicht vom System vorgeschlagen wird, die Informationsstelle anrufen
muss und der Diagnosevorgang damit beendet ist. Wenn das Symptom
eingegeben wird, erzeugt die Diagnose-Anwendung automatisch einen
entsprechenden Symptomdiagnosebaum, der auf die Fahrzeugkonfiguration
abgestimmt ist. Ein Symptombaum wird erzeugt, indem die Funktionen
des Fahrzeugs ausgehend von der Fahrzeugkonfiguration verzweigt
werden. Dabei ist die Wurzel des Symptombaums ein Symptom, und von
der Wurzel zu den Blättern
verzweigt sich der Baum so lange in Funktionen und Teilfunktionen
usw., bis eine reparierbare Einheit erreicht wird, wobei die Blätter die
unterschiedlichen Fehlermodi sind, die dieser reparierbaren Einheit
zugehörig
sind. Wie weiter unten mit Bezug auf die 5 und 6 erläutert wird,
wird der Symptombaum aus einer Diagnosedatenbank erhalten, die alle
Symptombäume
enthält,
welche von den Verfassern der Diagnose-Inhalte erzeugt und verwaltet werden.
Zum Erzeugen des Symptombaums wählt
das System den betreffenden Symptombaum aus der Diagnosedatenbank aus
und entfernt die Knoten, die nicht der Fahrzeugkonfiguration entsprechen.
Die Eingaben des Systems für das
dynamische Erzeugen des Symptombaums bestehen sowohl aus der Diagnosedatenbank
als auch aus dem Bild der Fahrzeugkonfiguration, das nach dem Schritt
der Symptomauswahl durch den Bediener kurz zuvor durch das System
erzeugt wurde. In der Diagnosedatenbank können die Inhaltsverfasser jedem
Knoten Prüfungen
zuweisen: So kann jede(r) fehlerhafte Funktion, Teilfunktion, reparierbare
Einheit oder Fehlermodus geprüft
werden. Eine Prüfung
erfolgt automatisch, wenn sie keinen Eingriff durch den Bediener
erfordert mit Ausnahme der Herstellung eines Fahrzeugkontextes,
in dem die Prüfung
vorgenommen wird. Eine automatische Prüfung wird durchgeführt, indem
logische Ausdrücke
auf Grundlage von Parametern, die von den Steuereinheiten des Fahrzeugs
erhalten wurden, ausgewertet werden. Eine automatische Prüfung gilt
dann als positiv, wenn sie eine Annahme (dargestellt durch die/den
ihr zugewiesene(n) Funktion, Teilfunktion oder Fehlermodus) als
gültig
bestätigt.
Die Gültigkeitsbestätigung einer
automatischen Prüfung
erfolgt anhand einer Bestätigungsprüfung. Ein
Beispiel für
eine Bestätigungsprüfung zum
Bestätigen
einer automatischen Prüfung
besteht darin, die fehlerhafte Verdachtseinheit zu reparieren und
dann zu überprüfen, ob
das Symptom nicht mehr vorhanden ist.
-
Es
wird darauf verwiesen, dass die Kosten für eine Prüfung sehr viel höher ausfallen,
wenn sie nicht automatisch, sondern von Hand ausgeführt wird,
da dies das Eingreifen eines Technikers beinhaltet. Erhebliche Kostenunterschiede
gibt es auch zwischen verschiedenen Arten, mit denen ein Kontext
für eine
automatische Prüfung
hergestellt wird, die eine Maßnahme
durch den Bediener erfordern. Alle Daten zu den Kosten für eine Prüfoperation
werden von den Inhaltsverfassern als Parameter der Symptombaumknoten
eingegeben. Diese Parameter werden vom System dafür verwendet,
die Reihe der durchzuführenden
Prüfungen
ihrer Rangfolge nach zu ordnen. Die Diagnose-Anwendung entscheidet,
welche automatischen Prüfungen
durchgeführt
werden. Wie später
in Schritt 355 ersichtlich wird, können die Prüfungen in mehreren Durchläufen oder Phasen
erfolgen. Da bei automatischen Prüfungen der Bediener zunächst den
Kontext der Prüfung
festlegen muss, kann eine Prüfphase
so durchgeführt
werden, dass im Symptombaum Ergebnisse für automatische Prüfungen erzielt
werden, deren Kontext mit Blick auf niedrige Kosten festgelegt wurde,
während
ein Durchlauf für automatische
Prüfungen
mit einem Kontext für
hohe Kosten durchgeführt
wird. Ein Beispiel für
die Herstellung eines Kontextes mit niedrigen Kosten lautet „Zündung einschalten", da hierfür keine
Teile zerlegt werden müssen.
Nach dem gleichen Grundsatz sind viele Ausführungsformen des Verfahrens
möglich.
Bei der bevorzugten Ausführungsform
aus 4 gibt es einen letzten Durchlauf von Prüfungen,
bei denen es sich um die kostenaufwändigsten Prüfungen handelt, da sie auf
von Hand durchzuführenden
Verfahrensweisen beruhen, die durch den Bediener durchgeführt werden.
Wenn die zu diagnostizierende Einheit oder – allgemeiner ausgedrückt – das System
nicht in der Lage ist, Daten von internen Elementen zu erfassen
und/oder Daten mit dem Computer auszutauschen, beruhen die einzig
möglichen
Durchläufe
auf von Hand durchzuführenden
Verfahrensweisen, die bei den darauf folgenden Durchläufen immer
höhere
Kosten verursachen. 7 und spätere Figuren im vorliegenden
Dokument beschreiben, wie das System die Daten nutzt, die von für die Verwaltung zuständigen Personen
eingegeben und in den Symptombaumknoten gespeichert wurden, um so
verschiedene Prüfphasen
zu definieren, die Durchläufen
für die
Ausführung
von Prüflisten
entsprechen. Die Zuweisung einer Prüfungsrangfolge kann auf unterschiedlichen
Kriterien beruhen wie beispielsweise den Kosten oder der Häufigkeit,
mit der ein Fehlermodusknoten auftritt usw.
-
Mit
erneutem Blick auf Schritt (330), in dem Symptombaumknoten
für automatische
Prüfungen
ausgewählt
werden, gewinnt die Diagnose-Anwendung entsprechend der Konfiguration
des Fahrzeugs alle Parameter und Diagnosefehlercodes (Diagnostic
Trouble Codes, DTCs) aus dem Symptombaum, die aus dem zu untersuchenden
Fahrzeug ausgelesen werden müssen,
um die automatischen Prüfungen
in der Liste durchzuführen.
DTCs sind Fehlercodes, die im Speicher der ECUS gespeichert sind.
Diese Fehlercodes beschreiben das Ergebnis der eingebetteten Selbstdiagnose
der ECUs. Bei jeder Prüfung
muss der Bediener einen Kontext für das Fahrzeug herstellen (340).
Die Diagnose-Anwendung
führt die
automatischen Prüfungen
durch (345), indem sie logische Ausdrücke auswertet, die aus diesen
Parametern und DTCs erzeugt werden, und die Ergebnisse analysiert.
Wenn einer oder mehrere logische Ausdrücke wahr sind, wurde ein Fehler
gefunden (Antwort „Ja" auf Prüfung 350),
und das System erzeugt eine nach der Rangfolge geordnete Liste von
Bestätigungsprüfungen und
fordert den Bediener auf, sie durchzuführen (360). Jedem
Knoten des Symptombaums ist eine Bestätigungsprüfung zugewiesen und wird ausgeführt, um
einen Knoten (eine Funktion, Teilfunktion, reparierbare Einheit
oder einen Fehlermodus) auf seine Gültigkeit zu überprüfen. Bei
einer Bestätigungsprüfung handelt
es sich um eine Prüfung,
die auf einer von Hand durchgeführten
Verfahrensweise des Bedieners beruht, mit welcher der Bediener das
positive Ergebnis einer automatischen Prüfung auf seine Gültigkeit überprüft. Wenn
die automatische Prüfung
bestätigt
wurde (Antwort „Ja" auf Prüfung 370),
wurde eine fehlerhafte, reparierbare Einheit gefunden, der Techniker
wird aufgefordert, die fehlerhafte Einheit auszutauschen oder zu reparieren,
und die Diagnosesitzung wird danach beendet (380).
-
Die
Rangfolgenzuweisung der Bestätigungsprüfungsliste
beruht auf Algorithmen, die das System auf Grundlage der Parameter
berechnen kann, die in dem Knoten des Symptombaums gelesen wurden.
Bei diesen Parametern kann es sich um die Prüfungskosten oder die Häufigkeit
handeln, mit der ein Fehlermodusknoten auftritt usw. Dabei ist zu
beachten, dass diese Eingaben von den für die Verwaltung zuständigen Personen
eingegeben werden können,
welche die Diagnosedatenbank pflegen, oder dass sie automatisch
durch das System verwaltet werden können.
-
Unter
Umständen
wird nach Durchführung
aller automatischen Prüfungen
(Antwort „Ja" auf Prüfung 355)
kein zu lesender Parameter oder DTC in dem Diagnosebaum gefunden
(Antwort „Nein" auf Prüfung 350), der
zu der Fahrzeugkonfiguration gehört.
Außerdem
kann es vorkommen, dass die Bestätigungsprüfung nicht erfolgreich
ist (Antwort „Nein" auf Prüfung 370)
und dass keine weitere Prüfung
in der Liste der Prüfungen durchzuführen ist
(Antwort „Ja" auf Prüfung 355).
In beiden Fällen
kann das System den Symptombaum erneut lesen (Antwort „Ja" auf Prüfung 375)
und eine neue Liste mit Prüfungen
berechnen. So kann die Anwendung beispielsweise einen ersten Durchlauf
automatischer Prüfungen
durchgeführt
haben, bei denen der Kontext mit Blick auf niedrige Kosten hergestellt
wurde, und einen zweiten Durchlauf automatischer Prüfungen durchführen, bei
denen der Kontext mit Blick auf hohe Kosten hergestellt wurde. Grundsätzlich sind
alle Kombinationen möglich,
die auf Algorithmen beruhen, bei denen Berechnungen der Parameter
von Symptombaumknoten zum Einsatz kommen.
-
Wenn
das System bei der bevorzugten Ausführungsform nicht entscheidet,
dass ein neuer Durchlauf automatischer Prüfungen durchgeführt wird,
trifft es die Entscheidung, dass eine neue Liste von Prüfungen erstellt
wird, bei denen es sich um Bestätigungsprüfungen handelt,
die Verfahrensweisen entsprechen, welche ausschließlich von
Hand durchgeführt
werden. Diese Prüfungen
sind meist kostenaufwändig
und können
bei dieser Ausführungsform
unter Verwendung des Grundsatzes möglicher Prüfungsdurchläufe so lange hinausgezögert werden,
bis alle weniger kostenträchtigen
automatischen Prüfungen
durchgeführt
wurden.
-
Eine
Ausführungsform,
die sich auf ein zu diagnostizierendes System bezieht, das keine
Daten von internen Elementen erfassen und/oder keine Daten mit dem
Computer austauschen kann, umfasst lediglich die Durchführung der
Prüfungen
aus 4, d. h. von Hand durchgeführte Prüfungen.
-
Wenn
eine automatische Prüfung
ein positives Ergebnis erbringt (Antwort „Ja" auf Prüfung 410), wird der
Techniker von der Anwendung dazu angeleitet, die zugehörigen Bestätigungsprüfungen für das Fahrzeug durchzuführen, um
die Diagnose der Diagnose-Anwendung zu bestätigen. Wenn eine Bestätigungsprüfung ein positives
Ergebnis hat (Antwort „Ja" auf Prüfung 410),
wurde eine fehlerhafte, reparierbare Einheit gefunden, der Techniker
erhält
als Lösung
den Austausch der reparierbaren Einheit, und die Diagnosesitzung
wird beendet (445). Wenn keine Bestätigungsprüfung ein positives Ergebnis
erbringt (Antwort „Nein" auf Prüfung 410) und
alle Bestätigungsprüfungen der
Liste abgeschlossen sind (Antwort „Ja" auf Prüfung 415), wurde von
der Anwendung keine Diagnose gefunden, die diesem Fahrzeug und dem
Symptom entspricht, und der Bediener informiert (440) die
Informationsstelle über
diesen Fall und beendet die Diagnosesitzung (445).
-
Die
von der Informationsstelle ausgeführten Operationen sind in der
Technik hinreichend bekannt. Wenn ein Symptom oder eine Diagnose
von der Anwendung nicht gefunden wird, werden die Daten zu dem Fall
von der Informationsstelle eingegeben und an die Personen weitergeleitet,
welche die Anwendung verwalten. In der Diagnosedatenbank muss dann
ein neuer Symptombaum oder ein neuer Zweig eines bestehenden Symptombaums
hingefügt
werden. Auf diese Weise stellt die Diagnose-Anwendung im Gegensatz
zum CBR-Ansatz keine Diagnose mit einem statistischen Näherungswert,
sondern eine genaue Diagnose bereit, wobei dies selbst dann der
Fall ist, wenn die Schlussfolgerung „Fehler ist dem System unbekannt" lauten kann.
-
Dabei
ist zu beachten, dass ein Kriterium für die Zuweisung einer Rangfolge
zu durchzuführenden
Prüfungen
in der statistischen Häufigkeit
bestehen kann, mit der ein Fehlermodus auftritt. Diese Häufigkeit
kann als ein Knotenparameter gespeichert werden; anstatt jedoch
diesen Parameter durch Inhaltsverfasser, welche die Diagnosedatenbank
pflegen, eingeben zu lassen, kann er durch das System immer dann
erzeugt und aktualisiert werden, wenn die Gültigkeitsprüfung eines Fehlermodusknotens
ein positives Ergebnis erbringt. Somit verbessert sich das Diagnoseverfahren
der bevorzugten Ausführungsform
nicht nur durch Verwendung einer Informationsstelle, sondern es
lässt sich
auch – ausgehend
von in der Vergangenheit erfolgreich vorgenommenen Diagnosesitzungen – automatisch
verbessern. Die Verwendung derartiger Statistikdaten macht einige
interessante Verhaltensweisen der diagnostizierten Systeme deutlich:
Ein und derselbe Symptombaum, der einer Funktion des Fahrzeugs entspricht,
kann je nach Modell des Fahrzeugs unterschiedlich ausfallen, wobei
dieselbe Funktion verwendet wird. In diesem Zusammenhang ist zu
beachten, dass z. B. ein und derselbe Motor, der in verschiedenen
Fahrzeugen eingebaut ist, unterschiedliche Statistikdaten für denselben Ausdruck
eines Symptoms aufweisen kann, da er in den verschiedenen Fahrzeugen
physikalisch unterschiedlich realisiert wurde.
-
5 ist
ein Beispiel für
einen Symptombaum der Diagnosedatenbank, der von der Diagnose-Anwendung
erzeugt und von der Diagnose-Einheitenschicht der Anwendung gelesen
wird. Anhand dieses Baums wird das kleinste reparierbare oder austauschbare
Teil gefunden, das einem Fehler in einem Fahrzeug entspricht, der
durch ein gegebenes Symptom festgestellt wird. Dabei ist die Wurzel
des Baums das Symptom, das über
Teilbäume
verfügt,
die einer Funktionszerlegung des Fahrzeugs entsprechen. Dies unterscheidet
sich von dem Baum, wie er bei den Diagnoseverfahren nach dem Stand
der Technik zum Einsatz kommt, bei dem jeder Knoten eine mögliche Ursache
für den
Fehler darstellt. Die Funktionsbäume
haben den Vorteil, dass ihre Erzeugung auf der Kenntnis der Fahrzeugstruktur
beruht, nicht jedoch auf dem Wissen oder der Erfahrung des Technikers,
der über
die Kenntnisse zur Bereitstellung einer Fahrzeugdiagnose verfügt. Beim
Baum aus 5 sind dem Ausgangssymptom „Motor
startet nicht" zwei
Funktionen zugeordnet: die Funktionen „Elektrik" und „Mechanik". Die im Zusammenhang mit dieser Funktion
entwickelten Funktionsbäume
(500, 510) wurden vereinfacht, da sie lediglich
eine Ebene der Teilfunktion (515, 520, 525)
umfassen, die jedem der Funktionsbäume zugehörig ist. In der Realität können Funktionsbäume mehrere
Ebenen von Teilfunktionen aufweisen, bevor die Blätter erreicht
sind. Die Blätter
der Funktionsbäume
stellen die letzte Ebene der Zerlegung dar, die reparierbare oder
austauschbare Einheit (530, 535, 540, 545).
Jeder reparierbaren oder austauschbaren Einheit sind ein oder mehrere
Fehlermodi (550, 555, 560, 565, 570, 575, 580)
zugehörig.
Die Daten, die diese Bäume wie
beispielsweise denjenigen aus 5 bilden,
werden von den Bedienern des Autorenwerkzeugs eingegeben. Die in
die Diagnosedatenbank eingegebenen Daten stammen aus der Funktionsbeschreibung
des Fahrzeugs. Um diese Daten zu erzeugen, wird kein besonderes
Fachwissen zu Fehlern und Diagnose des Fahrzeugs benötigt.
-
Bei
der bevorzugten Ausführungsform
sind jedem Funktions- bzw. jedem für eine reparierbare Einheit stehenden
Knoten des Baums drei Attribute zugehörig: Das Merkmalsmodell, eine
automatische Prüfung
und eine Bestätigungsprüfung. Das
Merkmalsmodell wird bei dem Diagnoseverfahren an erster Stelle verwendet, da
es dem Fahrzeugelement eine Beschreibung des Fahrzeugtyps zuordnet.
Wie mit Blick auf 3 beschrieben, besteht der erste
Schritt des Diagnoseverfahrens (300) in einer Ermittlung
der Fahrzeugkonfiguration: Dabei werden sowohl der Fahrzeugtyp als
auch alle Optionen, die seine Konfiguration definieren, ermittelt.
Hierfür wird
das Merkmalsmodell für
alle Funktionen und reparierbaren Einheiten, die das Fahrzeug ausmachen,
auf seine Gültigkeit überprüft. Auf
diese Weise lässt
sich ein ausufernder theoretischer Ausgangsbaum vermeiden, der alle
Optionen und Fahrzeugtypen sowie alle Funktions- oder für eine reparierbare
Einheit stehenden Knoten aufweist, die ein anderes Merkmalsmodell
haben, als dies während
des Schritts der Ermittlung der Fahrzeugkonfiguration (300)
festgestellt wurde.
-
Eine
automatische Prüfung
ist eine Prüfung,
die automatisch mit Hilfe einer Steuereinheitskomponente des Fahrzeugs
erfolgen kann. Wie bereits erwähnt,
ist eine auch als ECU bezeichnete Steuereinheitskomponente in der
Lage, von Sensoren bereitgestellte Parameter des Fahrzeugs zu überprüfen. Allerdings
kann eine automatische Prüfung
nur dann stattfinden, wenn der Fahrzeugkontext hergestellt wurde.
Die Diagnose-Anwendung leitet den Techniker in der Werkstatt dazu
an, den Kontext für
das Fahrzeug herzustellen: Beispiele hierfür sind „Motor ausschalten", „Fahrertür öffnen" usw. Ein Beispiel
für eine
automatische Prüfung
kann lauten „Prüfe, ob Batteriespannung über 8,5
Volt liegt". In
der Diagnosedatenbank kann diese Prüfung mit dem Autorenwerkzeug
als der Ausdruck „SPANNUNG_BATTERIE,
CMM] > 8,5" codiert werden.
Dabei ist ebenfalls zu beachten, dass die Prüfausdrücke Ausdrücke umfassen können, die
logischen Operatoren wie beispielsweise ODER und/oder UND, NICHT
usw. entsprechen. Wenn die Diagnose-Einheit beim Lesen des Baums auf
diese Prüfung
stößt, übergibt
sie den Ausdruck an die anderen Schichten der Anwendung, um ihn
unter Verwendung des VCP-Protokolls in eine Anforderung umzuwandeln,
die von den Fahrzeugkomponenten verstanden werden kann. Diese Anforderungen
werden dann an das Fahrzeug gesendet und von den ECUs ausgeführt. Bei
dem codierten Prüfausdruck
ist „CMM" eine ECU, aus der
das System einen Parameter ausliest, „SPANNUNG_BATTERIE" ist der Parameter,
und „> 8,5" ist die Prüfoperation.
Dabei ist zu beachten, dass das Ergebnis einer automatischen Prüfung zwar
einen guten Hinweis darauf geben kann, wo der Fehler angesiedelt
ist, hierfür
jedoch keinen Beweis liefert. Daher werden auf Fehlermodusebene
durchgeführte
automatische Prüfungen
mit einem positiven Ergebnis stets durch eine Bestätigungsprüfung bestätigt. Bei
der bevorzugten Ausführungsform
ist eine Bestätigungsprüfung auf
Funktionsknotenebene wahlfrei und auf Fehlermodusebene zwingend
vorgeschrieben.
-
Wenn
das Ergebnis der Bestätigungsprüfung WAHR
lautet, endet das System hier, sofern keine weiteren Bestätigungsprüfungen in
tieferen Knoten vorhanden sind. Wenn das Ergebnis der Bestätigungsprüfung FALSCH
lautet, fährt
das System in dieser Richtung des Baums nicht weiter fort. Die Bestätigungsprüfungen werden über das
Autorenwerkzeug in Form eines Textausdrucks in die Datenbank eingegeben.
-
In
der Baumstruktur erben tiefere Knoten automatische Prüfungen von
ihren Stammknoten. Dabei wird die automatische Prüfung eines
Knotens anhand einer logischen UND-Operation mit sämtlichen
von ihm geerbten automatischen Prüfungen kombiniert. Wenn z.
B. auf Ebene des Funktionsknotens (515, 520, 525)
der logische Prüfausdruck „Parameter
A: x > 6" lautet, dann wird
Parameter A = WAHR an die tieferen Ebenen weitergegeben und als
geerbt gekennzeichnet. Wenn in einem Fehlermodusknoten (550 bis 580)
ein ursprünglicher
logischer Ausdruck einer Prüfung „Parameter
B: p < 4000" lautet und wenn
dieser Ausdruck WAHR ist, dann lautet der tatsächliche logische Ausdruck,
der für
diesen Fehlerknotenmodus WAHR ist, A UND C, d. h. „Parameter
A: x > 6" UND „Parameter
B: p < 4000".
-
Das
Ergebnis der Auswertung einer automatischen oder Bestätigungsprüfung lautet
entweder WAHR, FALSCH oder NICHT DEFINIERT. Eine automatische Prüfung wird
auf NICHT DEFINIERT gesetzt, wenn bei ihrer Auswertung ein Fehler
aufgetreten ist (im Allgemeinen infolge eines Fehlers beim Datenaustausch
mit der ECU). Das Ergebnis einer Bestätigungsprüfung wird vom Techniker dann
auf NICHT DEFINIERT gesetzt, wenn er die Antwort nicht kennt (z.
B. bei einer Prüfung,
die innerhalb des gegebenen Kontextes nicht durchführbar ist).
Wenn ein Teilausdruck eines logischen Ausdrucks NICHT DEFINIERT
ist, ist das Ergebnis der Auswertung des vollständigen Ausdrucks abhängig von
dem verwendeten logischen Operator: Wenn A NICHT DEFINIERT ist,
dann ist das Ergebnis des logischen Ausdrucks A ODER B gleich der
Auswertung von B. Wenn A oder B NICHT DEFINIERT sind, dann erbringt
die Auswertung des logischen Ausdrucks A UND B das Ergebnis NICHT
DEFINIERT. Wenn A NICHT DEFINIERT ist, hat der Ausdruck NICHT(A)
das Ergebnis NICHT DEFINIERT.
-
Das
Ergebnis einer Bestätigungsprüfung ist
von der Antwort des Technikers abhängig, der die Bestätigungsprüfung durchgeführt und
das Ergebnis in die Client-Diagnose-Anwendung eingegeben hat. Das
Ergebnis einer automatischen Prüfung,
die einen logischen Ausdruck überprüft, beruht
auf einem Algorithmus, der auf die Erfordernisse des Verwenders/Eigentümers des
Diagnoseverfahrens abgestimmt werden kann. Diese Auswahlmöglichkeit
ist insofern flexibel, als sie die Kosten einer Prüfung, die
Kosten für
eine austauschbare Komponente, die Anzahl der positiven Prüfungsergebnisse
usw. berücksichtigen
kann. Anhand dieses Gewichtungsparameters der Prüfung wählt die Diagnose-Einheit die
Rangfolge der Knoten aus, die während späterer absteigender
Lese-Operationen des Baums, die weiter unten mit Bezug auf 7 erläutert werden, aus
dem Baum ausgelesen werden sollen. So sollte z. B. einem Knoten,
in dem der Prüfausdruck
wiederholt als WAHR bestätigt
und entsprechend gespeichert wurde, bei der Prüfung Vorrang eingeräumt werden,
da die Prüfung
mit höherer
Wahrscheinlich ein positives Ergebnis erbringt. Aus diesem Grund
kann das Ergebnis WAHR bei einer Ausführungsform abgeändert werden,
indem es mit „WAHRHEITS-Prozentsatz" und einer Gewichtung
für WAHR
näher bestimmt
wird. Dabei gibt „WAHRHEITS-Prozentsatz" den Prozentsatz
des gesamten Ausdrucks an, der überprüft wurde.
Seine Berechnung erfolgt unter Verwendung der WAHRHEITS-Gewichtung:
Wenn z. B. zwei Bestandteile einer logischen ODER-Verknüpfung WAHR
sind, dann hat die WAHRHEITS-Gewichtung
den Wert 2, wobei es sich um die Anzahl der Parameter handelt, die
den Ausdruck WAHR sein lassen. Die WAHRHEITS-Gewichtung beträgt in diesem
Fall 100%. Auf Fehlermodusebene wird die WAHRHEITS-Gewichtung durch
das Ergebnis der automatischen Prüfungen der Stammknoten beeinflusst,
da die tieferen Knoten das Ergebnis der Ausdrücke von den Stammknoten erben.
-
Ein
Beispiel für
diese Ausführungsform
gibt 6, welche die logischen Ausdrücke von automatischen Prüfungen für denselben
Beispielbaum wie in 5 darstellt. Wenn in dieser
Figur C, G und H WAHR und B, D, E und F FALSCH sind, dann lauten
die WAHRHEITS-Gewichtungen und WAHRHEITS-Prozentsätze (abgeleitet
aus den WAHRHEITS-Gewichtungen) wie folgt:
- – Das Ergebnis
der automatischen Prüfung
für den
Fehlermodus 1 hat eine WAHRHEITS-Gewichtung von 2 und einen WAHRHEITS-Prozentsatz von 67%.
- – Das
Ergebnis der automatischen Prüfung
für den
Fehlermodus 2 hat eine WAHRHEITS-Gewichtung von 1 und einen WAHRHEITS-Prozentsatz von 100%.
- – Das
Ergebnis der automatischen Prüfung
für den
Fehlermodus 3 hat eine WAHRHEITS-Gewichtung von 1 und einen WAHRHEITS-Prozentsatz von 50%.
- – Das
Ergebnis der automatischen Prüfung
für den
Fehlermodus 4 hat eine WAHRHEITS-Gewichtung von 1 und einen WAHRHEITS-Prozentsatz von 50%.
- – Das
Ergebnis der automatischen Prüfung
für den
Fehlermodus 5 hat eine WAHRHEITS-Gewichtung von 2 und einen WAHRHEITS-Prozentsatz von 100%.
-
7 ist
eine Darstellung der Parameter, die den Knoten eines Symptombaums
gemäß der bevorzugten
Ausführungsform
zugehörig
sind. Einige in den Knoten gespeicherte Parameter werden dazu verwendet, das
Fahrzeug in der bevorzugten Ausführungsform
kenntlich zu machen. Im Knoten 702 lautet der Motorentyp „Benziner". Andere Parameter
sind für
Prüfungen
vorgesehen: Bei den Ausdrücken
in den Knoten 760 und 720 handelt es sich um automatische
Prüfungen.
In den Knoten 750, 755, 760, 765, 770 wird
der Häufigkeitsparameter
im Gegensatz zu den anderen Parametern nicht von den Personen eingegeben,
die den Inhalt verfassen, sondern vom System aktualisiert: Er steht
für die
Häufigkeit,
mit welcher der entsprechende Knoten anhand einer Ausführung der
Diagnosesitzung als das fehlerhafte Teil ermittelt wurde. Im Allgemeinen
werden die Parameterwerte dazu verwendet, die Art und Weise anzupassen,
in welcher der Symptombaum gelesen und die Prüfungsreihenfolge festgelegt
wird.
-
8 ist
das allgemeine Ablaufdiagramm des Verfahrens der Diagnose gemäß der bevorzugten
Ausführungsform.
Gegenüber
dem Ablaufdiagramm aus 3 und 4 stellt 7 die
Schritte des Verfahrens dar, die von dem System ausgeführt werden,
um die Symptombäume
zu erzeugen und die verschiedenen Prüfungsdurchläufe auszuwählen. Bei der bevorzugten Ausführungsform
werden die Phasen optimiert, um innerhalb kürzester Zeit eine Diagnose
zu erhalten. Dabei ist zu beachten, dass eine Diagnose umso schneller
erhalten wird, je mehr Daten die Bäume enthalten und je besser
die Phasen optimiert sind.
-
Noch
allgemeiner ist zu beachten, dass das Verfahren umso besser ist,
je komplexer das zu diagnostizierende System ist. Wie weiter oben
im Dokument bereits erläutert,
umfasst beispielsweise das Verfahren, das sich auf ein System bezieht,
welches keine Steuereinheit beinhaltet, die Daten von internen Elementen erfassen
und mit dem Computer austauschen kann, lediglich von Hand durchgeführte Prüfungen.
Selbst in diesem Fall kann das Verfahren der bevorzugten Erfindung
jedoch teilweise auf die von Hand durchzuführende Prüfung angewendet werden, um
so die Diagnose-Ermittlung zu optimieren. So können z. B. abhängig von
der Schwierigkeit und damit von den Kosten der Prüfungen zwei
Prüfungsdurchläufe für von Hand
durchzuführende
Prüfungen
geplant werden. In einem Symptombaum kann eine von Hand durchgeführte Prüfung an
einem Knoten einen Wert des „Schwierigkeitsparameters" von „Hoch" oder „Gering" aufweisen: Dabei
erfolgt ein erster Prüfungsdurchlauf
mit Prüfungen
eines geringen Schwierigkeitsgrads, und wenn kein Fehler gefunden
wird, kann ein zweiter Durchlauf mit den Prüfungen mit hohem Schwierigkeitsgrad
erfolgen. Wenn das System bei jeder Diagnosesitzung automatisch
die Häufigkeit
eines Fehlermodusfehlers zählt
und im Fehlermodusknoten speichert, kann der Häufigkeitswert außerdem dazu
herangezogen werden, einen Prüfungsdurchlauf
mit Prüfungen
für diejenigen
Fehlermodusknoten durchzuführen,
welche die höchsten
Häufigkeitswerte
aufweisen.
-
Mit
erneutem Blick auf die bevorzugte Ausführungsform des Ablaufdiagramms
aus 8 kann die Diagnosesitzung beginnen, wenn der
Werkstatttechniker ein Eingabesymptom (805) ausgewählt hat.
Die Diagnose-Einheit, bei der es sich um das Programm handelt, welches
das Verfahren der bevorzugten Ausführungsform realisiert, hat
an diesem Punkt bereits das Fahrzeug ermittelt (800) und
den Symptombaum erzeugt, indem sie relevante Baumknoten für Funktionen,
reparierbare oder austauschbare Einheiten und Fehlermodi in Übereinstimmung
mit dem Fahrzeugtyp und den Fahrzeugfunktionen, welche dem Symptom
entsprechen, beibehalten oder nicht relevante Baumknoten entfernt
hat. Wie weiter oben in dem Dokument bereits erläutert, kann es sich bei den
Daten, welche Symptombaumknoten zugehörig sind, um Bestätigungsparameter und/oder
Beschreibungsparameter für
automatische Prüfungen
(auf der Ebene des Funktions-, Teilfunktions- und Fehlermodus von
Knoten reparierbarer Einheiten, nicht jedoch auf der Ebene der Knoten
selbst) sowie um anderweitige Parameter handeln, welche die Fahrzeugkonfiguration,
den Prüfwert,
den Häufigkeitszählwert für Fehler
in einem Fehlermodusknoten usw. angeben. Die Diagnose-Einheit geht
in aufeinander folgenden Schritten vor, die in Prüfungsdurchläufe unterteilt
sind, welche zwei Hauptphasen bilden, wobei innerhalb jeder Phase
unterschiedliche Techniken angewendet werden, um so schneller zu
dem Fehlermodus zu gelangen. Sobald die Diagnose-Einheit eine auf
ihre Gültigkeit überprüfte Fehlerursache
findet (d. h. einen Fehlermodus, bei dem das Ergebnis der zugehörigen Bestätigungsprüfung WAHR
lautet), endet die Diagnosesitzung (895). Unter Umständen ist
der in dem diagnostizierten System vorhandene Fehler jedoch nicht
in der Datenbank aufgeführt:
In diesem Fall endet die Sitzung ebenfalls, wobei das Ergebnis jedoch
lautet „Fehler
nicht gefunden" (885).
In diesem besonderen Fall ist der Techniker aufgefordert, die technische
Informationsstelle anzurufen, die dann die Diagnosesitzung aus der
Ferne fortführt.
In diesem Fall kann die Sitzung auf Funktionsebene enden (selbst
wenn ihr eine Bestätigungsprüfung mit
einem Ergebnis WAHR zugehörig
ist), wodurch angegeben wird, dass der Fehler zwar mit dieser Funktion
in Zusammenhang steht, jedoch im Inhalt nicht definiert ist.
-
Die
Diagnosesitzung ist in zwei Hauptphasen unterteilt. In der ersten
Phase, Phase A, untersucht die Diagnose-Einheit die Datenübertragungsfunktionen
der Bordelektronik, und in der zweiten Phase, B, werden verschiedene
Ansätze
verwendet, die im Wesentlichen auf Bestätigungsprüfungen beruhen. Eine Bestätigungsprüfung ist
entweder eine von Hand durchgeführte,
zwingend vorgeschriebene Prüfung,
mit der ein positives Ergebnis einer automatischen Prüfung bestätigt wird,
oder aber eine vollständig
von Hand durchgeführte
Prüfung,
mit der ein Knoten des Symptombaums bestätigt wird.
-
Phase
A ist in vier Teilphasen untergliedert, die wiederum abhängig vom
Prüfungskontext
und der Ebene des Symptombaums, auf welcher Prüfungen durchgeführt werden,
weiter unterteilt sind. Dabei besteht der Kontext aus Operationen,
die von Hand durch den Techniker ausgeführt werden und so die Ausführung einer automatischen
Prüfung
des Fahrzeugs ermöglichen.
Der Techniker stellt einen bestimmten Fahrzeugkontext her, bevor
die automatische Prüfung
durchgeführt
werden kann. In der Realität
können
in dem Symptombaum mehrere automatische Prüfungen ein und desselben Kontext
erfordern. Aus diesem Grund führt
der Computer, nachdem der Techniker einen gegebenen Kontext festgelegt
hat, alle automatischen Prüfungen
eines Prüfungsdurchlaufs
aus, die diesem Kontext entsprechen.
-
Dabei
wird daran erinnert, dass es sich bei einer Ausführung einer automatischen Prüfung, die
einem Knoten zugehörig
ist, tatsächlich
um eine Bewertung des logischen Ausdrucks handelt, die diesem Knoten
zugehörig
ist. Somit ist die Ausführung
des automatischen Prüfungsdurchlaufs
eine Abfolge aus einem Schritt, der von dem Techniker durchgeführt wird,
um das Fahrzeug in einen Kontext zu stellen, und den nachfolgenden
Schritten, mit denen alle logischen Ausdrücke des Knotens des Symptombaums
ausgewertet werden, für welche
der gleiche Kontext hergestellt werden muss.
-
In
Phase A1a (810) werden die automatischen Prüfungen auf
Funktions- und Fehlermodusebene mit Blick auf Kontexte mit niedrigen
Kosten ausgewertet. Ein Kontext mit niedrigen Kosten kann beispielsweise lauten „Zündung einschalten", wobei es sich eindeutig
um eine einfache Anforderung handelt, die keine Zerlegung von Teilen
notwendig macht. Jede Prüfung
gibt ein Ergebnis „Wahr", „Falsch" oder „Nicht
definiert" zurück. Die
Diagnose-Einheit analysiert die Ergebnisse, behält die Knoten, welche einen
Wahrheitsprozentsatz des logischen Ausdrucks von 100% zurückgeben,
und entfernt die Knoten, deren Wahrheitsprozentsatz unter 100% liegt,
sowie diejenigen, die einen Komponentenaustausch erfordern. Danach
muss für
die ausgewählten Knoten
eine Bestätigungsprüfung durchgeführt werden.
Die Diagnose-Einheit sortiert die Bestätigungsprüfungen in einer der Rangfolge
nach geordneten Liste, wobei eine Formel zum Einsatz kommt, die
Folgendes berücksichtigt:
- – die
Schwierigkeit ihrer Durchführung
- – die
Häufigkeit
und/oder die Wahrscheinlichkeit, mit welcher der Fehlermodus auftritt
- – die
Wahrheitsgewichtung.
-
Wenn
das Ergebnis einer Bestätigungsprüfung WAHR
lautet, hat die Diagnose-Einheit die Ursache des Symptoms gefunden
und endet (Antwort „Ja" auf Prüfung 815).
Wenn alle Ergebnisse FALSCH lauten (Antwort „Nein" auf Prüfung 815), fährt die
Diagnose-Einheit mit der nächsten
Prüfungsphase,
A1b, fort.
-
Das
gleiche Ablaufdiagramm der Prüfungsphase,
das in 8 für
Phase A1a (810, 815, 895) abgebildet
ist, wird wiederholt, wobei es in 8 für die anderen
Prüfungsphasen
(A1b, A2b, A3, A4a, A4b, B1) jedoch nicht vollständig dargestellt ist.
-
Mit
erneutem Blick auf die Prüfungsphase
Alb wird für
diese Prüfungsphase
dieselbe Verfahrensweise verwendet wie für Phase A1a mit der Ausnahme,
dass sie mit einem abwärts
gerichteten Ansatz erfolgt, der auf Funktionsebene beginnt und bis
auf Fehlermodusebene absteigt. Diese Verfahrensweise wird für jeden Kontext
mit niedrigen Kosten befolgt. In Phase Alb ordnet die Diagnose-Einheit
die Bestätigungsprüfungen unter
Verwendung derselben Formel, wie sie in A1a auf Fehlermodus- und Funktionsebene
zum Einsatz kam, wobei die Formel Folgendes berücksichtigt:
- – die Schwierigkeit
ihrer Durchführung
auf Funktionsebene
- – die
Häufigkeit
und/oder die Wahrscheinlichkeit, mit welcher der Fehlermodus auf
der Ebene des Kindknotens auftritt
- – die
Wahrheitsgewichtung auf Funktionsebene.
-
Die
Phasen A2a und A2b folgen derselben Verfahrensweise wie A1a und
Alb mit der Ausnahme, dass die Reihenfolge der automatischen Prüfungen für Kontexte
mit hohen Kosten festgelegt wird. Die Phasen A2a und A2b verwenden
dieselbe Formel wie die Phasen A1a und A1b.
-
Die
Phase A3 betrifft alle verbleibenden Bestätigungsprüfungen auf Fehlermodusebene,
deren automatische Prüfungen
für alle
Kontexte zu 100% wahr waren, wobei sich dies jedoch auf reparierbare
Einheiten bezieht, die dahingehend gekennzeichnet sind, dass ihr
Austausch notwendig ist um sicherzustellen, dass sie nicht funktionieren.
Dabei berücksichtigt
die Formel, mit der die Prüfungen
ihrer Rangfolge nach geordnet werden, folgende Variablen:
- – die
Schwierigkeit ihrer Durchführung
- – die
Häufigkeit
und/oder Wahrscheinlichkeit, mit welcher der Fehlermodus auftritt
- – die
Wahrheitsgewichtung
- – die
Kosten der Komponente, die ausgetauscht werden muss, um die Bestätigungsprüfung durchführen zu
können.
-
Nach
Abschluss von Phase A3 wurden alle automatischen Prüfungen,
deren logische Ausdrücke
zu 100% wahr waren, durchgeführt
(für Kontexte
mit hohen und niedrigen Kosten sowie für sämtliche Ebenen des Symptombaums).
Daher werden in Phase A4 Bestätigungsprüfungen ausgeführt, deren
logische Ausdrücke nicht
zu 100% wahr waren, sondern die im Autorenwerkzeug dahingehend gekennzeichnet
waren, dass sie als nicht 100% wahre logische Ausdrücke zur
Auswahl stehen. Dabei verwenden die Phasen A4a und A4b dieselbe
Formel wie die Phasen A1a und Alb.
-
Phase
B ist in zwei Teilphasen, B1 und B2, untergliedert. In Phase B1
werden Bestätigungsprüfungen unter
Verwendung eines abwärts
gerichteten Ansatzes durchgeführt.
Auf Fehlermodusebene wird die Reihenfolge der Bestätigungsprüfungen von
den folgenden Variablen bestimmt:
- – Schwierigkeit
der Bestätigungsprüfung
- – Faktor
für die
Häufigkeit
des Auftretens und/oder die Wahrscheinlichkeit.
-
Auf
Funktionsebene wird die Reihenfolge der Bestätigungsprüfungen von den folgenden Variablen
bestimmt:
- – Schwierigkeit
der Bestätigungsprüfung auf
Funktionsebene
- – Faktor
für die
Häufigkeit
des Auftretens und/oder die Wahrscheinlichkeit auf Ebene des untersten
Kindknotens.
-
Phase
B2 (875) geht insofern über
B1 hinaus, als sie sich auf Fehlermodi bezieht, die dahingehend gekennzeichnet
wurden, dass sie den Austausch reparierbarer Einheiten beinhalten.
Dabei wird die Reihenfolge der Bestätigungsprüfungen von den folgenden Variablen
bestimmt:
- – Schwierigkeit
der Prüfung
- – Faktor
für die
Häufigkeit
des Auftretens und/oder die Wahrscheinlichkeit
- – Kosten
der Komponente, die ausgetauscht werden muss, um die Bestätigungsprüfung durchzuführen.
-
Wenn
kein Ergebnis einer Bestätigungsprüfung WAHR
ist (Antwort „Ja" auf Prüfung 815),
hat die Diagnose-Einheit die Ursache des Symptoms nicht gefunden
und endet. Diese Informationen werden – ohne dass dies in dem Ablaufdiagramm
abgebildet sind, da es einer Unzulänglichkeit des Symptombaums
entspricht – an eine
Informationsstelle übergeben,
die dies an die Fachleute für
Fahrzeugtechnik weiterleitet, die einen Fehler finden, der diesem
Symptom entspricht. Die Inhaltsverfasser aktualisieren dann die
Symptombaumdatenbank entsprechend, sodass die nächste Diagnosesitzung in der
Lage ist, dieses Symptom erfolgreich zu diagnostizieren.
-
Um
die Leistungsfähigkeit
des Diagnoseverfahrens zu verbessern, können bei der Behandlung konkreter
Fälle wahlweise
auch bestimmte Knotenbeziehungen in der Diagnose-Einheit verwendet werden.
-
Ein
Beispiel hierfür
lautet: Wenn ein ermittelter Fehlerknotenmodus FM1 zu einer Funktion
A gehört, die
von einer Funktion B impliziert wird, dann muss die Bestätigungsprüfung von
Funktion B (die aufgrund der Implikationsverknüpfung vorhanden ist) vor der
Bestätigungsprüfung von
FM1 stattfinden. Dabei gibt es zwei Fälle:
- – Wenn die
Bestätigungsprüfung von
Funktion B wahr ist, behält
die Diagnose-Einheit nur diesen Zweig bei, entfernt die übrigen Zweige
des Symptoms und fährt
mit der momentanen Phase fort.
- – Wenn
die Bestätigungsprüfung von
Funktion B als Ergebnis FALSCH erbringt, werden diese Funktion und ihre
Kindfunktionen entfernt.
-
Ein
zweites Beispiel lautet, dass eine Beziehung zwischen Symptomen
definiert werden kann:
- – Es gibt eine Verknüpfung zwischen
einem so genannten Kundensymptom und einem Expertensymptom auf Funktionsebene.
Die beiden Symptome werden miteinander verknüpft, während der Symptombaum geladen
wird, um so ein einziges Symptom zu bilden. Dieser Grundgedanke
gilt für
alle Prüfungsphasen.
- – Es
gibt eine Verknüpfung
von einem Fehlermodus zu einem Expertensymptom. In diesem Fall fährt die Diagnosesitzung
für das
Expertensymptom fort, wenn die Bestätigungsprüfung, die dem Fehlermodus mit der
Verknüpfung
zugehörig
ist, das Ergebnis WAHR erbringt.
-
Kundensymptome
sind Symptome, die vom Endbenutzer des Systems ausgedrückt werden
(z. B. „Motor
startet nicht" oder „Es tritt
schwarzer Qualm aus dem Motor aus"). Expertensymptome sind Symptome, die
von einem Diagnosetechniker ausgedrückt werden (z. B. „Sicherung
XYZ durchgebrannt" oder „Neue Software
nicht in ECU ladbar").
Im Allgemeinen beginnt eine Diagnosesitzung mit einem Kundensymptom,
kann jedoch von dort mit Expertensymptomen fortfahren (Beispiel: „Motor
startet nicht, da Sicherung 13 durchgebrannt ist" ist der Rückschluss aus dem Kundensymptom,
und „Sicherung
13 ist durchgebrannt, da ein Kurzschluss an Kontakt 31 der ECU für die Motorsteuerung
vorliegt" ist der
Rückschluss
aus dem Expertensymptom.) Der Übergang
von einem Kunden- zu einem Expertensymptom ist für den Benutzer des Diagnosewerkzeugs
transparent. Diese Art von Verknüpfung
zwischen Symptomen wird zur Verwaltung kaskadierender Fehler verwendet,
bei denen ein gegebener Fehler die Ursache für einen anderen Fehler ist,
der wiederum die Ursache für
die Beschwerde des Endbenutzers ist.
-
Eine
andere Verwendung eines Expertensymptoms besteht darin, dass der
Diagnose-Inhalt von mehreren Symptomen gemeinsam genutzt wird, indem
ein universelles Expertensymptom verwendet wird (so kommt das Expertensymptom „Datenübertragungsbus
zwischen ECUS ist beschädigt" z. B. bei vielen
Kundensymptomen vor, da dieses Expertensymptom zu vielen Kundenbeschwerden
führen
kann). Diese Verwendung von Expertensymptomen ist nützlich,
um den Aufwand für
die Inhaltserzeugung zu verringern, indem das Konzept einer Wiederverwendbarkeit
häufig
vorkommender Teile eingeführt
wird. Sie kann auch für
den Wechsel zwischen Fachgebieten dienen: Bei komplexen Systemen
wie beispielsweise einem Fahrzeug ist die Inhaltserzeugung auf mehrere
Verfasser mit unterschiedlichen Fachgebieten verteilt. Allerdings
kann die Diagnose mancher Systeme (z. B. eines Motors) zu anderen
Fachgebieten führen
(z. B. zum Autoradio). Durch Symptomverknüpfungen innerhalb von Funktionen
Symptomverknüpfungen
kann ein Inhaltsverfasser Symptome verwenden, die von anderen Verfassern
anderer Fachgebiete erzeugt wurden.
-
Die
folgende Tabelle ist ein Beispiel von Merkmalen, die für die einzelnen
Prüfungsphasen
bereitgestellt werden. Dabei bezeichnet „Ebene" die Ebene des Symptombaums: Eine Prüfungsphase
kann sich ausschließlich
auf Fehlermodusknoten oder ausschließlich auf Funktionsknoten beziehen
usw. „Kontext
der automatischen Prüfung" gibt den Wert des
Parameters an, der auf der Ebene der Funktions-, Teilfunktions-
und Fehlermodusknoten gespeichert ist, um die Kosten der automatischen
Prüfung
zu beschreiben. Der Wert kann „Hoch", „Niedrig” oder „Nicht
zutreffend" lauten,
wenn die Prüfung
von Hand erfolgt. „Bedingung" bezeichnet die Bedingung
für die
Auswahl der Knoten in der Prüfungsphase.
So wird Prüfungsphase
A4 z. B. begonnen, wenn sämtliche
Prüfungsphasen
mit automatischen Prüfungen
A1, A2, A3 und logischen Prüfausdrücken von 100%
nicht erfolgreich waren. Somit bezieht sich Prüfungsphase A4 auf Knoten, bei
denen die logischen Ausdrücke
der automatischen Prüfungen
einen Wahrheitsprozentsatz von unter 100% aufweisen. „Reihenfolge" bezieht sich auf
die Rangfolge der Bestätigungsprüfung. Die
Bestätigungsprüfungen werden
ausgeführt,
um entweder eine automatische Prüfung
mit einem positiven Ergebnis zu bestätigen oder um einen Knoten
zu bestätigen,
für den
lediglich eine von Hand durchzuführende
Prüfung
vorgesehen ist. Vor der Ausführung
werden die Bestätigungsprüfungen in
einer der Rangfolge nach geordneten Liste geordnet, indem Algorithmen
zum Einsatz kommen, welche die Werte von aus den Knoten ausgelesenen
Parametern verwenden. In diesem Beispiel wurden einige Formeln mit
der Bezeichnung A, B, usw. aus Gründen des logischen Zusammenhaltes
bereits im Vorfeld vom Administrator des Diagnoseverfahrens definiert
und auf alle Symptombäume
angewendet. Dabei ermöglicht
die Auswahl der Formeln eine Feinabstimmung der Art und Weise, wie
der Symptombaum gelesen wird, um so die Listen mit den Bestätigungs-
und den automatischen Prüfungen
der Rangfolge nach zu ordnen. Dabei ist zu beachten, dass sich diese
Prüfungsphasen
beliebig verbessern lassen, indem die Formeln oder die Anzahl der
in den Knoten gespeicherten Parameter verbessert werden.
| Phase A1a | Ebene | Systemeigene
und geerbte Fehlermodi (mit Ausnahme von Fehlermodi mit Kennzeichnung) |
| Kontext
der automatischen Prüfung | Niedrige
Kosten |
| Bedingung | Logischer
Ausdruck zu 100% wahr |
| Rangfolge | Gemäß Formel
A.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung |
| Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase A1b | Ebene | Funktionen
und Fehlermodi, die wahre logische Ausdrücke geerbt haben |
| Kontext
der automatischen Prüfung | Niedrige
Kosten |
| Bedingung | Logischer
Ausdruck zu 100% wahr |
| Reihenfolge | Gemäß Formel
A auf Fehlermodusebene.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung
Gemäß Formel
B auf Funktionsebene.
Parameterliste:
– Schwierigkeit ihrer Durchführung auf
Funktionsebene
– Häufigkeit
des Auftretens und/oder
Wahrscheinlichkeit des Fehlermodus
auf Ebene des Kindknotens
– Wahrheitsgewichtung
auf Funktionsebene |
| | Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase A2a | Ebene | Systemeigene
und geerbte Fehlermodi (mit Ausnahme von Fehlermodi mit Kennzeichnung) |
| Kontext
der automatischen Prüfung | Hohe
Kosten |
| Bedingung | Logischer
Ausdruck zu 100% wahr |
| Rangfolge | Gemäß Formel
A.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung |
| Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase A2b | Ebene | Funktionsebene |
| Kontext
der automatischen Prüfung | Hohe
Kosten |
| Bedingung | Logischer
Ausdruck zu 100% wahr |
| Rangfolge | Gemäß Formel
A auf Fehlermodusebene.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung
Gemäß Formel
B auf Funktionsebene:
Parameterliste:
– Schwierigkeit ihrer Durchführung auf
Funktionsebene
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus auf Ebene
des Kindknotens – Wahrheitsgewichtung
auf Funktionsebene |
| | Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase A3 | Ebene | Systemeigene
und geerbte Fehlermodi (Fehlermodi mit Kennzeichnung) |
| Kontext
der automatischen Prüfung | Niedrige
und hohe Kosten |
| Bedingung | Logischer
Ausdruck zu 100% wahr |
| Rangfolge | Gemäß Formel
C.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung
– Kosten
der Komponente, die ausgetauscht werden muss, um Bestätigungsprüfung durchführen zu
können |
| Kennzeichnung
für Austausch
der reparierbaren Einheit? | Ja |
| Phase
A4a | Ebene | Fehlermodi |
| | Kontext
der automatischen Prüfung | Niedrige
und hohe Kosten |
| | Bedingung | Logischer
Ausdruck nicht zu 100% wahr, sondern dahingehend gekennzeichnet,
dass er als nicht 100% wahrer logischer Ausdruck zur Auswahl steht |
| | Rangfolge | Gemäß Formel
A.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung |
| | Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase
A4b | Ebene | Abwärts gerichtet,
von Funktions- zu Fehlerebene |
| | Kontext
der automatischen Prüfung | Niedrige
und hohe Kosten |
| Bedingung | Logischer
Ausdruck nicht zu 100% wahr, sondern dahingehend gekennzeichnet,
dass er als nicht 100% wahrer logischer Ausdruck zur Auswahl steht |
| Rangfolge | Gemäß Formel
A auf Fehlermodusebene.
Parameterliste:
– Schwierigkeit
ihrer Durchführung
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus
– Wahrheitsgewichtung
Gemäß Formel
B auf Funktionsebene.
Parameterliste:
– Schwierigkeit ihrer Durchführung auf
Funktionsebene
– Häufigkeit
des Auftretens und/oder Wahrscheinlichkeit des Fehlermodus auf Ebene
des Kindknotens
– Wahrheitsgewichtung
auf Funktionsebene |
| Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase B1 | Ebene | Abwärts gerichtet,
von Funktions- zu Fehlerebene |
| Kontext
der automatischen Prüfung | nicht
anwendbar |
| | Bedingung | Kein
logischer Ausdruck zugehörig
oder logische Ausdrücke
falsch (während
A-Phasen), jedoch als „Nicht exklusiv" gekennzeichnet |
| | Rangfolge | Gemäß Formel
D auf Fehlermodusebene.
Parameterliste:
– Schwierigkeit
der Durchführung
der Bestätigungsprüfung
– Faktor
für die
Häufigkeit
des Auftretens und/Oder die Wahrscheinlichkeit
Gemäß Formel
E auf Funktionsebene.
Parameterliste:
– Schwierigkeit der Durchführung der
Bestätigungsprüfung auf
Funktionsebene
– Häufigkeit
des Auftretens und/oder Faktor für
die Wahrscheinlichkeit und oder die Häufigkeit auf Ebene des untersten
Kindknotens |
| Kennzeichnung
für Austausch
der reparierbaren Einheit? | Nein |
| Phase
B2 | Ebene | Fehlermodus |
| | Kontext
der automatischen Prüfung | nicht
anwendbar |
| Bedingung | Fehler
in Phase B1 |
| Rangfolge | Gemäß Formel
F.
Parameterliste:
– Schwierigkeit
der Durchführung
der Bestätigungsprüfung
– Faktor
für die
Häufigkeit
des Auftretens und/oder die Wahrscheinlichkeit
– Kosten
der Komponente, die ausgetauscht werden muss, um die Bestätigungsprüfung durchzuführen |
| Kennzeichnung
für Austausch
der reparierbaren Einheit? | Ja |