DE102004024262A1

DE102004024262A1 - Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen

Info

Publication number: DE102004024262A1
Application number: DE102004024262A
Authority: DE
Inventors: Martin Konieczny
Original assignee: DaimlerChrysler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2004-05-15
Filing date: 2004-05-15
Publication date: 2005-12-01
Also published as: EP1751637A1; WO2005111752A1; US20070226540A1

Abstract

Das vorliegende Dokument beschreibt ein Diagnosesystem zur Fehlerlokalisierung in der Werkstattdiagnose. Das Diagnosesystem berücksichtigt sowohl triviale als auch kostspielige intermittierende Fehlerfälle. Es ist durch ein strukturiertes Modulkonzept der Software-Architektur geprägt. DOLLAR A Anhand einer Klassifizierung der Diagnoseaufgaben findet eine Gliederung in eine Lokalisierung quasistationärer sowie intermittierender Fehler statt. Erstgenannte Problemstellungen können mittels einer systematischen Vorgehensweise unter Zuhilfenahme aller zur Verfügung stehenden Informationen gelöst werden. Die modulare Software-Architektur mit einer strikten Trennung von gesicherten Daten und unscharfen Informationen unterstützt den geführten Prozess der Fehlersuche. Aktuelle Methoden, die nach dem Stand der Technik arbeiten, kommen in einzelnen Modulen der Software-Architektur zum Einsatz. Es werden die Vorteile der bekannten Systemdiagnose, wie die Verdichtung der verdächtigten Komponenten, genutzt und ausgeweitet. Die erfindungsgemäße Hinzunahme einer Symptomverarbeitung verbessert das Ergebnis bisheriger Systeme der Systemdiagnose. Die verbesserte Führung bei der Systemdiagnose hilft bei der Vermeidung von in Ordnung Ausbauten. Für eine effiziente Fehler-Lokalisierung kommt innovativ eine dynamische Prüfschrittbaum-Generierung zum Einsatz. DOLLAR A Intermittierende Fehler führen bei der bekannten Systemdiagnose zu langen Fehlersuchzeiten aufgrund der notwendigen Reproduzierbarkeit des ...

Description

