DE102004019151A1 - Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien - Google Patents

Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien Download PDF

Info

Publication number
DE102004019151A1
DE102004019151A1 DE102004019151A DE102004019151A DE102004019151A1 DE 102004019151 A1 DE102004019151 A1 DE 102004019151A1 DE 102004019151 A DE102004019151 A DE 102004019151A DE 102004019151 A DE102004019151 A DE 102004019151A DE 102004019151 A1 DE102004019151 A1 DE 102004019151A1
Authority
DE
Germany
Prior art keywords
error
heuristic
diagnostic
path search
structural model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102004019151A
Other languages
English (en)
Inventor
Harald Nauerz
Wojciech Oberdorfer
André Dr. Schulz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
DaimlerChrysler AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by DaimlerChrysler AG filed Critical DaimlerChrysler AG
Priority to DE102004019151A priority Critical patent/DE102004019151A1/de
Priority to PCT/EP2005/004024 priority patent/WO2005109136A1/de
Priority to US11/587,166 priority patent/US20070220330A1/en
Publication of DE102004019151A1 publication Critical patent/DE102004019151A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • G05B23/0248Causal models, e.g. fault tree; digraphs; qualitative physics

Abstract

Die Erfindung betrifft ein rechnergestütztes Diagnosesystem, bei dem die physikalische Struktur des zu diagnostizierenden technischen Systems in Form eines Strukturmodells implementiert ist. Tritt in einem zur Eigendiagnose fähigen Bauteil des technischen Systems und damit auch im Strukturmodell ein Fehlercode auf, so wird mit einer parametrierbaren Pfadsuche abhängig von dem aufgetretenen Fehler in dem Strukturmodell mittels des Pfadsuchalgorithmus nach dem Fehlerort gesucht. Die Parametrierung der Pfadsuche gelingt hierbei durch fehlerspezifische Heuristiken. Eine Heuristik im Sinne der Erfindung ist hierbei ein in Abhängigkeit eines aufgetretenen Fehlers auswählbares Softwaremodul, das einen fehlerspezifischen Auswertealgorithmus enthält, das Angaben zur Menge der Kandidaten, die in die Fehlersuche einzubeziehen sind, enthält und das Regellisten mit Fehlersetzbedingungen enthält, die vom Auswertealgorithmus für eine Fehlerentscheidung herangezogen werden. Der Fehlerort ist gefunden, wenn eine Zustandsvariable eines Bauteils im Strukturmodell eine Fehlersetzbedingung erfüllt.

