DE102006017824A1

DE102006017824A1 - Diagnose in automotiven Anwendungen

Info

Publication number: DE102006017824A1
Application number: DE102006017824A
Authority: DE
Inventors: Heinrich Balzer; Oliver Dr.rer.nat. Niggemann; Benno Maria Prof. Dr.rer.nat. Stein
Original assignee: Dspace GmbH; Dspace Digital Signal Processing and Control Engineering GmbH
Current assignee: Dspace GmbH
Priority date: 2006-04-13
Filing date: 2006-04-13
Publication date: 2007-10-18
Anticipated expiration: 2026-04-14
Also published as: US20070283188A1; US7991583B2; DE102006017824B4

Abstract

Dieses Dokument behandelt komplexe Diagnosesituationen in modernen Fahrzeugen. Es geht dabei um ein neues und weniger bekanntes Diagnoseparadigma, bei dem die modellbasierte und die assoziative Diagnose kombiniert werden. Dieses wird auch Modellkompilierung genannt (2, ?, 12). Die grundlegende Idee ist die, ein Modell des entsprechenden Systems in verschiedenen Fehlermodi und in seinem typischen Eingabebereich zu simulieren und eine Simulationsdatenbank C anzulegen. Aus C wird ein vereinfachtes, regelbasiertes Verhaltensmodell erstellt, in dem lange Ursache-Wirkung-Ketten durch deutlich einfachere Assoziationen ersetzt und für eine heuristische Klassifikation der in Frage kommenden Fehler optimiert werden. Der Hauptteil dieses Dokuments erläutert die Anwendung dieser Idee auf komplexe ereignisdiskrete/kontinuierliche Systemmodelle moderner Fahrzeuge. Unsere Experimente, die auf den neuesten Simulationsmodellen der Automobilindustrie basieren, sind vielversprechend und deuten möglicherweise einen Paradigmenwechsel weg von den bisher in diesem Bereich eingesetzten Diagnoseansätzen an. Keywords automotive Diagnose, Modellkompilierung, Simulation, Datamining

Description

1 EINLEITUNG UND DIAGNOSEEINSTELLUNG
Bei den heutigen Fahrzeugen handelt es sich um komplexe mechatronische Systeme. Trotz ihrer ständig steigenden Komplexität kann deren Zuverlässigkeit erhöht werden. Daher wurde der Diagnoseprozess selbst stark involviert: Hardware- und Software-Systeme bilden zusammen einen anspruchsvollen Aufbau; Daten verschiedener Sensoren werden von einem komplexen Netzwerk verteilter und voneinander abhängiger Software-Module eingesetzt. Module, die in unterschiedlichen Phasen des Entwicklungsprozesses von unterschiedlichen Firmen spezifiziert werden.
Das vorliegende Dokument adressiert diese Situation, er stellt eine neue Technologie zur Diagnose automotiver Systeme vor, diskutiert die Vor- und Nachteile und präsentiert erste Anwendungsergebnisse. Das Dokument ist folgendermaßen aufgebaut: Der erste Teil beschreibt nachfolgend die Diagnoseeinstellungen und stellt die Terminologie sowie eine Taxonomie möglicher und adressierter Fehlertypen vor. Teil 2 erläutert, ob und wie die genannten Fehlertypen von bestehenden Ansätzen behandelt werden. Teil 3 stellt den Modellkompilierungsansatz sowohl als formales Gerüst als auch als konkrete Implementierung vor, einschließlich Experimentaufbau, Simulationsaufgaben und Klassifikationsergebnissen.
1: Das System der verbundenen Steuergeräte und der Fahreugumgebung. In heutigen Automobilen sind bis zu 70 Steuergeräte sowohl mit mechanischen Vorrichtungen als auch mit anderen Steuergeräten verbunden und führen dedizierte Regelungsaufgaben aus.
1.1 Eine Klassifikation der Fehlertypen
Fehler und Fehlfunktionen können in einem Fahrzeug an den unterschiedlichsten Stellen auftreten. Wie in 1 gezeigt, lässt sich das Gesamtsystem "Fahrzeug" in zwei Teilsysteme gliedern; Elektronik und Umgebung. Zur Elektronik gehören die elektronischen Steuergeräte („electronic control units", Kurzbezeichnung „ECUs"), die Busse für den Anschluss der Steuergeräte sowie die Aktoren und Sensoren als Steuergeräte-Schnittstelle zur Umgebung.
Die Hauptaufgabe der Steuergeräte ist die Steuerung der Umgebungsteile, zum Beispiel des Motors oder des Getriebes. Für diesen Zweck führen Steuergeräte Anwendungssoftwaremodule aus. Neben diesen Anwendungen enthalten Steuergeräte auch die so genannte Basis-Software, die benötigt wird um Anwendungen ausführen zu können und diese mit Sensoren, Aktoren und Bussen zu verbinden. Zur Basis-Software gehören Module wie Betriebssystem, I/O-Treiber, Kommunikationsstack und Steuergeräte-Services. Normalerweise ist auch die Stromversorgung in den elektronischen Teilsystemen enthalten.
Zur Umgebung gehört der Rest des Fahrzeugs und beinhaltet den Fahrer, die Straße, das Wetter und die folgenden Fahrzeugbereiche:

• Antriebsstrang. Beispiele: Motor, Getriebe, Antriebswelle
• Fahrwerk. Beispiele: Bremsen, Dämpfung, Lenkung
• Karosserie. Beispiele: Scheinwerfer, Scheibenwischer, Klimaanlage, Keyless Entry
• Sicherheit. Beispiele: Airbag, aktive Rückhaltegurte
• Telematik/Infotainment. Beispiele: Radio, Navigation, Telefon