Die Erfindung betrifft ein Diagnosesystem aus der Kategorie der modellbasierten Systemdiagnose. Bei diesen rechnergestützten Diagnosesystemen wird das zu analysierende technische System mit einem rechnerverarbeitbaren Modell abgebildet und mittels Sensoren und Fehlererkennungsalgorithmen auf auftretende Fehler überwacht. Die Fehler werden kodifiziert und mittels einer Wissensbasis, die das zur rechnergestützten Diagnose relevante Diagnosewissen enthält, und einem Diagnosesystem ausgewertet. Die Auswertung basiert hier im wesentlichen auf dem festgestellten Fehlercode und das Diagnosesystem ermittelt aus der Wissensbasis die dem Fehlercode zugeordnete Fehlerkandidatenmenge. In einem weiteren Schritt wird die Anzahl der Fehlerkandidaten durch Heranziehen von sogenannten Fehlerumgebungsdaten, also von während des Auftretens des Fehlers vorliegenden weiteren Systemdaten, und deren Berücksichtigung mittels fehlerspezifischer Ausschlusskriterien von dem Diagnosesystem auf ein Minimum reduziert. Alternativ können die verbleibenden Fehlerkandidaten noch von dem Diagnosesystem bewertet und gewichtet werden.
Derartige Modellbasierte Diagnosesysteme sind in verschiedenen Ausprägungen aus dem Stand der Technik bekannt.
In der DE 195 23 483 A1 ist ein modellbasiertes, rechnergestütztes Diagnosesystem entsprechend dem Oberbegriff des unabhängigen Anspruchs bekannt, bei dem die Modellbildung ein Strukturmodell und ein Wirkungsmodell, das oft auch als Verhaltensmodell bezeichnet wird, umfasst. 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 technischen Systems abgebildet. In einer Wissensbasis ist das für die Diagnose relevante Diagnosewissen abgespeichert. Mit dem Diagnosesystem kann eine Fehlererkennung und durch Rückgriff auf die Wissensbasis eine rechnergestützte Fehlersuche durchgeführt werden. Das Diagnosesystem selbst hat hierbei nur und ausschließlich Zugriff auf Fehlerumgebungsdaten aus dem technischen System und auf eine Wissensbasis, die ausschließlich auf die fehlerspezifische Auswertung der technischen Systemdaten abstellt. Kundenbeanstandungen oder symptomatische Fehlerbeschreibungen können nur durch eine von einem erfahrenen Servicetechniker ausgeübte Menusteuerung berücksichtigt werden, wenn aus den technischen Systemdaten und den Fehlerumgebungsdaten keine eindeutige Diagnose oder überhaupt keine Diagnose durch das Diagnosesystem möglich ist.
Eine andere Möglichkeit der Modellbildung, wie sie unter dem Begriff der modellbasierten Systemdiagnose im Sinne dieser Erfindung verstanden wird und geeignet ist, ist beispielsweise in der EP 1 069 487 B1 ausführlich offenbart. Hier wird das zu diagnostizierende technische System für die rechnergestützte Diagnose mit einem Wahrscheinlichkeitsnetz, einem sogenannten Bayes Netzwerk abgebildet und modelliert. Eine Modellbildung mit Wahrscheinlichkeitsnetzen hat den Vorteil, das die Modellbildung auf funktionaler Ebene der einzelnen Komponenten des Systems erfolgen kann. Die einzelnen Komponenten selbst brauchen nicht bis auf ein physikalisches Strukturmodell modelliert werden. Allerdings erkauft man sich diesen Vorteil mit dem Problem die richtigen Apriori Wahrscheinlichkeiten des Bayes Netzwerkes aufzufinden. Entsprechend einer aufgefundenen Fehlermeldung wird mittels einer Wissensbasis eine die Systemzustände abbildende Wahrscheinlichkeitsverteilung innerhalb des Wahrscheinlichkeitsnetzwerkes berechnet und daraus mit einem Diagnosesystem eine Fehleraussage getroffen und eine zu dieser Fehleraussage passende Abhilfemaßnahme vorgeschlagen. Um das Diagnoseergebnis zu verbessern sind im Wahrscheinlichkeitsnetz Frageknoten integriert, die es ermöglichen über eine Mensch Maschine Schnittstelle während des Diagnoseablaufs an einen Benutzer des Diagnosesystems einfache Ja/Nein-Fragen zu stellen. Durch Beantwortung der Fragen wird im Diagnoseablauf an entscheidenden Netzwerknoten evidentes Wissen abgefragt und in den Diagnoseablauf eingeführt, so dass sich das Diagnoseergebnis mit Hilfe dieses evidenten Wissens entscheidend verbessert. Allerdings kann lediglich evidentes Wissen eingepflegt werden, dessen Abfrage vom Systemdesigner vorgesehen war und in Form eines Frageknotens in die Modellbildung implementiert wurde. Nach Einbindung des abgefragten evidenten Wissens wird unter dessen Berücksichtigung und unter Berücksichtigung einer Wissensbasis, die die funktionalen technischen Zusammenhänge der einzelnen Komponenten des technischen Systems enthält, eine Wahrscheinlichkeitsverteilung innerhalb des Netzwerkes berechnet und daraus auf die wahrscheinlichste Fehlerursache geschlossen.
Der Modellierungsaufwand bei der modellbasierten Systemdiagnose ist hoch. Insbesondere hängt die Qualität des Diagnoseergebnisses entscheidend von der Modellierung ab. Man sucht deshalb auch nach Alternativen zur modellbasierten Systemdiagnose. Eine derartige Alternative ist ein symptombasierter Ansatz, wie er beispielsweise in der DE 102 35 416 A1 beschrieben wird. Beim symptombasierten Ansatz wird auf eine Modellierung des technischen System verzichtet. Stattdessen werden einfache z.B. akustische Symptome aufgezeichnet und mit bereits bekannten Mustern verglichen. Findet sich zu einem auftretenden Symptom ein bekanntes Muster, so ist der Diagnoseprozess weitgehend beendet. Man untersucht dann die dem aufgefundenen Muster zugeordnete Fehlerkandidatenmenge bis man den exakten Fehler gefunden hat.
Ein Problem bei allen vorbeschriebenen rechnergestützten Diagnosesystemen ist, dass sie lediglich in der Lage sind, vordefinierte und damit bekannte Fehlermeldungen und Beanstandungen zu verarbeiten. Dies macht auch die aufwendige Modellierung notwendig, da immer versucht werden muss, alle möglichen Komplikationen schon beim Design des Diagnosesystems zu erfassen und abzubilden. Und selbst dann ist es nicht möglich Kundenbeanstandungen, die naturgemäß ohne technische Detailkenntnisse nur symptomhaft beschrieben werden, rechnergestützt zu verarbeiten und für den Diagnoseprozess nu nutzen.
Dies hat zwei entscheidende Nachteile. Zum einen besteht die Gefahr, dass der Fehlerraum, in dem die Fehlerkandidatenmenge zu suchen ist, nicht weit genug aufgespannt wird. Diese Gefahr ist immer dann besonders groß, wenn ein von einem Kunden berichteter Fehler intermittierend, also nur gelegentlich und nicht dauerhaft auftritt. Solche Fehler können von bekannten rechnergestützten Diagnosesystem nicht gefunden werden, da sie auf das Vorliegen eines Fehlercodes angewiesen sind und den Fehlerraum um den Fehlercode herum aufspannen.
Der zweite Nachteil liegt in dem Informationsverlust, der auftritt wenn die Kundenerfahrung nicht genutzt oder nur ungenügend berücksichtigt wird. Diese Kundenerfahrung mit einem auftretenden Fehlersymptom kann nämlich bei richtig aufgespanntem Fehlerraum und bei richtig identifizierter Fehlerkandidatenmenge dazu genutzt werden, die Menge der identifizierten Fehlerkandidaten weiter einzuschränken. Beispielsweise kann zu einer „Fehlerkandidatenmenge „Sitzsteuerung defekt" mit einer Kundenbeanstandung „der Sitz lässt sich nur noch nach oben fahren" rechnergestützt ausgeschlossen werden, dass der Stellmotor der Sitzmechanik defekt ist.
Erfindungsgemäße Aufgabe ist es daher, bestehende modellbasierte Diagnosesysteme dahin gehend zu erweitern, dass von Kunden berichtete Symptome mit in den rechnergestützten Diagnoseablauf integriert werden und beim Diagnoseablauf rechnergestützt verarbeitet werden.
Die Aufgabe wird gelöst mit einem Diagnosesystem mit den Merkmalen des unabhängigen Anspruchs. Vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprüchen und in der Beschreibung der Ausführungsbeispiele offenbart.
Die Lösung gelingt hauptsächlich indem ein bekanntes modellbasiertes Diagnosesystem mit einem zweiten symptombasierten Zweig und einer zweiten Wissensbasis ergänzt wird, die mit Hilfe eines Symptombaumes mit den Kundenbeanstandungen gefüllt wird. Der Symptombaum ist notwendig, um den Wortlaut der originalen Kundenbeanstandung, in maschinell verarbeitbare Aussagen umzusetzen, die vom Diagnosesystem rechnergestützt interpretiert werden können. So werden mit dem Symptombaum zu einem in der Kundenbeanstandung im Originalwortlaut enthaltenen Symptom weitere Informationen in der Symptomumgebung dieses Symptom abgefragt. Von besonderen Interesse sind hierbei Informationen darüber, welche Funktionen bei einer gemeldeten Kundenbeanstandung in der Symptomumgebung intakt sind. Da dies auf schnelle und einfache Weise eine Verbesserung des Diagnoseergebnisses während einer abschließenden Bewertung erlaubt. Diese abschließende Bewertung ist hierbei als Fehlerkandidatenverrechnung ausgebildet. Es wird zunächst mit dem rein modellbasierten Zweig des Diagnosesystems eine erste Fehlerkandidatenmenge ermittelt. Dann wird mit dem symptombasierten Zweig des Diagnosesystems eine zweite Fehlerkandidatenmenge errechnet. Die zweite Fehlerkandidatenmenge kann insbesondere Angaben zu vom Kunden als intakt gemeldete Fehlerkandidaten enthalten. Am Schluss werden die beiden Fehlerkandidatenmengen miteinander verrechnet, indem die Fehlerkandidaten ausgeschlossen werden, die nicht gleichzeitig in beiden Fehlerkandidatenmengen als defekt diagnostiziert sind.
In einer Ausführungsform erfolgt die Fehlerkandidatenverrechnung durch Ausschließen der in einer der beiden Fehlerkandidatenmengen als intakt gemeldeten Fehlerkandidaten.
In einer alternativen Ausführungsform erfolgt die Fehlerkandidatenverrechnung durch Schnittmengenbildung. Es werden lediglich diejenigen Fehlerkandidaten berücksichtigt, die in beiden Fehlerkandidatenmengen gleichzeitig vorhanden sind.
In einer alternativen Ausführungsform, die für modellbasierte Diagnosesysteme auf der Basis von Bayesnetzen geeignet ist, erfolgt in beiden Fehlerkandidatenmengen eine Priorisierung der einzelnen Fehlerkandidaten. Bei der Fehlerkandidatenverrechnung werden dann diejenigen Fehlerkandidaten ermittelt, die aus beiden Fehlerkandidatenmengen die größte Summenpriorität haben.
Die mit der Erfindung hauptsächlich erzielten Vorteile liegen in einer verbesserten Diagnose. Mit dem System ist es möglich Kundenbeanstandungen im Originalton zu verarbeiten. Die Verarbeitung der Kundenbeanstandung kann hierbei bei der Abarbeitung des Symptombaumes bereits in Zusammenarbeit mit dem Kunden oder auch erst nachträglich durch Abarbeiten des Symptombaumes durch einen Servicetechniker in der Servicewerkstatt erfolgen.
Ein weiterer Vorteil der Erfindung liegt darin, das mit dem symptombasierten Zweig des Diagnosesystems auch intermittierend auftretende Fehler bearbeitet werden können. Auch ist es ein Vorteil, dass der symptombasierte Zweig des Diagnosesystems nicht an irgendwelche Fehlercodes gebunden ist, die bei rein modellbasierten Diagnosesystemen notwendig sind und von Steuergeräten geliefert werden müssen.
In einer weiteren vorteilhaften Ausführungsform des Diagnosesystems wird nach Ermittlung der Fehlerkandidaten der dann in der Werkstatt erforderliche Prüfschrittbaum von dem Diagnosesystem aus vordefinierten und abgespeicherten Prüfschrittprimitiven zusammengesetzt und gebildet. Das ermöglicht ein mit dem Diagnosefortschritt dynamisches Aufspannen eines möglichst flachen und breiten Prüfschrittbaumes zur Unterstützung des Servicetechnikers in der Servicewerkstatt.
Ein Ausführungsbeispiel eines erfindungsgemäßen Diagnosesystems wird im folgen anhand von Figuren näher erläutert.
Dabei zeigen:
1 ein Datenflussdiagramm des Diagnosesystems,
2 eine Systemarchitektur,
3 die Symptomverarbeitung,
4 die Verarbeitung fahrzeuginterner Daten,
5 die Fehlerkandidatengenerierung,
6 die Verarbeitung weiterer Eingangsdaten,
7 die Fehlerkandidatenverrechnung,
8 das Aufstellen des Prüfschrittbaumes,
9 die Fehlerkandidatenmengen im Fehlerraum,
10 einen Gesamtablauf des Diagnoseverfahrens,
11 das Aufspannen des Prüfschrittbaumes aus Prüfschrittprimitiven.
Das nachfolgende Beschreibung offenbart den modularen Systemaufbau und die Funktionalitäten der einzelnen Module. Das genaue Zusammenspiel der einzelnen Bestandteile bei der Fehlersuche ist ebenfalls dargestellt.
Systemarchitektur
Um die Anforderungen nach einer bestmöglichen Flexibilität, Erweiterbarkeit, Wartbarkeit und Nutzung aktueller Techniken zur Fehlerlokalisierung erfüllen zu können, ist das Diagnosesystem zunächst in sieben Module eingeteilt:

• Verarbeitung fahrzeuginterner Daten (als Erweiterung der heutigen Systemdiagnose). Das Diagnosesystem wertet fahrzeuginterne Informationen automatisch zur Fehlerkandidatengenerierung aus. Fahrzeugdaten können Fehlerkandidaten belasten und entlasten.
• Symptomeinstieg. Die Überführung der Kundenbeanstandung, also der originalen Problembeschreibung seitens des Kunden, in eine technische Problembeschreibung in standardisierter Form wird als Symptomeinstieg bezeichnet. Nennt der Kunde intakte Funktionalitäten, so müssen auch diese in einer geeigneten Form ebenfalls standardisiert werden.
• Symptomverarbeitung. Basierend auf den Informationen des DMS (Dealer Management System) sowie des Symptomeinstiegs werden Fehlerkandidaten generiert. An dieser Stelle kann auch die Verarbeitung der Kundenaussagen bezüglich intakter Funktionen erfolgen.
• Fehlerkandidatenverrechnung. Die aus der Symptomverarbeitung, der Verarbeitung fahrzeuginterner Daten und ggf. aus weiteren vorangehenden Informationsverarbeitungen generierten Fehlerkandidaten sind miteinander zu verrechnen. Die Verrechnung ermittelt eine Menge von Fehlerkandidaten einschließlich einer Gewichtung der einzelnen Elemente.
• Dynamisches Aufspannen von Prüfschrittbäumen. Die ermittelten Fehlerkandidaten sind systematisch zu überprüfen. Hierzu wird ein Prüfschrittbaum gemäß der Fehlerkandidaten dynamisch aufgespannt. Die systematische Überprüfung orientiert sich an Kosten und Informationsgehalt einzelner Prüfschritt-Primitive. Der Grad der Benutzerführung entscheidet letztendlich, ob der Baum einmalig aufzu spannen ist, oder ob er ggf. nach jeder durchgeführten Prüfung zu korrigieren ist.
• Verarbeitung der Fahrzeughistorie. Zu jedem Werkstattaufenthalt des Fahrzeuges existiert ein Bericht mit den getauschten Komponenten etc. Diese Daten können die Fehlersuche vereinfachen, da die Wahrscheinlichkeit einer fehlerhaften Komponente als Ursache mit jedem Tausch dieser Komponente sinkt.
• TIPS/NEWS. Vor der systematischen Fehlerlokalisierung mit Hilfe der geführten Fehlersuche wird eine Anfrage nach bestehenden Abhilfen an das TIPS/NEWS-System gestartet. Bekannte und eindeutig identifizierbare Fehler liegen der Datenbank zugrunde. Die Anfrage basiert auf den aktuell vorliegenden Eingangsdaten.