Description

  • Die Erfindung betrifft eine Diagnosevorrichtung, ein rechnergestütztes Diagnosesystem und ein rechnergestütztes Verfahren zur Durchführung einer Diagnose für ein komplexes technisches System wie z.B. einem Kraftfahrzeug. Das Diagnosesystem setzt hierbei auf der Systemtopologie des zu untersuchenden Systems auf und macht sich logische und physikalische Zusammenhänge in der Systemtopologie zu Nutze, um mit einem softwaremäßig implementierten Algorithmus zu einer Diagnose zu gelangen.
  • Technologische Grundlagen:
  • Ziel der Gewinnung von Diagnose-Wissen ist die Vereinfachung der Fehlersuche. Man möchte eine möglichst scharfe Aussage im Bezug auf mögliche Fehlerursachen in einem Pannenfall. Als Fehlerursachen kommen Steuergeräte in Frage sowie Bauteile aus der angeschlossenen Peripherie (Stecker, Leitungen, Aktoren, Sensoren usw.). Die rechnergestützte Systemdiagnose ist allerdings nicht in der Lage, mögliche Fehler im Fahrzeug selbst zu erkennen. Dafür ist die Information zu erkannten Fehlern aus den Steuergeräten erforderlich; diese müssen an die Systemdiagnose übertragen werden. Nicht von den Steuerge räten erkannte Fehler können von der Systemdiagnose nicht verarbeitet bzw. diagnostiziert werden.
  • Aus der obigen Erläuterung folgt, dass folgende Inputs für die Gewinnung von Diagnose-Wissen erforderlich sind:
    • – Informationen zur Topologie (Steuergeräte inklusive Peripherie). Hiermit ist gemeint, dass Informationen zum Typ eines jeden Bauteils sowie zu seiner Verbindung mit anderen Bauteilen erforderlich ist. Diese Informationen sind z.B. in Schaltplänen ersichtlich oder in Leitungssatz-Report-Dateien (auch Netzlisten genannt) vorhanden. Der Typ eines Bauteils kann in der Regel anhand des Bauteilnamens identifiziert werden; verschiedene Bauteiltypen besitzen unterschiedliche Namenspräfixe (z.B. "X23/5" ist eine Trennstelle, "N93" ist ein Steuergerät, "5117" ist ein Schalter usw.).
    • – Informationen zu den von den Steuergeräten erkennbaren Fehlern. Im Diagnose-Lastenheft eines jeden Steuergeräts findet man eine Fehlercodetabelle. Diese Tabelle gibt Auskunft über alle erkennbaren Fehler: Wann sie vorliegen (Fehlersetzbedingung), wann sie nicht länger vorliegen (Fehlerrücksetzbedingung), und um welche Fehlerart es sich dabei handelt (Software-Fehler, Unter-/Überspannung, Unterbrechung, Kurzschluss usw.).
  • Um Diagnose-Wissen aus den oben genannten Inputs gewinnen zu können müssen sie miteinander kombiniert werden. Das heißt, die von den Steuergeräten erkennbaren Fehler müssen ihrem zugehörigen Peripherieanteil zugeordnet werden; hierzu reicht, den Fehler dem Steuergerät-Pin korrekt zuzuordnen. Erst dann kann eine Aussage zu einem Bauteil bei einem gegebenen Fehler gemacht werden. Die Zuordnung zwischen Fehlercode und Steuergerät-Pin muss vom Systemdiagnoseautor gemacht werden und programmtechnisch in einen Software-Algorithmus umgesetzt werden.
  • Bekannte rechnergestützte Diagnosesystem sind in der Fachwelt unter dem Begriff modellbasierte Systemdiagnose bekannt. Derartige Diagnosesysteme sind z.B. in der DE 195 23 483 A1 und in der DE 100 51 781 A1 beschrieben.
  • Ziel der modellbasierten Methode ist die Gewinnung von Diagnose-Wissen aus der Benutzung eines möglichst realen Abbilds des betreffenden Systems. Das dadurch gewonnene Diagnose-Wissen ist daher zur Diagnose des realen Systems am geeignetesten.
  • Um ein möglichst reales Abbild des Systems zu erstellen ist eine detaillierte Modellierung erforderlich. Dazu zählen zum einen die Systemtopologie (auch Strukturmodell genannt) und zum anderen das Systemverhalten (auch Verhaltensmodell genannt); beide zusammen werden der Einfachheit halber "Modell" genannt (daher der Name "modellbasierte Diagnose").
  • Das Strukturmodell kann aus dem Schaltplan oder aus den Leitungssatz-Report-Dateien gewonnen werden. Die Erstellung des Strukturmodells kann dabei automatisch erfolgen, lediglich auf mögliche Varianten muss geachtet werden.
  • Das Strukturmodell allein stellt kein geeignetes Abbild des realen Systems dar. Es muss mit Verhaltensinformationen --in der Regel bestehend aus mathematischen Beziehungen-- angereichert werden. Diese Arbeit kann nur bedingt automatisch erfolgen: Für einfache, Standardbauteile kann das Verhalten aus einer Bibliothek entnommen werden, für komplexere Bauteile muss der Systemdiagnoseautor das Verhalten selbst eingeben.
  • Ist das Systemmodell, bestehend aus Struktur- und Verhaltensmodell, komplett, so kann man Schlüsse im Bezug auf das Verhalten in verschiedenen Situationen ziehen. Um Diagnose-Wissen aus diesem Modell zu extrahieren, werden dann alle möglichen Fehlerbilder in das Modell eingebaut und das Verhalten beobachtet; dies geschieht im Rahmen einer Reihe von Simulationen, aus denen eine Datenbank entsteht. Diese Datenbank enthält dann für alle Fehlerkombinationen die Parameter aller Systemkomponenten, also gewissermaßen das Verhalten in jeder Fehlersituation.
  • Mit einem im Diagnosesystem implementierten Entscheidungsalgorithmus findet man zu einem Fehlersymptom passende Verhaltensbilder in der Datenbank, so kann man auf die möglichen Fehlerursachen rechnergestützt schließen. Diese Methode ist aber in der Praxis oft nur für einfache Systeme durchführbar, da die Datenbank für aufwendigere Systeme sehr groß sein kann. Man hat deshalb in der Vergangenheit z.B. in der DE 197 42 450 A1 den Weg der Datenreduktion eingeschlagen. Durch die Beschränkung auf beobachtbare Größen und durch graphentheoretische Überlegungen werden alle Systemknoten, die keinen Einfluss auf die beobachtbaren Größen haben, mittels eines Reduktionsgraphen eliminiert.
  • Einige Steuergeräte realisieren sehr einfache Funktionen, wie z.B. die Bedienung des Dachs oder der Beifahrertür. Die physikalische Ausprägung solcher Systeme spiegelt die Komplexität der Funktion wider, d.h., solche Steuergeräte besitzen eine kleine Peripherie und erkennen nur wenige Fehler. Hierfür ist eine aufwendige Modellierung und Simulation nicht erforderlich; der Systemdiagnoseautor ist in der Lage, mit Hilfe der verfügbaren Informationen das Diagnose-Wissen selbst manuell zu erstellen. Dazu ist lediglich ein EDV-Editor notwendig, mit dem die funktionalen Zusammenhänge in Form von rechnergestützten Entscheidungsregeln festgehalten werden, z.B. durch einfache „wenn... dann... Regeln".
  • Bei der manuellen Erstellung von Diagnose-Wissen hat man folgende Vorteile:
    • – Das Diagnose-Wissen kann direkt formuliert werden; keine Vorarbeit ist hier erforderlich.
  • Bei der manuellen Erstellung von Diagnose-Wissen hat man folgende Nachteile:
    • – Unterschiedliche Qualität des Diagnose-Wissens. Da der Erstellungsprozess manuell durchgeführt wird, ist die Qualität des Diagnose-Wissens abhängig vom Systemdiagnoseautor. Um ein Mindestmaß an Qualität zu garantieren sind daher regelmäßige Reviews erforderlich.
    • – Aufwendige Nachvollziehbarkeit. Der Weg zur Erstellung des Diagnose-Wissens lässt sich nicht explizit darstellen, es ist eine Leistung des Systemdiagnoseautors. Durch ausreichende Dokumentation lässt sich dieser Weg nachvollziehen; diese Dokumentation muss vom Systemdiagnoseautor erstellt werden.
    • – Hoher Aufwand bei Varianten. Besitzt ein System verschiedene Varianten, so muss der Erstellungsprozess für jede Variante neu angestoßen werden. In gewissen Fällen lassen sich Teilumfänge wiederverwenden.
    • – Hoher Pflegeaufwand. Bei Änderungen muss der Erstellungsprozess im schlimmsten Fall, sprich, wenn keine ausreichende Dokumentation vorliegt, neu angestoßen werden.
  • Bei der modellbasierten Methode zur Gewinnung von Diagnose-Wissen hat man dagegen folgende Vorteile:
    • – Garantiertes Qualitätsmaß. Unter Verwendung einer geeigneten Komponentenbibliothek und der Modellierung des Verhal tens auf der mathematischen Ebene kann ein hohes Maß an Qualität sichergestellt werden.
    • – Gute Nachvollziehbarkeit. Das Systemmodell stellt eine geeignete Dokumentation der Modellierung dar.
  • Bei der modellbasierten Methode zur Gewinnung von Diagnose-Wissen hat man folgende Nachteile:
    • – Aufwendiger Prozess. Auch mit Hilfe eines modellbasierten Werkzeugs ist die Modellierungsarbeit aufwendig. Die Modellierung des Verhaltens ist zum großen Teil manuelle Arbeit, die Simulation ist zeitintensiv.
    • – Hoher Aufwand bei Varianten. Die Modellierung von Varianten erfordert einen Neuanstoß des Prozesses ab der Struktur- oder Verhaltensmodellebene.
    • – Hoher Pflegeaufwand. Bei Änderungen muss der Erstellungsprozess neu angestoßen werden, im schlimmsten Fall angefangen beim Strukturmodell.
    • – Unnötige Tiefe des Diagnose-Wissens. Das Diagnose-Wissen, welches sich in der Simulationsdatenbank befindet, ist sehr tief bzw. zu umfangreich für die Nutzung im Fahrzeug. Das gewonnene Diagnose-Wissen muss also stark vereinfacht werden, damit es benutzt werden kann.
  • Obwohl beide Methoden für manche Fälle sehr gut anwendbar sind, gibt es viele andere Fälle, bei denen die modellbasierte Methode zu aufwendig ist, und weitere Fälle, bei denen die manuelle Erstellung des Diagnose-Wissens zu riskant ist. Typischerweise ist das System zu umfangreich, um manuell verarbeitet zu werden, aber gleichzeitig ist eine aufwendige Modellierung nicht lohnenswert. In solchen Situationen wäre eine vereinfachte Modellierung wünschenswert, so dass der Prozess qualitativ hochwertiges Diagnose-Wissen bei vertretbarem Aufwand liefert.
  • Bekannt ist ebenfalls, dass es möglich ist, mittels bekannter Pfadsuchalgorithmen Kopplungen und funktionale Zusammenhänge in Strukturmodellen aufzufinden und die zugehörigen Bauteile korrekt zu identifizieren. An der Universität Paderborn mit Unterstützung durch die DFG, unter Projekt Nummer KI529/7-1;Schw120/56-1 hat man verschiedene Pfadsuchalgorithmen auf deren Verlässlichkeit hin untersucht. Die Ergebnisse wurden in Form eines technischen Berichtes „Topological Analysis of Hydraulic Systems" an der Universität Paderborn von Benno Stein und Andre Schulz im Juni 1997 veröffentlicht. Beginnend mit dem physikalischen Strukturmodell, der System-Topologie, das in einen Graphen entsprechend der oben erwähnten Graphentheorie z.B. aus DE 19 742 450 A1 umgewandelt wird, ist es daher mit Pfadsuchalgorithmen möglich, zu einem vorgegebenen funktionalen Zusammenhang den zugehörigen Pfad im Strukturgraphen mit den zugehörigen Bauteilen automatisch und rechnergestützt korrekt zu ermitteln.
  • In Anbetracht der Tatsache, dass die manuelle Erstellung von Diagnose-Wissen oft unzureichend ist und die klasssische modellbasierte Vorgehensweise oft zu aufwendig ist, wird erfindungsgemäß eine Lösung angestrebt, die dazwischen liegt.
  • Ausgehend von dem vorbeschriebenen Stand der Technik ist es daher erfindungsgemäße Aufgabe eine alternative Form der rechnergestützten Diagnose anzugeben, die mit einer reduzierten Modellbildung, insbesondere ohne der Modellierung eines Verhaltensmodell, und ohne Simulation zur Erzeugung von entscheidungsrelevantem Diagnosewissen auskommt.
  • Die Lösung gelingt mit einem rechnergestützten Diagnosesystem nach Anspruch 1. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen und der Erfindungsbeschreibung enthalten.
  • Die Lösung gelingt mit einem rechnergestützten Diagnosesystem, bei dem die physikalische Struktur des zu diagnostizierenden technischen Systems in Form eines Strukturmodells implementiert ist. Tritt in einem zur Eigendiagnose fähigen Bauteil des technischen Systems und damit auch im Strukturmodell ein Fehlercode auf, so wird mit einer parametrierbaren Pfadsuche abhängig von dem aufgetretenen Fehler in dem Strukturmodell mittels des Pfadsuchalgorithmus nach dem Fehlerort gesucht. Die Parametrierung der Pfadsuche gelingt hierbei durch fehlerspezifische Heuristiken. Eine Heuristik im Sinne der Erfindung ist hierbei ein in Abhängigkeit eines aufgetretenen Fehlers auswählbares Softwaremodul, das einen fehlerspezifischen Auswertealgorithmus enthält, das Angaben zur Menge der Kandidaten, die in die Fehlersuche einzubeziehen sind, enthält und das Regellisten mit Fehlersetzbedingungen enthält, die vom Auswertealgorithmus für eine Fehlerentscheidung herangezogen werden. Der Fehlerort ist gefunden, wenn eine Zustandsvariable eines Bauteils im Strukturmodell eine Fehlersetzbedingung erfüllt
  • In einer Ausführungsform ist hierbei in dem Auswertealgorithmus der Heuristik ein Pfadsuchalgorithmus integriert. Dann kann es zu jedem Fehler einen fehlerspezifischen Pfadsuchalgorithmus geben.
  • In einer anderen vorteilhaften Ausführungsform der Erfindung dient die Heuritik lediglich der Parametrierung der Pfadsuche, im folgenden auch als informierte Graphensuche bezeichnet. Das hat den Vorteil, das für die Pfadsuche unabhängig vom Fehler jedesmal der gleiche Pfadsuchalgorithmus verwendet werden kann. Über den Auswertealgorithmus, der in diesem Fall mit dem Pfadsuchalgorithmus zusammenarbeitet, gelingt dann die Parametrierung auf den jeweils aufgetretenen Fehler. Der Auswertealgorithmus stellt dann auf die zu untersuchenden Systemobservablen und Systemvariablen ab, und stellt fest, wann für eine Systemvariable oder Systemobservable eine Fehlersetzbedingung erfüllt ist.
  • Das erfindungsgemäße Diagnosesystem ist vorteilhafterweise geeignet für technische Systeme mit einer Topologie, bei der die zur Eigendiagnose fähigen Bauteile des technischen Systems über einen Datenbus miteinander und mit einem Buscontroller kommunizieren. In diesem Fall ist es zweckmäßig dem Mikroprozessor, der die Funktion des Buscontrollers übernimmt soweit zu erweitern, dass er auch in Lage ist, das erfindungsgemäße Diagnosesystem aufzunehmen und die Diagnose auf der Basis des Strukturmodells durchzuführen. Die Erweiterung besteht hierbei hauptsächlich darin, genügend Arbeitsspeicher und genügend Programmspeicher vorzuhalten sowie ein in seiner Rechenleistung geeignet dimensionierten Mikrocontroller einzusetzen. Die Rechenleistung ist hierbei nicht besonders kritisch, da lediglich die Buskommunikation quasi in Echtzeit zu erfolgen hat. Die Durchführung der Diagnose braucht nicht in Echtzeit zu erfolgen.
  • Der mit der Erfindung hauptsächlich erzielte Vorteil liegt im verminderten Aufwand für die Modellbildung. Der Rückgriff auf die Fehlercodes der zur Eigendiagnose fähigen Bauteile des technischen Systems erlaubt in Kombination mit den fehlerspezifischen den Verzicht auf die Modellierung eines Verhaltensmodells und den Verzicht auf eine aufwendige Simulation, mit der bei bekannten modellbasierten Diagnosesystemen erst alle möglichen Systemzustände durchgespielt und bewertet werden müssen, um eine Datenbank mit Diagnosewissen aufbauen zu können, mit dem dann erst die eigentliche Diagnose durchgeführt werden kann. Zwar ist dadurch das erfindungsgemäße Diagnosesystem beschränkt auf diejenigen Fehler, die von den zur Eigendiagnose fähigen Bauteilen des Strukturmodells erkannt werden können, jedoch ergibt die tägliche Erfahrung, dass damit etwa 90%–95% der auftretenden Fehler erfasst werden, und die vereinfachte Fehlersuche mit Heuristiken eher bessere Ergebnisse für die Fehlersuche liefert, als ein modellbasiertes Diagnosesystem, dass alle denkbaren Varianten der Systemzustände durchrechnet und doch nicht zu einem eindeutigen Ergebnis kommt und dadurch die Fehlersuche doch wieder dem Fachmann bleibt, der naturgemäß sowieso heuristisch vorgeht.
  • Man kann also als einen weiteren Vorteil des erfindungsgemäßen Diagnosesystems herausstellen, dass es besser an die Vorgehensweise eines Fachmanns angepasst ist, und dadurch die Diagnoseergebnisse von diesem Fachmann besser beurteilt werden können.
  • Anhand von graphischen Darstellungen wird im folgenden die Erfindung näher erläutert. Dabei zeigen:
  • 1 Eine Übersichtsgraphik mit den wichtigsten Elementen der Erfindung,
  • 2 Eine Blockgraphik zur Veranschaulichung einer softwaremäßig implementierten Heuristik,
  • 3 Eine Kurzdarstellung der Erfindung zur Erläuterung des Hauptunterschiedes der Erfindung im Vergleich mit einem modellbasierten Diagnosesystem aus dem Stand der Technik,
  • 4 Ein modellbasiertes Diagnosesystem aus dem Stand der Technik.
  • Der größte Teil des Aufwands bei einer modellbasierten Methode aus dem Stand der Technik nach 4 fällt bei der Verhaltensmodellierung und der anschließenden Simulation an. Außerdem wird die aus diesem aufwendigen Prozess entstehende Modelltiefe in der Realität einer Werkstatt nicht genutzt. Beschränkt man sich bei der Modellierung des Diagnosesystems auf das Strukturmodell, also auf die Systemtopologie, so kann man auch Diagnose-Wissen daraus extrahieren. Im Vergleich zur vorbekannten modellbasierten Diagnose ist das gewonnene Diagnose-Wissen zwar vereinfacht, aber die resultierende Tiefe entspricht der, die von der heutigen Systemdiagnose in einer Werkstatt genutzt werden kann.
  • Die 3 illustriert die vereinfachte Modellierung auf der Strukturmodell-Ebene gemäß der Erfindung.
  • Hier wird nur das Strukturmodell des zu analysierenden technischen Systems benutzt. Die einzige Informationen, die man außer der Topologie benötigt, sind die Typen der Komponenten, die im Strukturmodell vorhanden sind; abhängig davon, ob es Arbeitselemente, Versorgungselemente oder Schaltelemente sind, wird unterschiedlich vorgegangen bei der Analyse des Strukturmodells. Diese unterschiedlichen Vorgehensweisen werden mit einer informierten Graphensuche umgesetzt.
  • Die informierte Graphensuche ist eine parametrierte Tiefensuche beginnend beim Steuergerät das auf Grund seiner Eigendiagnose einen Fehlercode gemeldet hat. Ein Fehlercode besteht hierbei aus Informationen, von wem der Fehlercode stammt und um welche Fehlerart es sich handelt. Dabei ist die Fehlerart der wichtigste Parameter zur Steuerung der informierten Gra phemsuche. Die Fehlerart bestimmt dabei, wie man mit der besuchten Peripherie des meldenden Steuergeräts umzugehen hat.
  • Die Parametrierung besteht aus einer fehlerartspezifischen Heuristik Zn, die vorgibt, welchen Umfang der zu untersuchenden Peripherie in die Menge der Fehlerkandidaten Zn des aktuell zu verarbeitenden Fehlercodes Zn übernommen werden soll. Eine beispielhafte Heuristik ist in 2 veranschaulicht. Die Heuristik Zn schließt nicht nur den fehlerspezifischen Auswertealgorithmus Zn der Vorgehensweise mit den zu untersuchenden Komponenten ein, sondern spiegelt die Vorgehensweise gemäß der Modellierungsrichtlinie wieder. Die Modellierungsrichtlinie ist eine Sammlung von Vorschriften, die bei der Erstellung von fehlerspezifischen Regellisten Zn eingehalten werden müssen. Beispiele für solche Richtlinien: "Masseknoten dürfen nicht entlastet werden" oder "Bei Fehlerart Kurzschluss nach Masse werden Schalter mit dem Fehlermodus 'Klemmt' versehen". Die Regellisten geben also an, bei welcher Belegung der Zustandvariablen eines Bauteils im Strukturmodell das Bauteil durch den Auswertealgorithmus als fehlerhaft zu bewerten ist.
  • Die wichtigsten, von den Steuergeräten erkennbaren Fehlerarten sind "Unterbrechung", "Kurzschluss nach Masse" und "Kurzschluss nach Versorgung". Diese Fehlerarten treten in der Realität sowohl vereinzelt als auch in Kombination mit anderen Fehlerarten auf, z.B. als "Unterbrechung und Kurzschluss nach Masse". Um solche Fälle abzudecken müssen die erfindungsgemäßen Heuristiken in Kombination verwendet werden können oder hintereinander geschaltet werden können.
  • Heuristik "Unterbrechung"
  • Bei der Fehlerart "Unterbrechung" werden alle Komponenten auf dem Weg zwischen dem Steuergerät und dem Masseknoten berücksichtigt. Dabei wird nach Komponententypen unterschieden:
    Stecker: Stecker werden mit der Ausfallart "Unterbrechung" verdächtigt.
    Leitung: Leitungen werden mit der Ausfallart "Unterbrechung" verdächtigt.
    Bauteile: Bauteile werden mit der Ausfallart "Defekt" verdächtig; der Masseknoten wird mit der Ausfallart "Unterbrechung" verdächtigt.
  • Befinden sich in der mit dem Pfadsuchalgorithmus und der Heuristik zu untersuchenden Peripherie mehrere Masseknoten, so werden alle Massepfade berücksichtigt. Dies führt zur Übernahme von überflüssigen Komponenten und muss anschließend vom Fachmann beurteilt werden. Jedoch hat dann der Fachmann Hinweise in welchen Massepfaden, welche Bauteile genauer zu untersuchen sind. Sind im Strukturmodell weitere Informationen vorhanden, z.B. welches der Standard Massepfad ist, so kann die Fehlersuche weiter eingeschränkt werden, auf diejenigen Massepfade, die durch einen Kurzschluss neu hinzugetreten sind.
  • Heuristik "Kurzschluss nach Masse"
  • Bei der Fehlerart "Kurzschluss nach Masse" werden alle Komponenten auf dem Weg zwischen dem Steuergerät und dem letzten Bauteil vor der Masse berücksichtigt. Dabei wird nach Komponententypen unterschieden:
    Stecker: Stecker werden nicht verdächtigt.
    Leitung: Leitungen werden mit der Ausfallart "Kurschluss nach Masse" verdächtigt.
    Bauteil: Bauteile werden feiner unterschieden:
    Schalter: Schalter werden mit der Ausfallart "Klemmt" verdächtigt.
    Motoren: Motoren werden mit der Ausfallart "Kurschluss" verdächtigt (alternativ: "Defekt").
    Sonstige: Sonstige Bauteile werden mit der Ausfallart "Defekt" verdächtigt.
  • Heuristik "Kurzschluss nach Versorgung"
  • Bei der Fehlerart "Kurzschluss nach Versorgung" werden alle Komponenten auf dem Weg zwischen dem Steuergerät und der Masse berücksichtigt. Dabei wird nach Komponententypen unterschieden:
    Stecker: Stecker werden nicht verdächtigt.
    Leitung: Leitungen werden mit der Ausfallart "Kurzschluss nach Versorgung" verdächtigt.
    Bauteile: Bauteile werden feiner unterschieden:
    Schalter: Schalter werden mit der Ausfallart "Klemmt" verdächtigt.
    Motoren: Motoren werden mit der Ausfallart "Kurschluss" verdächtigt (alternativ: "Defekt").
    Sonstige: Sonstige Bauteile werden mit der Ausfallart "Defekt" verdächtigt.
  • Um die Qualität des gewonnenen Diagnose-Wissens zu steigern, können einige Erweiterungen hinzugenommen werden. Hierzu werden dem Strukturmodell zusätzliche Informationen hinzugefügt; dieses zusätzliche Wissen kann dann von den Heuristiken ausgenutzt werden.
  • Für die Heuristik "Kurschluss nach Masse" ist das Wissen über vorhandene Massepfade sehr hilfreich, da es der Heuristik ermöglicht, die Suche rechtzeitig abzubrechen und eine manuelle Nachbesserung des Diagnose-Wissens überflüssig macht.
  • Die Bestimmung der Massepfade kann direkt nach der Nachbildung der Topologie anhand der Leitungssatz-Report-Dateien erfolgen. Masseknoten müssen dafür als solche erkannt werden können; bei Mercedes-Benz kann man Masseknoten anhand des Namens erkennen, da sie mit dem Buchstaben "W" beginnen müssen. Nach dem Laden der Leitungssatz-Report-Dateien und der Nachbildung der Topologie kann die Vorverarbeitung stattfinden: Angefangen bei jedem vorhandenen Masseknoten werden die Wege zu allen Nachbarn besucht und die darauf liegenden Komponenten als zum Masseweg gehörend markiert. Diese Suche endet auf jedem Weg immer beim ersten Bauteil, der eine nichttriviale Funktion besitzt (solche Bauteile können anhand des Namens erkannt werden). Auf einem Massepfad liegen schließlich nur Stecker, Trennstellen, Leitungen, Verteilerknoten (sie können anhand des Namens ebenfalls erkannt werden) sowie der Masseknoten selbst.
  • In manchen Fällen beziehen Bauteile, die zur Peripherie eines Steuergeräts gehören, ihre Masse vom Steuergerät selbst. In solchen Fällen werden diese Massepfade nicht während der Vorverarbeitung erkannt. Damit dies aber doch funktioniert, kann die Information über eine Masseleitung am Steuergerät dem System übergeben werden -- in gewisser Weise fügt man virtuelle Masseknoten in die System-Topologie ein. In einer "zwei ten" Vorverarbeitung kann dann analog zur Bestimmung der Massepfade während der Vorverarbeitung verfahren und diese Wege als Massepfade markiert werden.
  • Angabe von Versorgungspfaden
  • Für die Heuristik "Kurzschluss nach Versorgung" gilt Ähnliches wie bei der Heuristik "Kurzschluss nach Masse". Der Unterschied hier ist, dass die Suche die Versorgungspfade selbst nicht betrachten muss.
  • Weitere Fehlerarten
  • Es gibt weitere Fehlerarten, die bisher nicht in Betracht gezogen worden sind. Diese Fehlerarten, wie z.B. "Signal unplausibel" oder "CAN-Kommunikationsfehler" sind keine elektrischen Fehler, sondern logische Fehler. Im Falle der Fehlerart "CAN-Kommunikationsfehler" dürfen nur CAN-Leitungen in die Fehlerkandidatenmenge aufgenommen werden. In den Leitungssatz-Report-Dateien müssen die CAN-Leitungen hierzu über eine geeignete Identifizierungsmöglichkeit verfügen.
  • Eine Zusammenfassung der bisher behandelten Merkmale des erfindungsgemäßen Diagnosesystems gibt die graphische Darstellung der 1. In einem rechnerverarbeitbaren Strukturmodell 1 ist die Systemtopologie des technischen Systems mit den vorhandenen Steuergeräten 2a, 2b, 2c und der den Steuergeräten zugeordneten Peripherie P2a1, P2a2, P2b1, P2b2, P2b3, P2c1, P2c2 und Masseknoten W1 unter Verwendung von Datensatz-Report-Dateien erfasst und festgehalten. Das Strukturmodell kann hierbei z.B. ein Systemgraph aus Kanten und Knoten sein, wie er aus der Graphentheorie bekannt ist, und der mittels Triangulation zu einem Junction Tree umgewandelt wurde, so dass er mit Pfadsuchalgorithmen bearbeitet werden kann. Miterfasst im Strukturmodell wird die Kommunikationsstruktur der Steuergeräte, die alle über einen Datenbus 3 mit Datenbustypischen Datenleitungen 3L vernetzt sind. Unter Strukturmodell wird im Sinne der Erfindung jede Repräsentationsform der Systemtopologie des technischen Systems verstanden. Die einzelnen Repräsentationsformen, wie Datensatz-Reportdateien, Graph oder Junction Tree können durch Anwendung entsprechender Umwandlungsprogramme per Rechner in einander umgewandelt werden. Jedes der zur Eigendiagnose fähigen Steuergeräte verfügt über eine im technischen System vereinbarte Fehlercodeliste 4, die für jedes Steuergerät die Liste der von diesem Steuergerät erkennbaren Fehlerzustände enthält. Jeder Fehlercode enthält hierbei Angaben über das Steuergerät von dem die Fehlermeldung stammt sowie über die Fehlerart, die aufgetreten ist. In dem Ausführungsbeispiel der 1 sei z.B. das Format für den Fehlercode SXFCODEY. Dann gibt z.B. SX das Steuergerät an, von dem die Fehlermeldung stammt und FCODEY die Fehlerart die aufgetreten ist. Je nach Belegung der Variablen X und Y können verschiedene Steuergeräte und verschiedene Fehlerarten identifiziert werden.
  • Mit einem Mikrocontroller 5, in dem das Diagnosesystem mit Strukturmodell, Diagnoseprogramm, Heuristiken und Pfadsuchalgorithmen softwaremäßig implementiert ist, werden die Busnachrichten auf dem Datenbus mitgelesen. Immer dann wenn eine Fehlermeldung auf dem Datenbus versendet wird, wird das hier beschriebene Diagnosesystem angewandt. Das heißt mit einem ablauffähigen Diagnoseprogramm werden in einem ersten Schritt anhand des aufgetretenen Fehlercodes die oder der Pfadsuchalgorithmus bzw. Pfadsuchalgorithmen um eine fehlerspezifische Heuristik Zn ergänzt. Die Heuristik enthält hierbei die Menge der Fehlerkandidaten, die es zu untersuchen gilt, die Regellisten für das Vorliegen einer Fehlersetzbedingung sowie den fehlerspezifischen Auswertealgorithmus, der angibt welche Zustandsvariablen der einzelnen Bauteile nach welchen Kriterien zu untersuchen ist und nach welchen Regeln an Knoten des Strukturmodells mit dem Pfadsuchalgorithmus zu verzweigen ist. Der Fehlerort bzw. das defekte Bauteil gilt entsprechend dem erfindungsgemäßen Diagnosesystem als gefunden, wenn mit dem durch die Heuristik parametrisierten Pfadsuchalgorithmus bei einem Bauteil eine Fehlersetzbedingung gefunden wurde.
  • Prototypische Realisierung
  • Der hier vorgestellte Ansatz zur Gewinnung von Diagnose-Wissen wurde prototypisch realisiert und verfügt über folgende Features:
    Nachbildung der Topologie
    Bestimmung der Massepfade
    Drei Heuristiken ("Unterbrechung", "Kurzschluss nach Masse" und "Kurzschluss nach Versorgung"), die vereinzelt oder in Kombination ausgeführt werden können.
    Einhaltung der aktuellen Modellierungsrichtlinien, d.h. zu jeder Fehlerart werden die richtigen Bauteiltypen aus der Peripherie bestimmt und einem Fehlermodus zugewiesen.