2: Eine Taxonomie der Fehlerstellen. Die hervorgehobene Fehlerklasse ist in diesem Dokument angesprochen.
Ausgehend von dieser ersten Klassifikation, kann eine Taxonomie der Fehlerlokalisierung definiert werden; 2 zeigt einen Auszug aus dieser Taxonomie. Im Umgebungsteilbaum werden hauptsächlich die bereits genannten Fahrzeugbereiche unterschieden. Im Elektronikteilbaum können Fehler in (i) Steuergeräten auftreten, (ii) in Verbindung mit Bussen, (iii) in Zusammenhang mit der Stromversorgung oder (iv) in Sensoren, Aktoren oder deren Verkabelung. Darüber hinaus können sowohl in der Steuergeräte-Hardware und -Software Fehler auftreten, was wiederum meist in Fehler in der Anwendungssoftware und in Fehler in der Basis-Software unterteilt wird.
1.2 Auf Symptomerkennung basierte Diagnose
In einem Fahrzeug hat das Diagnosesystem die Aufgabe, Fehler zu erkennen und geeignete Behebungsmaßnahmen einzuleiten. Dabei geht die Fehlererkennung mit einem Problem einher: Die Fahrzeugelektronik erkennt nur die Auswirkungen des Fehlers, nicht aber den Fehler selbst. So könnte ein Fehler im Motor zu unüblichen Sensorauslesungen wie Motortemperatur oder Umdrehungen führen. Die Diagnose kann als dreiphasiger Prozess angesehen werden:

1. Identifikation unüblicher Fahrzeugbedingungen. Derartige Bedingungen werden durch Vergleichen von Soll- und Ist-Verhalten des Fahrzeugs identifiziert, wobei zur Beobachtung oftmals Sensorauslesungen durchgeführt werden. Die beobachteten Abweichungen nennt man Symptome.
2. Herleitung von Fehlern. Basierend auf den Symptomen, werden die eigentlichen Fehler hergeleitet.
3. Abschließend löst das Diagnosesystem Maßnahmen zur Behebung aus, indem es beispielsweise eine Warnmeldung für den Fahrer ausgibt.

Symptome werden in Software-Modulen auf den Steuergeräten erkannt. 3 zeigt eine vereinfachte Steuergeräte-Struktur aus Software-Sicht. Sensorinformationen oder Bussignale werden von einem Anwendungssoftwaremodul über unterschiedliche Hardware- und Software-Schichten gelesen (oberer Teil des Diagramms) und an Aktoren oder Busse geschrieben (unterer Teil des Diagramms).
Dabei ist zu beachten, dass die Symptomerkennung nur durch Treiber/Basis-Software und durch Anwendungssoftwaremodule implementiert werden kann, das heißt, die Symptome aller Fehlerstellen werden mit Hilfe dieser Software-Module erkannt, wodurch es sehr schwer wird, die Fehler zu unterscheiden. Symptome werden grob in zwei Kategorien unterteilt:

• Lokale Symptome. Solche Symptome treten direkt an der Stelle des Fehlers auf. Zum Beispiel ein Kurzschluss eines Steuergeräte-Kabels. Fehler, die solche Symptome verursachen, können verhältnismäßig leicht identifiziert werden. In dem Beispiel konnte der entsprechende I/O-Treiber den falschen Spannungspegel erkennen. Im Allgemeinen existieren für derartige Fehler bereits etablierte Erkennungsmethoden.
• Entfernt liegende Symptome. Andere Symptome treten abseits der eigentlichen Fehlerstelle auf. Beispiele sind (i) Fehler in der Umgebung wie Motorprobleme oder (ii) Busfehler, die Auswirkungen auf alle angeschlossenen Steuergeräte haben. Natürlich stellt die Erkennung von Fehlern, die derartige Symptome verursachen, eine deutlich größere Herausforderung dar.

3: Ein Steuergerät ist organisiert wie verschiedene Hardware- und Softwareschichten. Fehler können in jeder Schicht auftreten, sind aber nicht wahrnehmbar bis zur Treiberschicht oder zur Applikationsschicht.
Entfernt liegende Symptome traten in den letzten Jahren wesentlich häufiger auf, was zu immer komplizierteren Diagnoseszenarien führte. Verantwortlich dafür sind im Wesentlichen die immer komplexer werdenden Anwendungen in Richtung umfangreiche, verteilte Software-Systeme. Beispiele dafür sind Fahrerassistenzsysteme wie Aktive Fahrgeschwindigkeitsregelung (Active Cruise Control, ACC), Aktivlenkung (Active Front Steering, AFS) oder Spurhalteunterstützung (Lane Keeping Support). Diesen Systemen ist gemein, dass sie auf mehrere Steuergeräte verteilt sind und oftmals von anderen bereits bestehenden Software-Modulen abhängen. Treten Fehler in einem Modul eines solchen verteilten Software-Systems auf, so werden weitere Fehler in anderen angeschlossenen Software-Modulen ausgelöst. Das führt dazu, dass zahlreiche Symptome auf mehreren Steuergeräten erkannt werden.
Die in diesem Dokument vorgestellte Methode der Modellkompilierung ist besonders zur Erkennung dieser neuartigen Fehlertypen geeignet. In Teil 3 werden die wesentlichen Gründe dafür genannt.
2 STAND DER TECHNIK
Die Diagnose eines technischen Systems gehört zu einem Forschungsbereich, der weitestgehend von Modellierungsaspekten bestimmt wird:

• Welche Modellierungsstrategie ist geeignet – ein in die Tiefe gehendes Verhaltensmodell oder ein eher oberflächliches Regelmodell?
• Ist eine Unterscheidung zwischen einem korrekten Verhaltensmodell und einem Fehlermodell notwendig?
• Wird der Diagnoseprozess durch heuristisches Fachwissen gelenkt und, wenn ja, wie soll der Prozess dargestellt werden?
• Wie können die Erfahrungswerte während der Diagnose konserviert und auf dem aktuellen Stand gehalten werden?
• Ist eine Modellierung offen, um bereits vorhandenes Know-how bei Auftreten unerwarteter Fehler zu integrieren?