1 zeigt den Datenfluss der gesamten Informationsverarbeitung anhand der ersten fünf Module obiger Aufzählung. Die Verarbeitung der Fahrzeughistorie ist an dieser Stelle aus Gründen der Übersicht zunächst weggelassen. TIPS und NEWS werden weiter unten separat behandelt.
Als Eingangsdaten stehen die Informationen aus dem Fahrzeug und die Kundenbeanstandung zur Verfügung. Nach der dargestellten Verarbeitung liegt ein aufgespannter Prüfschrittbaum vor, der abzuarbeiten ist.
2 zeigt den Datenfluss anhand der zu verarbeitenden Mengen. Gleichzeitig lässt sich die Systemarchitektur der Fehlerlokalisierung erkennen.
Die Systemarchitektur ist durch einen modularen Aufbau mit definierten Schnittstellen geprägt. Die Einzelnen Komponenten sind austauschbar und weiterentwickelbar. Durch die Austauschmöglichkeit können die einzelnen Verarbeitungsschritte dem Stand der Technik angepasst werden.
Im Unterschied zu 1 ist die Verarbeitung der Fahrzeughistorie in die Darstellung integriert. Sie ist ein zu der Symptomverarbeitung und der Verarbeitung fahrzeuginterner Daten paralleler Zweig. Gleichermaßen sind weitere Dateneingänge möglich, die alle eine Informationsart auf Fehlerkandidaten abbilden.
Im Wesentlich gibt 2 gleichzeitig den Ablauf wieder, der von oben nach unten zu lesen ist. Die Verarbeitung der fahrzeuginternen Daten, des Symptoms und der Fahrzeughistorie können automatisch und parallel arbeiten. Die Ergebnisse aller drei Verarbeitungen sind Fehlerkandidatenmengen, die zu verrechnen sind. Im letzten Schritt findet die gezielte Fehlerkandidatenüberprüfung und damit die systematische Fehlerlokalisierung statt.
Die einzelnen Komponenten des Diagnosesystems:
Jedes Modul ist durch sein äußeres Verhalten bestimmt. Die Eingangs- und Ausgangsdaten sind klar festgelegt. Für die Datenverarbeitung innerhalb der einzelnen Module können verschiedene Techniken genutzt werden.
Modul Symptomeinstieg (und Kundenangabe)
Der Symptomeinstieg dient der Standardisierung der Kundenbeanstandung in Form des Orginaltons zur maschinellen Weiterverarbeitung. Für die Eingliederung der Begriffe ist ein eindeutiger Symptombaum heranzuziehen. Dieser verfeinert die Begriffe (Symptome) nach einer funktionalen Betrachtungsweise. Alternativ kann durchaus ein spezieller MMI-Symptombaum (Mensch-Maschine.Interface), der in Form eines Thesaurus oder eines Lexikons die Begriffe aus dem Originalton der Kundenbeanstandung auf die technischen Fachbegriffe des Werkstattpersonals abbildet, für die Schnittstelle zum Kunden verwendet werden. Der MMI-Symptombaum ist dadurch gekennzeichnet, dass die Kundenaussage über mehrere Wege klassifiziert werden kann. So zählt ein Abstandsradar beispielsweise sowohl zu dem Motor als auch zum Fahrkomfort oder den Bedienelementen im Innenraum. Da für die weitere Verarbeitung ein eindeutiges Symptom gefordert ist, existiert eine Zuordnung der Einträge aus dem MMI-Symptombaum zu dem eindeutigen (tatsächlichen) Symptombaum. Tabelle 0-1 stellt die wesentlichen Charakteristiken des Symptomeinstiegs dar.
Bei der manuellen Standardisierung navigiert der Servicetechniker durch den Symptombaum. Der Servicetechniker kann die Standardisierung in beliebiger Stufe aufhören. Hört der Servicetechniker an einer relativ hohen Stufe auf, so liefert das unpräzise Symptom einen relativ großen Fehlersuchraum. Aus diesem Grund strebt die Reparaturannahme eine möglichst detaillierte Aussage des Kunden an.
Prinzipiell kann der Symptomeinstieg unmittelbar bei der Fahrzeugannahme erfolgen. Hierzu sind entsprechende Funktionalitäten des Diagnosesystems bereitzustellen. Liegt vor dem Symptomeinstieg oder zum Zeitpunkt des Symptomeinstiegs die Verbindung zum Fahrzeug vor, kann eine Hervorhebung der zu den Fahrzeugdaten konsistenten Symptome stattfinden. Dieser Mechanismus wird bei der Symptomverarbeitung weiter unten näher betrachtet.
Eine wichtige Erweiterung des Symptomeinstiegs ist die äquivalente Verarbeitung einer Angabe der intakt funktionierenden Einheiten durch den Kunden. Auch diese Angabe muss standardisiert werden. Außerdem sollte der Kunde bei seiner Beanstandung ebenfalls die Angabe machen, ob die Beanstandung dauerhaft oder sporadisch auftritt. In Abhängigkeit dieser Angabe werden zum Teil unterschiedliche Fehlerkandidaten belastet, insbesondere ändert sich aber die Art der Belastung und damit die weitere Vorgehensweise bei der Fehlersuche. Eine Detaillierte Angaben zur Lokalisierung sporadischer Fehler ist weiter unten in der Beschreibung angegeben. Tabelle 0-1: Charakteristiken des Symptomeinstiegs
Als Verarbeitungsmethode ist bei dem Symptomeinstieg bewusst die manuelle Zuordnung angegeben zwischen dem MMI-Sysmptombaum und dem Sysmptombaum, der letztlich von dem Diagnosesystem zur Fehlersuche benutzt wird. Prinzipiell gibt es viele Mechanismen, die eine automatische Klassifizierung und Zuordnung von semantischen Begriffen vornehmen. Allerdings bringen automatische Verfahren in der Regel eine weitere Unschärfe in die Fehlersuche, da sie mit Ähnlichkeitskriterien arbeiten. Zu Empfehlen ist daher an dieser Stelle eine manuelle Standardisierung der Kundenbeanstandung, insbesondere bei Anwesenheit des Kunden.
Selbstverständlich kann der Kunde auch mehrere Symptome nennen, die den Suchraum präzisieren oder sich auf Mehrfachfehler beziehen. Darüber hinaus ist die optionale Angabe einwandfreie funktionierender Systeme gewünscht aber nicht zwingend notwendig. Letztere führen letztendlich zu einer Fehlerkandidateneinschränkung.
In Zusammenarbeit mit der Symptomverarbeitung ist ein Dialog realisierbar, der die Eingabe der Kundenbeanstandung leitet. Wird beispielsweise das Symptom „Sitzverstellung vorne/hinten" eingegeben, so ermittelt die Symptomverarbeitung alle passenden Fehlerkandidaten. Ausgehend von den Fehlerkandidaten lassen sich wiederum alle Symptome ermittelt, die mindestens einen dieser Fehlerkandidaten enthalten. Der Kunde wird nach diesen Symptomen gefragt und kann sich zu ihnen äußern, indem er angibt, ob das Symptom dauerhaft vorhanden, sporadisch vorhanden oder nicht vorhanden ist. Hierdurch wird der Suchraum eingeschränkt. Gibt der Kunde hierzu keine oder nur teilweise Angaben, verschlechtert sich die Fehlersuche u. U. entsprechend, da der Suchraum größer wird.
Symptomverarbeitung
Bei der Symptomverarbeitung findet eine Abbildung des standardisierten Symptoms auf Fehlerkandidaten statt. In gleicher Art und Weise werden Kundenangaben verarbeitet, die sich auf einwandfrei funktionierende Teile beziehen. Mit Hilfe letzterer Angabe kommt es zu einer Entlastung von Fehlerkandidaten. Zwar wird folglich lediglich die reine Symptomverarbeitung beschrieben, die Darstellung bezieht sich aber in gleicher Weise auf die Kundenangaben der intakten Funktionen.
Um die richtigen Wissensbasen auszuwerten, sind die Fahrzeugdaten, insbesondere die Fahrzeugidentifikationsnummer FIN, ebenfalls anzugeben bzw. aus den Kontextinformationen der aktuellen Fehlersuche auszulesen und zu berücksichtigen. Da das Symptom auf der Kundenbeanstandung basiert, handelt es sich um unscharfes, respektive unsicheres Wissen.
Zur Verarbeitung des Symptoms können unterschiedliche Methoden eingesetzt werden. Raum, F.; Schreier, N.; Spöttl, G.: „Die Zukunft computergestützter Kfz-Diagnose. Rechnergeführte Handlangerarbeit oder qualifizierte Facharbeit.", erschienen im Bertelsmann Verlag, Bielefeld 2002, enthält eine Gegenüberstellung verschiedener Techniken. U. a. eignet sich beispielsweise das Case based reasoning (CBR), da hierbei eine unscharfe Verarbeitung stattfindet. Beim CBR wird versucht anhand definierter Ähnlichkeiten den aktuell vorliegenden Fall aus einem bereits bekannten Fall herzuleiten.
Eine andere Möglichkeit und sehr anschauliche Methode ist eine regel-orientierte Verarbeitung. In den Regeln können die Beziehungen zwischen einem Symptom und den möglichen Fehlerkandidaten in einfacher Weise abgelegt werden. Allerdings sind dem auf Dauer Grenzen gesetzt, da lediglich ein direkter Zusammenhang zwischen den beiden Informationsarten symptom und Fehlerkandidat möglich ist. In komplexen Systemen lässt sich der Zusammenhang nicht unmittelbar in Beziehung bringen, da eigentlich ein komplexes Zusammenspiel vieler Funktionalitäten vorliegt.
Ein Umweg über Funktionsmodelle ist für komplexe technische Systeme daher empfehlenswert. Eine geeignete Technik ist an dieser Stelle der Einsatz von Bayes'schen Netzen, die eine Modellierung der Zusammenhänge zwischen Symptomen und Fehlerkandidaten über beliebige Netzwerke zulassen.
Tabelle 0-2 fasst den Verarbeitungsschritt der Symptomverarbeitung zusammen. Tabelle 0-2: Charakteristiken der Symptomverarbeitung
Eine wichtige Eigenschaft der vorgesehenen Symptomverarbeitung ist die Möglichkeit einer Kandidatenverrechnung aufgrund von Mehrfacheingaben. Viele Fehler wirken sich in verschiedenen Kundenbeanstandungen gleichzeitig aus. Ein Beispiel hierfür ist eine durchgebrannte Sicherung. Liegt ein solcher Fehlerfall vor, sind gleichzeitig mehrere Funktionalitäten gestört. Sind seitens des Kunden einige von ihnen bekannt, können sie die Fehlersuche signifikant beschleunigen.
Für die Symptomverarbeitung ist zusätzlich der Symptombaum (ggf. MMI-Symptombaum o. ä.) notwendig. Dies hat den Vorteil, dass ein Symptom nicht immer bis auf die kleinste Differenzierungsstufe klassifiziert werden kann. Ist das Symptom nur auf einer höheren (unschärferen) Klassifizierungsstufe bekannt, so werden alle darunter liegenden Symptome bei der Abbildung auf die Fehlerkandidaten herangezogen.
Mit Hilfe der Symptomverarbeitung und des Symptomeinstiegs lässt sich ein Dialog zur Minimierung der Fehlersuchzeiten realisieren.
Verarbeitung fahrzeuginterner Informationen
Bei der Verarbeitung fahrzeuginterner Daten erfolgt die Berechnung von Fehlerkandidaten anhand der gespeicherten Fehlercodes und ihrer Umgebungsdaten, der Fahrzeugkonfiguration sowie der zur Verfügung stehenden Ist-Werte des Fahrzeuges. Ist das Symptom bekannt, erfolgt die Auswertung der relevanten Steuergeräte. Hierzu ist nach Möglichkeit ein Zusammenhang zwischen dem standardisierten Symptom und den betroffenen Steuergeräten bereitzustellen. Mit Hilfe derartiger Informationen müssten nicht alle fahrzeuginternen Daten betrachtet werden, sondern eine Fokussierung auf den relevanten Teil erfolgen. Die Fokussierung auf die relevanten Steuergeräte schafft eine signifikante Beschleunigung bei der Kommu nikation und damit im gesamten Prozesses. Tabelle 0-3 fasst die Verarbeitung fahrzeuginterner Informationen zusammen. Tabelle 0-3: Charakteristiken der Verarbeitung fahrzeuginterner Daten
4 stellt die Verarbeitung der fahrzeuginternen Daten graphisch dar. Momentan findet die Verarbeitung fahrzeuginterner Daten onboard statt. Sie umfasst die Diagnose von CAN-B-Komponenten sowie von CAN-Leitungsfehlern. Zur BR 221 ist eine Erweiterung der Diagnose auf alle CAN- und Most-Komponenten vorgesehen. Ab BR 204 findet die Verarbeitung ausschließlich offboard statt. In der BR171 soll der CAN-C-Bereich offboard abgedeckt werden, während der CAN-B-Bereich onboard verarbeitet wird. Das modulare Konzept erlaubt den vorgesehenen Entwicklungsprozess.
Die heutige Onboard-Diagnose (Systemdiagnose) arbeitet regelorientiert und muss aufgrund der zur Verfügung stehenden Ressourcen in ihrem Umfang und ihrer Diagnosetiefe stark eingeschränkt werden. Dadurch schöpft man nicht ihr volles Potential aus. Auf der anderen Seite erfolgt eine situationsbedingte Be- und Entlastung statt. Durch eine Verlagerung der Verarbeitung fahrzeuginterner Daten gehen u. U. wichtige In formationen verloren, was zu kompensieren ist. Auf der anderen Seite steht wesentlich mehr Performance zur Verfügung, so dass dieser Verarbeitungsteil bestmöglich ausgeschöpft werden kann.
Die automatische Verarbeitung fahrzeuginterner Informationen kann auch Offboard realisiert werden, wenn entsprechende Schnittstellen im und zum Fahrzeug bereitgestellt werden. Für die automatische Verarbeitung sind problemspezifisch unterschiedliche Verfahren geeignet. Einsetzbar ist beispielsweise eine regelorientierte oder modellbasierte Verarbeitung. Strukturelle Modellanalysen auf physikalischen Modellen erlauben eine Problemdekomposition sowie die Untersuchung der Diagnostizierbarkeit.
Graphentheoretische Ansätze ermöglichen eine Topologieauswertung zur Ermittlung der am Fehler beteiligter Komponenten oder Funktionsgruppen. Die zur Verfügung stehenden Ressourcen sowie der Grad einer Wissens-Vorverarbeitung entscheiden über den Einsatz der jeweiligen Technik. Aufgrund der definierten Schnittstelleninformationen sind die Methoden austauschbar und ein multimodales Diagnoseverfahren konfigurierbar.
Methoden des Case based Reasoning können ebenfalls zum Einsatz kommen. In 5 wird auf diesen Aspect mit einer graphischen Darstellung näher eingegangen. Bei den Systemen TIPS und NEWS handelt es sich um eigenständige Softwarekomponenten des Case based reasoning (CBR), die in die Fehlerlokalisierung eingebunden sind. Der zu Beginn vorliegende Datensatz, bestehend aus den fahrzeuginternen Informationen sowie den Symptom- und Fahrzeugdaten, wird an die Systeme TIPS und NEWS übergeben. Die Systeme durchsuchen die eigenen Wissensbasen nach zu den Eingangsdaten passenden Fällen. Liegt ein derartiger Fall vor, signalisiert das System das Vorhandensein einer Abhilfe. Im einfachsten Fall kann die Abhilfe direkt ausgegeben werden, was allerdings nicht zu empfehlen ist, da die systematische Fehlersuche nicht mehr gegeben ist. Viel wichtiger ist die Nutzung der zusätzlichen Informationen für eine gezielte und systematische Fehlersuche. Tabelle 0-4: Charakteristiken der Datenbankabfragen in TIPS und NEWS während der Fehlerlokalisierung
Grundsätzlich ist die Eindeutigkeit der Suchergebnisse nicht gewährleistet, so dass die Datenbankabfrage u. U. mehr als eine Abhilfe liefert. Da mit jeder Abhilfe prinzipiell Fehlerkandidaten repariert oder getauscht werden, können die Abhilfen mit Sicherheit auf Fehlerkandidaten abgebildet werden, so dass sie im Falle einer mehrdeutigen Lösung eine Menge an Fehlerkandidaten resultieren. Mit Hilfe der fallspezifischen Prüfbaumaufspannung kann die Fehlerkandidatenmenge im weiteren Verlauf der Fehlersuche systematisch eingegrenzt werden. An dieser Stelle ist eine Einbindung der Ergebnisse von TIPS bzw. NEWS in das hier beschriebene Diagnosesystem notwendig. Die entsprechenden Schnittstellen zwischen der geführten Fehlerlokalisierung und den Systemen TIPS und NEWS sind zu spezifizieren. Tabelle 0-4 beschreibt die wichtigsten Charakteristiken des gesamten Verarbeitungsschrittes in der Fehlerlokalisierung.
Für eine vollständige Integration von TIPS muss das System im Falle einer gefundenen Abhilfe die zugrunde liegenden Fehlerkandidaten mitteilen. Anschließend kann das hier konzipierte Verfahren die Fehlerkandidaten entsprechend gewichtet gleichermaßen wie alle anderen Fehlerkandidaten behandeln. 10 veranschaulicht die vollständige Integration von TIPS/NEWS in das Diagnosesystem.
Des Weiteren enthält das System NEWS Reparaturanleitungen, Schadenschlüssel zur Abrechnung sowie Ersatzteilnummern. Die entsprechenden Informationen werden nach erfolgreicher Fehlerlokalisierung referenziert.
Verarbeitung der Fahrzeughistorie und weiterer Eingangsdaten 6 veranschaulicht die prinzipielle Erweiterungsfähigkeit des Diagnosesystems um weitere Module. Besonders interessant ist hierbei die Einbindung von Datenbanken, die Informationen zur Fahrzeughistorie und damit Informationen über bereits ausgeführte Reparaturen und Wartungen enthalten. Die Fahrzeughistorie beinhaltet Informationen zu bereits durchgeführten Reparaturen und ist nur bedingt für die Fehlerlokalisierung nutzbar. U. a. gehen Beanstandungen sowie die getauschten Komponenten aus der Fahrzeughistorie hervor. Wurde vor kurzer Zeit eine Komponente getauscht, so ist die Wahrscheinlichkeit relativ gering, dass bei gleicher Kundenbeanstandung die bereits getauschte Komponente die Ursache darstellt. Vielmehr wird es sich bei der getauschten Komponente um einen Folgefehler oder einen In-Ordnung-Ausbau handeln. Dies bedeutet, dass die nun verdächtigte Komponente zwar durchaus wieder defekt sein kann, sie aber nicht die Ursache der Kundenbeanstandung ist. Tabelle 0-5: Charakteristiken der Verarbeitung der Fahrzeughistorie
Die Auswertung der Fahrzeughistorie beschränkt sich hauptsächlich auf eine Datenbankabfrage. Basierend auf den Fahrzeugdaten, die der Identifizierung des Fahrzeuges dienen, liefert die Abfrage die bereits getauschten Komponenten. Diese können u. U. einer Entlastung von Fehlerkandidaten bei der aktuellen Fehlersuche dienen.
Eine Integration der Verarbeitung der Fahrzeughistorie soll an dieser Stelle als Option für das Diagnosesystem gesehen werden. Gleiches gilt für weitere, hier nicht näher spezifizierte Verfahren, die z.B. den Verschleißstatus oder das Eingangsdatum von Komponentenins Fahrzeug auf Fehlerkandidaten abbilden. Somit veranschaulicht 6 die allgemeingültige Erweiterungsfähigkeit des Diagnosesystems um weitere Module dar.
Kandidatenverrechnung
Die Kandidatenverrechnung übernimmt die Reduzierung der zu betrachtenden Fehlerkandidaten. Gleichzeitig werden die zu betrachtenden Fehlerkandidaten priorisiert. Es findet somit eine Eingrenzung und Bewertung des Fehlersuchraumes statt. 7 veranschaulicht den Verarbeitungsprozess der Kandida tenverrechnung anhand der wichtigsten beteiligten Fehlermengen.
Ausgangspunkt der Verrechnung bilden die zuvor auf den fahrzeuginternen Daten sowie auf der Kundenbeanstandung basierend ermittelten Mengen der Belastungs- (K_Fahrzeug, K_Symptom, (K_TIPS, K_NEWS)) und Entlastungskandidaten (
K_Fahrzeug,
K_Symptom). Für die Kandidatenverrechnung ist im ersten Schritt ein parametrierbarer Algorithmus implementiert, der auf bestehenden Diagnosealgorithmen aus dem Stand der Technik auf der Basis von Komponentenerkennung Fehlerarterkennung durch Fehlercodes aufbaut. Diese bestehenden Diagnosesysteme und deren Algorithmen werden um folgende Aspekte erweitert:

• Belastungskandidaten, die sowohl in der Komponente als auch in der Fehlerart übereinstimmen und sowohl aus dem Symptom als auch aus der Verarbeitung fahrzeuginterner Daten resultieren, bilden die wahrscheinlichsten Fehlerursache.
• Innerhalb der Schnittmenge (K_Fahrzeug ∩ K_Symptom), die die Komponente sowie die Fehlerart berücksichtigt, erfolgt eine Gewichtung gemäß der aus den vorangehenden Verarbeitungsschritten vorliegenden Wahrscheinlichkeiten.
• Ein Kandidat der Entlastungsmenge
K_Fahrzeug oder
K_Symptom entlastet einen korrespondierenden Belastungskandidaten, sofern Komponente und Fehlerart übereinstimmen.
• Bei unterschiedlichen Fehlerarten einer Komponente kann eine vollständige Entlastung eines Fehlerkandidaten nur dann stattfinden, wenn entsprechende Entlastungskandidaten der Komponente in allen möglichen Fehlerarten vorliegen. Eine geeignete Wissensbasis ist bereitzustellen.
• Liegt eine Belastung einer Komponente mit unterschiedlichen Fehlerarten seitens des Symptoms und seitens der

Verarbeitung fahrzeuginterner Daten vor, so ist die Belastung des Fehlerkandidaten aus der Verarbeitung fahrzeuginterner Daten höher zu gewichten.
Als weitere Option kann der Algorithmus durch Methoden für mehrdimensionale Optimierungsprobleme verbessert werden. Tabelle 0-6 charakterisiert die Kandidatenverrechnung, wobei neben den bereits genannten Mengen auch die Fehlerkandidaten aus den Abhilfesystemen TIPS und/oder NEWS berücksichtigt werden. Existieren in TIPS und/oder NEWS zu den gegebenen Eingangsdaten Abhilfen, so sind diese mit den verdächtigten Fehlerkandidaten zu versehen. Die Kandidatenverrechnung übernimmt die Integration der Daten. Tabelle 0-6: Charakteristiken der Kandidatenverrechnung
Fallspezifische Generierung des Prüfbaums
Ist die Kandidatenverrechnung zu einem Ergebnis gekommen und hat eine Fehlerkandidatenmenge ermittelt, so kann mit dem Diagnosesystem optional die Fehlerkandidatenmenge weiter eingeschränkt werden, indem dem Servicetechniker ein Prüfschrittbaum empfohlen wird. Mit Hilfe der Prüfschritte soll die Fehlerkandidatenmenge unter Berücksichtigung der Prüfkosten sys tematisch eingegrenzt werden. Ziel ist eine möglichst schnelle Eingrenzung. Um eine überschaubare Modellierung der Prüfungen zu erzielen, sind die Prüfschritte als Primitive realisiert. Ein Primitiv ist hierbei z.B. eine Überprüfungsanweisung für die Funktionsüberprüfung einer im Kraftfahrzeug verbauten Komponente oder im Falle von allgemeinen Störungen, die mehrere Komponenten betreffen Der Algorithmus des Diagnosesystems übernimmt die Auswahl und Bewertung der Prüfschritt-Primitive und spannt einen Prüfschrittbaum auf, der in der Werkstatt abgearbeitet wird. Die Aufspannung orientiert sich an