Claims (15)

  1. Diagnosevorrichtung mit einem Mikrocontroller (5), der über eine Datenverbindung (3L) mit einem Datenbus (3) eines technischen Systems verbunden ist, dadurch gekennzeichnet, – dass in dem Mikrocontroller (5) ein rechnerverarbeitbares Strukturmodell (1) des technischen Systems implementiert ist, – dass in dem Mikrocontroller (5) ein ablauffähiges Diagnoseprogramm implementiert ist, – dass in dem Mikrocontroller (5) ein Kommunikationsprogramm auftretende Fehlermeldung auf dem Datenbus mitliest, – und dass das Diagnoseprogramm in Abhängigkeit der aufgetretenen Fehlermeldung die Fehlersuche mittels einer durch eine fehlerspezifische Heuristik parametrierbaren Graphensuche im Strukturmodell durchführt.
  2. Diagnosevorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die fehlerspezifische Heuristik ein Softwaremodul ist, das einen Auswertealgorithmus, eine oder mehrere Regellisten und eine Menge der zu untersuchenden Fehlerkandidaten enthält.
  3. Diagnosevorrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass in die Heuristik ein Pfadsuchalgorithmus integriert ist.
  4. Diagnosevorrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Heuristik mit einem Pfadsuchalgorithmus zusammenarbeitet.
  5. Rechnergestütztes Diagnosesystem, bei dem die physikalische Struktur des zu diagnostizierenden technischen Systems in Form eines Strukturmodells implementiert ist, dadurch gekennzeichnet, – dass beim Auftreten einer Fehlermeldung von einem Bauteil des technischen Systems und damit auch im Strukturmodell mit einer fehlerspezifischen durch eine Heuristik parametrierbaren Pfadsuche nach dem Fehlerort innerhalb des Strukturmodells gesucht wird.
  6. Rechnergestütztes Diagnosesystem nach Anspruch 5, dadurch gekennzeichnet, dass die Heuristik ein Softwaremodul aus einem Auswertealgorithmus, mindestens einer Regelliste und einer Menge der zu untersuchenden Fehlerkandidaten ist.
  7. Rechnergestütztes Diagnosesystem nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass in die Heuristik ein Pfadsuchalgorithmus integriert ist.
  8. Rechnergestütztes Diagnosesystem nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass die Heuristik mit einem Pfadsuchalgorithmus zusammenarbeitet.
  9. Diagnoseverfahren für technische Systeme dadurch gekennzeichnet, – dass zunächst aus Informationen zur Systemtopologie ein Strukturmodell des technischen System erzeugt wird, – dass weiterhin für jeden Fehlercode derjenigen Bauteile des technischen Systems, die zu einer Eigendiagnose fähig sind, eine fehlerspezifische Heuristik mit einem Auswertealgorithmus, mindestens einer Regelliste und mit einer Menge der zu untersuchenden Fehlerkandidaten erstellt wird, – dass weiterhin eine durch die Heuristik parametrierte Pfadsuche innerhalb des Strukturmodells zur Auffindung des Fehlerorts durchgeführt wird.
  10. Diagnoseverfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Pfadsuche bei dem Bauteil beginnt, dass einen Fehler gemeldet hat.
  11. Diagnoseverfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass die Pfadsuche auf die Bauteile die in der Menge der Fehlerkandidaten enthalten sind, beschränkt wird.
  12. Diagnoseverfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Heuristik das Auffinden von Kurzschlüssen nach Masse ermöglicht.
  13. Diagnoseverfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Heuristik das Auffinden von Kurzschlüssen zum Versorgungspfad ermöglicht.
  14. Diagnoseverfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Heuristik das Auffinden von Unterbrechungen in der Systemtopologie ermöglicht.
  15. Diagnoseverfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Heuristik das Auffinden von Bauteilen ermöglicht, die logische Fehler verursachen.