Ansätze der in den letzten Jahren vorherrschend eingesetzten modellbasierten Diagnose ([11, 3]). Die grundlegende Idee ist die, ein System parallel zum Echtzeitsystem zu simulieren und die Simulationsergebnisse zur Symptomerkennung einzusetzen, also Abweichungen zwischen Soll- und Ist-Verhalten aufzudecken. Dieses Modell heißt in diesem Dokument Verhaltensmodell und wird als M bezeichnet; unter dem Unterabschnitt 3.1 findet sich eine genaue Spezifikation seiner Elemente.
Theoretisch können mögliche Fehler, die Symptome verursachen, durch Analyse eines Verhaltensmodells in umgekehrter Richtung, also von Symptomen zu Fehlern, abgeleitet werden. Aber in der Praxis resultiert aus einer inversen Simulation von M normalerweise ein hochkomplexes Analyseproblem, das gewöhnlich nicht beherrschbar ist. Daher erstellen Arbeitsgebiet-Experten oftmals ein spezielles Diagnosemodell M_D, in dem die Fehlerherleitung nach der Methode der Vorwärtsverkettung (Forward Reasoning) behandelt wird.
Modellbasierte Ansätze verwenden möglicherweise unterschiedliche Algorithmen. Ein Ansatz zur Fehlererkennung während der Laufzeit wird unter [13] beschrieben. Hier wird die Regelsoftware autonomer Roboter von Beobachtern überwacht. Ein Beobachter ist eine bestimmte Art parallel ausgeführtes Verhaltensmodell zur Erkennung von Symptomen. Zur Fehlerlokalisierung wird die modellbasierte Diagnose eingesetzt. Das Systemverhalten, also M_D, wird hier durch eine Aussagenlogik modelliert. Deshalb wird Reiters Hitting-Set-Algorithmus (weitere Informationen siehe [11, 5]) zusammen mit einem propositionalen Hornklausel-Theorembeweiser verwendet. Darauf wird an dieser Stelle nicht näher eingegangen. Nach der Fehlererkennung wird ein Algorithmus ausgeführt, der die Software repariert.
Unter [8] wird ein einfacher so genannter "zeitgesteuerter Fehlerpropagierungsgraph" vorgestellt. Dieser Graph repräsentiert M und gibt an, wie sich ein Fehler durch das System fortsetzt. Zusätzlich ist der Zeitbereich für die Fehlerpropagierung zwischen den Systemkomponenten bekannt. Aufgrund der Abweichungen zwischen Soll- und Ist-Verhalten eines Signals wird die Fehlererkennung gestartet. Dafür kommt derselbe Graph zum Einsatz, hier also M = M_D.
Unter [10] werden Systeme aus Hard- und Software diagnostiziert. Dafür wird für M und M_D ein PHCA (Probabilistic, Hierarchical, Constraint-based Automata) eingesetzt. Die Diagnoseaufgabe ist als COP (Constraint Optimization Problem) formuliert und wird durch Optimierungstechniken gelöst.
Da in [1] gezeigt wurde, dass die modellbasierte Diagnose auf Programm-Debugging angewendet werden kann, wurden in diesem Bereich zahlreiche Forschungen durchgeführt (zum Beispiel [7, 9, 6]). In [7] wird eine Technik ähnlich der Constraint Propagation in Kombination mit Model Checking eingesetzt. Diese Technik hängt von einem Modell M = M_D ab, das auf dem Quellcode basiert. Komponentenbasierte Software wird in [6] überwacht, wobei das Verhalten der Software-Komponenten durch Petri-Netze modelliert wird, also hier M = M_D. Die Symptomerkennung erfolgt online.
Weiterhin bestehen Ansätze zur Fehlererkennung in verteilten Systemen oder Multi-Agenten-Systemen ([Roychoudhury et al., 2005], [Kurien et al., 2002], [Su et al., 2002], [Roos et al. 2003], [Lamperti and Zanella, 2003], [Kalech und Kaminka, 2005]).
Neben der modellbasierten Diagnose ist die so genannte assoziative Diagnose ein weiterer weit verbreiteter Ansatz. Diese Technik verwendet ein Diagnosemodell, das Symptome direkt mit möglichen Fehlern verbindet. Beispiele dazu unter [].
2.1 Diagnose in automotiven Anwendungen
In der Automobilindustrie werden häufig auch modellbasierte Ansätze eingesetzt. Ein wesentliches Unterscheidungsmerkmal ist dabei das Einsatzgebiet: entweder on- board im Fahrzeug für die Fehlerdiagnose zur Fahrzeugslaufzeit oder off-board im Ruhezustand, z.B. in der Werkstatt. Insbesondere gesetzliche Bestimmungen in Bezug auf Abgasemissionen und Sicherheit, z.B. für Fahrerassistenzsysteme, erforderten komplexere Diagnosesysteme für die Onboard-Diagnose.
In [Nyberg, 2002) werden ein fehlerloses Modell M₁ = M_D1 und mehrere Fehlermodelle M₂ = M_D2 nach M_k = M_Dk erstellt, um Sensorfehler und Leckagen am Lufteinlass-System eines Motors zu diagnostizieren. Im entsprechenden Diagnosesystem wird ein Gerüst aus strukturierten Hypothesentests eingesetzt, um entscheiden zu können, welches der Modelle die Messdaten erklären kann.
Bei vielen modellbasierten Ansätzen werden qualitative Modelle verwendet, siehe [Struss und Price, 2003), bei denen für die Onboard-Diagnose die konsistenzbasierte Diagnose benutzt wird. Es wird also nur ein Modell M = M_D eingesetzt. Qualitative Modelle, oder genauer gesagt qualitative Abweichungsmodelle, hier M, werden in [Cascio et al., 1999] für die Onboard-Diagnose verwendet, wo Diagnosesituationen simuliert werden. Das Ergebnis der Simulation wird ausgewertet, um einen Entscheidungsbaum für das Diagnosesystem anzulegen.
Weitere modellbasierte Ansätze werden in [Sanseverino und Cascio, 1997]4, [Fritz und Albers, 2002], [Seibold und Höfig, 2004] und [Kimmich et al., 2005] aufgezeigt.
Unser Ansatz basiert auf dem in [Stein, 2001] und in [Husemeyer, 2001] vorgestellten Modellkompilierungsansatz. Der folgende Teil dieses Dokuments wendet diese Idee auf reale Fahrzeug-Diagnose an.
3 DER MODELLKOMPILIERUNGSANSATZ
Die Modellkompilierung ist ein Diagnoseansatz, der das modellbasierte Paradigma und das assoziative (heuristische) Paradigma in den folgenden vier Schritten kombiniert [?]:

1. Simulation. Eine Datenbank, C, wird durch Simulation des entsprechenden Systems in mehreren Fehlermodi und in seinem üblichen Eingabebereich kompiliert.
2. Symptomberechnung. Durch Vergleichen der fehlerfreien Simulation mit der im Fehlermodus ausgeführten Simulation wird eine Symptomdatenbank C Δ erstellt.
3. Generalisierung. Mit Hilfe der Cluster-Analyse oder der Vektorquantisierung werden die numerischen Werte in C Δ in Richtung Intervalle abstrahiert.
4. Lernen. Die Zuordnung von Symptomen zu der Reihe der Fehlermodi erfolgt mit Hilfe von Datamining und Maschinenlernen. Der resultierende Klassifizierer kann als ein „diagnosekompiliertes Modell" betrachtet werden.