• der Menge (Anzahl) verdächtigter Fehlerkandidaten,
• der Fehlerwahrscheinlichkeiten einzelner Fehlerkandidaten,
• der Kosten einzelner Prüfungen,
• einer schnellstmöglichen Eingrenzung des Fehlers.

Tabelle 0-7 zeigt die Charakteristiken der Prüfschrittbaumgenerierung. 8 und 10 veranschaulichen den Datenfluss und die Auswahl der Prüfschrittprimitive zur Aufspannung des Prüfschrittbaumes dar. Tabelle 0-7: Charakteristiken der dynamischen Prüfschritte
Als Resultat liegt also ein Prüfschrittbaum in impliziter Form vor, der den Fehler in Abhängigkeit der zuvor ermittelten Fehlerkandidatenmenge unter Berücksichtigung der ent stehenden Kosten lokalisiert. Für eine Realisierung der Fehlersuchstrategie muss die Struktur der Prüfschritt-Primitive die Elemente gemäß Tabelle 0-8 beinhalten. Tabelle 0-8: Datenstruktur der Prüfschritt-Primitive
Darüber hinaus müssen Abhängigkeiten der Prüfungen berücksichtigt werden, um notwendige Reihenfolgen einhalten zu können. In Zukunft sollten die Prüfungen in vorangehende Arbeiten, Prüfung und nachfolgende Arbeiten getrennt werden. Zu den vorangehenden oder nachfolgenden Arbeiten gehören beispielsweise das Freilegen einer zu prüfenden Komponente. Der Algorithmus ist dann in der Lage, diese Tätigkeiten mit zu berücksichtigen. Damit können beispielsweise nach Ausbau einer Komponente alle Prüfungen durchgeführt werden, die diesen Ausbau voraussetzen.
Des Weiteren sind neben den Prüfschritt-Primitiven auch komplexere Prüfstrukturen mit mehreren Ausgängen und unterschiedlichen Aussagen bedatbar. Mit ihnen lassen sich komplexe, zusammenhängende Abläufe abbilden. Kontextabhängig werden die Strukturen, wie die Primitive, vom Algorithmus eingesetzt, so dass sich ein optimaler Ablauf für den Diagnoseprozess in der Werkstatt ergibt.
Fehlerlokalisierung
Das hier offenbarte Diagnosesystem verfolgt das Ziel einer geführten Fehlersuche. Die Führungs erfolgt in an sich bekannter weise mit einem Bildschirmmenu. Mit Sicherheit wird es auch die Möglichkeit eines Kurztests und damit der vollständigen Dateneinsicht geben. In einem solchen Fall, hat der Servicetechniker die Möglichkeit, an der Führung vorbei zu arbeiten Hierdurch entstehen heute enorme Kosten, weil der Servicetechniker mit diesen Optionen beliebige Freiräume bei der Fehlersuche hat und damit seine eigene Systematik bei der Fehlersuche ergreift. Außerdem kommt es sehr oft zu Verdachtsreparaturen. Auf der anderen Seite wird es immer einen Kurztest oder einen Zugang zu Diagnosedaten über eine Produktgliederung geben, da der Zugriff für einen Systemcheck oder eine gezielte Erweiterung des Diagnosesystems zugänglich sein muss.
Aus diesen Gründen sollte der Auftrag bei der Kundenannahme über den Grad der Führung entscheiden. Ist ein Tausch einer vorher bestimmten Komponente gefordert, so können Diagnoseda ten über einen festzulegenden aber direkten Zugriff erreicht werden. Ist der Fehler aber unbekannt und der Auftrag weist eine Fehlersuche auf, so muss der beschriebene Zugang untersagt werden und lediglich die geführte Fehlersuche zugänglich sein.
Gesamtablauf bei der Suche nach dauerhaft vorliegenden Fehlern
Dauerhaft vorliegende Fehler können mittels einer systematischen Auswertung der zur Verfügung stehenden Informationen unter Zuhilfenahme weiterer Messungen lokalisiert werden. An dieser Stelle soll der Gesamtablauf der Fehlersuche anhand der im Hintergrund verarbeiteten Datenmengen erläutert werden.
Geführte Fehlersuche
9 veranschaulicht den Zusammenhang der einzelnen Fehlerkandidatenmenge unter Angabe der Diagnosemodul aus denen sie erzeugt wurden und deren Verhältnis zum gesamten Fehlersuchraum.
Während der Fahrzeugannahme werden die Fahrzeugdaten sowie die Kundenbeanstandungen erfasst. Damit liegt die Kundenbeanstandung als Originalwortlaut vor und ist auf standardisierte Symptome abzubilden. Für eine möglichst gute Eingrenzung des Fehlersuchraumes ist die Angabe mehrere Symptome möglich, da sich viele Fehler gleichzeitig in verschiedenen Symptomen auswirken. Die Differenzierung in ein dauerhaft oder sporadisch vorliegendes Symptom verhilft bei der Spezifizierung der Fehlerart. Grundsätzlich ist an dieser Stelle auch eine Angabe einwandfrei funktionierender Systemteile denkbar, die zu einer wesentlich schnelleren Fehlersuche durch Ausschluss von Fehlerkandidaten führen würde.
Der Symptomeinstieg kann in der Fahrzeugannahme (Dealer Management System) erfolgen. Da es allerdings weltweit zwölf verschiedene Annahmesysteme gibt, ist der Symptomeinstieg in der Werkstatt gegebenenfalls durch den Servicetechniker manuell vorzunehmen.
Im Anschluss an die Symptomeingabe erfolgt eine Verarbeitung aller zur Verfügung stehenden Informationen. Die Auswertung findet auf dem Diagnoserechner ablauf- und programmtechnisch im Hintergrund statt. Nach der Verarbeitung bekommt der Servicetechniker bei strikter Systemführung den ersten Prüfschritt einer Baumstruktur angezeigt. Er arbeitet den Prüfschrittbaum sukzessive ab. Will man die Systemführung auflockern, kann man den gesamten Prüfbaum oder eine definierte Sequenzen hieraus anzeigen. Der Servicetechniker kann in einem solchen Fall selber entscheiden, welche Prüfung er als nächstes wählt, wobei der Baum immer den effizientesten Weg vorgibt. Eine Auflockerung der Systemführung ist insbesondere dann sinnvoll, wenn für die Prüfungen spezielle Werkzeuge benötigt werden. Liegt das benötigte Werkzeug nicht griffbereit, so kann es von Vorteil sein, die Folgeprüfung vorzuziehen. Nach der Prüfung ist der Prüfbaum gemäß des Ergebnisses zu korrigieren.
Die Arbeitsmenge der Fehlersuche sind Fehlerkandidaten. Diese sind durch ein Daten-Tupel aus verdächtigter Komponente, Fehlerart der Komponente, Fehlerstatus und Fehlerwahrscheinlichkeit repräsentiert. Als Komponente ist nicht zwangsweise eine physikalische Komponente gemeint, so dass auch eine Software oder Codierung einen Fehlerkandidaten darstellen kann. Der Fehlerart dient insbesondere dem Auffinden sporadischer Fehler und wird weiter unten in der Beschreibung im Detail erläutert.
Mit Hilfe der Symptome ermittelt das System die Fehlerkandidatenmenge K_Symptom. Gemeint sind alle Fehlerkandidaten, die sich in dem vorgegebenen Symptom auswirken. Eine Angebe der intakten Funktionen führt zu der entlastenden Menge
K_Symptom.
Die Verarbeitung fahrzeuginterner Daten führt zu einer belastenden Kandidatenmenge K_Fahrzeug Und einer entlastenden Kandidatenmenge
K_Fahrzeug.
Eine weitere Informationsquelle ist das Abhilfesystem TIPS/NEWS, sowie die Fahrzeughistorie, die erst zu einem späteren Zeitpunkt in die Verarbeitung integriert wird.
Mit den ermittelten Fehlerkandidaten findet eine Kandidatenverrechnung statt. Diese läuft auf dem Diagnoserechner automatisch und im Hintergrund ab. Die zu den einzelnen Fehlerkandidaten zugeordneten Wahrscheinlichkeiten werden bei der Verrechnung herangezogen. Ziel ist eine möglichst kleine Menge an verdächtigten Fehlerkandidaten, die im weiteren Verlauf der Fehlersuche zu überprüfen ist.
Fehlerkandidaten der Mengen
K_Fahrzeug,
K_Historie und
K_Symptom bilden Ausschlusselemente. Mit Hilfe der enthaltenen Elemente können zuvor verdächtigte Fehlerkandidaten eliminiert werden. Die Eliminierung erfolgt über ein weites Herabsetzen der Wahrscheinlichkeit. Für die verbleibenden Fehlerkandidaten sind die Elemente der Schnittmenge K_Fahrzeug ∩ K_Symptom mit höchster Priorität zu behandeln. Dann folgen die Elemente aus K_Symptom und schließlich diejenigen aus K_Fahrzeug. Die zugrundeliegenden Metriken sind parametrierbar. Bei der Verrechnung sind sowohl Komponente als auch Fehlerart zu berücksichtigen. Als Ergebnis liegt eine geordnete Liste von Fehlerkandidaten K vor.
Bei Integration der Abhilfesysteme TIPS und NEWS gibt es weitere Mengen, die bei der Fehlersuche zu berücksichtigen sind. Für eine strukturierte Einbettung der Systeme, sollten diese ebenfalls Fehlerkandidaten liefern, die in die Kandidatenver rechnung einbezogen werden. 10 veranschaulicht den Diagnoseablauf einschließlich der Verarbeitung von TIPS- bzw. NEWS-Informationen der Abhilfesysteme dar. Nachdem die fahrzeuginternen Daten ausgelesen wurden und die standardisierten Symptome vorliegen, startet das System eine Anfrage bei den Systemen TIPS und NEWS. Liegen zu den gegebenen Informationen Abhilfen vor, liefern die Datenbankabfragen die in den ermittelten Abhilfen beinhalteten verdächtigten Fehlerkandidaten. Diese werden in die Kandidatenverrechnung aufgenommen und verarbeitet, so dass im folgenden Schritt ein Prüfschrittbaum unter Berücksichtigung der aus TIPS bzw. NEWS stammenden Fehlerkandidaten erfolgen kann.
Alternativ kann TIPS als reine Informationsquelle dienen. Statt der weiterverarbeitbaren Fehlerkandidaten liefert TIPS dann eine Sammlung an Dokumenten. Diese werden dem Servicetechniker angezeigt bevor er in die systemgeführte Prüfung einsteigt.
Mit Hilfe der gewichteten Fehlerkandidatenliste aus der Kandidatenverrechnung ist im nächsten Schritt der Prüfbaum aufzuspannen. Dieser Schritt läuft automatisch und im Hintergrund. Der Algorithmus greift dabei auf Prüschritt-Primitive zu, die einzelne Prüfungen einschließlich der dabei geprüften Fehlerkandidaten und die für die Prüfung benötigten Informationen, sowie der entstehenden Reparaturkosten beinhalten. 11 stellt diesen Prozessschritt dar. Der Baum versucht die Fehlersuchzeit sowie die Kosten der Fehlersuche zu minimieren. Hierbei gilt es demnach, einen möglichst flachen Baum aufzuspannen. Ist der Prüfbaum aufgespannt, bekommt der Servicetechniker den ersten Prüfschritt angezeigt und durchläuft geführt die einzelnen Prüfungen.
Mit jeder Prüfung werden Fehlerkandidaten als in Ordnung oder nicht in Ordnung geprüft. Damit grenzt der Servicetechniker mit jeder Prüfung den Fehlerraum und damit K weiter ein. Folgt aus einer Prüfung der Ausschluss der geprüften Fehlerkandidaten, so findet eigentlich eine Entlastung statt. Dies soll nach diesem Konzept nicht erfolgen. Der Kandidat soll weiterhin bestehen bleiben, allerdings wird er nun als sporadischer Fehlerkandidat behandelt. Der genaue Hintergrund und der sich ergebene Ablauf wird im folgenden erläutert: Der Prüfbaum gibt grundsätzlich den effizientesten Weg der Fehlersuche vor. Diese Vorgabe sollte also nach Möglichkeit strikt geführt sein. Will man dem Servicetechniker die Freiheit gewähren, seinen nächsten Prüfschritt aus dem vorgegebenen Prüfbaum selbst auszuwählen, ist ein iterativer Prozess, wie in 10 anhand der gestrichelten Linie angedeutet, unumgänglich. In Abhängigkeit der zuletzt durchgeführten Prüfung wird der Prüfbaum online korrigiert, so dass zu jedem Zeitpunkt ein optimaler Weg vorgegeben werden kann.
Lokalisierung sporadischer Fehler
Sporadische Fehler sind in der Regel nicht diagnostizierbar, da sie sich nicht reproduzieren lassen. Das wesentliche Problem besteht darin, dass ein Fehler zur Zeit seiner Prüfung nicht vorliegt und dadurch der Kandidat fälschlicherweise entlastet wird. Um dem entgegenzuwirken, verfügen die Daten-Tupel der Fehlerkandidaten über einen zusätzlichen Fehlerstatus, der bei Entlastung von dauerhaft auf sporadisch umgeschaltet wird.
Dementsprechend bleibt der Verdacht zunächst erhalten. Der Kandidat muss auf den sporadischen Verdacht hin (erneut) geprüft werden. Bei einer Leitung bedeutet dies beispielsweise, dass eine Durchgangsprüfung den zuvor als dauerhaft belasteten Fehlerkandidaten Leitung mit der Fehlerart Unterbrechung entlastet. Hierdurch kommt es zu einem Statuswechsel, so dass der Kandidat Leitung mit der Fehlerart Unterbrechung und dem Status sporadisch bestehen bleibt. Eine weitere Prüfung für genau diesen Fall, entlastet den Verdacht erst vollständig. Die Prüfung verfolgt das Ziel, den Fehlerkandidaten unter sporadischen Verdacht zu entlasten. Dies könnte beispielsweise bei der Leitung eine Durchgangsprüfung mit dem Hinweis, an der Leitung zusätzlich zu wackeln, sein.
Mit Sicherheit sind derartige Prüfungen mit wesentlich höheren Kosten verbunden, so dass die Prüfungen automatisch zu einem späteren Zeitpunkt herangezogen werden.
Oft kann bereits der Kunde eine Angabe zum Fehlerstatus machen. Die Angabe wird entsprechend bei der Ermittlung der Fehlerkandidaten bei der Symptomverarbeitung berücksichtigt. Die Bedatung steuert diesen Verdacht. Die Prüfschrittdatenbank ist um Prüfschritte für Kandidatenprüfung unter Verdacht auf einen sporadischen Fehler zu erweitern. Der Algorithmus bei dem Aufspannen des Prüfschrittbaumes koordiniert ihren Einsatz.
Optionale Methoden zur Lokalisierung nicht-reproduzierbarer Fehler
An dieser Stelle sollen optionale Systemerweiterungen vorgeschlagen werden.
In der aus dem Stand der Technik bekannten Werkstattdiagnose spielen insbesondere die sporadischen Fehler eine wesentliche Rolle. Diese Fehler sind im Allgemeinen nur zum Zeitpunkt ihres Vorliegens detektierbar und identifizierbar. Liegt ein solcher Fehler vor muss das Fahrzeug in der Werkstatt verbleiben, um die Beanstandung nachzuvollziehen. Der Kunde verliert das Vertrauen in die Kompetenz der Werkstatt und das Produkt. Wird das Fahrzeug in der Werkstatt gehalten, verur sacht die Fehlersuche unmittelbar zusätzliche Kosten durch ein Ersatzfahrzeug. Die langfristigen Auswirkungen, durch den Verzicht auf das eigene Fahrzeug des Kunden, sind erst gar nicht überschaubar. Die Fehlersuche erstreckt sich oft über ein Wochenende. Der Kunde hat sein Fahrzeug nicht zur Disposition, während die Werkstatt nicht an der Fehlerlokalisierung arbeitet. Daher sind vor allem Systeme gefragt, die das Geschehen innerhalb des Fahrzeuges verfolgen können. Einen zusätzlichen Reiz haben Systeme, bei denen der Kunde nicht auf sein Fahrzeug verzichten muss, während die Werkstatt versucht, den Fehler zu finden. Folgende optionalen Systemerweiterungen des hier beschriebenen Diagnosesystems stellen ein erhebliches Potential zur Verbesserung der vorbekannten Diagnosesysteme bereit:

• Datenlogger: Unter Einverständnis des Fahrzeughalters sollte ein parametrierbarer Datenlogger eingesetzt werden. Je nach Symptom nimmt der Logger wichtige Daten auf, die zu einem späteren Zeitpunkt zentral oder mit einem speziellen Werkstattsystem analysiert werden. Ein Konverter zur Visualisierung der Daten in der Werkstatt sollte vorhanden sein. Um Speicher zu sparen, kann der Logger als Ringpuffer realisiert werden, der die Daten über ein definiertes Intervall um den Zeitpunkt der Fehlerdetektion aufzeichnet. Durch den Ringpuffer können auch Daten vor der Fehlermeldung aufgezeichnet werden. Als Trigger eignet sich ein festgelegter Fehlercode oder der Response-on-event-Mechanismus.
• Ferndiagnose: Die Ferndiagnose ist als Ergänzung zum Datenlogger zu betrachten. Grundlage der Ferndiagnose ist eine temporär integrierbare Komponente (Fahrzeug-Interface), die an der Fahrzeugkommunikation passiv beteiligt ist. Zusätzlich sind weitere Eingänge denkbar, die physikalische Messdaten unmittelbar am Fahrzeug abgreifen. Des Weiteren enthält die Komponente ein GSM- Modem, um die Fahrzeugdaten an ein externes Diagnosegerät oder -team zu übermitteln.