DE102004019151A 2004-04-21 2004-04-21 Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien Withdrawn DE102004019151A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102004019151A DE102004019151A1 (de) 2004-04-21 2004-04-21 Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien
PCT/EP2005/004024 WO2005109136A1 (de) 2004-04-21 2005-04-15 Rechnergestütztes diagnosesystem auf der basis von heuristiken und system-topologien
US11/587,166 US20070220330A1 (en) 2004-04-21 2005-04-15 Computer-Supported Diagnostic System, Based on Heuristics and System Topologies

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004019151A DE102004019151A1 (de) 2004-04-21 2004-04-21 Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien

Publications (1)

Publication Number Publication Date
DE102004019151A1 true DE102004019151A1 (de) 2005-11-10

Family

ID=34966957

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004019151A Withdrawn DE102004019151A1 (de) 2004-04-21 2004-04-21 Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien

Country Status (3)

Country Link
US (1) US20070220330A1 (de)
DE (1) DE102004019151A1 (de)
WO (1) WO2005109136A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019206837A1 (de) * 2019-05-10 2020-11-12 Dürr Systems Ag Analyseverfahren und Vorrichtungen hierzu
US11928628B2 (en) 2019-05-09 2024-03-12 Dürr Systems Ag Method for checking workpieces, checking facility and treatment facility
US11927946B2 (en) 2019-05-09 2024-03-12 Dürr Systems Ag Analysis method and devices for same

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5278310B2 (ja) * 2007-03-29 2013-09-04 日本電気株式会社 診断システム
DE102007018732A1 (de) * 2007-04-20 2008-10-23 Volkswagen Ag Diagnosesystem und Verfahren zum Erstellen eines Prüfablaufs für eine Diagnose eines mechatronischen Gesamtsystems
JP5446894B2 (ja) * 2010-01-12 2014-03-19 富士通株式会社 ネットワーク管理支援システム、ネットワーク管理支援装置、ネットワーク管理支援方法およびプログラム
US8935040B2 (en) * 2012-08-27 2015-01-13 GM Global Technology Operations LLC Method and system for actively locating bus faults
CN107516169A (zh) * 2017-08-29 2017-12-26 上海航天控制技术研究所 一种闭环控制系统可诊断性评价方法
CN109613851B (zh) * 2018-11-07 2020-07-21 北京航空航天大学 一种基于多阶组合的网络化在线监控方法
US20220035359A1 (en) * 2020-07-31 2022-02-03 Palo Alto Research Center Incorporated System and method for determining manufacturing plant topology and fault propagation information
AT525591A1 (de) * 2021-10-15 2023-05-15 Avl List Gmbh Verfahren und Vorrichtung zur automatischen Analyse eines Diagnosesystems eines Fahrzeugs

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19523483C2 (de) * 1995-06-28 1998-10-22 Daimler Benz Ag Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
DE19742450A1 (de) * 1997-09-26 1999-04-08 Daimler Chrysler Ag Reduktionsverfahren für Simulationen zur Wissensdatenerzeugung
JP3266126B2 (ja) * 1999-01-14 2002-03-18 日本電気株式会社 ネットワーク障害情報管理システム及び記憶媒体
GB2373607B (en) * 2001-03-23 2003-02-12 Sun Microsystems Inc A computer system
US20030191978A1 (en) * 2002-04-04 2003-10-09 International Business Machines Corporation Multiple fault location in a series of devices

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11928628B2 (en) 2019-05-09 2024-03-12 Dürr Systems Ag Method for checking workpieces, checking facility and treatment facility
US11927946B2 (en) 2019-05-09 2024-03-12 Dürr Systems Ag Analysis method and devices for same
DE102019206837A1 (de) * 2019-05-10 2020-11-12 Dürr Systems Ag Analyseverfahren und Vorrichtungen hierzu