Da sich dieser Prozess vollständig automatisieren lässt, hat dieser Ansatz das Potenzial die Vorteile der modellbasierten Philosophie wie Verhaltenstreue und Allgemeingültigkeit mit der Effizienz und Robustheit eines heuristischen Diagnosesystems zu vereinen. Besonders in Verbindung mit der Diagnose in Fahrzeug-Anwendungen sind folgende Vorteile zu nennen:

• Die beträchtliche Anzahl bestehender Bibliotheken mit Verhaltensmodellen kann zusammen mit der Einsatzexpertise in Schritt (1) wieder verwendet werden.
• Die Verhaltensmodelle werden nach ihrer beabsichtigten Folgerungsrichtung analysiert, das heißt, es muss weder ein spezielles Diagnosemodell entwickelt noch ein inverses Simulationsproblem gelöst werden.
• Der Klassifizierer, der aus den Schritten (3) und (4) gelernt wurde, integriert sich nahtlos in bestehende Diagnoseansätze im automotiven Bereich, z.B. Fehlerbäume.
• Das kompilierte Diagnosemodell weist sehr geringe Berechnungsspuren auf. Andere moderne Diagnoseansätze erfordern Ausführung und Analyse eines Verhaltensmodells zur Laufzeit [?].

3.1 Formales Gerüst
In diesem Unterabschnitt wird die Idee eines Verhaltensmodells formal vorgestellt, welches manchmal auch Regelstrecken- oder Reglermodell genannt wird. Die Definition wirkt sich sowohl auf die Bestimmung der verschiedenen Diagnoseaufgaben als auch auf das Kompilierungsprinzip in mathematischen Ausdrücken unterstützend aus.
Ein Fahrzeug ist ein komplexes System, das aus mehreren miteinander verbundenen Teilsystemen wie Motor, Antriebsstrang, Motorsteuerung etc. besteht. Zu Simulationszwecken betrachten wir jedes in Frage kommende Teilsystem als adäquat dargestelltes Verhaltensmodell M. Je nach verbundenem Teilsystem und Simulationszweck ist M eingabefrei oder eingabeabhängig, oder speicherlos oder dynamisch. Die wichtigste Unterscheidung bezieht sich auf die Zeitbasis dynamischer Modelle, die entweder kontinuierliche Zeit, diskrete Zeit oder ein diskretes Ereignis sein kann.
Definition 1 (Verhaltensmodell [?]) Ein Verhaltensmodell M ist ein Tupel (F_U, F_Z, F_Y, ν, Δ, Λ). F_U ∩ F_Z = ∅, dessen Elemente folgendermaßen definiert sind:

• F_U, F_Z und F_Y sind Eingangsvariablen, Bedingungsvariablen und Ausgangsvariablen.
• Für jede Variable υ ∈ F_U, F_Z und F_Y existiert ein arbiträrer, möglicherweise unendlicher Satz Uυ, Zυ und Yυ, der Domäne von υ genannt wird. Für jedes υ ∈ F_U gibt es eine zusätzliche Domäne, U T / υ, aus teilweise definierten Funktionen in der Parameterzeit U T / υ : = {u|u : T → Uυ, t ↦ u(t)}. Abhängig von der Zeitbasis des Modells, die entweder kontinuierliche Zeit, diskrete Zeit oder ein diskretes Ereignis ist, bezeichnet T möglicherweise ein Intervall aus R⁺, ein Intervall aus N oder einen linear sortierten endlichen Satz.
V umfasst die Domänen aller Variablen. Aus praktischen Gründen werden die kartesischen Produkte der Domänen der Variablen in F_U, F_Z und F_Y als U, u^T, z und y bezeichnet. Zum Beispiel Yυ₁ × Yυ₂ ×... × Yυ_|FY|, υ_i ∈ F_Y.
• Δ ist eine Funktion, die globale Zustandsbeschreibungsfunktion genannt wird. Δ bezeichnet einen Satz an Zustandsvariablen, F_X ⊆ F_Z, und einen Zustandsraum, χ, der die Projektion von z im Hinblick auf F_X darstellt. Gegeben ist ein Zustandsvektor x ∈ χ, ein Vektor aus Eingangsfunktionen u(t) ∈ u^T und einige Zeitpunkte t ∈ T, Δ bezeichnet einen Bedingungsvektor z ∈ z einschließlich eines neuen Zustands, zum Beispiel Δ : χ × u^T × T → z • Λ ist eine Funktion, die Ausgangsfunktion genannt wird. Bei der Ausgangsfunktion kann es sich um eine Funktion aus Bedingungsvariablen und Eingang oder nur um eine Funktion aus Bedingungsvariablen handeln. Gegeben ist ein Bedingungsvektor z ∈ z und ein Eingangsvektor u ∈ u, Λ bestimmt einen Ausgangsvektor y ∈ y, zum Beispiel Λ : z × u → y oder Λ z → y.