Die Fehlerlokalisierung findet offboard statt, während der Kunde nicht auf sein Fahrzeug verzichten muss. Durch eine Nominalüberwachung kann der Fehler detektiert werden. Alternativ triggern Fahrzeugereignisse den Diagnoseprozess. Letzteres basiert auf einer Verarbeitung regulärer Systembotschaften oder dem Response-on-event Mechanismus, indem das Steuergerät ereignisorientiert reagiert.
Die Kommunikationsaufnahme zum Fahrzeug erfolgt durch die Fahrzeugkomponente oder das externe Diagnosegerät bzw. -Team. Zukünftig kann für die Kommunikation größerer Datenmengen UMTS eingesetzt werden.
Wie bereits erwähnt, kann die Diagnose durch ein kompetentes Team unter Zuhilfenahme des Entwicklers unternommen werden. Für die automatische Diagnose stehen fallspezifisch verschiedene Verfahren zur Verfügung. Während für statische Fälle regelbasierte oder modellbasierte Verfahren zur Verfügung stehen, übernimmt beispielsweise eine Auswertung von Zustandsautomaten oder die Residuenverarbeitung die Diagnose dynamischer Vorgänge. Eine Auswertung mit Zustandsautomaten basiert auf der Möglichkeit einer Abbildung der Trajektorien von Zustandsgrößen auf nichtdeterministische oder stochastische Automaten. Liegt eine Diskretisierung des Zustandsraumes vor, verhält sich das System ereignisdiskret. Funktionale Zusammenhänge können in einem Kausalitätsgraphen oder Bayes'schen Netzwerk dargestellt und entsprechend ausgewertet werden.

• Temporäre Onboard-Diagnose. Eine temporäre Onboard-Diagnose stellt eine weitere optionale Erweiterung für das hier offenbarte Diagnosesystem dar, das einen signifikanten Beitrag zur Fehlerlokalisierung von sporadischen Fehlern leisten kann. Sie wird in das Fahrzeug integriert und übernimmt die Systemauswertung zur Laufzeit mit allen notwendigen Randbedingungen.

Da für eine temporäre Onboard-Diagnose nicht die heutigen Einschränkungen bezüglich der Ressourcen im Embedded-Bereich gelten, kann ihr volles Potential ausgeschöpft werden. Größere Kapazitäten der zur Verfügung stehende Speicher- und Rechen-Ressourcen, die mit temporär eingebauten Geräten möglich sind, ermöglichen eine Erweiterung der Wissensbasen sowie den Einsatz modellbasierter Ansätze onboard im Fahrzeug, so dass auch Mehrfachfehler lokalisiert werden können. Stochastische Automaten oder Analysen kausaler Zusammenhänge übernehmen die Diagnose dynamischer oder funktionaler Vorgänge. Das Ergebnis der Onboard-Diagnose kann in der Werkstatt wieder ausgelesen und weiterverarbeitet werden. Alternativ ist eine Kombination der temporären Onboard-Diagnose mit der Ferndiagnose denkbar. Hierbei übernimmt die Onboard-Diagnose die Vorverarbeitung bzw. Vorauswertung im Fahrzeug und kommuniziert die Ergebnisse an eine externe Einheit.

Claims

Rechnergestütztes Diagnosesystem für technische Vorrichtungen mit einem ablauffähigen Diagnoseprogramm, – das mit einem implementierten Auswertealgorithmus fehlerspezifische technische Systemdaten der zu analysierenden technischen Vorrichtung erfasst, – das mit dem Auswertealgorithmus die erfassten, technischen Systemdaten mit einem rechnerverarbeitbaren Modell der technischen Vorrichtung und mit einer technischen Wissensbasis, in der zu dem rechnerverarbeitbaren Modell regelbasiertes Diagnosewissen über die zu analysierende technische Vorrichtung abgelegt ist, bewertet, interpretiert und zu einer Diagnoseentscheidung gelangt, wobei die Diagnoseentscheidung eine erste Fehlerkandidatenmenge enthält, die angibt welche Teile der technischen Vorrichtung, als fehlerhaft verdächtigt werden, dadurch gekennzeichnet, dass mit einem Mensch-Maschine-Interface beobachtete Fehlersymptome erfasst werden und auf einen aktuellen, modellbasierten Symptombaum abgebildet werden – und dass der Auswertealgorithmus mit einer Symptomverarbeitung und einer zweiten symptombasierten Wissensbasis die Symptome des aktuellen, standardisierten Symptombaums bewertet, interpretiert und eine zweite Fehlerkandidatenmenge ermittelt.
Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass mindestens eine der beiden Fehlerkandidatenmengen für die einzelnen Fehlerkandidaten sowohl Belastungsmerkmale als auch Entlastungsmerkmale enthalten.
Diagnosesystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Fehlersymptome aus einer Kundenbeanstandung ermittelt werden.
Diagnosesystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Auswertealgorithmus die erste und die zweite Fehlerkandidatenmenge miteinander verrechnet.
Diagnosesystem nach Anspruch 4, dadurch gekennzeichnet, dass bei der Verrechnung von erster und zweiter Fehlerkandidatenmenge diejenigen Fehlerkandidaten ausgesondert werden, die Entlastungsmerkmale enthalten.
Diagnosesystem nach Anspruch 4, dadurch gekennzeichnet, dass bei der Verrechnung von erster und zweiter Fehlerkandidatenmenge die Durchschnittsmenge beider Fehlerkandidatenmengen bestimmt wird.
Diagnosesystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass für die Fehlerkandidaten eine Priorisierung durchgeführt wird.
Diagnosesystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass zu der ermittelten Fehlerkandidatenmenge ein Prüfschrittbaum aufgespannt wird.
Diagnosesystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass das Diagnosesystem in seiner Struktur um weitere Auswertealgorithmen und Wissensbasen erweiterbar ist.
Diagnosesystem nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass mit einem Abhilfesystem (Tips/News) eine weitere Fehlerkandidatenmenge ermittelt wird.
Diagnosesystem nach Anspruch 8, dadurch gekennzeichnet, dass der Prüfschrittbaum aus Prüfschrittprimitiven aufgespannt wird.
Diagnosesystem nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass von dem Auswertealgorithmus eine weitere Wissensbasis zur Fahrzeughistorie mit in die Bestimmung der Fehlerkandidatenmenge einbezogen wird.