Also Published As

Publication number Publication date
US20070220330A1 (en) 2007-09-20
WO2005109136A1 (de) 2005-11-17

Similar Documents

Publication Publication Date Title
WO2005109136A1 (de) Rechnergestütztes diagnosesystem auf der basis von heuristiken und system-topologien
EP1330685B1 (de) Prüfverfahren und prüfvorrichtung zur inbetriebnahme von mittels einer programmlogik gesteuerten systemen
EP1192543B1 (de) Verfahren und anordnung zur ermittlung eines fehlerbaums eines technischen systems, computerprogramm-erzeugnis und computerlesbares speichermedium dafür
EP1703350B1 (de) Diagnose eines Automatisierungssystems
EP1751637A1 (de) Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen
EP0685086B1 (de) Einrichtung zur automatischen erzeugung einer wissensbasis für ein diagnose-expertensystem
EP1265146A2 (de) Fehlersuchverfahren und Fehlersuchvorrichtung
DE19732046A1 (de) Prozeßdiagnosesystem und Verfahren zur Diagnose von Vorgängen und Zuständen eines technischen Prozesses
WO2006105930A1 (de) Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben
EP2866111B1 (de) Testen eines Steuergerätes mittels einer Testumgebung
EP2718774A1 (de) Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt
EP2718773A1 (de) Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt
EP3400452B1 (de) Transporteinheit mit zumindest einer anlage
EP1860565A1 (de) Verfahren zur Funktionsprüfung eines Steuergeräts für ein Kraftfahrzeug
EP3699704B1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
DE102007047421A1 (de) Verfahren zum Beschreiben eines Verhaltens einer technischen Einrichtung
DE19707065A1 (de) System zur Erstellung eines Entscheidungsbaums insbesondere für eine Fehlerdiagnose bei einem Kraftfahrzeug
DE102020102996A1 (de) Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung
WO2008064616A1 (de) Verfahren und diagnosesystem zur diagnose eines technischen systems
DE102006015207A1 (de) Verfahren und Vorrichtung zur Entwicklung eines Systems für die Betriebsdiagnostik von Fahrzeugen
DE10121587A1 (de) Verfahren und Vorrichtung zur automatisierten Prüfung grundlegender CAN-Eigenschaften von Steuergeräten
EP3553679A1 (de) Verfahren zur computergestützten fehlerdiagnose für ein technisches system
DE102013010783A1 (de) Verfahren und Steuergerät zum Testen einer Automatisierungslösung basierend auf einer PLC-Steuerung
DE10055679A1 (de) Verfahren, Computersystem und Computerprogramm-Produkte zur modellbasierten Generierung von Testszenarien
EP3720056B1 (de) Verfahren und system zur parallelen echtzeitanalyse bei funktionsprüfungen von hardware und software von steuergeräten

Legal Events

Date Code Title Description
8127 New person/name/address of the applicant

Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE

8127 New person/name/address of the applicant

Owner name: DAIMLER AG, 70327 STUTTGART, DE

8130 Withdrawal