Schon ein Modell einer kleineren Fahrzeugkomponente kombiniert möglicherweise Verhaltensmodelle unterschiedlicher Typen, zum Beispiel mit unterschiedlichen Zeitbasen. Ein solches Modell wird als „hybrid" bezeichnet.
Angenommen M = {M₁, ... , M_k} bezeichnet ein Hybridfahrzeugmodell, dann sind M_i und M_j gekoppelt, falls sie gemeinsame Ausgangs- und Eingangsvariablen haben, das heißt, wenn F_Yi ∩ F_Uj ≠ ∅, mit F_Yi ∈ M_i, F_Uj ∈ M_j, i ≠ j. Zum Beispiel ist M_i ein zeitkontinuierliches Modell des Motors und M_j ist ein zeitdiskretes Modell der Motorsteuerung. Im Fahrzeug wird eine solche Kupplung durch einen Sensor realisiert, dessen Signal an ein Steuergerät (electronic control unit = ECU) übertragen wird, wo, in der Software-Abstraktionsschicht, die physikalische Größe als eine Eingangsvariable der Motorsteuerungssoftware dargestellt wird.
Die vorangegangene Definition kann als eine korrekte Verhaltensmodellspezifikation eines Systems betrachtet werden. Für unseren Diagnoseansatz benötigen wir zudem Modelle des Fehlverhaltens gemäß GDE + [14, 15, 4]. Ein Fehlverhaltensmodell stellt eine Erweiterung zur oben genannten Definition dar: Es besteht ein zusätzlicher Satz an Zustandsvariablen, F_D, zusammen mit entsprechenden Domänen D und einer Zustandsbeschreibungsfunktion Δ'. F_D definiert die Fehlerstatus der Komponenten, wie sie bereits in Teil 1 beschrieben wurden. Somit ist die Domäne von Δ'. = D × χ × u^T × T.
σ(M, u(t)) und σ(M'_i, u(t)) bezeichnen Simulationsergebnisse des fehlerlosen Modells M und einiger Fehlermodelle M'_i für einen gegebenen Vektor der Eingabefunktionen u(t). Durch Anwendung eines modell- und mengenspezifischen "Differenzoperators", ⊖, kann zwischen den simulierten OK-Werten und den entsprechenden Fehlerwerten eine Datenbank C Δ mit Symptomvektoren kompiliert werden: σ(M, u(t)) ⊖ σ(M'i, u(t)) = C Δ (1) i = 1, ... , k
In einem zweiten Schritt, basierend auf Filtern, Maschinenlernen und Datamining-Methoden, kann ein Klassifizierer erstellt werden, der die Zuweisung von Symptomen zu Fehlern übernimmt: C Δ → FD (2)
Eine Alternative zu den obigen Schritten stellt die direkte Anwendung eines Lernansatzes auf die Simulationsergebnisse dar: C → FD mit (3) C = (σ(M, u(t)) ∪ σ(M'i, u(t))) i = 1, ... , k
Allerdings unterliegt diese Alternative dem Lernansatz, das heißt, die ⊖-Operation muss sowohl entdeckt als auch implizit berechnet werden, was diese Alternative weniger leistungsfähig macht. Auf der anderen Seite ermöglicht diese Alternative die direkte Anwendung der gelernten Diagnoseassoziationen zur Laufzeit, ohne dass dafür M simuliert und der ⊖-Operator angewandt werden muss.
3.2 Fallstudie
Für erste experimentelle Ergebnisse führten die Autoren eine Fallstudie durch, wobei fehlerhafte Sensorauslesungen innerhalb eines Motorsteuergeräts diagnostiziert wurden.
Um das Verhalten des Motors und seines Steuergerät zu simulieren, wurden fortgeschrittenere Modelle benötigt, die in der Lage waren das physikalische Verhalten eines Motors korrekt darzustellen. Zudem sind weitere Modelle, z.B. für den Antriebsstrang, notwendig, da Motor und Steuergerät nicht autonom agieren, sondern mit anderen Komponenten und Steuergeräten zusammenarbeiten. Aus diesem Grund wurde das "Gasoline Engine Simulation Package" der Automotive Simulation Models (ASM) von dSPACE eingesetzt. Dieses Modell ist in MATLAB/Simulink implementiert. Es handelt sich dabei um das vollständige Modell eines 2,9-Liter-, 6-Zylinder-Bezinmotors, zu dem auch Modelle für das Motorsteuergerät, den Antriebsstrang, die Fahrdynamik und die Umgebung gehören. Das Fahrdynamikmodell berücksichtigt zudem auf das Fahrzeug wirkende externe Kräfte wie Luftwiderstand und Bremsen. Im Umgebungsmodell werden Straßenverhältnissen und Fahrereingriffen Rechnung getragen. 4 gibt einen Überblick über die Modellkomponenten.
Im letzten Abschnitt dieses Teils wird der Modellkompilierungsansatz am Beispiel einer falschen Auslesung der Gaspedalposition beschrieben. Im Motormodell gibt es einen Gaspedalsensor, der das Signal an das Steuergerät weitergibt. Das Steuergerät verwendet diese Daten, um zum Beispiel die Aktoren für die Drosselklappenposition im Motor einzustellen. Dieser Signalverlauf ist in 5 dargestellt.
3.2.1 Modellbeschreibung
Zur Vereinfachung werden die Modelle für Antriebsstrang, Fahrdynamik und Umgebung in dieser Darstellung nicht berücksichtigt, da sie für die Beschreibung der unterschiedlichen Fehler nicht notwendig sind. Daher konzentriert sich diese Beschreibung auf das Motormodell, hier M₁, und das Modell für das Motorsteuergerät, M₂. Ein drittes Modell, M₃ umfasst die Soft- und Hardware der Sensoren und Aktoren. In diesem Modell können Fehler generiert werden.
4: Überblick über das Modell mit den Submodellen für das Steuergerät, den Motor, den Antriebsstrang, die Fahrdynamik und die Umgebung.
5: Signalfluss der Fallstudie; Startpunkt ist die User-Eingabe für das Gaspedal.
Solange keine Fehler auftreten, macht M₃ nichts anderes als Signale zwischen M₂ und M₁ weiterzuleiten. Wenn aber Fehler simuliert werden sollen, wird M₃ zur Manipulation (i) der Sensordaten oder (ii) der Aktordaten eingesetzt, so dass die Motorsteuerung Störgrößen empfängt. Daher könnten mit diesen Modellen sowohl das fehlerlose Verhalten als auch das Fehlerverhalten simuliert werden. Aus diesem Grund wird in diesem Fall kein Fehlerverhaltensmodell M' eingesetzt. Diese drei Modelle sind in 6 dargestellt. In weiteren Implementierungen konnten Fehler auch in anderen Teilen von M₃ generiert werden, z.B. in den Treibern oder in der API.
In der folgenden Definition beschreibt 1 das Beispiel formell:

• F_YM1 beschreibt Werte wie den Mittelwert des Motordrehmoments.
• F_UM1 besteht aus Variablen wie dem Kurbelwinkel pro Zylinder und dem Drosselklappenwinkel, wobei F_UM1 = F_YM2.
• Beispiele für Eingangsvariablen von F_UM₂ sind Gaspedalposition, Zündsignal und Motordrehzahl.
• In F_UM3 und F_YM3 sind keine Variablen enthalten, die nicht in M₁ und M₁ verwendet wurden. Daher gilt: F_UM3 = F_UM2 ⋃ F_UM1 = F_YM3. Der Grund dafür ist, dass M₃ ausschließlich für die Manipulation der Eingangs- und Ausgangsvariablen der Motorsteuerung einsetzt wird.
• F_XM2 könnte z.B. die Drosselklappenposition enthalten.

6: Zusammenspiel dreier Modelle: M₁ (Motor), M₂ (Motorsteuerung), M₃ (verbindendes Subsystem zwischen User-Eingabe, Motor und Motorsteuerung). In der Situation des fehlerfreien Verhaltens arbeitet M₃ als Kurzschluss, der sowohl die User-Eingabe mit M₂ direkt verbindet als auch M₁ mit M₂; in einer Fehlersimulation agiert das Modell M₃ als Fehlermodell und fügt spezielle Signalstörungen ein (siehe dunkle Pfeile).

• F_XM2 M₁ besteht aus Variablen wie Krümmertemperatur, Luftstrom durch die Drosselklappe u.a.
• In M₃ handelt es sich bei den Zustandsgrößen F_XM3 um Konstanten zur Steuerung der Fehlertypen.
• Δ M₁ und Δ M₂ sind eine oder mehrere Differenzialgleichungen, die das reale Verhalten der entsprechenden Komponenten zur Berechnung der Bedingungsvariablen und der Ausgangsvariablen beschreiben. Wenn keine Fehler simuliert werden, weist M₃ keine Differenzialgleichungen auf, so dass Δ M₃ in diesem Fall eine Identitätsfunktion darstellt und nur die Eingangsvariablen weiterleitet. Im Fall eines Fehlers manipuliert Δ M₃ eine oder mehrere Eingangsvariablen durch Multiplizieren eines gegebenen Wertes mit der Eingangsvariable oder durch Addieren eines Offsets zur Eingangsvariablen. Zum Beispiel kann ein zufälliger Wert zum Gaspedalsignal addiert werden, um Weißrauschen zu simulieren.
• In diesem Fall weist Λ die Werte von z nach y zu. Daher bilden Λ M₁, Λ M₂ und Λ M₃ die Identitätsfunktionen.

3.2.3 Betrachtete Fehlertypen
Für diese erste Fallstudie wurden mehrere Basisfehler implementiert, die in Sensoren und Aktoren auftreten. Dabei handelte es sich um einen realistischen Fehlertyp in modernen Fahrzeugen. Es wurden vier unterschiedliche Fehlertypen modelliert:

1. Das Signal wird auf 90% seines korrekten Wertes reduziert.
2. Der Signalwert für die Simulation beträgt 110% des korrekten Wertes.
3. Das Signal wird verrauscht.
4. Das Signal fällt aus.

3.2.3 Simulation des Gesamtmodells
Das Gesamtmodell umfasst das oben beschriebene Modell sowie die Modelle für den Antriebsstrang, die Fahrdynamik und die Umgebung. Die Haupteingangsvariablen dieses Modells sind die Aktionen des Fahrers, überwacht durch die entsprechenden Sensoren. Hier ist der Fahrer ein Teilsystem des Umgebungsmodells. Unter anderem gehören auch die Positionen von Bremspedal, Kupplungspedal, Gaspedal und die des eingelegten Ganges zu den Eingangsvariablen.
Für die Simulation werden j unterschiedliche Vektoren an Eingangsfunktionen u₁(t), ... , u_j(t) ∈ u^T definiert. Diese Vektoren werden Szenarien genannt und repräsentieren spezifisches Fahrverhalten innerhalb eines definierten Zeitrahmens. So könnte das Modell in unterschiedlichen Fahrsituationen ausgeführt werden.
Da es unwahrscheinlich ist, dass alle Fehler während der gesamten Szenarios auftreten, werden an mehreren willkürlichen Zeitpunkten Fehler in das Modell eingefügt. So wird jeder Simulationsdurchlauf durch das Szenario, durch den Fehlertyp (einschließlich des fehlerlosen Szenarios), durch die Fehlerkomponente, (z.B. dem Drosselklappenaktor) und durch den Zeitpunkt des Fehlerauftritts charakterisiert.
Anschließend werden mehrere Szenarien mit den unterschiedlichen Fehlertypen des Gaspedalpositionssensors simuliert. Bei jedem Simulationsdurchlauf werden die Werte aller relevanten Signale, das heißt, Signale, die möglicherweise durch den fehlerhaften Gaspedalpositionssensor beeinflusst wurden, aufgezeichnet und in eine Simulationsdatenbank, C, geschrieben. Als Alternative könnten alle zugreifbaren Daten aufgezeichnet werden. Zusätzlich werden die Informationen zum Fehlertyp in der Datenbank gespeichert. Zur späteren Fehlersimulation werden Fehlertyp und Zeitpunkt des Fehlerauftretens ebenfalls in der Datenbank abgelegt.
7 und 8 zeigen einen Auszug der Simulationsergebnisse eines fehlerlosen und eines fehlerhaften Verhaltens. Der Vergleich beider Figuren zeigt, dass der Fehler im Gaspedalpositionssensor Auswirkungen auf andere Werte hat wie z.B. den Drosselklappenpositionswert und die Anzahl der Umdrehungen.
7: Ergebnisse der Simulation eines fehlerfreien Verhaltensmodells. u1(t), y1(t), y2(t) bezeichnen die Gaspedalposition, die Drosselklappenposition und die entsprechende Drehzahl.
8: Ergebnisse der Simulation eines Modells für das Fehlerverhalten, das zu dem fehlerfreien Modell in 7 korrespondiert. Der eingeführte und simulierte Fehler täuscht ein Rauschen auf dem Pedalpositionssignal vor.
3.2.4 Lernen der Diagnosefunktionen
Nach der Systemsimulation in verschiedenen Szenarien mit unterschiedlichen Fehlern (einschließlich des fehlerfreien Falls) wurde ein Maschinenlernansatz auf die Simulationsergebnisse angewandt, wie in Gleichung 3 dargestellt. Die Grundidee ist es, dass der Algorithmus die Daten des fehlerfreien Simulationsdurchlaufs und die des fehlerhaften Simulationsdurchlauf (z.B. dem verrauschtem Signal) benutzt um Datenmuster zu erfassen. Basierend auf dieser Erkennung entwickelt der Algorithmus eine Klassifikationsfunktion, die entscheidet, ob der Gaspedalsensor verrauscht war oder nicht. Dabei liegen die Hoffnungen selbstverständlich darauf, dass dieser Klassifizierer für neue Messdaten eines realen Fahrzeuges eingesetzt werden kann. Das heißt, dass der Klassifizierer die Daten verallgemeinern muss. Daher besteht die Aufgabe darin, einen Maschinenlernansatz zu finden, der die Klassifikationsfunktion so gut wie möglich lernt.
Im Bereich des Maschinenlernens gibt es mehrere Algorithmen. Hier wurden zwei unterschiedliche Lernalgorithmen angewandt:

• Lineare Regression. Diese bekannte Methode verwendet die Schätzung der kleinsten Quadrate zur Anforderung der Parameter a₁, ... , a_n ∈ R für die Diagnosefunktionsvorlage d_i = α₁·υ₁ + ... + α_n·υ_n mit
υ₁, ... , υ_n sind die während der Simulation gemessenen Variablen. Einzelheiten dazu siehe [WW81, Mye86, Wei85, BEPW96, Har99].
• Entscheidungsbäume. Ein Entscheidungsbaum verwendet eine Serie binärer Entscheidungen, um eine Klassifikation zu erstellen. Das Lernen eines solchen Baumes erfolgt über binäre rekursive Partitionierung des Eingaberaums mit Hilfe eines gegebenen Optimierungskriteriums. Einzelheiten dazu siehe [BFOS84, Rip96].

Für diese Fallstudie wurde die Programmierumgebung R eingesetzt.
Das Problem an dieser Vorgehensweise ist, dass die Diagnosefunktion, die einen bestimmten Fehlertyp gelernt hat, möglicherweise nicht mit Messdaten umgehen kann, bei denen ein anderer Fehlertyp aufgetreten ist. Um zwischen den unterschiedlichen Fehlertypen zu differenzieren, wurden in einem zweiten Schritt die Daten zum Lernen der Diagnosefunktion eines bestimmten Fehlertyps um die Daten der anderen drei entsprechenden Fehlertypen erweitert. Diese neuen Daten wurden als fehlerlose Szenarien klassifiziert. Nachteilig an diesem Vorgehen ist, dass die Anzahl der Fehlerfälle nicht länger der Anzahl der fehlerfreien Fälle entspricht, wodurch die Bewertung des Lernergebnisses deutlich erschwert wird.
3.2.5 Experimentierergebnisse
Obwohl nur einfache Standardalgorithmen zum Lernen der Diagnosefunktion eingesetzt und keine weiteren Nachbearbeitungsschritte implementiert wurden, gingen aus den Ergebnissen gute Lösungen hervor. Die Tabellen 1 und 2 zeigen die Fehlerraten der gelernten Diagnosefunktionen für die vier Fehlertypen "–10% Offset", "+10% Offset", "Verrauschtes Signal" und "Ausgefallenes Signal". Die Ergebnisse werden für beide angewandten Lernalgorithmen angezeigt. Für jeden Fehlertyp fanden jeweils fünf Durchläufe statt. Der Durchschnitt der fünf Durchläufe wird in den Tabellen dargestellt.
Die Fehlerrate ist der Prozentsatz der Fälle, die der Algorithmus als fehlerhaft erkannt hat. In der ersten Zeile stehen die Fehlerraten, die aus den Durchläufen mit den Daten resultieren, die für das Lernen der Diagnosefunktion verwendet wurden. Die Fehlerraten in der zweiten Zeile stammen von Eingangsdaten, die nicht von dem Algorithmus zum Lernen der Diagnosefunktion verwendet wurden.
Tabelle 1. Fehlerraten der linearen Regression für die vier Fehlertypen.
Die Ergebnisse zeigen, dass der Entscheidungsbaumalgorithmus leistungsfähiger ist als die lineare Regression. Nur wenn das Signal ausfällt, ist die lineare Regression effektiver als der Entscheidungsbaum.
Tabelle 2. Fehlerraten des Entscheidungsbaums für die vier Fehlertypen.
Ferner sind die Ergebnisse der ersten Zeile und die der zweiten Zeile nahezu identisch.
Wurden die Diagnosefunktionen auch zur Unterscheidung der verschiedenen Fehlertypen eingesetzt, reichten die Ergebnisse nicht an die vorherigen heran. Dennoch geht daraus hervor, dass zufriedenstellende Ergebnisse möglich sind.
4 FAZIT UND AUSBLICK
Dieses Dokument stellte das Modellkompilierungsparadigma für die Diagnose komplexer technischer Systeme vor. Die Modellkompilierung gewinnt zunehmend an Bedeutung und kombiniert moderne Simulationstechnologie mit Methoden des Dataminings und der Lerntheorie: Die Modelle M eines in Frage kommenden Systems werden gemäß den erwarteten Eingaben zusammen mit möglichen Fehlern simuliert und ein kompiliertes Diagnosemodell aus den zahlreichen generierten Daten destilliert. Im Grunde ist das kompilierte Modell ein Klassifizierer, der nicht nur simulierte Fehler erkennt, sondern auch in der Lage ist, im Falle unvorhersehbarer Situationen zu generalisieren.
Die Modellkompilierung wird besonders dadurch attraktiv, dass die ursprünglichen Simulationsmodelle M des Anwendungsbereichs genutzt werden können. Tatsächlich enthält M in dieser Fallstudie aus dem Automobilbereich die Regelstrecken- und Reglermodelle eines Fahrzeugs; es ist hybrid und verfügt über 100 Zustände. Die skizzierten Diagnosesituationen adressieren realistische Signalfehler, die zwischen Umgebung und Fahrzeugelektronik auftreten. Zwei Lernansätze, lineare Regression und Entscheidungsbäume, kamen zum Einsatz und führten zu einer akzeptablen (85%) und einer hervorragenden (99%) Fehlererkennungsrate. Diese Ergebnisse zeigen, dass dieser Ansatz großes Potenzial mit sich bringt und weiter verfolgt werden sollte.

1. Komplexere und unterschiedliche Fehlerszenarien, die auch Software-Fehler in Steuergeräten berücksichtigen.
2. Leistungsstärkere Techniken zur Datenfilterung während der Phase des Dataminings wie Vektorquantisierung und Cluster-Analyse.
3. Verfeinerte Methoden zur Unterscheidung einer großen Anzahl von Fehlern. Hinweis: Auswahl und Adaption der Maschinenlernalgorithmen sind der Schlüssel zum Erfolg des Modellkompilierungsparadigmas. Assoziationsregeln oder Bayessche Netze haben Potenzial, Entscheidungsbäume bei umfangreichen Datensätzen zu übertreffen.

Referenzen

[1] Luca Console, Gerhard Friedrich und Daniele Theseider Dupr'e, 'Model-Based Diagnosis Meets Error Diagnosis in Logic Programs', in IJCAI, pp. 1494–1501, Chambery, France, (1993).
[2] Adnan Darwich, 'On Compiling System Descriptions into Diagnostic Rules', in Proceedings of the 10th International Workshop on Principles of Diagnosis, Scotland, (Juni 1999).
[3] Johan de Kleer und Brian C. Williams, 'Diagnosing Multiple Faults', Artificial Intelligence, 32(1), 97–130, (1987).
[4] Johan deKleer und Brian C. Williams, 'Diagnosis with Behavioral Models', in Proceedings of the Eleventh International JointConference on Artificial Intelligence (IJCAI89), pp. 1324–1330, Detroit, Michigan, (1989).
[5] Russell Greiner, Barbara A. Smith, Ralph W. Wilkerson, 'A Correction to the Algorithm in Reiter's Theory of Diagnosis', Artificial Intelligence, 41(1), 79–88, (1989).
[6] Irene Grosclaude, 'Model-based monitoring of component-based software systems', in 15th International Workshop on Principles of Diagnosis, DX-04, Carcassonne, Frankreich, (Juni 2004).
[7] Daniel K^..ob, Rong Chen, Franz Wotawa, 'Abstract model refinement for model-based program debugging', in 16th International Workshop on Principles of Diagnosis, DX-05, pp. 7–12, Monterey, Kalifornien, USA, (Juni 2005).
[8] Daniel K^..ob und Franz Wotawa, 'A Consistency-based Robust Diagnosis Approach for Temporal Causal Systems', in 16^th International Workshop on Principles of Diagnosis, DX-05, pp. 73–79, Monterey, Kalifornien, USA, (Juni 2005).
[9] Wolfgang Mayer und Markus Stumptner, 'Approximate Modeling for Debugging of Program Loops', in 15th International Workshop on Principles of Diagnosis, DX-04, pp. 87–92, Carcassonne, Frankreich, (Juni 2004).
[10] Tsoline Mikaelian, Brian C. Williams, Martin Sachenbacher, 'Diagnosing Complex Systems with Software-Extended Behavior using Constraint Optimization', in 16th International Workshop on Principles of Diagnosis, DX-05, pp. 19–24, Monterey, Kalifornien, USA, (Juni 2005).
[11] Raymond Reiter, 'A Theory of Diagnosis from First Principles', Artificial Intelligence, 32(1), 57–95, (1987).
[12] Benno Stein, 'Model Compilation and Diagnosability of Technical Systems', in Proceedings of the 3rd LASTED International Conference on Artificial Intelligence and Applications (AIA 03), Benalmdena, Spanien, ed., M. H. Hanza, pp. 191–197. ACTA Press, (September 2003).
[13] Gerald Steinbauer und Franz Wotawa, 'Detecting and locating faults in the control software of autonomous mobile robots', in IJCAI, pp. 1742–1743, (2005).
[14] Peter Struß, 'Model-Based Diagnosis-Progress and Problems', in Proceedings of the International GI-Convention, Band 3, pp. 320–331, (Oktober 1989).
[15] Peter Struß und Oskar Dressler, "Physical Negation"-Integrating Fault Models into the General Diagnostic Engine', in Proceedings of the Fifteenth International Joint Conference on Artificial Intelligence (IJCAI89), Band 2, pp. 1318–1323, (1989).

Claims

Methode zum Konstruieren einer Diagnosefunktion zum Mappen eines Symptoms eines Fehlers in einem Mechatroniksystem, insbesondere in einem Fahrzeug, auf den Fehler, der das Symptom verursacht hat, gekennzeichnet durch a. Simulieren des Mechatroniksystems in Fehlermodi und Nicht-Fehler-Modi, insbesondere bei gegebenen Vektoren von Eingabefunktionen, und b. Erlernen einer Klassifizierungsfunktion aus gesammelten Simulationsergebnissen zum Zuweisen der Fehler-Symptome auf Fehler.
Methode nach Anspruch 1, dadurch gekennzeichnet, dass die Symptome, insbesondere Symptomvektoren, bestimmt werden durch Kompilieren der Ergebnisse von Fehler- und Nicht-Fehler-Simulationen und Vergleichen damit verbundener Ergebnisse.
Methode nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass ein Erlernen der Klassifizierungsfunktion ausgeführt wird durch Filtern und/oder maschinelles Lernen und/oder Datamining und/oder Mustererkennung, insbesondere durch lineare Regression oder Entscheidungsbäume.
Methode nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass im Vorfeld des Erlernens der Klassifizierungsfunktion die gesammelten Symptome, insbesondere die gesammelten Symptomvektoren generalisiert werden, insbesondere abstrahiert auf Intervalle.
Methode zur Erkennung eines Fehlers in einem Mechatroniksystem, inbesondere in einem Fahrzeug, dadurch gekennzeichnet, dass ein Symptom eines Fehlers erkannt und zugewiesen wird auf den Fehler mit Hilfe einer Klassifizierungsfunktion, konstruiert gemäß einem der vorangegangenen Ansprüche.
Methode gemäß Anspruch 5, gekennzeichnet durch ein Erkennen von Symptomen durch Vergleichen eines erwarteten Verhaltens mit einem beobachtetem Verhalten des Mechatroniksystems, insbesondere mit Hilfe von Sensorauslesen.
System zum Erkennen eines Fehlers in einem Mechatroniksystem, insbesondere in einem Fahrzeug, gekennzeichnet durch mindestens ein elektronisches Steuergerät, insbesondere ein Steuergerät in einem Fahrzeug oder ein externes Teststeuergerät, das Symptome von Fehlern erkennt und die Symptome zu Fehlern zuweist mit Hilfe einer Klassifizierungsfunktion gemäß eines der vorangegangenen Ansprüche 1 bis 4, die ausgeführt wird auf mindestens einem elektronischen Steuergerät.
System gemäß Anspruch 7, dadurch gekennzeichnet, dass Erkennen von Symptomen durchgeführt wird durch Vergleichen eines erwarteten Verhaltens mit einem beobachteten Verhalten des Systems, insbesondere mit Hilfe von Sensorauslesen.