Konzeption und Evaluation eines hybriden - OPUS Würzburg

Konzeption und Evaluation eines hybriden - OPUS Würzburg

Künstliche Intelligenz Konzeption und Evaluation eines hybriden, skalierbaren Werkzeugs zur mechatronischen Systemdiagnose am Beispiel eines Diagnose...

6MB Sizes 1 Downloads 10 Views

Künstliche Intelligenz

Konzeption und Evaluation eines hybriden, skalierbaren Werkzeugs zur mechatronischen Systemdiagnose am Beispiel eines Diagnosesystems für freie Kfz-Werkstätten

Nghia Duc Dang

Dissertation

Konzeption und Evaluation eines hybriden, skalierbaren Werkzeugs zur mechatronischen Systemdiagnose am Beispiel eines Diagnosesystems für freie Kfz-Werkstätten

zur Erlangung des akademischen Grades

Doktor der Naturwissenschaft Von der Fakultät für Mathematik und Informatik, Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik der Universität Würzburg genehmigte

Dissertation von

Nghia Duc Dang aus Hanoi

Tag der Disputation: Erster Gutachter: Zweiter Gutachter:

20. April 2012 Prof. Dr. rer. nat. Frank Puppe Professor Dr. rer. nat. Klaus-Dieter Althoff

ii

Danksagung Die vorliegende Arbeit entstand während meiner dreijährigen Tätigkeit als Doktorand sowie zwei weiteren Jahren als Mitarbeiter in dem Zentralbereich Forschung und Vorausentwicklung der Robert Bosch GmbH. An dieser Stelle möchte ich mich bei Herrn Prof. Dr. Frank Puppe herzlich für die Unterstützung bedanken, die er mir zukommen ließ, und für die Freiheit, die er mir während der Forschungsarbeit sowohl in wissenschaftlicher als auch in zeitlicher Hinsicht gewährte. Darüber hinaus gilt mein Dank allen Mitgliedern der Prüfungskommission, insbesondere Herrn Prof. Dr. Klaus-Dieter Althoff für sein Interesse an meiner Arbeit und für die Übernahme des Co-Referats. Obwohl eine Dissertation die Befähigung eines Einzelnen zu selbständiger wissenschaftlicher Arbeit unter Beweis stellen soll, wäre diese Arbeit nicht ohne die Mitwirkung von Kollegen und Freunden zustande gekommen: Neben anderen danke ich daher insbesondere Dr. Gerrit de Boer, der mir während unserer engen Zusammenarbeit immer wieder wertvolle Denkanstöße gab, sowie Peter Engel, Alexander Opfermann, Dr. Anes Hodzic, Prof. Dr. Dirk Weidemann, Martin Schaedel, Manfred Kaul und Dieter Hagenlocher, mit denen ich viele fruchtbare Diskussionen führte. Für die gute Zusammenarbeit und die anregenden Diskussionen während des ersten und zweiten Feldtests gilt mein Dank folgenden Werkstattmitarbeitern sowie Fachexperten: Rolf Endemann, Manfred Kärcher, Volker Kolonko, Uwe Steingass, Uzunkaya Hatec, Michael Dörrer, Daniel Tica, Florian Hiekel, Dominic Ferro, Sven Fisch, Steffen Seyfang, Frank Breganski, Lothar Nagel, Martin Walter, Daniel Gruber, Claus Schulz, Alexander Maier, Martin Schaedel, Dennis Behrendt, Dietrich Pagel, Alex Bader, Oliver Eitle und Thomas Wambera. Nicht nur hierfür, aber besonders für die Hilfe bei der anstrengenden Arbeit des Korrekturlesens und der Herstellung der Kompatibilität zur deutschen Sprache danke ich Claudia Köhler sowie Susanne Kischitzki. Meiner Familie danke ich für ihr Verständnis, in der Zeit der Anfertigung dieser Arbeit häufig nur geteilte Aufmerksamkeit erfahren zu haben. Ludwigsburg, den 24 Oktober 2011

Nghia Dang Duc

iii

Kurzfassung Die Entwicklung eines wissensbasierten Systems, speziell eines Diagnosesystems, ist eine Teildisziplin der künstlichen Intelligenz und angewandten Informatik. Im Laufe der Forschung auf diesem Gebiet wurden verschiedene Lösungsansätze mit unterschiedlichem Erfolg bei der Anwendung in der Kraftfahrzeugdiagnose entwickelt. Diagnosesysteme in Vertragswerkstätten, das heißt in Fahrzeughersteller gebundenen Werkstätten, wenden hauptsächlich die fallbasierte Diagnostik an. Zum einen hält sich hier die Fahrzeugvielfalt in Grenzen und zum anderen besteht eine Meldepflicht bei neuen, nicht im System vorhandenen Fällen. Die freien Werkstätten verfügen nicht über eine solche Datenbank. Somit ist der fallbasierte Ansatz schwer umsetzbar. In freien Werkstätten - Fahrzeughersteller unabhängigen Werkstätten - basiert die Fehlersuche hauptsächlich auf Fehlerbäumen. Wegen der wachsenden Fahrzeugkomplexität, welche wesentlich durch die stark zunehmende Anzahl der durch mechatronische Systeme realisierten Funktionen bedingt ist, und der steigenden Typenvielfalt ist die geführte Fehlersuche in freien Werkstätten nicht immer zielführend. Um die Unterstützung des Personals von freien Werkstätten bei der zukünftigen Fehlersuche zu gewährleisten, werden neue Generationen von herstellerunabhängigen Diagnosetools benötigt, die die Probleme der Variantenvielfalt und Komplexität lösen. In der vorliegenden Arbeit wird ein Lösungsansatz vorgestellt, der einen qualitativen, modellbasierten Diagnoseansatz mit einem auf heuristischem Diagnosewissen basierenden Ansatz vereint. Neben der Grundlage zur Wissenserhebung werden in dieser Arbeit die theoretische Grundlage zur Beherrschung der Variantenvielfalt sowie die Tests für die erstellten Diagnosemodelle behandelt. Die Diagnose ist symptombasiert und die Inferenzmechanismen zur Verarbeitung des Diagnosewissens sind eine Kombination aus Propagierung der abweichenden physikalischen Größen im Modell und der Auswertung des heuristischen Wissens. Des Weiteren werden in dieser Arbeit verschiedene Aspekte der Realisierung der entwickelten theoretischen Grundlagen dargestellt, zum Beispiel: Systemarchitektur, Wissenserhebungsprozess, Ablauf des Diagnosevorgangs in den Werkstätten. Die Evaluierung der entwickelten Lösung bei der Wissenserhebung in Form von Modellerstellungen und Modellierungsworkshops sowie Feldtests dient nicht nur zur Bestätigung des entwickelten Ansatzes, sondern auch zur Ideenfindung für die Integration der entwickelten Tools in die existierende IT-Infrastruktur.

iv

Inhaltsverzeichnis 1 Einleitung und Lösungsübersicht

1

1.1

Motivation und Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Verbrennungsmotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3.1

Konzept zur Modellierung des Diagnosewissens . . . . . . . . . . . . .

6

1.3.2

Beschreibung des Ansatzes des Inferenzmechanismus . . . . . . . . . .

10

1.3.3

Modellierungsapplikation

. . . . . . . . . . . . . . . . . . . . . . . . .

16

1.3.4

Diagnose-Runtime-System . . . . . . . . . . . . . . . . . . . . . . . . .

19

Überblick über die Evaluierungsergebnisse . . . . . . . . . . . . . . . . . . . .

22

1.4.1

Aufwand bei der Modellbildung . . . . . . . . . . . . . . . . . . . . . .

22

1.4.2

Ergebnisse der Feldtests . . . . . . . . . . . . . . . . . . . . . . . . . .

24

Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

1.4

1.5

2 Werkstattdiagnose im Kraftfahrzeugbereich 2.1

2.2

2.3

Randbedingungen und Anforderungen . . . . . . . . . . . . . . . . . . . . . .

27

2.1.1

Wissenserhebung für die Werkstattdiagnose . . . . . . . . . . . . . . .

27

2.1.2

Das Diagnoselaufzeitsystem in der Werkstatt . . . . . . . . . . . . . .

29

Stand der Forschung und Technik . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.2.1

Bestehende Diagnoseverfahren . . . . . . . . . . . . . . . . . . . . . . .

31

2.2.2

Existierende Lösungen der Werkstattdiagnose . . . . . . . . . . . . . .

35

Lösungsweg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

3 Wissenserhebung 3.1

26

41

Anforderungsanalyse des Diagnosemodells . . . . . . . . . . . . . . . . . . . .

41

3.1.1

Funktionale Modellierung auf Basis der objektorientierten Methode . .

41

3.1.2

Qualitative Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . .

42

3.1.3

Stationäre Betrachtung . . . . . . . . . . . . . . . . . . . . . . . . . .

43

3.1.4

Berücksichtigung des Fehlermodus bei der Modellierung . . . . . . . .

44

INHALTSVERZEICHNIS 3.1.5

v

Verwendung zusätzlichen heuristischen Wissens . . . . . . . . . . . . .

45

3.2

Inhalt des Diagnosemodells . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.3

Komponentenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

3.3.1

Komponentenschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . .

54

3.3.2

Interne Variablen einer Komponente . . . . . . . . . . . . . . . . . . .

56

3.3.3

Qualitatives Verhaltensmodell . . . . . . . . . . . . . . . . . . . . . . .

58

3.3.4

Verhaltenstabelle einer Komponente . . . . . . . . . . . . . . . . . . .

61

3.3.5

Beeinflussungstabelle einer Komponente . . . . . . . . . . . . . . . . .

62

3.3.6

Ein beispielhaftes Komponentenobjektdiagramm . . . . . . . . . . . .

65

Messungsmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

3.4.1

Messung mittels Systemsensor . . . . . . . . . . . . . . . . . . . . . . .

65

3.4.2

Abbildung der externen Messung . . . . . . . . . . . . . . . . . . . . .

67

3.5

Abbildung des Fehlercodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

3.6

Abbildung der Beanstandung . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

3.7

Abbildung der Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

3.7.1

Modellierung des Stellgliedtests . . . . . . . . . . . . . . . . . . . . . .

78

3.7.2

Modellierung des Komponententests . . . . . . . . . . . . . . . . . . .

79

Systemmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

3.8.1

Systemschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

3.8.2

Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

Parametrisierung und Bedatung des Modells . . . . . . . . . . . . . . . . . . .

84

3.10 Behandlung der Variantenvielfalt . . . . . . . . . . . . . . . . . . . . . . . . .

84

3.11 Modellprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

3.4

3.8

3.9

4 Inferenzmechanismen zur Diagnoseerstellung

98

4.1

Aufbereitung der Eingabedaten (Algorithmen E und A) . . . . . . . . . . . .

4.2

Verdachtsgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.3

99

4.2.1

Ermittlung der verdächtigen Komponenten (Algorithmus P) . . . . . . 103

4.2.2

Bewertung der verdächtigen Komponenten (Algorithmus B) . . . . . . 108

Koordination der Messungen und Tests . . . . . . . . . . . . . . . . . . . . . . 109 4.3.1

Koordinierung der Sensoren-, Messungseinsätze und Tests (Algorithmus K) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.3.2

Gruppierung der verdächtigen Komponenten (Algorithmus S) . . . . . 112

vi

INHALTSVERZEICHNIS 4.4

Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.4.1

Anwendungsbeispiel mit existierenden Fehlercodes . . . . . . . . . . . 114

4.4.2

Anwendungsbeispiel mit Kundenbeanstandung, Sichtprüfung und ohne Fehlercode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.4.3

Anwendungsbeispiel mit Kundenbeanstandung . . . . . . . . . . . . . 124

5 Wissenserhebung mit DMB-System 5.1

5.2

Modellerstellungsprozess, Rollen und Systemarchitektur . . . . . . . . . . . . 131 5.1.1

Modellerstellungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5.1.2

Rollen bei der Modellerstellung . . . . . . . . . . . . . . . . . . . . . . 137

5.1.3

Systemarchitektur DMB-System . . . . . . . . . . . . . . . . . . . . . 138

Das entwickelte DMB-System . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 5.2.1

Speicherformat des Modells . . . . . . . . . . . . . . . . . . . . . . . . 142

5.2.2

Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5.2.3

Variantenmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

6 Diagnose mit DRT-System 6.1

131

148

Diagnoseprozess und Systemarchitektur . . . . . . . . . . . . . . . . . . . . . 148 6.1.1

Diagnoseprozess mit DRT-System . . . . . . . . . . . . . . . . . . . . . 148

6.1.2

Systemarchitektur DRT-System . . . . . . . . . . . . . . . . . . . . . . 151

6.2

Diagnose mit DRT-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

6.3

Migration in das bestehende Laufzeitsystem . . . . . . . . . . . . . . . . . . . 159

7 Evaluierung des Lösungsansatzes

163

7.1

Evaluierung der Wissenserhebung . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.2

Evaluierung der Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

8 Zusammenfassung und Ausblick

184

8.1

Zusammenfassung

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.2

Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8.2.1

Erweiterung des Diagnosewissens . . . . . . . . . . . . . . . . . . . . . 187

8.2.2

Weiterführende Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Literatur

194

1

Einleitung und Lösungsübersicht

Der ansteigende Vernetzungsgrad im Fahrzeug, die stark zunehmende Anzahl der durch Software realisierten Funktionen, die steigende Komplexität hydraulischer, pneumatischer und mechanischer Fahrzeugkomponenten sowie die steigende Typenvielfalt der Kraftfahrzeuge erschweren die Fehlersuche und -behebung in der Werkstatt. Diese stetige Zunahme der Komplexität im Fahrzeug ist bedingt durch Forderungen von Staat und Umwelt, durch Kundenwünsche und technische Angebote. Staat und Umwelt fordern die Reduzierung von Abgasausstoß und Kraftstoffverbrauch und schreiben eine Onboard-Diagnose zur Auswertung dieser Faktoren vor. Die Individualisierung des Fahrzeugs ist durch Kundenwünsche entstanden; hier müssen verschiedene Aspekte betrachtet werden, wie zum Beispiel Sicherheit, Kraftstoffverbrauch, Zuverlässigkeit und Qualität, Verbesserung der Verkehrssituation, Abgas- und Außengeräuschemissionen, Fahrleistung und Transportvolumen, Kauf- und Betriebskosten, Komfort, Emotionalität und Recycling. Die technischen Angebote sind vielseitig und umfassen verschiedene Bereiche des Fahrzeugs von Motor bis Komfort. Bei der Fahrzeugassistenz sind beispielsweise Systeme wie elektronisches Stabilisierungsprogamm (ESP), Antiblockiersystem (ABS) oder Antriebsschlupfregelung (ASR) für schnellere und präzisere Eingriffe in Gefahrensituationen seit längerer Zeit im Einsatz. Fahrerassistenzsysteme, welche den Fahrer entlasten und gleichzeitig seine Konzentration fördern wie Navigation, adaptive Geschwindigkeitsregelung (ACC), Spurwechselassistent (SWA) oder Spurhalteassistent (LDW), etc. sind in Fahrzeugen der Oberklasse eingebaut und werden zukünftig auch in preiswerten Klassen Einzug finden. Konsequenz daraus sind eine größere Verteilung der Fehlerauswirkungen und mehr Fehlermöglichkeiten. Erforderlich sind daher verbesserte Diagnosefunktionalitäten in Entwicklung, Produktion und Service, das heißt im gesamten Lebenszyklus eines Kraftfahrzeugs. Diese Anforderung ist Ziel der Dissertation und wird im ersten Teil dieses Kapitels besprochen. Danach werden die Anwendungsbeispiele sowie die Randbedingungen kurz beschrieben. Der entwickelte Lösungsansatz wird im dritten Teil erörtert. Im Anschluss daran wird ein Überblick der Realisierung und der Evaluierung des Lösungsansatzes präsentiert. Abschließend wird die Gliederung der Arbeit vorgestellt.

1.1

Motivation und Zielstellung

In den Werkstätten müssen Personal und Prüftechnik mit der fortschreitenden Entwicklung der Kraftfahrzeuge mithalten. Dies wird zunehmend erschwert durch die oben genannten Gründe wie steigende Typenvielfalt - insbesondere bei den Diagnoseabläufen in freien Werkstätten -, die wachsende Fahrzeugkomplexität und die stark zunehmende Anzahl der durch Software realisierten Funktionen im Fahrzeug. Die Diagnose von Fahrzeugen in den Werkstätten basiert heute auf dem Einsatz von spezieller Prüftechnik, mit deren Hilfe die in den Steuergeräten des Fahrzeugs abgelegten Diagnoseinformationen („Diagnostic Trouble Codes“, DTC) ausgelesen werden. Ein DTC gibt - aus Sicht des erzeugenden Steuergerätes - Hinweise auf mögliche Fehlerquellen, die aber in der Regel 1

2

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

nicht hinreichend sind. Aus diesem Grund werden in der Werkstatt neben den DTC der Steuergeräte weitergehende relevante Informationen zur Diagnose herangezogen, wie zum Beispiel physikalische Messgrößen (Spannung, Druck, Abgas usw.) und subjektive Beobachtungen (Geräusche, Sichtkontrolle).

Personalprofil Kundenbeanstandungen Fehlercodes Systemsensorwerte Externe Messungen Komponentenalter

Hybrid Diagnostic Suite

Ausfallwahrscheinlichkeit Prüf-/ Reparaturkosten

.. .

Diagnoseinformationen

Werkstattpersonal

Heute

Prüfprozedur (Reihenfolge, Prüfschritte)

Werkstattpersonal

Morgen

Abbildung 1.1: Verfahren und Strategien für neue Prüftechniksysteme Bei der Suche nach der defekten Komponente müssen die vorliegenden Diagnoseinformationen zur Bildung von Fehlerhypothesen logisch kombiniert und hieraus weitere Prüfschritte und Messungen abgeleitet werden. Hierbei wenden Diagnosesysteme in Vertragswerkstätten hauptsächlich die fallbasierte Diagnostik an. Zum einen hält sich hier die Fahrzeugvielfalt in Grenzen und zum anderem besteht eine Meldepflicht bei neuen, nicht im System vorhandenen Fällen. Die freien Werkstätten verfügen nicht über eine solche Datenbank. Somit ist der fallbasierte Ansatz schwer umsetzbar. Das Werkstattpersonal der freien Werkstätten muss bei einem Diagnosevorgang die vorliegenden Diagnoseinformationen zur Bildung von Fehlerhypothesen selbst kombinieren und hieraus weitere Prüfschritte und Messungen ableiten. Hierzu gehört auch die Methodik bei der Fehlersuche, das heißt, das Treffen von Entscheidungen über durchzuführende Prüfgänge und deren Reihenfolge („Welches Steuergerät wird zuerst

1.2. VERBRENNUNGSMOTOR

3

abgefragt?“, „Welche physikalischen Signale werden als nächstes gemessen?“, „Welche Komponente wird als erstes einem Komponententest unterzogen?“usw.). Diese Methodik bestimmt erheblich die Kosten bei der Fehlersuche und mitunter deren Erfolg, insbesondere in freien Werkstätten, da die Anzahl der zu diagnostizierenden Fahrzeuge entsprechend hoch und der relative Erfahrungsschatz des Werkstattpersonals entsprechend gering sein kann, verglichen mit dem einer Vertragswerkstatt (Abbildung 1.1, Heute). Bei der Entwicklung und Produktion von Fahrzeugen wird Diagnosewissen aus Entwicklungsdaten und Testdaten erstellt. Hier ist Wissen in detaillierter Form vorhanden, das nicht öffentlich zugänglich ist. Eine nicht vertraglich gebundene Werkstatt, die dieses Wissen anfordert, muss einen sehr hohen Betrag zahlen. Im Service in der freien Werkstatt ist daher detailliertes Wissen über einen bestimmten Fahrzeugstyp oft nicht verfügbar, insbesondere bei neuen Fahrzeugtypen. Um Fahrzeugtypen bestimmter Hersteller zu diagnostizieren, benötigt eine freie Werkstatt im Allgemeinen das Diagnosetool des jeweiligen Herstellers. Dadurch entstehen enorme Kosten für diese Werkstatt. Eine herstellerunabhängige Diagnosesoftware stellt für diese Werkstätten eine kostengünstige Alternative dar. Um die Unterstützung des Personals von freien Werkstätten bei der zukünftigen Fehlersuche zu sichern, werden neue Generationen von herstellerunabhängigen Diagnosetools, die die Probleme der Variantenvielfalt und Komplexität lösen, benötigt. Diese Arbeit trägt zur Lösung dieser Aufgabe bei, indem sie eine neue Methode der Offboard-Diagnose vorstellt (Abbildung 1.1, Morgen). Als Anwendungsbeispiel dienen in dieser Arbeit Otto- und Dieselmotor, welche in Kraftfahrzeugen häufig eingesetzt werden. In verschiedenen vorhergehenden Arbeiten wurden oft elektrische Systeme als Anwendungsfall herangezogen. Beim Verbrennungsmotor treffen mehrere physikalische Domänen aufeinander, zum Beispiel Mechanik, Thermodynamik, Elektronik, Hydraulik, außerdem sind die Informations- und Steuerungssysteme (ECU) beteiligt. Bei der Verarbeitung der Diagnoseinformationen sind daher nicht nur Messwerte und Beobachtungen wie bei elektrischen Systemen sondern zusätzliche Informationen, welche aus den ECU stammen, nötig. Alle diagnoserelevanten Informationen in einer Diagnosewissensbasis abzubilden und bei dem Diagnosevorgang zu verwenden ist eine Herausforderung für die zu entwickelnden Wissenserhebungs- und Diagnosetools.

1.2

Verbrennungsmotor

Die Anwendungsbeispiele sind ein Common-Rail-System (CP3-System; Versuchträger: Daimler E220cdi) und ein Motronic-System mit E-Gas (ME 7.x-System; Versuchträger: OpelCorsa 1.2). Die Bereitstellung des Moments aus dem Verbrennungsvorgang im Brennraum ist die Hauptfunktion der beiden Systeme. Um das Verbrennungsmoment zu erzeugen, werden bei dem ME 7.x-System die Luftmasse und die verfügbare Kraftstoffmasse gemischt und in den Brennraum eingeführt; der Zündfunke leitet die Verbrennung des Luft-KraftstoffGemischs zu einem bestimmten Zeitpunkt ein. Das Motorsystem kann in verschiedene Subsysteme aufgeteilt werden: Luft, Einspritzung, Brennraum, Abgas, Kühlung und Motorsteuerung (vgl. [122]). Die Aufteilung des Systems bezieht sich auf die einzelnen Funktionen bzw. Aufgaben der Subsysteme. Zum Beispiel ist es Aufgabe des Luftsystems, beim jeweiligen Betriebszustand des Motors (Warmlauf, Leerlauf, Teillast, etc.), ein bestmöglich angepasstes Luft-Kraftstoff-Verhältnis bereitzustellen. Um die zugewiesene Aufgabe auszuführen, sind die Subsysteme im Ottomotor-System wiederum aus mehreren Komponenten aufgebaut. Das

4

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

Luftsystem (Abbildung 1.2) zum Beispiel besteht aus mehreren Komponenten wie Drosselklappe, Ansauglufttemperatursensor, Luftmassenmesser, Luftfilter und Luftleitung [107]. Das Motorsystem besitzt damit bezüglich der Diagnoseaufgaben des mechatronischen Systems typische Randbedingungen (vgl. [152]): • Durch den Dekompositionsansatz wird das System in Subsysteme und Komponenten aufgeteilt und durch den Kompositionsansatz können die Komponenten beziehungsweise Subsysteme umgekehrt zu einem System zusammengefasst werden. • Das System verfügt über eigene Sensoren; diese Sensoren haben eine beschränkte Messgenauigkeit und werden für die Regelung und Selbstdiagnose verwendet. • Aufgrund der begrenzten Anzahl der Systemsensoren ist es oft nicht möglich, direkt von dem Fehlercode der Onboard-Diagnostik auf eine mögliche Fehlerursache zu schließen. • Die Einbringung zusätzlicher Sensoren ist möglich, jedoch aufwendig, da sie direkt an das zu diagnostizierende System angebunden werden müssen. • Die Ausfallwahrscheinlichkeiten und die entstehenden Kosten bei Reparatur bzw. Austausch der Komponenten in Standardsituationen sind in der Regel bekannt. • Die Fehlfunktion im mechatronischen System kann meist auf Komponentenfehler zurückgeführt werden.

P1

Volumenstromsignal S2 S0 Volumenstromsensor

Kraftstoff

S1

P2

Kraftstoff

Steuersignal S3 S0 Druckregelventil

S1 Kraftstoff

S0 Rücklaufleitung

P3 S0 S5 Kraftstoff

S1 Rohr

Kraftstoff

S6 Kraftstoff

Abbildung 1.2: Teilmodell des Kraftstoffsystems Des Weiteren existieren typische Merkmale bei der Werkstattdiagnose: • Es gibt viele Komponenten mit gleichen Funktionen, die sich in vielen Systemen wiederfinden, aber immer wieder in unterschiedlichen Varianten und Kombinationen vorkommen; hinsichtlich der Diagnostik sollten diese gleich behandelt werden. • Die Vorgänge bei der Diagnostik in der Werkstatt sind vorwiegend stationär, daher ist eine statische Betrachtungsweise möglich. • Das System funktioniert mit unterschiedlichen Betriebzuständen und wird in verschiedenen Zuständen betrieben.

1.3. LÖSUNGSANSATZ

5

• Bei der Diagnostik beschreiben die Experten die funktionalen Zusammenhänge durch grobe Wertebereiche und ungefähre Zusammenhänge, zum Beispiel monotone Abhängigkeit. Solche Beziehungen oder Relationen können nur durch qualitative Beschreibungen erfasst werden, welche viele spezielle Ausprägungen zulassen. • Der Diagnosevorgang muss nicht in Echtzeit durchgeführt werden, er gilt aber weiterhin als zeitkritische Anwendung mit begrenzter Rechenleistung und begrenztem Speicherplatz. Aufgrund der oben genannten Diagnoserandbedingungen des Verbrennungsmotors ist dieser sehr gut geeignet zu prüfen, ob der zu entwickelnde Diagnoseansatz für mechatronische Systeme geeignet ist. Um ein wissensbasiertes Diagnosesystem zu realisieren, muss das Expertenwissen formalisiert werden. Unter Berücksichtigung der erwähnten Randbedingungen werden im nächsten Abschnitt die Repräsentationsform des Diagnosewissens und das Implementierungskonzept der Inferenzkomponente des Diagnosetools erläutert und ein Konsens für diese Arbeit gebildet.

1.3

Lösungsansatz

Um die Herausforderungen der freien Werkstattdiagnose beherrschen zu können, müssen in dieser Arbeit verschiedene Probleme bei der Wissenserhebung sowie den Schlussfolgerungen gelöst werden. Bei der Wissenserhebung soll eine neue Wissensrepräsentation, die die in Abschnitt 1.2 beschriebenen Eigenschaften des mechatronischen Systems und das verfügbare Diagnosewissen in freien Werkstätten abbildet, entwickelt werden. Aus diesem Grund konzentriert sich der Lösungsansatz, der die Wissenserhebungsprobleme bewerkstelligt, auf zwei Hauptthemen: • Abbildungskonzept des mechatronischen Systems für die Werkstattdiagnose • Lösung der Variantenvielfalt in freien Werkstätten. Die Lösungskonzepte zur Wissenserhebung werden in Abschnitt 1.3.1 beschrieben. Analog zur Wissenserhebung soll die Inferenzkomponente in dem Diagnosetool verschiedenen Anforderungen der freien Werkstattdiagnose gerecht werden: • Ausnutzung aller diagnoserelevanten Informationen • Ermöglichung der systemübergreifenden Diagnose • Reduzierung des Rechenaufwandes. Zur Lösung dieser Probleme bei der Entwicklung der Inferenzkomponente werden in Abschnitt 1.3.2 Konzepte vorgeschlagen.

6

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

1.3.1

Konzept zur Modellierung des Diagnosewissens

Im Laufe der Forschungen haben sich nacheinander unterschiedliche Ansätze des diagnostischen Schließens entwickelt. Die wichtigste Unterscheidung besteht zwischen erfahrungsbasierter (regel- beziehungsweise fallbasierter) Diagnostik und modellbasierter Diagnostik (vgl. [112]). Alle Ansätze arbeiten mit abgespeichertem Wissen, welches zum Lösen einer Diagnoseaufgabe genutzt wird, wobei die Güte und Aussagekraft der Diagnostik direkt von der Qualität und Relevanz des abgespeicherten Wissens abhängt. Die meisten Diagnosesysteme, die gegenwärtig in freien Werkstätten eingesetzt werden, beruhen auf dem erfahrungsbasierten Ansatz. Bei diesem ist vor allem partielles und unvollständiges Wissen leichter abbildbar als bei dem modellbasierten Ansatz und damit schneller eine Diagnosemöglichkeit lieferbar. Andererseits existieren einige Vorteile der funktionalen modellbasierten gegenüber der erfahrungsbasierten Diagnostik: • Bei neuen beziehungsweise fremden technischen Systemen ist oft nur funktionales Wissen über einzelne Systemkomponenten und über Komponentenzusammenhänge (Strukturaufbau des Systems) und wenig Erfahrungswissen vorhanden. • Die Beherrschbarkeit der Variantenvielfalt ist besser, da sich Modellbestandteile, die möglichst kontextfrei modelliert sind, wesentlich besser als Erfahrungswissen wiederverwenden lassen.

Reales System

Onboard-DiagnoseInformationen

Qualitatives Modell des realen Systems

Diagnoserelevante Informationen aus der Werkstatt

+

Diagnosemodell

Abbildung 1.3: Grober Aufbau des Diagnosemodells Aufgrund der oben beschriebenen Abwägungen wurden Konzepte und Implementierung eines hybriden, skalierbaren Lösungsansatzes zur mechatronischen Systemdiagnose entwickelt und realisiert. Der Ansatz ist ein Hybrid, da sowohl der modell- als auch der erfahrungsbasierte Ansatz bei der Wissenserhebung und dem Diagnosevorgang verwendet werden. Damit können bei der Diagnose alle verfügbaren Informationen berücksichtigt werden, da das Diagnosemodell neben dem physikalischen Modell des Systems auch die Informationen der

7

1.3. LÖSUNGSANSATZ

Onboard-Diagnose sowie diagnoserelevante Informationen aus der Werkstatt beinhaltet. In der Inferenzkomponente des Ansatzes müssen die modellbasierten und die erfahrungsbasierten Schließalgorithmen kombiniert werden. Das Diagnosemodell besteht aus folgenden Bestandteilen (Abbildung 1.3): • Qualitatives Modell des physikalischen Systems • Onboard-Diagnoseinformationen • Diagnoserelevante Informationen aus der Werkstatt. Das qualitative Modell wird aus einzelnen Komponentenmodellen und deren Verbindungen aufgebaut. Ein Komponentenmodell besteht aus folgenden Teilinformationen: • Komponentenschnittstellen, mit denen eine Komponente mit seinen benachbarten Komponenten interagiert (vgl. [15], [111]). • Interne Funktions- und Fehlervariablen, die die internen Komponenteneigenschaften oder Fehlerzustände darstellen (vgl. [137]). • Die Verhaltensbeschreibung definiert das Nominal- und Fehlverhalten der Komponente in unterschiedlichen Betriebszuständen, da eine Komponente in unterschiedlichen Betriebzuständen unterschiedliche Verhalten aufweisen kann (vgl. [137]). Die Spezifikation des Verhaltens erfolgt in Form von relationalen qualitativen Übergangsfunktionen. Als Beispiel hierfür soll die Verhaltensbeschreibung einer Luftleitung betrachtet werden (vgl. [78]): qual

M assenf lussin = M assenf lussaus qual

qual

Druckin − Druckaus = M assenf lussaus Aus dieser Spezifikation des Verhaltens wird die Verhaltenstabelle generiert (vereinfachtes Beispiel in Tabelle 1.1). Die Generierung setzt voraus, dass die qualitativen Gleichheitszeichen und die qualitativen Operationen (zum Beispiel qualitative Addition, Subtraktion, Monotonie usw.) vordefiniert sind (vgl. [20], [136], [92]). M assenf lussin

Druckin

M assenf lussaus

Druckaus

hoch

hoch

normal

hoch

hoch

hoch

niedrig

hoch

...

...

...

...

hoch

niedrig

hoch

niedrig

Tabelle 1.1: Beispiel für Aufbau einer Verhaltenstabelle

Weil Systemsensoren eine weitere Rolle bei dem Diagnosevorgang übernehmen, enthalten sie zusätzliche Messeigenschaften mit folgenden Informationen: • physikalische Modellgröße, die gemessen wird

8

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT • Wertebereich der Modellgröße.

Eine Verbindung beschreibt die Abhängigkeit zwischen zwei Schnittstellen unterschiedlicher Komponenten. Das Verhalten des Gesamtsystems ergibt sich aus der Interaktion der einzelnen Komponenten über die Verbindungen. Nicht zu verwechseln sind die Verbindungen des realen Systems mit den Verbindungen des Modells (vgl. [15], [124]). So wird beispielsweise ein Rohr nicht durch eine Verbindung, sondern durch eine Komponente modelliert. Zum Grundumfang des Motorsteuergeräts in modernen Kraftfahrzeugen gehört die OnboardDiagnostik (OBD). Die OBD erfolgt durch den permanenten Abgleich der Aktionen und der Reaktionen des Systems im Betrieb mit den Befehlen des Steuergerätes und der Signale der verschiedenen systemeigenen Sensoren untereinander auf ihre Plausibilität (vgl. [99]). Wenn die Plausibilität nicht gegeben ist, erfolgt ein Eintrag in den Fehlerspeicher des Steuergeräts. Wegen der unterschiedlichen Diagnoseinformationen, die ein Fehlercode beinhaltet, ist es notwendig, dass eine Abbildung des Fehlercodes im Modell in zwei Arten unterschieden wird: • Fehlercode als virtueller Sensor: Dieser zeigt auf abgebildete physikalische Modellgrößen. Bei der Modellierung kann wie folgt vorgegangen werden: – Fehlercode: 2352-1 – Schnittstelle: Virtuelle Schnittstelle, mit der sich der Fehlercode mit Injektor 6 verbindet qual

– Wertebelegung: M assenf lussaus = niedrig • Fehlercode als Diagnoseregel: Dieser zeigt direkt auf systemeigene Komponenten oder Komponentengruppen. Die Diagnoseregel kann wie folgt beschrieben werden: – Wenn: Fehlercode 0206-3 - existiert – Dann: ∗ Verdächtige Komponente: Injektor 6 ∗ Anweisung: Bauteil Kraftstoffinjektor 6 prüfen ∗ Möglicher Fehler: Kurzschluss nach Masse. Kundenbeanstandungen sind eine der diagnoserelevanten Informationen in den Werkstätten. Sie liegen in Form verbaler Aussagen vor und können verschiedene Ursachen beinhalten. Soweit möglich werden sie auf physikalische Größen des Modells abgebildet. Falls das nicht möglich ist, werden Diagnoseregeln in das Modell integriert. Als Beispiel hierfür wird die Kundenbeanstandung „Motor klingelt oder klopft“ betrachtet (vgl. [122]): • Kundenbeanstandung als virtueller Sensor. Dieser zeigt auf abgebildete physikalische Modellgrößen: – Kundenbeanstandung: „Motor klingelt oder klopft“ – Schnittstelle: Virtuelle Schnittstelle, mit der sich die Kundenbeanstandung mit Drallklappe verbindet qual

– Wertebelegung: M assenf lussaus = hoch

1.3. LÖSUNGSANSATZ

9

• Kundenbeanstandung als Regel. Direkte Zuweisung der Kundenbeanstandung auf verdächtige Komponenten: – Wenn: Kundenbeanstandung „Motor klingelt oder klopft“ existiert – Dann: ∗ Verdächtige Komponente: Brennraum ∗ Anweisung: Geometrie des Brennraums prüfen ∗ Möglicher Fehler: Die Änderung beziehungsweise Abweichung der Brennraumgeometrie – Optimierungsinformationen: ∗ Aufwand der Prüfung: Hoch ∗ Wahrscheinlichkeit: Selten. Eine weitere Information im Feld sind die Offboard-Messungen. Im Unterschied zu den systemeigenen Sensoren erfolgt die Modellierung des externen Messgeräts ohne die Verhaltensbeschreibung. Analog zu dem systemeigenen Sensor beinhaltet das externe Messgerät folgende Messeigenschaften: • Physikalische Modellgröße, die gemessen wird • Wertebereich der Modellgröße. Die Anbindung von Komponenten- und Stellgliedtests in das Modell ist unkompliziert (vgl. [3]), da sie direkt an eine systemeigene Komponente beziehungsweise Komponentengruppe gebunden sind. Eine automatische Anbindung in Form einer Datenbankabfrage ist möglich, wenn die systemeigenen Komponenten und deren Tests den gleichen Identifizierungscode besitzen. Die Optimierungsinformationen wie Testdauer, Testkosten beziehungsweise Aufwand (soweit vorhanden) werden direkt an die Komponenten- und Stellgliedtests gebunden. Diese Aufteilung des Komponentenmodells ermöglicht die Anwendung des Schichtkonzeptes bei dem Modellerstellungsvorgang. Dabei wird ein Systemmodell in drei Hauptschichten unterteilt: • Grundschicht: In dieser Schicht werden folgende Aktivitäten durchgeführt: – Festlegen der Systemschnittstellen und damit der Systemgrenzen – Modellierung der systemeigenen Komponenten und deren Verhalten – Abbilden der Verbindungen zwischen Komponenten sowie zwischen Komponenten und Systemschnittstellen • Mittelschicht: Hier werden die Fehlercodes aus der Onboard-Diagnostik abgebildet • Oberschicht: Die Kundenbeanstandung sowie externe Mess- und Testmöglichkeiten werden in dieser Schicht modelliert. Häufig kommt es vor, dass in unterschiedlichen Fahrzeugen das gleiche System eingebaut ist. Die Unterschiede liegen im Fehlercode des einzelnen Fahrzeugs oder bei externen Messund Testmöglichkeiten. Zum Beispiel existiert der Fehler-Code P-0016 (Funktionsstörung bei Nockenwellen- und Kurbelwellensignal) beim Corsa D - Z12XEP und beim Agila - Z12XEP

10

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

nicht, obwohl in beiden Fahrzeugtypen der gleiche Benzinmotor eingebaut ist. Mit dem Schichtkonzept ist es möglich, die Mittel- und Oberschicht auszutauschen. Damit wird der Modellierungsaufwand bei verändertem Fehlercode beziehungsweise Kundenbeanstandungen sowie externen Mess- und Testmöglichkeiten reduziert, weil die Änderung durch das Austauschen der Schicht oder in unterschiedlichen Schichten vorgenommen werden kann. Der Prozess zur Vervollständigung des Diagnosemodells wird in zwei Hauptphasen untergliedert: Die Modellierungsphase und die Bedatungsphase. Der Modellierer konzentriert sich darauf, welche Komponenten im betrachteten System verbaut wurden, welches Verhalten sie aufweisen und wie sie miteinander zusammengeschaltet sind. In der Bedatungsphase werden die technischen Daten wie Testmöglichkeiten, Soll- und Grenzwerte einer Komponente in das Modell integriert. Die Bedatungsphase kann wiederum in zwei unabhängige Phasen unterteilt werden: Die erste Teilphase umfasst die Integration der Informationen über die Sollwertbereiche der Sensoren und Testprozeduren der Komponenten in das Diagnosemodell. Die Anbindung der Optimierungsdaten (Ausfallwahrscheinlichkeit, entstehende Kosten bei Messung, Prüfung oder Reparatur von systemeigenen Komponenten, etc.) zur Priorisierung der verdächtigen Komponenten im Diagnosevorgang bildet die zweite Teilphase. Das Ergebnis der Trennung von Modellen und komponentenspezifischen Daten führt zu einer enormen Reduzierung der Anzahl benötigter Modelle. Die Wartung und weitere Entwicklung des Modells sowie die Pflege der Parameter können unabhängig voneinander geschehen. Mit den oben beschriebenen Trennungsmöglichkeiten ist das Diagnosemodell skalierbar, weil für die Diagnostik nicht alle diagnoserelevanten Informationen im Diagnosemodell enthalten sein müssen. So funktioniert das System auch, wenn zum Beispiel die Ausfallwahrscheinlichkeit von Komponenten noch unbekannt ist, weil das Wissen über die Ausfallwahrscheinlichkeit erst über Jahre gesammelt wird.

1.3.2

Beschreibung des Ansatzes des Inferenzmechanismus

Da der Diagnoseprozess in der Werkstatt ein symptomorientierter Diagnoseprozess ist, besteht der Algorithmus aus folgenden Schritten: Algorithmus 1.1 : Diagnostik-Algorithmus (D) Eingabe: (Input Algorithmus D) - Menge der Kundenbeanstandungen, die sich bei der Fahrzeugannahme beziehungsweise bei der Probefahrt durch das Werkstattpersonal ergaben. - Menge der vorhandenen Fehlercodes. - Menge der Modellgrößen mit Wertebelegung, die sich durch systemeigene Sensoren bestimmen lassen. - Menge der Modellgrößen mit Wertebelegung, die sich durch externe Messungen bestimmen lassen. - Menge aller Stellglied- und Komponententests, die durchgeführt wurden. Ausgabe: (Ouput Algorithmus D) - Menge der verdächtigen Komponenten mit Bewertungspunktzahl.

11

1.3. LÖSUNGSANSATZ

- Eine Menge der Systemsensoren, externen Messungen, Stellgliedtests und Komponententests mit Bewertungspunkten, die zum Ausschließen der Systemkomponenten aus der verdächtigen Menge dienen soll. Algorithmus: D1 Aufbereitung der eingegebenen Diagnoseinformationen: Analyse der Werte der Einund Ausgangsattribute sowie der internen Variablen und der zu diagnostizierenden Komponenten anhand der Eingabedaten. D1.1 Setzen der Attribute im Modell gemäß der Eingabedaten: Für alle Kundenbeanstandungen, Fehlercodes, Messungen und Tests beziehungsweise Prüfungen werden mögliche Abbildungen in dem Modell ermittelt. D1.2 Einschränkung der zu diagnostizierenden Komponenten: - Durch Fehlercodes, die bestimmte Komponenten verdächtigen. - Durch Ausschluss offensichtlich korrekt funktionierender Komponenten. - Durch Testergebnisse von Komponenten- und Stellgliedtests. D2 Verdachtsgenerierung: D2.1 Propagierung der Attribute im Modell zur Ermittlung verdächtigter Komponenten; D2.2 Bewertung der verdächtigten Komponenten mit Bewertungspunktzahlen; D3 Koordinierung der Sensoren- und Messeinsätze sowie der Komponententests: Ermittlung von möglichen Messaktionen, Komponententest mit Ranking. D4 Erneuter Aufruf des Diagnostik-Algorithmus bis keine Kundenbeanstandungen oder Fehlercodes mehr vorliegen. Zur Erläuterung dieses Diagnosealgorithmus kann hierfür das Beispielsystem (Abbildung 1.2) herangezogen werden. Dabei beinhaltet das Modell des Rohres eine Verhaltenstabelle 1.2: Rohr In

Out

S0

S1

Kraf tstof f V˙ ...

Kraf tstof f V˙ 1 ...

V ariable

Leckage

...

H

...

H

...

N

...

H

...

{H, N, L}

...

H

...

N

...

N

...

N

...

...

...

...

...

...

...

L

...

L

...

N

...

Tabelle 1.2: Ein Abschnitt der Verhaltenstabelle des Rohres Neben dem Modell existieren folgende Diagnoseinformationen: 1

V˙ := Volumenstrom; N := normal; L := niedrig; H := hoch

12

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT • Fehlercode ist nicht vorhanden. • Die Kundenbeanstandung lautet „Höchstleistung kann nicht erreicht werden“. • Es existiert keine Leckage in dem System (Sichtprüfung). • Das Messsignal des Volumenstromsensors vor dem Druckregelventil ist im Sollbereich.

Mit Hilfe der Methode D1.1 wird aus den einzelnen Diagnoseinformationen von Kundenbeanstandungen, Fehlercodes aus Steuergeräten, Messwerten der systemeigenen sowie externen Sensoren und Komponententests eine Menge der Diagnoseparameter gebildet: • Kundenbeanstandung: Kraf tstof f system.P3 .Kraf tstof f.V˙ = L, • Fehlercode: DT C = , • Messung: V olumenstromsensor.S1 .Kraf tstof f.V˙ = N , • Test: – Druckregelventil.Leckage = N , – Rohr.Leckage = N , – Ruecklauf leitung.Leckage = N , Die Ergebnisse der Methode D1.1 dienen als Parameter der Methode D1.2. Unter der Voraussetzung, dass alle systemeigenen Komponenten eine Verhaltenstabelle besitzen, wird die erste Reduktion der Verhaltenstabelle der gefundenen Komponenten durch den Aufruf der Methode D1.2 durchgeführt. Dabei werden alle nicht relevanten Zeilen der Verhaltenstabelle einer Komponente, die nicht mit der Wertebelegung in den Diagnoseparametern übereinstimmen, entfernt. Zum Beispiel existiert als Ergebnis der Komponentenüberprüfung keine Leckage im Kraftstoffrohr. Dadurch reduziert sich die Verhaltenstabelle des Rohres. Die daraus resultierende Verhaltenstabelle 1.3 besteht aus folgenden Zeilen: Rohr In

Out

S0

S1

Kraf tstof f V˙ ...

Kraf tstof f V˙ ...

H

...

H

N

...

L

...

V ariable

Leckage

...

...

N

...

N

...

N

...

L

...

N

... qual

Tabelle 1.3: Ein Abschnitt der reduzierten Verhaltenstabelle mit Leckage = N des Rohres Analog zu diesem Rohr werden die Verhaltenstabellen des Druckregelventils mit dem Ergebnis der Sichtprüfung reduziert (Tabelle 1.4).

13

1.3. LÖSUNGSANSATZ

Zur weiteren Eingrenzung der verdächtigen Komponenten im Modell werden die Diagnoseparameter rückwärts und vorwärts propagiert (D2.1). Diese zielorientierte Inferenz unterliegt der transitiven Verknüpfungen von Komponenten im System. Weil sich das Modell durch einen gerichteten Graphen darstellen lässt - wobei ein Knoten eine Komponente und eine Kante die Verbindung zwischen zwei Komponenten symbolisiert - sind die transitiven Verknüpfungen die gerichteten Kanten des Modells. Druckregelventil In

Out

S0

S3

S5

S6

Kraf tstof f V˙ ...

Steuersignal

Kraf tstof f V˙ ...

Kraf tstof f V˙ ...

Signal

V ariable

Leckage

...

...

...

...

...

...

...

...

...

...

L

...

N

L

...

L

...

N

...

N

...

L

H

...

L

...

N

...

N

...

N

N

...

N

...

N

...

N

...

N

H

...

H

...

N

...

N

...

N

L

...

L

...

N

...

L

...

N

L

...

N

...

N

...

N

...

L

L

...

N

...

N

...

N

...

L

L

...

H

...

N

...

...

...

...

...

...

...

...

...

...

qual

Tabelle 1.4: Ein Abschnitt der reduzierten Verhaltenstabelle mit Leckage = N des Druckregelventils Im Rückwärtspropagierungsvorgang wird das Verhalten der Komponenten gegen die Richtung der Verbindungen im Modell analysiert. Die Modellgrößen, die in den Diagnoseparametern enthalten sind, befinden sich in den Ausgangsschnittstellen der Komponenten beziehungsweise in den Ausgangsschnittstellen des Systems. Der Algorithmus propagiert diese Diagnoseinformationen in entgegengesetzter Richtung entlang der Verbindungen vom Ende bis zum Anfang der Wirkkette. Hierzu werden alle Zeilen der Verhaltenstabelle der einzelnen Komponenten, die für die Erklärung der vorgegebenen Symptome nicht relevant sind, entfernt. Bei einer Wirkkette, die eine Rückkopplung oder mehrere Rückkopplungen beinhaltet, muss der Propagierungsvorgang wiederholt werden, bis keine Änderungen an den Zeilen der Verhaltenstabelle mehr existieren. Als Ergebnis entsteht für jede Komponente in der Wirkkette eine reduzierte Verhaltenstabelle. Diese reduzierte Tabelle beinhaltet zum einen den möglichen Eingangsfehler, der nicht durch die betrachtete Komponente verursacht ist, und zum anderen das mögliche Fehlverhalten der Komponente, die die Symptome verursacht. An dem Beispiel des Kraftstoffsystems soll diese rekursive Methode zur Rückwärtspropagierung veranschaulicht werden. Aus der Verbindung zwischen der Ausgangsschnittstelle S1 des Rohres und der Ausgangsschnittstelle P3 des Systems (Abbildung 1.2) kann durch die Rückwärtspropagierung folgende Schlussfolgerung gezogen werden:

14

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT Rohr.S1 .Kraf tstof f.V˙ = L

Mit dieser Wertebelegung kann die Verhaltenstabelle 1.3 des Rohres weiter reduziert werden: Rohr In

Out

S0

S1

Kraf tstof f V˙ ...

Kraf tstof f V˙ ...

L

L

...

V ariable

Leckage

...

N

...

...

Tabelle 1.5: Weitere Reduzierung der Verhaltenstabelle durch Wertebelegung der Ausgangsqual schnittstelle des Rohres (Rohr.S1 .Kraf tstof f.V˙ = L) Die Wertebelegungen an der Eingangsschnittstelle S0 des Rohres in der Tabelle 1.5 wird durch die Rückwärtspropagierung der Ausgangsschnittstelle S5 des Druckregelventils weitergereicht. Es gilt: ((Rohr.S0 .Kraf tstof f.V˙ = L)∧ (Rohr.S0 .Kraf tstof f.V˙ = Druckregelventil.S5 .Kraf tstof f.V˙ )) ⇒ Druckregelventil.S5 .Kraf tstof f.V˙ = L Analog zum Rohr reduziert sich die Verhaltenstabelle 1.4 des Ventils zur Verhaltenstabelle 1.6: Druckregelventil In

Out

S0

S3

S5

S6

Kraf tstof f V˙ ...

Steuersignal

Kraf tstof f V˙ ...

Kraf tstof f V˙ ...

Signal

V ariable

Leckage

...

...

...

...

...

...

...

...

...

...

N

...

L

L

...

N

...

N

...

L

...

N

L

...

L

...

N

...

N

...

N

L

...

L

...

N

...

L

...

N

L

...

N

...

N

...

N

...

L

L

...

H

...

N

...

...

...

...

...

...

...

...

...

...

Tabelle 1.6: Weitere Reduzierung der Verhaltenstabelle des Druckregelventils durch Rückqual wärtspropagierung (Diagnoseparameter Druckregelventil.S5 .Kraf tstof f.V˙ = L) Nach dem Beenden der Rückwärtspropagierung wird die Vorwärtspropagierung gestartet. Im Vorwärtspropagierungsvorgang wird die Verhaltenstabelle der Komponenten entlang der Rich-

15

1.3. LÖSUNGSANSATZ

tung der Verbindungen im Modell reduziert. Dieser Vorgang ist analog zur Rückwärtsverkettung, die Unterschiede sind die Propagierungsrichtung und dass sich die Modellgröße in den Eingangsschnittstellen der Komponenten des Systems befindet. In dem Beispiel des Kraftstoffsystems steht die Diagnoseinformation für die Vorwärtspropagierung aus dem gemessenen Volumenstrom des Volumenstromsensors. Gemäß dem Messergebnis ist der Volumenstrom an der Ausgangsschnittstelle S1 in Ordnung: V olumenstromsensor.S1 .Kraf tstof f.V˙ = N Die Wertebelegungen an der Ausgangsschnittstelle S1 des Volumenstromsensors wird durch die Vorwärtspropagierung der Eingangsschnittstelle S0 des Druckregelventils weitergereicht. Es gilt: V olumenstromsensor.S1 .Kraf tstof f.V˙ = Druckregelventil.S0 .Kraf tstof f.V˙ ⇒ Druckregelventil.S0 .Kraf tstof f.V˙ = N Mit dieser Information kann die Verhaltentabelle (Tabelle 1.6) des Druckregelventils weiter reduziert werden. Als Ergebnis besteht die Tabelle des Ventils nach der Vorwärtspropagierung aus folgenden Zeilen: Druckregelventil In

Out

S0

S3

S5

S6

Kraf tstof f V˙ ...

Steuersignal

Kraf tstof f V˙ ...

Kraf tstof f V˙ ...

Signal

V ariable

Leckage

...

...

...

...

...

...

...

...

...

...

N

...

N

L

...

L

...

N

...

N

...

L

L

...

N

...

N

...

N

...

L

L

...

H

...

N

...

...

...

...

...

...

...

...

...

...

Tabelle 1.7: Relationen des Volumenstroms (V˙ ) in der reduzierten Verhaltenstabelle des Druckregelventils bei Vorwärtspropagierung (Diagnoseparameter qual Druckregelventil.S0 .Kraf tstof f.V˙ = N ) Bei der Bewertung der verdächtigen Komponenten mit Bewertungspunktzahlen werden alle Komponenten in der Wirkkette mit einer reduzierten Verhaltenstabelle untersucht (D2.2). Dabei bekommen die Komponenten, welche mit den meisten Zeilen die Symptome durch ihre eigenen internen Variablen erklären können, höhere Verdächtigungspunkte als Komponenten, die die Symptome nur teilweise oder nicht erklären können. In dem Beispiel bekommt das Druckregelventil eine höhere Bewertungspunktzahl als das Rohr beziehungsweise die Rücklaufleitung. Die Koordination der Sensoren- und Messeinsätze sowie der Komponententests (D3) gestaltet sich einfach, wenn weitere Systemsensoren existieren, die noch nicht ausgelesen wurden.

16

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

Da das Auslesen der Systemsensoren mit geringerem Aufwand als externe Messungen beziehungsweise Tests oder Prüfungen zu bewerkstelligen ist, werden zuerst die restlichen relevanten Systemsensoren ausgelesen. Die Ermittlung von möglichen externen Messaktionen und Komponententests mit Ranking beruht auf einem einfachen Algorithmus, welcher als Eingabe die Defektwahrscheinlichkeit der Komponenten und die dabei entstehenden Testkosten bei Prüfung der jeweiligen Komponente sowie die entstehenden Messkosten bei Durchführung von Messungen auswertet. Dieser Vorgang ist trivial und gehört zu den Standardaufgaben der Optimierung.

1.3.3

Modellierungsapplikation

Modelierungstool3.jpg

Abbildung 1.4: Entwickelte Modellierungsapplikation (DMB-System) Der Wissenserhebungsansatz, der in Abschnitt 1.3.1 beschrieben ist, wurde in dieser Arbeit umgesetzt. Die entwickelte Modellierungsapplikation wird im Folgenden als DMB-System (Diagnostic Model Builder System) bezeichnet. Aufgrund des Umfangs sowie der Komplexität

1.3. LÖSUNGSANSATZ

17

der entwickelten Applikationen wird hierbei nur eine grobe Beschreibung der Funktionen der Applikation gegeben. Aus Benutzersicht ist die Oberfläche der Modellierungsapplikation in vier Bereiche aufgeteilt. Im rechten oberen Bereich in Abbildung 1.4 befindet sich ein Modellbrowser, in welchem der Benutzer unter Verwendung des Navigationsbaums die einzelnen Elemente des erstellten Modells anwählen kann. Die Modell- und Komponentenbibliothek befindet sich im rechten unteren Bereich der Benutzeroberfläche und beinhaltet Komponenten-, Teilsystem- und Systemmodelle, welche per Drag & Drop in den grafischen Editor zur Erstellung eines neuen Modells eingefügt werden können. Die Modellbibliothek verfügt über Suchfunktionen, die neben Namen- und Volltextsuche weitere Suchfunktionen wie Suche über Kriterien, Metadaten beziehungsweise Kategorien beinhaltet. Diese erweiterte Suchfunktion steigert die Effizienz bei der Modellerstellung und reduziert damit den Erstellungsaufwand. Im linken oberen Bereich der Benutzeroberfläche befindet sich ein grafischer Editor, in welchem die Struktur des realen Systems als ein Objektdiagramm abgebildet wird. Die Systemkomponenten, Systemschnittstellen sowie weitere Elemente des Systemmodells werden durch unterschiedliche Symbole visualisiert. Die Zusammenhänge zwischen den Elementen werden im grafischen Modell durch gerichtete Verbindungslinien zwischen den Schnittstellen der Elemente dargestellt. Neben den Funktionen zur Visualisierung der Systemkomponenten, Beschreibung der Zusammenhänge der Komponenten und Definition der Systemgrenze bietet dieser grafische Editor die Möglichkeit zur Darstellung der Strukturvarianten; dabei wird die Layertechnik umgesetzt. Durch Aus- und Einblenden der einzelnen Layer wird die grafische Darstellung der verschiedenen Varianten des Systemmodells angezeigt. Für die Editierung von Struktur und Verhalten ist der linke untere Bereich zuständig (Abbildung 1.5). Dabei werden die Anzahl und die Position der Schnittstellen der Komponente über eine eigene Eingabemaske definiert. Außerdem müssen für jede einzelne Schnittstelle ein oder mehrere Transportobjekte festgelegt werden, wobei jedes Transportobjekt ein oder mehrere Attribute hat, welchen physikalische Größen zugeordnet sind. All diese Informationen werden ebenfalls in dieser Maske spezifiziert. Zusätzlich kann eine Komponente eine oder mehrere interne Variablen besitzen, über welche die Eingangsgrößen mit den Ausgangsgrößen verknüpft werden. Die Eigenschaften der internen Variablen werden in einer separaten Eingabemaske in diesem Bereich festgelegt. Zur Beschreibung des Verhaltens einer Komponente werden die Komponentenschnittstellen sowie die internen Variablen über ein qualitatives Gleichungssystem miteinander verknüpft. Die Definition der Gleichungen erfolgt in einer separaten Maske. In dieser Maske wird darüber hinaus auch eine Verhaltenstabelle dargestellt, welche aus den Gleichungen abgeleitet wird.

Abbildung 1.5: Verhaltenseditor von DMB-System

18 KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

über verschieden Filter das entsprechendes Modell auszuwählen. Die Diagnose beginnt mit der Eingabe der Informationen zur Fahrzeug beziehungsweise Systemidentifikation. Dazu werden zunächst der Fahrzeugtyp und die Antriebsart gewählt. Anschließend kann über Marke, Model, Type und Motorkennung die Auswahl eingegrenzt werden. In unterem Bereich 1.3. LÖSUNGSANSATZ 19 werden die Modelle mit Informationen angezeigt, die den gewählten Filterkriterien entsprechen. Über einen Doppelklick auf das entsprechende Modell wird dieses Modells im 1.3.4 Diagnose-Runtime-System DRT-Explorer geladen.

Abbildung 1.6: Auswahl des Modells mit DRT-System Der Inferenzmechanismus, der in Abschnitt 1.3.2 beschrieben ist, wurde in dieser Arbeit umgesetzt. Das daraus entstehende Diagnoselaufzeitsystem wird im Folgenden als DRT-System (Diagnostic Runtime System) bezeichnet. In diesem Abschnitt werden die Ergebnisse der Realisierung aus Benutzersicht vorgestellt. Nach dem Start von DRT-System sucht dieses in der entsprechenden Datenbank nach abgelegten Modellen. Diese werden, nachdem aus ihnen die wichtigsten Informationen extrahiert wurden, zur Auswahl angezeigt (Abbildung 1.6). In der oberen Hälfte der Oberfläche ist es möglich, über verschiedene Filter das entsprechende Modell auszuwählen. Die Diagnose beginnt mit der Eingabe der Informationen zum Fahrzeug beziehungsweise mit der Systemidentifikation. Dazu werden zunächst der Fahrzeugtyp und die Antriebsart gewählt. Anschließend kann über Marke, Modell, Typ und MotorkenDie Bedienoberfläche des DRT-Systems ist in Abbildung 5.1 zu sehen.die DieModelle wesentlichen nung die Auswahl eingegrenzt werden. Im unteren Bereich werden mit InforElemente angezeigt, der Oberfläche des gewählten DRT-Systems sind eine Liste mit sämtlichen mationen die den Filterkriterien entsprechen. Über verdächtigen einen Doppelklick Komponenten mit Bewertungspunkten, die Modell zum aktuellen Zeitpunkt vorliegenden auf das entsprechende Modell wird dieses geladen. Nachdem das Modell ausgewählt Diagnoseinformationen zur Eingrenzung der Fehlerursachen, ein Workflow mit den weiteren und geladen wurde, erscheint eine andere Bedienoberfläche im Benutzerinterface. Diese ist Prüfschritten für das Werkstattpersonal sowie einer Übersicht mit in Abbildung als 1.7Handlungsempfehlung zu sehen. Die wesentlichen Elemente der Oberfläche von DRT-System sind zusätzlichen Hintergrundinformationen. eine Liste mit sämtlichen verdächtigen Komponenten mit Bewertungspunkten, die zum aktuellen Zeitpunkt vorliegenden Diagnoseinformationen zur Eingrenzung der Fehlerursachen, ein Workflow mit den weiteren Prüfschritten als Handlungsempfehlung für das Werkstattpersonal sowie eine Übersicht mit zusätzlichen Hintergrundinformationen. Zu Beginn des eigentlichen Diagnosevorgangs werden die Diagnoseinformationen durch das Werkstattpersonal im linken unteren Bereich eingegeben. Über den ersten von vier verschiedenen Tabulatoren werden die Symptome oder Kundenbeanstandungen aus einer vordefinierten Liste ausgewählt. In einem separaten Fenster werden nach der Auswahl einer Kundenbeanstandung detaillierte Informationen angezeigt. Diese Informationen dienen zur Symptomerklärung, da die Überführung des Symptoms in verschiedene Abweichungen der Modellgrößen im Modell gespeichert ist. Im zweiten Tabulator werden die automatisch aus den Steuergeräten ausgelesenen Fehlercodes aufgelistet. Analog zur Kundenbeanstandung wird in einem Fenster nach der Auswahl eines Fehlercodes die zugehörige Interpretation in textueller Form angezeigt.

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

Abbildung 1.7: Entwickeltes DRT-System

20

welcher in Abbildung 5.13 vergrößert dargestellt ist.

1.3. LÖSUNGSANSATZ

21

Der dritte Tabulator enthält eine Auflistung aller verfügbaren Systemsensoren, von denen einzelne ausgewählt werden können. Nach dem Auswählen eines Sensors wird automatisch eine Messung mittels des angeschlossenen Diagnosegerätes durchgeführt. Das Messergebnis wird anschließend in einem Fenster dargestellt. Eine automatische Auswertung des Messergebnisses erfolgt durch den Abgleich zwischen Istwert und Sollwertbereich. Eine manuelle Auswertung ist trotzdem möglich und obliegt der Entscheidung des Werkstattpersonals. Der vierte Tabulator beinhaltet sämtliche externen Messmöglichkeiten und Stellgliedtests, von denen wiederum nur ein Teil für die Diagnose ausgewählt wird. Die Anzeige für das externe Messergebnis ist analog zu der Anzeige des Systemsensors. Die Eingrenzung der Fehlerquelle ist ein iterativer Prozess, bei welchem nach den durchgeführten Messungen, Stellgliedtests beziehungsweise Komponententests die am meisten verdächtigen Komponenten von DRT-System vorgeschlagen und in der Regel vom Werkstattpersonal 5.6 –Ergebnis Maske zur des Alterungszustands der Komponenten überprüftAbbildung werden. Das derEingabe Überprüfung einer einzelnen Komponente wird in jedem Iterationsschritt DRT-System zur Verfügung gestellt. Das Testergebnis kann mittels eines DiaIn Abbildung 5.14 ist die Maske der Handlungsempfehlung für Werkstattmitarbeiter logs des Benutzerinterface aufgenommen werden. Die Ergebnisse der Stellgliedtests oder der dargestellt. Dabei sind Messungen und Prüfungen in sortierter Liste abgebildet. Es existiert Messungen durch systemeigene Sensoren werden automatisch bewertet und aufgenommen. eine Rückkopplung zwischen der Handlungsempfehlung und aller vier Tabulatoren im linken unteren Bereich derdes Abbildung 5.7. Diese Kopplung ist wichtig, daneben ein bereits ausgewählter Für die Bewertung Fehlerzustands einer Komponente werden den bisher genannten Sensor oder Prüfung beiden Bereichen maskiert werden soll. genutzt, Die getrennte Informationen weitereinAngaben über das Alter der Komponente welcheDarstellung einen Hinweis zwischen der Handlungsempfehlung und Die der Eingabe Liste alledieser Messungen und Prüfungen lässt das auf die Ausfallwahrscheinlichkeit liefern. zusätzlichen KomponenteninforWerkstattpersonal die den Handlungsfreiheit und erhört in damit die Akzeptanz der Benutzer. mationen erfolgt über rechten unteren Bereich Abbildung 1.7.

Abbildung 1.8: Maske zur Darstellung der Handlungsempfehlung In Abbildung 1.8 ist die Maske der Handlungsempfehlung für Werkstattmitarbeiter dargestellt. Dabei sind Messungen und Prüfungen in sortierter Liste abgebildet. Es existiert eine Rückkopplung zwischen der Handlungsempfehlung und allen vier Tabulatoren im linken unteren Bereich der Abbildung 1.7. Diese Kopplung ist wichtig, da ein bereits ausgewählter Sensor oder eine Prüfung in beiden Bereichen maskiert werden sollen. Die getrennte Dar-

22

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT

stellung der Handlungsempfehlung und der Liste aller Messungen und Prüfungen lässt dem Werkstattpersonal die Handlungsfreiheit und erhört damit die Benutzerakzeptanz.

1.4

Überblick über die Evaluierungsergebnisse

In diesem Abschnitt werden die wesentlichen Ergebnisse der Evaluierung beschrieben. Dabei wird auf zwei Aspekte eingegangen: • Aufwandsabschätzung für die Erstellung und Pflege von Diagnosemodellen mit der entwickelten Modellierungsapplikation, • Diagnosegüte bei der geführten Fehlersuche unter Verwendung der erstellten Diagnosemodelle und des Runtime-Systems.

1.4.1

Aufwand bei der Modellbildung

Mit der Modellierungsapplikation (DMB-System) wurden ein Common Rail CP3-System (Diesel), eine Saugrohreinspritzung ME 7.x-System (Otto) und ein Lichtsystem ALWR 1.0 (automatische Leuchtweiteregelung) modelliert und deren Komponenten parametrisiert beziehungsweise bedatet. Dabei wurde der Aufwand protokolliert und mit den vorhandenen Daten der zurzeit gängigen Redaktionssysteme verglichen. Der Aufwand für nicht modellierte Anteile der Fehlersuchanleitung (wie zum Beispiel Sicherheitshinweise, Bildrecherche, Fahrzeugerprobung, Administration) wurden mit dem gleichem Aufwand wie bei den vorhandenen Redaktionssystemen bewertet. Die Evaluierung hat gezeigt, dass sich mit dem entwickelten DMB-System ein Teil des Aufwands für die Wissenserhebung einsparen lässt. Die Aufwandsreduzierung bei der Wissenserhebung beträgt im Schnitt über 25%. Diese Aussage kann durch einen grundlegenden Vergleich des Erstellprozesses ermittelt und durch die Analyse der während der Modellierung gesammelten Daten für drei Systeme verifiziert werden. Bei der Modellierung von Fahrzeugsystemen beziehungsweise Fahrzeugfunktionen wird prinzipiell zwischen der Modellierung der Struktur (Vernetzung einzelner Subsysteme und Komponenten untereinander), der Modellierung des Verhaltens (internes Verhalten der Komponenten) und der Parametrisierung (Spezialisierung und Bedatung der Modelle) unterschieden. Dabei ist die Modellierung eines neuen Modells als Leitprojekt zu bezeichen, wenn: • Die Vernetzung der Subsysteme und Komponenten neu erstellt werden muss; • Für mehr als 30%2 der Komponenten Verhalten neu hinterlegt werden sollen. Enthält ein Modell nicht alle Subsysteme oder Komponenten des realen Systems, so muss das Modell um diese Komponenten beziehungweise Subsysteme erweitert werden. Das erweiterte Modell kann dann als neues Basismodell für die Ableitung des vorangegangenen Modells genutzt werden. Wenn die Anzahl der erweiteten Komponenten mehr als 30% der gesamten Komponentenanzahl beträgt, ist die Aktivität zur Erzeugung des Modells als Leitprojekt zu bezeichen. Sind für die Modellierungen eines Systems weitere Schnittstellen der Subsysteme 2

Der Richtwert 30% ist aus verschiedenen Modellierungsworkshops mit Fehlersuchanleitungsautoren, die später DMB-System benutzen sollen, entstanden

1.4. ÜBERBLICK ÜBER DIE EVALUIERUNGSERGEBNISSE

23

oder der Komponenten nicht oder nicht passend vorhanden, so muss eine Überarbeitung der Modellierung des Systems oder der Komponenten erfolgen. Sie lässt sich meistens aus den bestehenden ableiten. Wenn die Anzahl der neuen Schnittstellen mehr als 30% beträgt, wird die Erstellung des Modells ebenfalls als Leitprojekt betrachtet. Eine Art des Folgeprojekts ist ein Projekt, bei dem die Aktivität auf die Parametrisierung der Modelle beschränkt ist. Die Parametrisierung beinhaltet zum Beispiel die Änderung der Sollwerte oder der Einbaulagen sowie Prüfkosten oder Ausfallwahrscheinlichkeiten. Weitere Arten des Folgeprojekts betreffen die Erzeugung des Modells: • Nutzen die umgebenden Systeme nicht alle Schnittstellen des betreffende Subsystems oder der Komponenten, so lassen sich durch geeignete Parametrisierung die ungenutzten Schnittstellen für die Diagnose deaktivieren. • Enthält ein existierendes Systemmodell Subsysteme oder Komponenten, die im zu modellierenden System nicht vorhanden sind, so lassen sich diese Subsysteme oder Komponenten ebenfalls durch geeignete Parametrisierung deaktivieren. • Wird die Abdeckung von zusätzlichen internen Variablen einer Komponente oder eines Subsystems erforderlich, so ist eine Anpassung oder Erweiterung der Verhaltensmodellierung erforderlich. • Wird eine interne Variable nicht benötigt, so lässt sich diese Variable durch geeignete Parametrisierung deaktivieren. Hochgerechnet auf den Gesamtdatenbestand ist die Ersparnis (über 25%) nur für gleiche Verhältnisse von Leit- und Folgeprojekten gültig. Für die Erstellung des Diagnosewissens mit DMB-System sind allerdings wesentlich weniger Leitprojekte erforderlich. Dafür steigt der Anteil der Folgeprojekte. Die Folgeprojekte erfordern einen wesentlich geringeren Aufwand. Daher kann ein erheblich höheres Einsparpotential bei der Erstellung vieler Systeme erwartet werden. Die Abschätzung des Gesamtaufwands für die Umstellung des Redaktionssystems auf DMBSystem erfolgte durch weitere Aktivitäten, zum Beispiel Modellierungsworkshops. Als Ergebnisse existieren folgende Auswertungen von den Autorenteams über die Fähigkeiten des entwickelten Ansatzes: • Machbarkeit: Erstellung der Diagnosemodelle mit vorhandenem Fachwissen und mit der Modellierungsapplikation möglich, • Effizienz: Zeit- und Kostenerspanis für das Einpflegen der Daten in die Datenbank durch komponentenorientierten Ansatz, • Durchgängigkeit: Nutzbarkeit der bestehenden Daten sowie Zukaufdaten, • Überprüfbarkeit: Automatische Test mit vordefinierten Testfällen am Rechner, • Know-how-Aufbau: Modellierung der Wirkkette ermöglicht weiteren Aufbau des Expertenwissens bei Autoren, • Robustheit: Sensitivität bezüglich Serienstreuung, Übertragbarkeit auf andere Fahrzeuge, Integrierbarkeit unterschiedlicher Informationsquellen,

24

KAPITEL 1. EINLEITUNG UND LÖSUNGSÜBERSICHT • Variantenvielfalt: Wiederverwendbarkeit von Komponenten und Systemen durch Schichtkonzept.

1.4.2

Ergebnisse der Feldtests

Ein weiteres Ziel der Evaluierung war die Erprobung des entwickelten, modellbasierten Diagnosesystems (DRT-System) am Realsystem und die Bewertung seiner Leistungsfähigkeit in Bezug auf Diagnosegüte und Diagnosedauer. Als Referenz wurden dafür marktführende Werkstattdiagnosesysteme herangezogen. Um einen objektiven Vergleich bei der Diagnose zu garantieren, wurden die Prüfschritte genau nach Vorgabe gegangen. Damit wurde auf die Erfahrungswerte des Werkstattpersonals verzichtet. Diese Einschränkung war nötig, weil bei der Evaluierung des Diagnosemodells kein heuristisches Wissen enthalten ist. Da die eingebauten Fehler unterschiedliche Situationen in der Werkstatt widerspiegeln sollten, wurden Fehler, die Fehlercodes provozieren, und Fehler, die keinen Fehlercode provozieren, eingebaut. Die Fehlercode provozierenden Fehler sind von Fehlercodes, die direkt auf fehlerhafte Komponenten und auf Systemgrößen zeigen, zu unterscheiden. Zusammenfassend können folgende Aussagen getroffen werden: • Die Anzahl der Prüfschritte im entwickelten Diagnosetool liegt im Durchschnitt 29% unter der von vorhandenen Tools. • Bei der Prüfzeit wird im Durchschnitt 45% eingespart. Neben der Steigerung der Effizienz bei der Fehlersuche existieren weitere Vorteile des entwickelten DRT-Systems gegenüber existierenden Diangosetools. Folgende Aussagen wurden nach den Feldtests und Live-Demos von Werkstattmitarbeitern, Trainern aus einem Schulungszentrum und Mitarbeitern aus dem Marketing getroffen: • Effizienz: Schnelles Auffinden gewünschter Informationen durch komponenten- und funktionsorientierten Ansatz, • Systemverständnis: Die Darstellung der Wirkkette fördert Know-how-Aufbau und damit Verbesserung der Lernkurve der Werkstattmitarbeiter, • Vermarktbarkeit: Sichtbarkeit der Veränderungen und des Nutzens für den Kunden, schrittweise Vermarktung einzelner Aspekte des Diagnoseansatzes möglich, • Individualisierung der Diagnose durch: Berücksichtigung regionaler Unterschiede und Reparaturhistorie einzelner Fahrzeuge, • Verbindung von geführter Fehlersuche und Steuergerätediagnose (Zukunftssicherheit): Automatische Durchführung von vorgeschlagenen Messungen und Stellgliedtest in optimaler Reihenfolge.

1.5

Gliederung der Arbeit

Auf die Problemstellung „Randbedingungen, Stand der Forschung und Technik“, die der Gegenstand der Untersuchung des Diagnoseproblems in freien Werkstätten in dieser Arbeit ist,

1.5. GLIEDERUNG DER ARBEIT

25

wird im ersten Abschnitt des Kapitels 2 eingegangen. Hier werden die grundsätzlichen Diagnoseansätze aus der Literatur besprochen und deren Vor- und Nachteile erläutert. Daraus wird das Modellierungskonzept sowie die Entwicklung eines neuen Modellierungs- und Diagnosetools abgeleitet, um der Diagnoseserviceabteilung und den herstellerunabhängigen Werkstätten neue Werkzeuge zur Beherrschung jetziger und zukünftiger Diagnoseprobleme zu geben. In Abschnitt 2.2 werden die Anforderungen und Erwartungen aus Sicht der Domäneexperten in der Serviceabteilung und aus Sicht des Werkstattpersonals besprochen. Daraus folgt im letzten Teil des Kapitels die Entscheidung der Modellform und die Anforderungsanalyse für die entwickelte Software. Mit den Erkenntnissen aus Kapitel 2 wird in Kapitel 3 der Modellaufbau behandelt. Hierbei wird zuerst über das Komponentenmodell und die Arten der Komponenten diskutiert. Die Schnittstellen, Verbindungen und das Verhalten des Systemmodells bilden den zweiten Teil des Kapitels 3. Im letzten Teil dieses Kapitels wird auf die Anbindung von diagnoseerforderlichem, heuristischem Wissen im Modell eingegangen. Kapitel 4 beginnt mit der Beschreibung der Modellanalysealgorithmen, die nicht nur für die Verdachtsgenerierung und Fehlerlokalisierung zuständig sind, sondern auch für die Modellüberprüfung eingesetzt werden können. Die Diagnose mittels des Diagnosealgorithmus wird anhand einiger Beispiele beschrieben. Die Umsetzung des Modellierungsansatzes in Form einer Modellierungsapplikation (MBDSystem) wird in Kapitel 5 beschrieben. Abschließend wird in diesem Kapitel auf den Ansatz und die Umsetzung der Modellqualitätssicherung, die in MBD-System eingebettet ist, eingegangen. Im ersten Abschnitt des Kapitels 6 wird die Systemarchitektur des realisierten Laufzeitsystems (DRT-System) erläutert. Im letzten Teil dieses Kapitels werden verschiedene Möglichkeiten zur Integration des neuen Laufzeitsystems analysiert und bewertet. Kapitel 7 stellt die Evaluierungsergebnisse des Modellierungstools und des Diagnosetools vor. Dabei soll die Effizienz des Modellierungskonzepts und des Modellierungstools im Vergleich zu einigen, derzeit eingesetzten Redaktionstools ermittelt werden. Ein weiterer Punkt ist der Vergleich zwischen dem Diagnosetool und einigen der besten, gegenwärtig auf dem Markt befindlichen herstellerunabhängigen Diagnosetools. Dies dient zur Untermauerung der Tragfähigkeit des Modellierungskonzepts und der Diagnosealgorithmen. Mit der Zusammenfassung und einem Ausblick in Kapitel 8 endet die vorliegende Arbeit.

26

2

Werkstattdiagnose im Kraftfahrzeugbereich

Wegen der zunehmenden Fahrzeugkomplexität und der abnehmenden Beherrschbarkeit des Gesamtfahrzeugsystems müssen entlang des gesamten Lebenslaufes eines Fahrzeugs verschiedene Prüf- und Diagnoseanwendungen durchgeführt werden: • Entwicklung: Die Prüfmöglichkeiten in dieser Phase beinhalten die Überprüfungen der Hardware und Software des zu entwickelnden Systems. Die Ansteuerung von Stellgliedern und das Lesen von analogen und digitalen Eingängen werden eingesetzt, um die Funktionsfähigkeit der Hardware zu überprüfen. Bei dem Softwaretest werden die Ansteuerungen und das Austesten von internen Testroutinen, Fehlercodesetz- und Rücksetzbedingungen sowie von Reaktionen auf länderspezifische Einstellungen durchgeführt. Bereits während der Entwicklung eines technischen Systems können Fehlermöglichkeiten, ihre Auswirkungen und mögliche konstruktive Maßnahmen zur Fehlervermeidung untersucht werden. Hierfür werden Methoden wie die Ereignisablaufanalyse, die Fehlerbaumanalyse und die Fehlermöglichkeits- und Einflussanalyse (FMEA) eingesetzt. Die entstehende FMEA kann bei der Fertigung (Massenproduktion) und beim Service für den Funktionstest der einzelnen Komponenten oder Komponentengruppen eingesetzt werden. • Fertigung: Um die Qualität des ausgelieferten Produkts zu gewährleisten, werden in der Fertigung speziell entwickelte Prüftechniken eingesetzt. In der Massenfertigung müssen nicht nur Endkontrollen durchgeführt, sondern Prüfschritte in die Fertigungslinien integriert werden, da Qualitätsprobleme, die erst bei der Endkontrolle festgestellt werden, schnell zu großen Ausschussmengen und damit zu hohen Fertigungskosten führen. Bei der Fertigung der Kraftfahrzeuge ist neben der Verbauprüfung (zum Beispiel Identifizierung des Steuergerätes, Ermittlung der aktuellen Konfiguration, Ansteuern von Stellgliedern und Auslesen von Istwerten) der Funktionstest im verbauten Zustand ein wesentliches Prüfmittel. Dabei wird das Zusammenwirken aller Steuergeräte in der vorliegenden Fahrzeugkonfiguration geprüft. Zusätzlich müssen die beim Verbau entstandenen Fehlercodes gelöscht und die Ermittlung noch bestehender Fehler durchgeführt werden. • Service: Im Service ist der Diagnoseprozess in zwei Hauptteile aufgeteilt: Betrieb und Wartung. Bei der Prozessdiagnose im Fahrbetrieb, auch Onboard-Diagnose genannt, sollen Fehler während des Betriebs möglichst schnell erkannt werden, um unerwünschte, insbesondere sicherheitskritische Zustände verhindern zu können. Die Verarbeitung der gemessenen Signale muss in Echtzeit durchgeführt werden, so dass geeignete Korrekturmaßnahmen noch während des Betriebs ergriffen werden können. Weitere Diagnoseprobleme ergeben sich bei der Wartung und Reparatur eines technischen Systems. Hier wird von der Werkstattdiagnose (Offboard-Diagnose) gesprochen. Im Unterschied

2.1. RANDBEDINGUNGEN UND ANFORDERUNGEN

27

zur Betriebsdiagnose können zusätzliche Messgrößen aufgenommen werden, damit die Messsignale nicht in Echtzeit verarbeitet werden müssen. Außerdem können zusätzliche Informationen aus Systembenutzerbeanstandungen, Ausfallwahrscheinlichkeiten der Komponenten sowie Testkosten und Reparaturkosten herangezogen werden. Die zu entwickelnde Diagnoseanwendung in dieser Arbeit soll in freien Werkstätten ihren Einsatz finden, daher sind die nachfolgend beschriebenen Randbedingungen, Anforderungen und der Stand der Technik sowie die Forschungen nur auf die Offboard-Diagnose bezogen. Zunächst werden die Anforderungen, Charakteristika und Randbedingungen der Werkstattdiagnose erläutert. Nach der Präzisierung der Problemstellung wird auf existierende Diagnoseverfahren, oft auch als Klassifikationsverfahren bezeichnet, eingegangen und diese werden diskutiert. Abschließend werden die Wissenserhebung und die Diagnosemechanismen der modellbasierten Diagnose vertieft.

2.1

Randbedingungen und Anforderungen

Die erfolgreiche Einführung eines neue Lösungsansatzes für die Werkstattdiagnose hängt von verschiedenen Faktoren ab. Die Funktionalitäten der neu entwickelnde Applikationen sollen nicht nur die funktionalen Anforderungen abdecken, sondern auch die nicht funktionalen Anforderungen erfüllen. In diesem Abschnitt werden die Randbedingungen, und damit die abgeleiteten Anforderungen aus Sicht der Autoren des Servicebereichs, die das Diagnosewissen aufbereiten und aus Sicht der Anwender, die in der Werkstatt die Diagnose durchführen, beschrieben.

2.1.1

Wissenserhebung für die Werkstattdiagnose

Die Werkstattdiagnoseproblematik im Kraftfahrzeugsektor zeichnet sich durch die hohe Geschwindigkeit technologischer Neuerungen aus. Es ist auf längere Sicht mit der Verwendung neuer Komponententypen oder neuartiger Realisierungen zu rechnen. Außerdem gibt es durch die Variantenvielfalt zum gleichen Zeitpunkt eine Fülle von Modifikationen, hervorgerufen durch unterschiedliche Einbausituationen in unterschiedlichen Fahrzeugtypen. Folglich erfordert es eine hohe Flexibilität und Modularität des Wissenserhebungsystems. Das System sollte einerseits geeignet sein, Wissen aus verschiedenen Anwendungsbereichen darzustellen, andererseits sollten aber auch, unabhängig vom Anwendungsgebiet, die für unterschiedliche Aufgabenstellungen benötigten Informationen effizient darstellbar sein. Die Wissensbasis sollte möglichst einfach veränderbar und erweiterbar sein. Dies ist am einfachsten zu erreichen, wenn die Wissensbasis modular aufgebaut ist. Das bedeutet, spezielle Bereiche des Wissens, wie etwa das Wissen über die Lösung eines bestimmten Teilproblems, sollten möglichst unabhängig vom Rest der Wissensbasis hinzugefügt oder verändert werden können. Die Informationen, die bei der Wissensakquise einfließen, sind entscheidend für die Diagnosegüte in dem wissensbasierten Diagnosesystem. Ein signifikanter Unterschied zwischen der Wissensakquise der Serviceabteilung der Fahrzeughersteller (OEMs) und der unabhängiger Diagnoseanbieter sind die verfügbaren Informationen über die zu diagnostizierenden Systeme. Trotz klarer gesetzlicher Bestimmungen ist die praktische Durchführung der KfzGruppenfreistellungsverordnung (vgl. [65], [90]) nicht zufriedenstellend für freie Werkstätten. Die hohen Preise der Hersteller-Diagnosetools und die eingeschränkte Verfügbarkeit von

28

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH

Diagnosedaten für unabhängige Diagnoseanbieter beschränken die Fahrzeugabdeckung. Unabhängige Anbieter von Diagnosetools erhalten nur vereinzelte Fahrzeuginformationen, weil bestimmte OEMs kaum Serviceinformationen, Reparaturinformationen beziehungsweise diagnoserelevante Informationen zur Verfügung stellen und wenig Informationen über aktuell entdeckte Fahrzeugfehler oder Rückrufaktionen von Seiten der OEMs existieren. Der stetige Anstieg der Auslagerungsaktivitäten bei allen OEMs und eine stärkere Fokussierung auf Kernkompetenzbereiche wirken sich negativ auf den Informationsgehalt der gelieferten Diagnosedaten aus. Für eine systemübergreifende Diagnose und darausfolgende Reparatur reicht dieser Informationsgehalt oft nicht aus, da das Wissen über Funktionen sowie Verhalten der Komponenten, Systeme und Subsysteme nicht immer transparent ist. Die Problematik der gerade erwähnten Fahrzeugabdeckung wird zusätzlich durch die Modell- und Variantenvielfalt verstärkt. Dabei beeinflussen folgende Faktoren die Steigerung der Variantenvielfalt (vgl. [11]): • Marktsättigung der wichtigsten Märkte in Europa und USA zwingt OEMs zu einer weiteren Marktsegmentierung und stärkt den Wettbewerb zwischen den OEMs • Kundenwünsche fordern die Fahrzeugindividualisierung und Mikrosegmentierung des Marktes • Suche der OEMs nach neuen Marktnischen. Die steigenden Anforderungen an die Modell- und Variantenvielfalt beeinflussen die Modellzyklen sowie die Fahrzeugentwicklungszeiten und damit die Qualitätssicherung des Fahrzeugs. Weil bei kürzeren Entwicklungszeiten mit einer erhöhten Fehleranzahl zu rechnen ist, können viele Fehler erst im Feld entdeckt werden. Damit steigt die Anforderung der Werkstattdiagnose an den Informationsfluss über aktuell häufig entdeckte Fahrzeugfehler einer bestimmten Fahrzeugserie aus dem Feld. Aus den oben beschriebenen Randbedingungen folgen einige Konsequenzen für den zentralen Servicebereich, welcher für die Einführung und Pflege des Diagnosesystems zuständig ist. Diese Konsequenzen sind gleichzeitig die Anforderung an das zu entwickelnde Autorensystem, das für die Wissenserhebung zuständig ist. Folgende Punkte gelten als hauptfunktionale Anforderungen an das Wissenserhebungstool: • Integration des bisherigen Wissens: Die existierenden Diagnoseinformationen und deren Fehlersuchlogik für ältere Produktreihen sollen durch die Weiterentwicklungen für neue Produktreihen nicht beeinflusst werden. Bei der Einführung des neuen Lösungsansatzes soll es eine Co-Existenz der älteren Ansätze und des neuen Ansatzes geben, sonst ist der Umstellungsaufwand zu hoch. • Modularisierung des Diagnosewissens: Weil das Diagnosewissen aus verschiedenen Quellen stammt, mit unterschiedlichen Kompetenzen bearbeitet wird und diese Erhebung zeitversetzt durchgeführt werden kann, soll das Diagnosewissen modularisiert werden. Die Vorteile der Modularisierung sind zum einen die Verkürzung der Akquisezeit und zum anderen eine Lösung der Variantenvielfaltsproblematik. • Systemübergreifende Diagnose: Die klassischen Vorgehensweisen bei der Erhebung des Diagnosewissens stoßen immer mehr an die Grenzen der Diagnosemöglichkeiten, da die

2.1. RANDBEDINGUNGEN UND ANFORDERUNGEN

29

Komponenten- und Systemsichten nicht immer zu einer erfolgreichen Diagnose führen. Viele Fahrzeugfunktionen sind nur systemübergreifend realisierbar. Zum Beispiel ist bei den meisten Fahrzeugen die ESP-Funktion abhängig von der Motorlast, welche von dem Motorsystem geliefert wird. Ohne die Möglichkeit über die Systemgrenze hinaus zu diagnostizieren ist die Lösung weder zukunftsorientiert noch nachhaltig. • Beherrschung der Variantenvielfalt: Da ein wesentliches Kriterium für die Güte des herstellerunabhängigen Diagnosesystems die Beherrschung von Produktvarianten ist, sollte idealerweise die Fehlersuchlogik für eine Baureihe nur einmal erstellt werden müssen und damit auch die Varianten abgedeckt sein. • Automatische Prüfbarkeit des Diagnosewissens: Die eingegebenen Informationen, welche für den Diagnosevorgang in der Werkstatt erforderlich sind, müssen in einer Form bereitgestellt werden, die eine unkomplizierte und effiziente Überprüfung ermöglichen. Für eine erfolgreiche Einführung des neuen Systems im Servicebereich muss das System neben der Erfüllung der funktionalen Anforderungen folgenden nicht funktionalen Anforderungen entsprechen: • Einhaltung der Prozessschritte: Der bisher etablierte Wissenserhebungprozess und dessen Arbeitsschritte sollen durch eventuelle zusätzliche Schritte, die durch den neuen Lösungsansatz erforderlich sind, nicht stark beeinflusst beziehungsweise geändert werden. Es besteht sonst die Gefahr, dass die Fachmitarbeiter im Servicebereich die neue Lösung ablehnen. • Wissenserhebung mit bestehender Struktur: Der neue Lösungsansatz darf nicht dazu führen, dass das bisherige Erfahrungswissen der Fachmitarbeiter unbrauchbar wird. Daher muss das vorhandene Erfahrungswissen in die neue Diagnosefunktion integriert werden können. Des Weiteren muss die Bearbeitung der erforderlichen neuen Diagnoseinformationen unkompliziert und mit der bestehenden Mannschaft und deren Struktur zu bewältigen sein. • Aufwand und Nutzen: Das Verhältnis zwischen Aufwand (Wissenserwerb, Modellbildung, Wissensumfang) und Nutzen (Detaillierungsgrad, Vollständigkeit, Kosten) muss berücksichtig werden und soll wirtschaftlich tragbar sein. Das heißt, dass der Aufwand der Modellerstellung nicht höher als der jetzige Erstellungsaufwand sein darf. Neben der genannten Problematik im Bereich der Wissensakquise existiert eine Reihe von Anforderungen an das Diagnosesystem, das im Feld zum Einsatz kommen soll. Im nächsten Abschnitt wird auf diese Anforderungen eingegangen. Dabei wird das gesamte Umfeld der Arbeit durchleuchtet und ein klares Bild erschaffen.

2.1.2

Das Diagnoselaufzeitsystem in der Werkstatt

Der Druck der Wirtschaftlichkeit zur Kosteneinsparung zeigt sich vor allem in modernen Kraftfahrzeugen an der begrenzten Zahl zusätzlicher Sensoren. Es werden zwar immer mehr Sensoren eingesetzt, diese werden aber im Wesentlichen für die Fahrfunktion entwickelt, so dass für die Diagnosezwecke geeignete Größen oftmals nicht gemessen werden können. Es werden nicht immer alle für die Diagnose gewünschten Größen gemessen.

30

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH

Aus Kostengründen werden die für die Diagnosefunktionen benötigten Rechenleistungen, der Speicherplatz und die Kommunikationskapazität des Steuergeräts möglichst gering gehalten. Folglich besitzen die Sensoren nur eine beschränkte Auflösung. Messgenauigkeit und die einzelnen für die Diagnose verwendeten Sensorsignale werden nur in festgelegten Abtastzeiten bereitgestellt. Durch temporäre Systemausfälle, zum Beispiel durch einen Wackelkontakt können diese Abtastzeiten jedoch nur bedingt eingehalten werden. Dies führt zu weiteren Messungenauigkeiten. Aufgrund der rauen Umgebungsbedingungen werden die Sensorsignale oftmals durch ein Rauschen überlagert. Zudem variieren zahlreiche Parameter bei Änderung der Umweltbedingungen, bei Massenfertigung und durch alterungsbedingte Bauteiltoleranzen. Dadurch kann das Systemverhalten selbst bei genauer Kenntnis der physikalischen Zusammenhänge nicht immer exakt bestimmt werden. Die Korrelationen zwischen verschiedenen Signalen können vielfach nur grob formuliert werden. Aus solchen inhärenten Unsicherheiten und Unvollständigkeiten der Informationen durch Sensorsignale werden unsichere Schlussfolgerungen gezogen. Wegen dieser Randbedingungen reicht die Abdeckung der Onboard-Diagnose nur bis zur systemeigenen Grenze und ist bei der Diagnose von gekoppelten Systemen nicht immer hilfreich. Zudem sind die Diagnoseinformationen aus der Onboard-Diagnose nur bei elektrischen Fehlern zuverlässig; bei Fehlern die nicht durch Kurzschluss, Massenschluss, etc. entstehen, ist die Diagnose oft nicht aussagekräftig. Aufgrund der beschrieben Randbedingungen bestehen die funktionalen Anforderungen an das Diagnosesystem aus vier Schwerpunkten: • Korrektheit: Die Diagnose soll korrekt sein. Es sollte nicht passieren, dass Fehlerursachen nicht gefunden werden oder, was noch schlimmer ist, dass falsche Ursachen gefunden werden, die zum Austausch von fehlerfreien Teilen am Fahrzeug führen, ohne dass damit der eigentliche Fehler beseitigt wurde. • Vollständigkeit: Die Diagnose soll vollständig sein. Alle Ursachen von Fehlern sollen gefunden werden, damit eine Instandsetzung des Fahrzeugs innerhalb einer einzigen Diagnosesitzung möglich ist. • Prävention: Nach erfolgreicher Reparatur sollte das Fahrzeug über einen längeren Zeitraum keine Ausfälle zu verzeichnen haben. Idealerweise sollten außer den regelmäßigen Wartungen überhaupt keine Standzeiten zu verzeichnen sein. Es ist daher von Vorteil, wenn während einer Diagnosesitzung zusätzliche Messergebnisse des Fahrzeugs ausgewertet werden können, die Hinweise auf in Kürze zu erwartende Ausfälle liefern. In diesem Fall können präventive Maßnahmen ergriffen werden. • Kostengünstigkeit: Die Diagnose soll kostengünstig sein. Dies fordert im Wesentlichen, dass die Ursache eines Fehlers mit möglichst wenigen Diagnoseschritten gefunden wird. Außerdem sollen während der Diagnosesitzung keine umfangreichen Einstellungen oder Montagen am Fahrzeug durchgeführt werden. Das entscheidende Kriterium ist immer die Zeit, die für eine Diagnosesitzung aufzuwenden ist. Neben den funktionalen Anforderungen existieren weitere nicht funktionale Anforderungen, zum Beispiel: • Lernorientierter Erklärungsansatz: Neben der Diagnosefähigkeit soll die Erlärungskomponente des Diagnoselaufzeitsystems die Lernkurve des Anwenders positiv beeinflussen.

2.2. STAND DER FORSCHUNG UND TECHNIK

31

Dazu gehören der Wissenstransfer und -aufbau durch genaue Erklärungen der Funktionen und der Wirkketten des zu diagnostizierenden Systems. Die offene Weitergabe diagnoserelevanten Wissens zwischen Experten und Werkstattpersonal schafft einen zusätzlichen Anreiz für die Wissensteilung des Werkstattmitarbeiters über die entwickelte Feedback-Funktion. • Optimale Navigation: Die diagnoserelevanten Informationen, die aus verschiedenen Quellen stammen, sollen in einem kundenorientierten Kontext verknüpft und dargestellt werden. Diese Anforderung ermöglicht eine optimale Benutzbarkeit und Zugänglichkeit des Diagnosewissens und damit eine optimale Nutzerführung. • Intuitive Bedienoberfläche: Für den Werkstattservicetechniker ist eine unkomplizierte Bedienung des Diagnosesystems während des Einsatzes von großer Wichtigkeit. Insbesondere bei rechnergestützten Diagnosesystemen muss die Bedienung so einfach und unmissverständlich sein, dass es zu diesem Zweck keines Computerspezialisten bedarf. • Rechenressourcen: Das Diagnosesystem soll mit geringen Rechenressourcen auskommen, weil nicht davon ausgegangen werden kann, dass die Rechner in den freien Werkstätten über große Leistung und Speicherkapazität verfügen.

2.2

Stand der Forschung und Technik

In diesem Abschnitt wird zuerst eine Übersicht über die vorhandenen Diagnoseansätze gegeben. Anschließend werden einige der bisher veröffentlichten Arbeiten auf dem Gebiet der funktionalen modellbasierten Diagnose kurz dargestellt. Danach werden die derzeit vorhandenen Lösungen der Werkstattdiagnose mechatronischer Systeme und Komponenten beschrieben.

2.2.1

Bestehende Diagnoseverfahren

Die Einteilung der Diagnoseansätze kann nach Wissensarten erfolgen. Demnach lassen sich die Ansätze in fünf Klassen je nach dem zugrundeliegenden Diagnosewissen unterteilen (vgl. [4], [113], [145], [146], [6]): • Sichere Diagnose: Bei diesem Diagnoseansatz wird das sichere Diagnosewissen in Form von Entscheidungsbäumen oder Entscheidungstabellen repräsentiert. Die Auswertung des Diagnosewissens erfolgt durch Beantwortungen der hierarchischen Fragen zu den beobachteten Symptomen. Hier werden keine komplizierten Problemlösungsansätze benötigt, da die Antworten direkt zu einer Aussage über die Fehlerursache führen können. • Heuristische Diagnose: Der heuristische Ansatz basiert auf der Auswertung von assoziativem Diagnosewissen, das in Form von Heuristiken, also Erfahrungsregeln (W irkung ⇒ U rsache), in einer Regelbasis repräsentiert wird. Die Regeln beschreiben direkt und oft ohne Begründung, welche Symptomkombinationen mit welcher Sicherheit auf welche Ursache hindeuten. Diese Regeln können jedoch mit Unsicherheiten behaftet sein und jede Wirkung kann verschiedene Ursachen haben. Daher kommen in einer konkreten Diagnosesituation üblicherweise mehrere Regeln zur Anwendung. Um eine Aussage über die wahrscheinlichste Ursache machen zu können, müssen diese Regeln geeignet verrechnet

32

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH werden. Für die Diagnose wird dann die Ursache mit der im Hinblick auf die beobachteten Symptome höchsten Bewertung herangezogen. Eine weitere Möglichkeit mit unsicherem Wissen umzugehen, ist die Anwendung von Fuzzy-Regeln. Bei ihnen wird anstelle der scharfen Zuordnung von numerischen Merkmalswerten zu symbolischen Größen eine unscharfe Zuordnung benutzt. Nach der Fuzzyfizierung der Merkmale und deren Verarbeitung durch Fuzzy-Regeln wird ein entsprechendes Ergebnis mit einer Zuordnung zu gegebenenfalls mehreren Diagnosen ausgegeben. Durch Defuzzyfizierung kann dieses Ergebnis auf eine einzelne, am stärksten zutreffende Diagnose reduziert werden. • Statistische Diagnose: Das Diagnosewissen in diesem Ansatz wird durch die statistische Auswertung von Fallsammlungen erstellt. Demzufolge existieren zunächst keine direkten Beziehungen zwischen Symptomen und Diagnosen. Die Ermittlung dieser Beziehungen erfolgt aus der Berechnung der Wahrscheinlichkeit, wie oft ein Symptom mit einer Diagnose in Verbindung steht. Die Problemlösungsmethode für diesen Ansatz ist das BayesTheorem oder die Dempster-Shafer-Theorie. Dieses Theorem lässt sich nur bei speziellen Problemstellungen anwenden. Eine breite Anwendung wird durch restriktive Voraussetzungen, insbesondere die Forderung einer statistischen Unabhängigkeit der Symptome und des gegenseitigen Ausschlusses von Fehlern sowie durch eine exponentielle Laufzeitkomplexität in der Anzahl der möglichen Fehler verhindert. Das Bayes-Netz ist ein probabilistischer Diagnoseansatz, welcher das Diagnosewissen über wahrscheinliche und unwahrscheinliche Fehlerauswirkungen in den Diagnoseregeln voraussetzt. Somit hängt die Diagnosegüte direkt von der ermittelten Wahrscheinlichkeit ab, welche nur garantiert werden kann, wenn die Falldatenbasis eine hinreichend große Auswahl typischer Fehlersituationen enthält, um das Fehlerspektrum geeignet abdecken zu können. Der Aufbau der Falldatenbasis im herstellerunabhängigen Kraftfahrzeugservicebereich hat sich als schwierig erwiesen, da zum einen die freien Werkstätten ihr Wettbewerbswissen ungern untereinander austauschen und zum anderen die erhobenen Daten für andere Zwecke benutzt werden können. • Fallbasierte Diagnose: Die Grundidee des fallbasierten Diagnoseansatzes ist es, zur Lösung eines neuen Problems auf Diagnosewissen zurückzugreifen, das in Form von gelösten Aufgaben des gleichen Problembereichs vorliegt und in einer sogenannten Falldatenbasis gesammelt wird ([5], [17]). Dabei besteht jeder Fall aus einer Problembeschreibung und der zugehörigen Lösung, der Diagnose. Liegt eine Diagnosesituation vor, wird aus der Falldatenbasis ein vergleichbarer, möglichst ähnlicher Fall herausgesucht und dessen Diagnose auf das aktuelle Problem übertragen. Zwei Faktoren sind entscheidend für die Problemlösungsfähigkeit von fallbasierten Diagnosesystemen: Zum einen die Anzahl und die Qualität der Fälle in der Falldatenbasis und zum anderen die Güte des sogenannten Ähnlichkeitsmaßes. Der Grad der Ähnlichkeit beziehungsweise die Übereinstimmung der alten Fälle mit dem aktuellen Fall wird mit dem Ähnlichkeitsmaß berechnet. Die Bestimmung des Ähnlichkeitsmaßes erfordert für komplexe kausale Zusammenhänge in der Regel zusätzliches Wissen. Außerdem muss dem Problembereich eine gewisse „Stetigkeit“ zugrunde liegen, damit die Übertragbarkeit der Lösung des alten Falls auf das aktuelle Problem gewährleistet ist. • Modellbasierte Diagnose: Bei diesem Diagnoseansatz existiert eine Unterteilung der Problemlösungsmethode in überdeckende und funktionale Klassifikation. Im Unterschied zur heuristischen Diagnose steht das assoziative Diagnosewissen der überdeckenden Klassifikation in der Form U rsache ⇒ W irkung. Die Gewichtung der Ursachen bei existie-

2.2. STAND DER FORSCHUNG UND TECHNIK

33

renden Wirkungen (Symptomen beziehungsweise Merkmalen) hängt von der vollständigen Erklärungsfähigkeit gemäß der zuvor definierten kausalen Regeln ab. Die Assoziation zwischen Ursache und Wirkung kann durch Zwischenzustände detailliert beschrieben werden. Diese Möglichkeit verbessert die Gewichtung bei sich überlagernden Ursachen, weil die Systemgrößen (Parameter) mit ihren Wertenbelegungen verknüpft werden können und so detailliertes Diagnosewissen für die Erklärungskomponenten liefern. Der Nachteil jedoch ist, dass, je höher der Detaillierungsgrad, desto ineffizienter die Diagnoselaufzeit ist. Dieses Defizit kann durch ein Verfeinerungskonzept vermindert werden. In diesem Konzept wird das detaillierte Wissen eines Zustands in Form von Zwischenzuständen nur bei Bedarf in dem Diagnosevorgang aufgerufen und bearbeitet. Die Gewichtung der Ursachen kann durch Anreicherung des Zusatzwissens über Wahrscheinlichkeiten verbessert werden. Wegen der graphischen Darstellungsmöglichkeit der Kausalregeln in der überdeckenden Klassifikation und der Berücksichtigung der Zustandwahrscheinlichkeit können die Inferenzalgorithmen mit Hilfe der Methode des Bayes-Netzes realisiert werden. Bereits während der 80er Jahre wurden einige entscheidende Arbeiten zur funktionalen Klassifikation veröffentlicht (vgl. [46], [61], [126], [30]). Dabei wurden viele Forschungen mit Anwendungsdomänen im Bereich der digitalen Schaltungen durchgeführt. In den folgenden Jahren wurden die Anwendungen in mehreren Arbeiten auf verschiedene Domänen ausgedehnt (vgl. [20], [92], [144]). In diesem Diagnoseansatz sind die zur Diagnose notwendigen Informationen in Form eines Modells gespeichert. Dabei enthält das Modell explizite Informationen über Struktur und Verhalten des betrachteten Systems und dessen Komponenten. Die Strukturinformationen eines Modells beinhalten die Angabe über verbaute Komponenten im System und die Verbindungen beziehungsweise Zusammenhänge zwischen den Komponenten. Die Benutzung der Relationsgleichungen von Ein- und Ausgängen sowie der internen Variablen zur Formulierung des Verhaltens des technischen Systems und dessen Komponenten ist hinlänglich bekannt. In verschiedenen Arbeiten und Veröffentlichungen [78], [87], [66], [92], [6] werden relationale Modelle technischer Systeme vorgestellt und zur Lösung der Diagnoseaufgaben verwendet. Bei den Ansätzen in oben genannten Veröffentlichungen besteht das Verhalten einer Komponente nicht nur aus korrektem sondern auch aus fehlerhaftem Verhalten. Diese Art der komponentenorientierten Modellierung (vgl. [71], [102], [103], [104], [105], [47]) ähnelt sehr stark der objektorientierten Modellierung bei der Softwareentwicklung. Daher können die Mechanismen zur Komplexitäts- und Variantenbeherrschung durch Vererbung, Generalisierung und Spezialisierung in diesem Diagnoseansatz an die allgemeine objektorientierte Modellierung angelehnt werden. Beispielsweise wird das Verhalten der Modellkomponenten durch Relationsgleichungen beschrieben und damit die Möglichkeit geschaffen, einen Abstraktionsmechanismus zu entwickeln, um eine Allgemeingültigkeit des Wissens über Komponenten mit gleichen Funktionen zu gewinnen, die sich damit zur Wiederverwendung eignet. Das grundlegende Prinzip der Fehlerlokalisierung in der funktionalen modellbasierten Diagnose ist prinzipiell in verschiedenen Veröffentlichungen immer ähnlich (vgl. [46], [61], [126], [126], [93], [67], [130], [132], [133], [134], [135], [136], [27], [29], [30], [31], [32], [125], [100]). Ausgehend von einer Menge der aktuellen Symptome des realen Systems können mit Hilfe des Modells Vorhersagen über das Verhalten dieses Systems gemacht werden. Wenn das Modell nur das Nominalverhalten des Systems beschreibt, liegt offenbar mindestens ein Fehler im System vor, da eine Abweichung zwischen den Vorhersagen des Nominalverhaltens von

34

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH den tatsächlichen Beobachtungen beziehungsweise Symptomen existiert. Eine Diagnose wird unter Zuhilfenahme von Diagnosewissen, das im Modell enthalten ist, erstellt. Dabei handelt es sich um Hypothesenmengen von Systemkomponenten, die fehlerhaft sein können. Die Kardinalität der Verdächtigenmenge ist abhängig von der Nützlichkeit der aktuellen Symptome beziehungsweise Merkmale. Je weniger hilfreich die verfügbaren Merkmale zum Ausschluss verdächtiger Komponenten sind, desto größer ist die Kardinalität der Hypothesenmengen. Die Reduzierung der Hypothesenmengen beziehungsweise Eingrenzung der fehlerhaften Komponenten kann durch das Anfordern weiterer Merkmale realisiert werden. Die zusätzlichen Merkmale entstehen durch weitere Messungen beziehungsweise zusätzliche Überprüfungen am realen System. Wenn das Modell Fehlerzustände beinhaltet, kann sich die erste Ermittlung der potenziell verdächtigen Komponenten an der abduktiven Vorgehensweise orientieren (vgl. [78], [127], [66]). Wenn keine vormodellierten Komponentenfehler die Symptome erklären können beziehungsweise bei der Komponentenprüfung die verdächtigen Komponenten sich als fehlerfrei erweisen, wird bei der weiteren Diagnosevorgehensweise weitgehend die oben beschriebene Strategie der Hypothesenerstellung und Hypothesenprüfung verfolgt.

In Laufe der Forschung im Diagnosebereich entstanden unterschiedliche Strategien, die sich als Standardtechniken zur Verarbeitung des Diagnosewissens herauskristallisiert haben. Dabei kann die Strategie „Hypothesenerstellung und Hypothesenprüfung“ als allgemein gültige Vorgehensweise gesehen werden. Weitere Strategien wie „Vorwärtsverkettung“, „Rückwärtsverkettung“ oder „Etablierung der hierarchischen Diagnoseverfeinerung“ sind Spezialfälle von „Hypothesenerstellung und Hypothesenprüfung“ (Abbildung 2.1). Die Vorgehensweise dieser Strategie kann wie folgt beschrieben werden: Algorithmus 2.1 : Hypothesenerstellung und Hypothesenprüfung Eingabe: SY M P T OM input - Menge der Symptome, die am Anfang des Diagnosevorgangs existieren Ausgabe: DIAGN OSE - Menge der Diagnosen, die existierende Symptome erklären Algorithmus: istDiagnoseBestaetigt = f alse; while(¬istDiagnoseBestaetigt) do DIAGN OSE = hypotheseAufstellung(SY M P T OM input ); isApproved = hypotheseBestaetigung(DIAGN OSE); if (¬istDiagnoseBestaetigt) then SY M P T OM add := neueSymptomeAuf f orderung (SY M P T OM input , DIAGN OSE); SY M P T OM input := symptomF usionierung (SY M P T OM input , SY M P T OM add ); end end return DIAGN OSE; Die Fehlerdiagnose mit der Strategie „Hypothesenerstellung und Hypothesenprüfung“ ist ein iterativer Vorgang. Hierbei ist der Eingangspunkt eine Menge der existierenden Symptome

35

2.2. STAND DER FORSCHUNG UND TECHNIK

Symptome S S SS S S S S S S S S S S S S S S S S S S S S

S

S S Anforderung weiterer Symptome bzw. Merkmale

S

S

S

Erstellung der Diagnosehypothesen inklusive Bewertungen

D D

Existierende Symptome

Mögliche Diagnosen

DD D D D D D D D D D D D D D D D D D D D D D D D D D D D D Diagnosen D D D D D D D D D

Nein

Bestätigung der Diagnosehypothesen Ja D

Abbildung 2.1: Prozess der Strategie „Hypothesenerstellung und Hypothesenprüfung“ und das Diagnosewissen, das im Basiswissen zur Verfügung steht. Die Erkennung und Bestätigung der Ursache und deren Behebung gilt als Ausgangspunkt der Diagnose. In der Methode hypotheseAuf stellung werden die vorhandenen Symptome beziehungsweise Merkmale zunächst untersucht, danach werden Hypothesen basierend auf dem Diagnosewissen über Ursachen aufgestellt. Die Methode hypotheseBestaetigung liefert das Ergebnis, ob die hypothetische Ursache bestätigt beziehungsweise nicht bestätigt ist. Bezogen auf Kraftfahrzeugwerkstattdiagnose beinhaltet die Überprüfung das Auslesen weiterer systemeigener Sensorwerte, die Durchführung weiterer externer Messungen oder Komponententests. Wenn die Ursachen bestätigt sind, wird die Fehlerbehebung durchgeführt. Anderenfalls werden die Ergebnisse der durchgeführten Überprüfungen in der Methode neueSymptomeAuf f orderung untersucht und weitere Messungen beziehungsweise Prüfungen vorgeschlagen. Die neu gewonnenen Informationen und die existierenden Symptome werden in der Methode symptomF usionierung zusammengefasst und dienen zur neuen Hypothesegenerierung.

2.2.2

Existierende Lösungen der Werkstattdiagnose

In Bereich der freien Kfz-Werkstattdiagnose basieren die Diagnoseverfahren auf dem heuristischen, auf dem fallbasierten Ansatz oder auf einer Kombination der beiden Ansätze. Eine Berücksichtigung des statistischen Wissens ist teilweise gegeben, wenn der Servicebereich über ein Servicefax und/ oder eine Hotline verfügt. Eine Internetlösung für Fallsammlungen in freien Werkstätten ist bis jetzt nicht gegeben. Die allgemeine Architektur all dieser Expertensys-

36

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH

teme aus funktionaler Sicht ist in [111] beschrieben. In Abbildung 2.2 sind die wesentlichen Komponenten sowie Benutzerrollen des Systems dargestellt.

Anwender

Experte

Dialogkomponente

Wissenserwerbskomponente Erklärungskomponente

Inferenzkomponente

Wissensbasis

Abbildung 2.2: Architektur des Expertensystems aus funktionaler Sicht Es existiert eine Rollenaufteilung der Benutzer: • Experte, der das Wissen in die Wissensbasis mittels einer Wissenserwerbskomponente einpflegt. Mit der Erklärungs- und Inferenzkomponente überprüft der Experte das Wissen in der Wissensbasis. • Anwender, der mit dem Expertensystem über die Dialogskomponente interagiert. Das System liefert die Lösung an den Anwender durch die Erklärungskomponente. Hierbei analysiert die Inferenzkomponente die Eingabeinformationen und schlussfolgert die Lösung anhand der Wissensbasis. In diesem Abschnitt wurden zunächst die Arbeitschritte der Experten in der Wissenserhebungsphase beschrieben. Danach wird auf den generellen Diagnoseablauf in den freien KfzWerkstätten eingegangen. In Abbildung 2.3 sind alle wesentlichen Schritte in der Wissenserhebung dargestellt. Um die Vermittlung des Diagnosewissens zwischen Fachexperten und Anwender zu ermöglichen, ist der erste Schritt die Erschließung des Herstellerwissens. Die Beschaffung dieser Informationen erfolgt hauptsächlich durch Datenzukauf. Neben dieser Aktivität verwendet der Experte im Servicebereich weitere Medien wie Internet oder Literatur, um sich in das System einzuarbeiten. Da das System nicht nur in einer Sprache verfügbar ist und die existierende Terminologie nicht ausreicht, um das neue System beziehungsweise deren Komponenten zu beschreiben, muss gegebenenfalls eine neue Terminologie definiert und abgestimmt werden. Weil die meisten zu reparierenden Fahrzeuge in freien Werkstätten mindestens drei Jahre auf dem Markt sind, ist es möglich, verschiedene Diagnosefälle zu sammeln. Eine Voraussetzung

37

2.2. STAND DER FORSCHUNG UND TECHNIK

Start

Beschaffung der Herstellerunterlagen bzw. Systeminformationen

Literaturrecherche und Einarbeitung in das System Diagnosefälle sammeln

Terminologie definieren, beantragen und abstimmen mit Terminologie-ADMIN Akquisition

Diagnoseinformationen über System und systemeigene Komponenten anlegen und ordnen

Anlage der relevanten Daten der geführten Fehlersuche (z.B. Sollwert, Fehlercode, ...)

Diagnosefälle auswerten

Texterfassung (Prüfkonzepte, Neuanlagen, Formatierungen, ...)

Schaltplan mit CADProgramm zeichnen

Einbaulage, Bilder, Legenden vorbereiten und anlegen

Diagnosefälle anlegen

Interpretation, Strukturierung und Integration

Simulationen und Erprobung am Fahrzeug

abschließende Prüfung und Freigabe Qualitätssicherung

Abbildung 2.3: Wissenserhebung für die Kfz-Werkstattdiagnose

Ende

38

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH

dafür sind gute Kontakte zwischen den Mitarbeitern des Servicebereichs und den Mitarbeitern in den Vertragswerkstätten. Die zweite große Phase innerhalb der Wissenserhebungsphase ist die Interpretation und Strukturierung des zuvor gesammelten Diagnosewissens sowie dessen Integration in die Wissensbasis. Diese Aktivitäten werden mittels eines existierenden Autorensystems durchgeführt. Um eine Fehlersuchanleitung der geführten Fehlersuche zu erstellen, werden zuerst die Informationen über das System und deren Komponenten im Autorensystem angelegt. Wenn die Informationen in Datenbank existieren, werden diese ausgesucht und neu geordnet. Weitere Daten wie Sollwerte der Systemsensoren, externe Messungen, Fehlercodes und Stellgliedtests werden angelegt und auf zugehörige Komponenten verlinkt. Die Texterfassung wird für einzelne Kundenbeanstandungen erstellt, dabei werden die Prüfkonzepte in Form von festgelegten Messund Testreihenfolgen realisiert. Die Erfassung von Bildern und Einbaulagen der Komponenten erleichtert den Diagnosevorgang und die Reparatur in der Werkstatt und soll neben der Schaltplanzeichnung die letzte Aktivität in dieser Phase sein. Wenn fallbasierte Diagnosedaten existieren, werden diese durch den Autor ausgewertet. Relevante Fälle werden als fertige Diagnoselösungen in der Suchanleitung gespeichert. Die dritte Phase im Wissenserhebungsprozess ist die Qualitätssicherung. Dazu wird ein Fahrzeug bestellt und es werden Fehler eingebaut. Durch eingebaute Fehler werden zum einen der Fehlercode und zum anderem die geführten Fehlersuchen geprüft. Die Abfrage der Istwerte von Systemsensoren und Überprüfungen der Sollwertbereiche werden ebenfalls in dieser Simulations- und Erprobungsaktivität durchgeführt. Die Freigabe der Fehlersuchanleitung erfolgt nach der abschließenden Überprüfung am Rechner durch das Autorenteam. In Abbildung 2.4 ist der Prozess zur Diagnose und Reparatur in der freien Kfz-Werkstatt grob dargestellt. Dabei beginnt dieser Diagnoseprozess damit, dass ein Kunde bei der Serviceannahme eintrifft und dem Werkstattmitarbeiter seine Beanstandungen beziehungsweise Symptome am Fahrzeug darstellt. Während der Annahme werden die Umgebungsbedingungen der Symptome, Fahrzeughistorie, allgemeine Sichtprüfungen, etc. dokumentiert. Wenn ein Symptom einer bemängelten Funktion entspricht, wird das Symptom durch Kontrolle - zum Beispiel bei einer Probefahrt - reproduziert. Anschließend verbindet der Werkstattmitarbeiter den Diagnosetester an das Fahrzeug über die Diagnose-Schnittstelle und liest die Fehlerspeicher aus. Danach erfolgt die Abfrage, ob ein bekannter Fall in der Datenbank vorhanden ist. Wenn ein bekannter Fall vorliegt, wird die Reparatur nach der Vorgabe zu diesem Fall vom Werkstattmitarbeiter durchgeführt. Die Reparatur wird auf Erfolg geprüft. Sofern kein Fehler vorliegt, wird das Fahrzeug an den Kunden zurückgegeben. Falls die Reparatur nicht erfolgreich war, wird der Prozessrückschritt zum Fehlercode-Auslesen eingeleitet und dort erneut begonnen. Wenn kein bekannter Fall existiert, startet der Werkstattmitarbeiter die geführte Fehlersuche mit dem vorliegenden Fehlercode und den Symptomen. Dabei gibt der Diagnosetester die durchzuführenden Prüfschritte vor und der Werkstattmitarbeiter arbeitet diese Vorgabe ab. Wird während dieser Prüfarbeiten ein Fehler gefunden, das heißt, eine defekte Komponente festgestellt, erfolgt die Reparatur durch Umtausch beziehungsweise Instandsetzen der fehlerhaften Komponente. Anschließend werden die Fehlerspeicher gelöscht. Falls kein Fehler gefunden wurde, beginnt der nächste Prozessschritt ohne Reparatur. Um eine erfolgreiche Reparatur zu bestätigen, können zuerst die Fehlerspeicher ausgelesen und als nächstes die bemängelte Funktion kontrolliert werden. Zeigt die Reparatur Erfolg, dokumentiert der Werkstattmitarbeiter alle ausgeführten Arbeitsschritte auf dem Auftrag und bereitet das Fahrzeug für die Rückgabe vor.

39

2.2. STAND DER FORSCHUNG UND TECHNIK

Start

Symptome vom Kunden erfassen, Fahrzeughistorie abfragen

Fahrzeug annehmen

Symptome auf Plausibilität prüfen

Verbindung zwischen Diagnosetester und Fahrzeug herstellen

Fehlercodes aus Steuergerät auslesen

nein

Bekannter Fall in Datenbank

ja

Geführte Fehlersuche mit Diagnosetester unter Verwendung von Fehlersuchbaum Reparatur nach Vorgabe aus bekanntem Fall durchführen nein

Fehlerursache gefunden ja Reparatur durchführen und Fehlercodes löschen

nein Reparatur erfolgreich

ja Fahrzeug zurückgeben

Ende

Abbildung 2.4: Diagnose- und Reparaturprozess in der Kfz-Werkstatt

40

2.3

KAPITEL 2. WERKSTATTDIAGNOSE IM KRAFTFAHRZEUGBEREICH

Lösungsweg

Die bestehenden Lösungsansätze können die sich steigernde Problematik der Wissenserhebung für die Diagnoseanwendung in der freien Werkstatt nicht mehr beherrschen. Aus den Anforderungen an systemübergreifende Diagnose, Variantenvielfalt, automatischer Wissensprüfung und Integration des vorhandenen Wissens folgt, dass die Lösung nur ein hybrider skalierbarer Ansatz sein kann. Diese hybride Lösung besteht aus funktionaler und heuristischer Klassifikation. Dabei löst die funktionale Klassifikation die Probleme der systemübergreifenden Diagnose und der Variantenvielfalt. Des Weiteren ermöglicht sie einen strukturierten Wissensaufbau der neuen Mitarbeiter im Autorenteam und erhört das Systemverständnis (Struktur- und Funktionszusammenhang) der Autoren. Mit der heuristischen Klassifikation kann das bisherige und zukünftig heuristische Diagnosewissen weiter verwendet und gepflegt werden. Die Eigenschaft der Skalierbarkeit ermöglicht den schrittweisen Aufbau des Diagnosewissens und die Erstellung einer Diagnose mit unterschiedlicher Tiefe abhängig vom verfügbaren Wissen. Der erste Unterschied bei der Vorgehensweise in der modellbasierten Kraftfahrzeugwerkstattdiagnose zu allen gängigen, modellbasierten Diagnoseverfahren ist domänespezifisch. Da das mechatronische System über ein Eigendiagnose-Informationssystem verfügt, muss das Vorgehen an diese Randbedingung angepasst werden. Wenn ein Fehlercode im Fehlerspeicher gesetzt ist und dieser Fehlercode auf bestimmte Komponenten zeigt, gilt es immer, zuerst diese Komponente zu überprüfen. Sollte ein Fehlercode auf mehrere Komponenten im System zeigen und ein Stellgliedtest existieren, gilt es immer, diese Tests zuerst durchzuführen. Wenn die beiden genannten Situationen nicht auftreten, kann das Diagnoseverfahren symptomorientiert erfolgen. Dabei kann sich die Ermittlung der potenziell verdächtigen Komponenten an der Strategie der „Hypothesenerstellung und Hypothesenprüfung“ orientieren. Aufgrund des oben erwähnten vorhandenen Fehlercodes beziehungsweise der Eigendiagnosemöglichkeiten des Steuergeräts und dadurch, dass die Diagnoseinformationen des Fehlercodes häufig in der Wenn-Dann-Form interpretierbar sind, müssen die Diagnoseparadigmen modellbasiert und mit der heuristischen Diagnose kombiniert werden. Dabei kann das heuristische Wissen in unterschiedlichen Modellebenen eingebunden werden. Diese Kombination ermöglicht die Ausnutzung des Funktionswissens des Modells zur Erklärung der Diagnoseschlussfolgerung durch heuristisches Wissen. Die Anreicherung des Diagnosemodells durch heuristisches Wissen erhöht nicht nur die Diagnosegüte und die Diagnosegeschwindigkeit, sondern auch die Ausnutzung des vorhandenem Diagnosewissens, das zum einen durch langjährige Erfahrung gesammelt wurde und zum anderen durch Gesetzgebung vorgeschrieben ist. Im Gegensatz zu den Diagnoseinformationen aus Steuergeräten, Sensor- und Messwerten kann die Kundenbeanstandung beziehungsweise Beobachtung durch das Werkstattpersonal mehrdeutig sein, zum Beispiel kann das Symptom „Klingeln und Klopfen bei Beschleunigung“ mehrere Deutungen wie Zündzeitpunkte, Drehzahl, Kraftstoff, Verdichtungsverhältnis, Luftverhältnis, Ansaugdruck, Ansaugtemperatur, Restgas, Brennraumform annehmen. Es kann nicht erwartet werden, dass die Beanstandungen vollständig sind; in manchen Fällen könnte es sein, dass die Beanstandungen sogar falsch sind. Um die Robustheit der Diagnoseergebnisse zu garantieren, sollen heuristische Diagnostiktabellen (vgl. [112]) als Erweiterung bei der Priorisierung der verdächtigen Komponenten verwendet werden. Die Hauptschwierigkeit, die Festlegung der vielen Einzelbewertungen bei der heuristischen Diagnostiktabelle, kann unter Zuhilfenahme von weiteren Diagnoseinformationen wie Ausfallwahrscheinlichkeiten, Zeit und Kosten gelöst werden.

41

3

Wissenserhebung

In diesem Kapitel wird der zu entwickelnde Modellierungsansatz beschrieben. In Abschnitt 3.1 werden die Anforderungen an die zu erstellenden Diagnosemodelle zusammengestellt. Sie dienen als Grundlage und gleichzeitig als Maßstab für die Bewertung der zu entwickelnden Techniken. Auf den Inhalt eines Diagnosemodells wird in Abschnitt 3.2 eingegangen. Dabei werden die Zusammenhänge zwischen den verschiedenen Bestandteilen des Modells dargelegt. Im Anschluss daran werden in Abschnitt 3.3 die theoretischen Grundlagen, Details und Überlegungen im Rahmen des zu entwickelnden Modellierungsansatzes, die für die Abbildung der Komponenten im Diagnosemodell eines Systems notwendig sind, erklärt. Für ausgewählte Beispiele verschiedener Komponentenarten wird die Modellierungstechnik angewandt und erläutert. Nach der Bereitstellung der Grundlagen der physikalischen qualitativen Modellbildung der systemeigenen Komponenten wird in Abschnitt 3.4 auf die Abbildung der Onboardund Offboard-Messungen eingegangen. Die Modellierung der Fehlercodes wird in Abschnitt 3.5 beschrieben. Die Abbildung der Beobachtungen beziehungsweise Beanstandungen wird in Abschnitt 3.6 erläutert. Die Vorgehensweise zur Modellierung des Diagnosewissens in Form von Stellglied- und Komponententests wird in Abschnitt 3.7 dargestellt. Demgegenüber bieten die Abschnitte 3.8.1 und 3.8.2 eine einführende Modellierungsübersicht der Systemschnittstellen sowie der Verbindungen im Modell. Für einen konkreten Diagnosefall muss die Grenze des Wertebereichs der Systemsensoren und der Messungen festgelegt werden. Ohne diese Festlegung können in dem Diagnosevorgang keine Komponenten ausgeschlossen und verdächtigt werden. In Abschnitt 3.9 wird auf die Möglichkeit eingegangen, die Modellgrößen zu parametrisieren.

3.1

Anforderungsanalyse des Diagnosemodells

Die Modelle sind ein zentrales Element der modellbasierten Diagnose, da sie das für die Problemlösungskomponenten im Diagnosesystem nötige Diagnosewissen beinhalten. Aus diesem Grund soll das Modell eines realen Systems alle Eigenschaften des Systems, die für die Diagnose notwendig sind, abbilden. Da bei der Werkstattdiagnose zusätzlich weitere Messgrößen aufgenommen und Informationen aus Kundenbeanstandungen herangezogen werden können, besteht das Diagnosemodell des zu entwickelnden Ansatzes nicht allein aus einem physikalischen Modell des realen Systems. Nachfolgend werden die detaillierten Anforderungen an das Diagnosemodell und die möglichen Lösungen vorgeschlagen.

3.1.1

Funktionale Modellierung auf Basis der objektorientierten Methode

Da ein mechatronisches System im Kraftfahrzeug sich durch seine Konstruktion in mehrere Komponenten aufteilen lässt und jede dieser Komponenten bestimmte Funktionen des Fahrzeugs übernimmt ([111], [112]), bietet sich die Möglichkeit, das Diagnosewissen entsprechend

42

KAPITEL 3. WISSENSERHEBUNG

den Komponenten in eigenständigen Wissensbasen abzubilden. Wenn im Fehlerfall die zu behandelnde Komponente möglicherweise eine relativ hohe Komplexität aufweist, kann diese in Subkomponenten durch Modularisierungsvorgänge weiter aufgeteilt werden. Dieses Zerlegungsprinzip trägt nicht nur zu Komplexitätsreduzierung, sondern auch zur Lösung des Problems der Variantenvielfalt bei, weil eine Modularisierung des Diagnosewissens vorliegt und sich so der Wiederverwendungsgrad des Diagnosewissens steigern lässt. Die Funktion und das Verhalten der Komponenten im mechatronischen System können durch das Fließen und Umwandeln von Transportobjekten (Material, Energie oder Signal) beschrieben werden ([46], [111]). Hierbei können die Ein- und Ausgänge als Schnittstellen der Komponente betrachtet werden. Diese Schnittstellen ermöglichen die Interaktion zwischen der modellierten Komponente und ihrer Umgebung und stimmen mit dem Schnittstellenparadigma der objektorientierten Methode überein. Die Beschreibungsform des Verhaltens einer Komponente kann durch Verhaltenstabellen beziehungsweise Relationsgleichungen dargestellt werden. Relationsgleichungen beschreiben die Beziehungen und Zusammenhänge zwischen dem Transportobjekt, dessen Attributen in Schnittstellen der Komponente sowie internen Variablen. Aus dem Verhalten seiner Komponenten in verschiedenen Betriebzuständen und den Verbindungen zwischen den Komponenten ergibt sich das Verhalten des gesamten Systems beziehungsweise Subsystems. Dieses Kompositionsprinzip des Modells wird in verschiedenen Veröffentlichungen, welche sich mit dem Diagnosethema beschäftigen, wie zum Beispiel [87], [22], [92], propagiert. Analog zur Modularisierung dient das Kompositionsprinzip zur Beherrschung der Modellkomplexität. Wegen der Möglichkeit, die Komplexität durch das Zerlegungs- und Kompositionsprinzip zu reduzieren sowie das Verhalten durch die Eingangs- und Ausgangsbetrachtungsweise des mechatronischen Systems zu beschreuben, ist die funktionale Modellierung auf Basis der objektorientierten Methode der richtige Lösungsansatz für die Diagnosewissensrepräsentation der Diagnoseproblematik in freien Werkstätten.

3.1.2

Qualitative Modellierung

Der Aufwand der Wissenserhebung ist ein großes Hindernis bei der Einführung des Expertendiagnosesystems im praktischen Einsatz. Bei einem modellbasierten Diagnosesystem hängt der Aufwand der Wissenserhebung von der Wahl der Form des Modells ab. Hier stehen zwei Möglichkeiten zur Auswahl: Die qualitative und die quantitative Modellform. Quantitative Modelle benötigen relativ exakte Vorstellungen über systemare Mechanismen. Die zum Bau solcher Modelle notwendigen Informationen lassen sich erst durch aufwändige und langwierige Messungen und Beobachtungen gewinnen. Die Berücksichtigung von Unsicherheiten erfolgt in solchen Modellen häufig durch Variation der Modellparameter innerhalb vertretbarer Grenzen, wobei anschließend die Menge der Lösungen betrachtet wird. In der Fahrzeugdiagnose ist aufgrund der Vielschichtigkeit der zu verbindenden Informationen nicht zu erwarten, dass das zur Konstruktion solcher Modelle notwendige Prozesswissen jemals ausreichend ist. Oft existieren weder quantitative Variablen noch exakte Vorstellungen über detaillierte Wirkungsmechanismen und exakte Daten über das betrachtete System. Häufig stützen sich Entscheider in solchen Situationen auf Expertenmeinungen, die nach subjektiver Kenntnis der Lage eine Einschätzung über mögliche systemare Zusammenhänge liefern. Allerdings besteht hier die Möglichkeit der Mehrdeutigkeit, eventuell sogar völlig gegenteiliger

3.1. ANFORDERUNGSANALYSE DES DIAGNOSEMODELLS

43

Aussagen, was zu einem Abwägungskonflikt führt. Das Expertenwissen ist zu einem großen Teil durch die Kenntnis prinzipieller Zusammenhänge und Einflüsse charakterisiert, ohne dass genaue und funktionale Abhängigkeiten bekannt sein müssen. Hier finden sich also sowohl parametrische Unsicherheiten als auch unvollständig bekannte Abhängigkeiten. Oft werden daher generelle Tendenzen und Grenzfälle zur Schlussfolgerung über reale Systeme herangezogen. Auch ist das Wissen über den aktuellen Systemzustand durch die eingeschränkte Beobachtbarkeit zwangsläufig unvollständig. In kaum einem realistischen Szenario ist eine vollständige räumliche und zeitliche Abdeckung durch Messungen denkbar. Auch sind viele relevante Stellgrößen, Messgrößen und Beobachtungen inhärent qualitativer Natur. Beispielsweise werden anstelle von genauen Werten wie U = 15,3V qualitative Werte wie „normale Spannung“ oder [U] = [14V - 18V] benutzt, was bedeutet, dass für die Spannung U lediglich bekannt ist, dass sie einen Wert aus dem Intervall von 14V bis 18V annimmt. Die Methode der qualitativen Modellierung bietet geeignete Abstraktionsebenen, Modellierungsparadigmen und Schlussverfahren, um dieses vorhandene Wissen verarbeiten zu können ([22]). Die Betrachtung des qualitativen Verhaltens eines Systems im Diagnoseverfahren ermöglicht außerdem Aussagen größerer Robustheit und Stabilität gegenüber Parameterabweichungen [92], [149]. Aus diesen Gründen wird in dieser Arbeit die qualitative Modellform für die Modellbeschreibung gewählt.

3.1.3

Stationäre Betrachtung

Stationäre und transiente Phasen durchläuft ein mechantronisches System immer abwechselnd. Dabei verhält sich das System in der stationären Phase im Gegensatz zur transienten Phase stabil, das heißt, die Zustandswahrscheinlichkeit während der stationären Phase ist relativ unabhängig von der Zeit, während der transienten Phase hingegen zeitabhängig. Die Vorgehensweise in der Werkstatt ist eher stationärer Natur; in vielen Fällen wird das zu diagnostizierende System in eine stationäre Phase gebracht, bevor die manuellen Messungen beziehungsweise das Auslesen von systemeigenen Sensoren durchgeführt werden. Kommt zum Beispiel ein Kunde mit dem Symptom „Starter dreht, Motor springt nicht oder schlecht an“ in die Werkstatt, ist eine mögliche Diagnose zur Erklärung dieser Symptome der anormale Istwert des Kraftstoffdrucks in der Vorlaufleitung des Kraftstoffsystems. Die Vorgehensweise des Werkstattpersonals zur Überprüfung des Kraftstoffdrucks läuft folgendermaßen ab: • Das Fahrzeug in Leerlauf bringen • Bei abgezogenem Unterdruckschlauch Istwert mit Sollwert vergleichen • Bei aufgestecktem Unterdruckschlauch Istwert mit Sollwert vergleichen • Istwert mit Sollwert des Haltedrucks nach 10 Minuten vergleichen. Bei dieser Vorgehensweise ist deutlich zuerkennen, dass die Druckmessungen im zu diagnostizierenden System innerhalb der stationären Phase (in diesem Fall der Leerlaufphase) durchgeführt werden. Bei Symptomen, die in der transienten Phase auftreten, wird die zeitliche Abhängigkeit des Systemverhaltens in der Werkstatt durch Komponenten- und Stellgliedtests bei dem Diagnosevorgang abgedeckt. Zur Veranschaulichung wird hierfür das Symptom „Schlechte Gasannahme, Übergangsfehler“ betrachtet. Eine Ursache des Symptoms ist das Fehlverhalten der Elektrokraftstoffpumpe. Zur Überprüfung der Pumpe wird das Werkstattpersonal die Kennlinie

44

KAPITEL 3. WISSENSERHEBUNG

des Systemdrucks im Verhältnis zur Fördermenge (Abbildung 3.1) bei stehendem Motor mit dem tatsächlichen Verlauf abgleichen. Die Feststellung der Abweichung, soweit diese existiert, erfolgt manuell durch das Werkstattpersonal oder automatisiert durch Abgleich per Datenanalyse. Bei diesem Vergleichsvorgang ist die zeitliche Abhängigkeit berücksichtigt worden. Bei dem Beispiel der Elektrokraftstoffpumpe verhält sich im normalen Fall die Fördermenge der Pumpe über die Zeit proportional zu dem Systemdruck.

Abbildung 3.1: Kennlinien der Elektrokraftstoffpumpe beim Golf III 1.8 (Quelle: BOSCH Group) Das oben beschriebene Beispiel verdeutlicht, dass der zeitliche Aspekt in das Modell eingebunden werden muss, um das Verhalten in der transienten Phase zu modellieren. Diese Erweiterung erlaubt eine Simulationsmöglichkeit und damit die Vorhersagemöglichkeit des Modells, bedarf aber erheblicher Erweiterungen in verschiedenen Modellierungsebenen: Komponentenmodell, Subsystem- sowie Systemmodell. So erhöht sich der Modellierungsaufwand auf ein Vielfaches und das Verhältnis zwischen Aufwand und Nutzung ist wirtschaftlich nicht vertretbar. Da in den meisten Fällen die Symptome bereits bei dem Werkstattbesuch vorliegen und die Reproduzierbarkeit der Symptome in bestimmten Betriebszuständen, bei denen die Symptome aufgetreten sind, in freien Werkstätten möglich ist, wird in dieser Arbeit nur die symptomorientierte Diagnose und keine präventive Diagnose beziehungsweise Überwachung mit Risikoanalyse berücksichtigt. Diese symptomorientierte Diagnose reduziert damit nicht nur das Modellwissen hinsichtlich des zeitlichen Verhaltens (System im quasi stationären Zustand) sondern auch den Umfang der Diagnosealgorithmen, weil keine Algorithmen für die Erkennung von Trends, die in Zukunft zu Fehler führen können, erforderlich sind. Weiterhin werden in dem Diagnosevorgang Fragen zur Auftrittshäufigkeit des Symptoms gestellt (reproduzierbare Symptome). Mit solchen Fragen wird der zeitliche Aspekt zum Teil berücksichtigt. Diese Berücksichtigung äußert sich in der Auswertung der verdächtigen Komponenten zur Symptomerklärung.

3.1.4

Berücksichtigung des Fehlermodus bei der Modellierung

Da in dieser Arbeit die Verhaltensbeschreibung über die Komponenten im System und das System in qualitativer Form unter stationärer Betrachtung erfolgen soll, leiden die Diagno-

3.1. ANFORDERUNGSANALYSE DES DIAGNOSEMODELLS

45

seergebnisse bei der Schlussfolgerung an Effizienz und bei der Fehlerlokalisierung an Ungenauigkeit. Die Integration von konkreten Fehlerzuständen im Modell kann oft irrelevante verdächtige Komponenten aussortieren und von der weiteren Berechnung ausschließen (vgl. [30], [31], [78], [134]). Sie verringert die Komplexität der Diagnoseberechnung, der konkrete Fehler einer Komponente kann bei der Erklärungskomponente des Diagnosesystems angegeben werden. Deshalb ist diese Integration bei dem zu entwickelnden Modellierungstool notwendig und als Muss-Kriterium zu betrachten. Nicht garantiert werden kann jedoch, dass die verwendeten Modelle hinsichtlich ihres Fehlverhaltens vollständig sind. Vollständigkeit bedeutet in jedem Fall für eine Komponente oder ein System, dass alle Fehlermodelle im Diagnosemodell vorhanden sind. Die Verwendung von konkreten Fehlerzuständen kann deshalb nur einen Teil der Probleme hinsichtlich Effizienz und Genauigkeit des modellbasierten Ansatzes lösen; zusätzliche Erweiterungen sind notwendig. Eine mögliche Ergänzung ist die Verwendung eines unbekannten Fehlerzustands. Diese Erweiterung garantiert die Vollständigkeit der Modelle in Bezug auf Fehlverhalten, ist aber keine Abhilfe bei der Fehlerlokalisierung. Weiterhin darf der unbekannte Fehlerzustand erst verwendet werden, wenn kein anderes Fehlermodell die Verhaltensabweichung erklären kann, sonst wirkt er sich negativ auf die Effizienz aus.

3.1.5

Verwendung zusätzlichen heuristischen Wissens

Zur Verbesserung der Fehlerlokalisierung ist neben der Erweiterung von konkreten Fehlerzuständen die Anbindung von heuristischem Wissen über Komponenten und Systeme nötig. Diese Anbindung ermöglicht eine Priorisierung der verdächtigen Komponenten zum einen durch die Kosten der Komponentenprüfung und zum anderen durch die Ausfallwahrscheinlichkeiten der Komponenten im System. Zudem kann durch die Angabe der Häufigkeit der konkreten Fehlerzustände einer Komponente der Diagnosealgorithmus die Komponenten, die für die Erklärung der Symptome wegen der nicht vorhandenen beziehungsweise geringen Häufigkeit der konkreten Fehlerzustände selten in Frage kommen, vorübergehend im ersten Durchlauf ausschließen. Auf die Möglichkeit zur Anbindung solcher heuristischen Diagnoseinformationen wird im Folgenden eingegangen. Das heuristische Diagnosewissen in freien Werkstätten stammt aus unterschiedlichen Quellen - zum Beispiel aus Onboard-Diagnose-Informationen oder aus Erfahrungswissen beziehungsweise direkt aus Werkstätten. Dieses heuristische Teilwissen gibt das unterschiedliche Wissen über Komponenten (zum Beispiel: Ausfallwahrscheinlichkeit, Test- beziehungsweise Prüfkosten, Prüfzeit) und den Kausalzusammenhang in Form von Wenn-Dann-Regeln zwischen Symptom und Ursache (insbesondere für Fehlercodes) wieder. Das benötigte Diagnosewissen, das in der Werkstatt bei dem Diagnosevorgang verwendet wird, soll aus all diesen diagnoserelevanten Informationen zusammengesetzt werden. Aufgrund des vorhandenen Fehlercodes beziehungsweise der Eigendiagnosemöglichkeiten des Steuergeräts und weil die Diagnoseinformationen des Fehlercodes häufig in der Wenn-DannForm interpretierbar sind, erfolgt in dieser Arbeit die Kombination zweier Diagnoseparadigmen: Modell- und regelbasierter Ansatz. Diese Kombination (im Folgenden als hybrider Ansatz bezeichnet) ermöglicht die Ausnutzung des vorhandenen Diagnosewissens, das durch langjährige Erfahrung in den Werkstätten gesammelt wurde, des physikalischen Verhaltens

46

KAPITEL 3. WISSENSERHEBUNG

und der Strukturen, die im Modell abgebildet sind. Bei seltener Fehlerursache ist eine Diagnose mit Unterstützung des Modellwissens wegen der Erhöhung der Modellkomplexität kaum zu erwarten; zum Beispiel kann eine der Ursachen des Symptoms „Klingeln und Klopfen bei Beschleunigung“ die Änderung der Brennraumgeometrie sein. Da diese Diagnose sehr selten vorkommt, ist es empfehlenswert, dieses Diagnosewissen in Form von Wenn-Dann-Regeln zu formulieren und in geeignete Modellierungsebenen einzubinden. Damit ist eine Reduzierung der Modellkomplexität möglich, weil bei seltener Fehlerursache, welche durch Modellwissen nicht abgedeckt ist, das Modell nicht erweitert werden muss. Bei der Diagnose in der freien Werkstatt steht das Werkstattpersonal oft vor folgender Situation: Es gibt eine Menge verdächtiger Komponenten und die Messmöglichkeiten sind ausgeschöpft. Die Entscheidung, welche Komponente zuerst geprüft werden muss, obliegt dem Werkstattpersonal. Mit Hilfe der Integration von Ausfallwahrscheinlichkeit, allgemeiner Wirkung der Komponente auf bestimmte Systemgrößen und Verschleißzustand der Komponenten im System kann die Lokalisierung der fehlerhaften Komponenten im Schlussfolgerungsprozess automatisiert und gegebenenfalls verbessert werden. Weitere Informationen wie Test- beziehungsweise Prüfkosten, Prüfzeit, etc. können die Effizienz des Diagnosevorgangs erheblich steigern. Die Zusammenführung dieser Informationen wird durch einen Identifizierungscode der Komponenten beziehungsweise des Systems durch Datenbankabfrage realisiert und bei der Parametrisierung des Modells durchgeführt.

3.2

Inhalt des Diagnosemodells

Auf Grund der angewendeten Dekompositions- und Kompositionsansätze bei der Konstruktion des Fahrzeugs 1 besteht das Diagnosemodell eines Fahrzeugs aus mehreren Modellen der fahrzeugeigenen mechatronischen Systeme. Ein mechatronisches System wird in dieser Arbeit durch ein Diagnosemodell dargestellt. Dieses Modell ist in Abbildung 3.2 mittels der Klasse VollständigesSystem repräsentiert. Nachfolgend werden die Assoziationen, die Kardinalitäten und die Generalisierung beziehungsweise Spezialisierung der Klassen in dem Klassendiagramm (Abbildung 3.2) kurz erläutert. Anschließend wird auf die Inhalte der Klassen eingegangen. Da ein Teil des Diagnosewissens fahrzeugabhängig ist, existieren mehrere 1:n Beziehungen zwischen dem Modell eines Fahrzeugs und verschiedenen fahrzeugspezifischen Diagnosewissen: • Testwissen, • Messungswissen, • Heuristisches Komponentenwissen, • Ersatzteilwissen, • Komponentenzusatzwissen. Heuristisches Komponentenwissen, Ersatzteilwissen und Komponentenzusatzwissen sind komponentenbezogene Diagnosewissen. Daher gilt eine 1:1 Beziehung mit der zugehörigen Komponente. 1

Die Klassen zur Abbildung des Diagnosewissens werden in diesem Abschnitt bei Ersterwähnung kursiv dargestellt

47

3.2. INHALT DES DIAGNOSEMODELLS

QualitativerWert QualitativerWert

Attribut

QualitativerWert

QualitativerWert

Beeinflussungstabelle 1 *

Einheit

QualitativerWert * Parameterbelegung

1

*

*

* 1

1

* * Parameter

Transportobjekt

Wertebereich * * 1 Schnittstelle

* QualitativerWert

1

InterneVariable

Verhaltenstabelle

Richtung Visualisierungstyp

Typ 1 1 QualitativesVerhalten

* 1 1 Komponente

* 1

Betriebszustand

Komponentenschnittstelle

Identifikation 1 1 1

1 * 1

*

1

1 * 1 PhysikalischesSystem 1

1

Beanstandung *

*

1 * VollständigesSystem

* Systemschnittstelle

*

1

1

Fehlercode

1 *

1

*

1

*

* *

1

Test

Messung

1

1

Komponententest

Stellgliedtest

1 *

1 1

Offboardmessung

1 1 1 Fahrzeug

Testwissen Sicherheitshinweis Prüfvoraussetzung Testauswertung

1

*

*

Fahrzeugidentifikation 1 * Ersatzteilwissen

* 1 HeuristischesKomponentenwissen Ausfallwahrscheinlichkeit Kosten Verschleißzustand 1

Bestellnummern Lagerbestand Lieferzeit Preis

Onboardmessung 1 Messungswissen

1

*

1

Instruktion Sollwertbereich

* Komponentenzusatzwissen

1

Funktionsbeschreibung Einbaulage EinUndAusbauInstruktion Instandsetzung

Abbildung 3.2: Bestandteile des Basis- und des vollständigen Diagnosemodells

Das Testwissen wird einem bestimmten Test zugeordnet, wobei ein Modell des vollständigen Systems mehrere Tests enthält. Ein Test ist eine Generalisierung des Komponenten- und

48

KAPITEL 3. WISSENSERHEBUNG

Stellgliedtests. Analog dazu besitzt eine Messung das Messungswissen und ist die Generalisierung von Offboard - und Onboardmessung. Ein vollständiges System enthält natürlich auch mehrere Messungen. Wenn eine Komponente in dem Diagnosevorgang verdächtigt wird, muss die Möglichkeit gegeben sein, dass diese Komponente als fehlerhaft beziehungsweise fehlerfrei identifiziert werden kann. Aus diesem Grund existiert eine 1:n Beziehung zwischen Komponente und Test sowie zwischen Komponente und Messung. Neben Tests und Messungen beinhaltet ein Modell des vollständigen Systems mehrere Beanstandungen und Fehlercodes. Es gibt 1:n Beziehungen zwischen Fahrzeug und Fehlercode und zwischen Fahrzeug und Beanstandungen, weil Fehlercode beziehungsweise Beanstandung Fahrzeug abhängig sind. Dass ein Modell des physikalischen Systems sich in verschiedenen vollständigen Systemen befinden kann, wird durch die 1:n Beziehung dargestellt. Diese Beziehung beschreibt die Wiederverwendbarkeit des Modells. Es beinhaltet mehrere Komponenten, Systemschnittstellen und gegebenenfalls Subsysteme. Analog zum System besitzt eine Komponente mehrere Komponentenschnittstellen. Die Klasse Schnittstelle ist die Generalisierung der Komponenten- und Systemschnittstelle. Die Verbindung zwischen den Schnittstellen wird durch die n:n Beziehung beschrieben. Eine Schnittstelle kann ein beziehungsweise mehrere Transportobjekte enthalten und ein Transportobjekt enthält mehrere Attribute. Die internen Eigenschaften einer Komponente werden durch mehrere interne Variablen definiert. Interne Variablen und Attribute bilden Parameter, die für die Diagnose notwendig sind. Die Wertebelegungen dieser Diagnoseparameter werden durch 1:n Beziehungen zwischen Beanstandung, Fehlercode, Test beziehungsweise Messung und Parameter beschrieben. Das qualitative Verhalten einer Komponente ist betriebszustandabhängig. Daher besitzt eine Komponente mehrere qualitative Verhalten und jedes Verhalten eine 1:1 Beziehung zu der Verhaltenstabelle. Eine Verhaltenstabelle hat mehrere Zeilen und eine Zeile wird durch die Parameterbelegungen repräsentiert. Die Inhalte einer Parameterbelegung bestehen aus mehreren Parameter und den zugehörigen qualitativen Werten. Eine Komponente beeinflusst durch ihre vordefinierten Funktionen bestimmte Ausgangsattribute. Dieses Wissen ist einfach zu erheben und eine Möglichkeit zur Priorisierung der verdächtigen Komponenten in einem Diagnoseschritt. Die Klasse Beeinflussungstabelle ist für die Erhebung dieses Wissens zuständig. Ein Fahrzeug wird durch die Fahrzeugidentifikation eindeutig identifiziert. Diese Eigenschaft legt fest, welche Fahrzeugtypen dieses Modell abdeckt. Dabei beinhaltet die Identifikation mehrere charakterische Merkmale des Fahrzeugs, zum Beispiel Fahrzeughersteller, Fahrzeugart (PKW, LKW, Motorad, etc.), Antriebsart (Benzin, Diesel, Elektro, Gas, Hybrid), Motorkenndaten (Motorhersteller, Motorkennbuchstabe, Hubraum, Motorleistung), Antriebsart, Länderausführung, Baujahr, Modelljahr, Fertigungsdatum, etc. Neben der Fahrzeugidentifikation besitzt ein Fahrzeugmodell verschiedenes fahrzeugbezogenes Diagnosewissen. Dabei beinhaltet das heuristische Komponentenwissen folgende Informationen über die eingebauten Komponenten: • Ausfallwahrscheinlichkeit der systemeigenen Komponenten: Diese Information kann aus verschiedenen Quellen erhoben werden. Zum einen können sie aus der Informationsrückführung aus dem Feld gewonnen, zum anderen aus dem Verkauf der Ersatzteile abgeleitet werden. • Kosten: Diese Optimierungsgröße besteht zum einen aus Test-, Prüf- sowie Messkosten,

3.2. INHALT DES DIAGNOSEMODELLS

49

zum anderen aus Test- beziehungsweise Prüfzeit, da die Information über den benötigten Aufwand in Form von Zeit in Kosten überführt werden kann. • Verschleißzustand der Komponenten: Wenn eine oder mehrere Komponenten des Systems Verschleißteile sind, können die Angaben über den Verschleißzustand für die Priorisierung der Prüfung in dem Diagnosevorgang genutzt werden. Die Effizienz der Diagnose kann gesteigert werden, wenn dem Werkstattpersonal weitere hilfreiche Hinweise zur Verfügung gestellt werden. In dieser Arbeit wird dieses Wissens als Komponentenzusatzwissen bezeichnet und besteht aus folgenden Informationen: • Einbaulage: Die Effizienz der Komponentenprüfungen sowie der Durchführung von manuellen Messungen im Diagnosevorgang ist abhängig von der Beschreibung der Einbaulage und von der Einbaulage selbst. Die Einbaulage kann entweder textuell und/oder mittels Bildern erfolgen. • Ein- und Ausbauinstruktion: Diese Informationen beschreibt, wie eine Fahrzeugkomponente aus- beziehungsweise eingebaut werden kann. Dieses Wissen reduziert die möglichen entstehenden Zusatzkosten durch Verringerung des Aufwands und Vermeidung von Beschädigungen beim Ein- und Ausbau der Komponenten. • Instandsetzung: Die erforderlichen Tätigkeiten, um eine Komponente wieder in den funktionsfähigen Zustand zu versetzen, werden als Hinweistexte beschrieben. Das Ersatzteilwissen ist bei dem Reparaturvorgang unabdingbar und bei vielen existierenden Diagnosesystemen ein Bestandteil. Im Folgenden werden nur die wesentlichen Inhalte des Ersatzteilwissens erläutert: • Bestellnummern: Mit dieser Information kann das Werkstattpersonal das Ersatzteil bestellen, wenn das Teil nicht vorrätig ist. • Lagerbestand und Lieferzeit: Die Standzeit bei der Reparatur ist abhängig von der Verfügbarkeit der Ersatzteile im Lager. • Preis: Die Höhe der Reparaturkosten ist zum einen von den Stundenkosten, die während der Diagnose und Reparatur anfallen,zum anderen vom Preis des Ersatzteils abhängig. Eine Auskunft darüber ist für den Kunden, der in die Werkstatt kommt, wichtig und muss immer gegeben werden. Weiteres fahrzeugspezifisches Diagnosewissen, das die Durchführung und Auswertung von Tests und Messungen ermöglicht, ist direkt an das Fahrzeug gebunden: • Messungswissen: – Instruktion: Diese Information beinhaltet den Anschlussplan der Komponenten und den Anschluss von Testgeräten und Werkzeugen. Je nach Art der Komponenten kann es ein elektrischer, hydraulischer oder pneumatischer Plan sein. Die Darstellung erfolgt vornehmlich anhand von Bildern. Zum Beispiel werden bei einem elektrischen System beziehungsweise einer elektrischen Komponente die Klemmenbelegungen dargestellt. Dabei werden sowohl die Einbaulage der Klemmen und damit die Messpunkte innerhalb der Steckanschlüsse als auch die funktionale Belegung der elektrischen Klemmen beschrieben.

50

KAPITEL 3. WISSENSERHEBUNG – Sollwertbereich: Soll- bezeihungsweise Richtwerte sind erforderlich, um Messergebnise zu bewerten. • Testwissen: – Sicherheitshinweis: Dieser beschreibt mögliche Gefahren für Personen, Sachwerte und Umwelt. Für sicherheitskritische Systeme wie zum Beispiel AirBag, ABS, ESP sind Hinweise über Eingriffsmöglichkeiten in das System zwingend erforderlich. – Prüfvoraussetzung: Die Einhaltung der Prüfvoraussetzung ist notwendig, um eine korrekte Schlussfolgerung zu ziehen. Es existiert zum Beispiel bei vielen Komponenten und Systemen eine Grundeinstellung und nur wenn die Grundeinstellung richtig eingestellt ist, kann die Prüfung beziehungsweise der Test durchgeführt werden. – Testauswertung: Die Beschreibung, wie ein Test oder eine Prüfung durchzuführen und wie die Ergebnisse zu bewerten sind, ist in der Testauswertung enthalten. Hierbei ist zu beachten, dass ein Test beziehungsweise eine Prüfung mehrere Testoder Prüfschritte beinhaltet.

Da das systemeigene Komponentenmodell der Hauptbestandteil des Systemmodells ist, soll auf die Modellierung der systemeigenen Komponenten vor der Modellierung des Systemmodells eingegangen werden. Im Folgenden werden die Inhalte der Klassen in einem Klassendiagramm kurz zusammengefasst. Um ein Modell des Systems aufzustellen, muss das System analysiert werden. Die Analyse erfolgt über zwei Betrachtungsweisen - von innen und von außen. Bei der Betrachtung von innen bietet die Darstellung des Systems durch seine Subsysteme, Komponenten und Verbindungen zwischen den Komponenten Erklärungen in unterschiedlicher Detailtiefe, wie die Eingangsgrößen in die gewünschten Ausgangsgrößen umgewandelt oder transformiert werden oder wie umgekehrt die Ausgangsgrößen aus unterschiedlichen Konstellationen der Eingangsgrößen entstehen. Demzufolge besteht ein System aus folgenden Elementen: • Subsysteme: Um ein komplexes physikalisches System abzubilden hat der Modellierer die Möglichkeit, dieses in mehrere Subsysteme zu unterteilen. Dies verringert nicht nur die Komplexität des Systems, sondern erhöht auch die Wartbarkeit des Modells. Die Subsysteme beinhalten wiederum einzelne Komponenten und deren Verbindungen. • Komponenten: Das Modell des realen Systems wird aus einzelnen Komponentenmodellen aufgebaut. Dabei ist eine Komponente die kleinste, in der Werkstatt austauschbare Einheit. Bei diesen Modellen muss neben den Schnittstellen auch das Verhalten der einzelnen Komponente spezifiziert werden. So stellen Kraftstoffleitung, Kraftstofffilter, Überströmventil, Hochdruckpumpe, Injektor und Rücklaufbehälter zum Beispiel Komponenten des Dieselsystems dar. • Verbindungen: Die Verbindungen beschreiben die Interaktion der einzelnen Komponenten untereinander. Zu beachten gilt es, dass die Verbindungen nicht Verbindungstücke (Schläuche etc.) oder Leitungen des realen Systems darstellen. Vielmehr sind Verbindungsstücke oder Leitungen des realen Systems als Komponenten zu interpretieren.

3.2. INHALT DES DIAGNOSEMODELLS

51

Analog zum System gibt es bei einer Komponente auch eine innere und eine äußere Betrachtungsweise. In dieser Arbeit enthält das Modell einer systemeigenen Komponente folgende Inhalte: • Schnittstellen, mit denen eine Komponente mit seinen benachbarten Komponenten oder seiner Umgebung interagiert. Neben der Flussrichtung beinhaltet eine Schnittstelle ein oder mehrere Transportobjekte. Das Transportobjekt hat die Form von Materialien beziehungsweise Signalen, die hinein beziehungsweise aus der Komponente heraus fließen. Daher besitzt das Transportobjekt ein oder mehrere Attribute, die die physikalischen Eigenschaften des Objekts beschreiben. Zum Beispiel besteht das Transportobjekt „Luft“ aus mehreren Attributen wie Druck, Temperatur, Massenfluss, etc. • Interne Funktions-, Zustands- und Fehlervariablen der Komponente, die die internen Komponenteneigenschaften oder Fehlerzustände beschreiben. • Verhaltenstabelle, die das Nominal- und Fehlverhalten der Komponente in unterschiedlichen Betriebszuständen beschreibt. Eine Komponente kann in unterschiedlichen Betriebzuständen, zum Beispiel Leerlauf, Teillast, Volllast unterschiedliche Parameterbelegungen zeigen. Eine Parameterbelegung beschreibt eine Zeile der Verhaltestabelle und beinhaltet die Zuweisungen der Parameter und deren zugehörigen qualitativen Werte. Dabei ist ein Parameter Ein- oder Ausgangsattribut beziehungsweise eine interne Variable der Komponente. Für den systemübergreifenden Diagnosezweck liegt der Fokus der Betrachtung eines Systems auf dessen Übertragungsverhalten. Es stehen nicht die systemeigenen Komponenten und deren Interaktionen im Vordergrund der Betrachtung, sondern die Ein- und Ausgänge des Systems. Deswegen besteht ein Basismodell aus dem Modell eines System, dessen Schnittstellen und den Verlinkungen zwischen systemeigenen Komponenten und Systemschnittstellen. Diese Modellverlinkungen beschreiben die Zugehörigkeit der explizit modellierten Systemschnittstellen und der realen systemeigenen Komponentenschnittstellen. Systemschnittstellen sind mit den Komponentenschnittstellen verlinkt, die nicht mit anderen Komponentenschnittstellen durch Verbindungen in das Modell des Systems eingebunden sind. Im realen System sind sie die Systemgrenze und bilden damit die realen Systemschnittstellen. Mit der expliziten Modellierung dieser Art von Schnittstellen legt der Modellierer nicht nur fest, wie das System mit seiner Umgebung beziehungsweise benachbarten Systemen interagieren kann, sondern auch die Systemgrenze. Durch die Anforderung der Abbildung verschiedener diagnoserelevanter Informationen aus Onboard- und Offboard-Quellen muss das Basismodell weitere Diagnoseinformationen beinhalten. Die Onboard- und Offboard-Messungen sollen durch den Modellierer im Modell abgebildet werden: • Onboard-Messung: Die Messergebnisse dieser Messungen werden von Sensoren, die im System verbaut sind, geliefert. • Offboard-Messung: Ein Beispiel dafür ist die Förderdruckprüfung im KraftstoffNiederdruck-Kreislauf des Dieselsystems. Als externes Messgerät kommt ein Manometer zum Einsatz, das mit zusätzlichen Prüfleitungen zwischen dem Kraftstofffilter und der Hochdruckpumpe angeschlossen wird. Mit Hilfe der Messwerte, die wahlweise zu hoch,

52

KAPITEL 3. WISSENSERHEBUNG zu niedrig oder normal sein können, werden geeignete Fehlerhypothesen mittels Diagnosealgorithmen gestellt.

Die Lokalisierung der verdächtigen Komponenten in der Werkstattdiagnose stützt sich nicht nur auf Messergebnisse, sondern auch auf weitere Diagnoseinformationen, die speziell in der Offboard-Diagnose verfügbar sind. Diese Informationen stammen aus zwei unterschiedlichen Quellen: • Fehlercodes: Dies sind Informationen, die aus den Fehlercodetabellen der Steuergerätdiagnose ausgelesen werden. Hier bedarf es einer Unterscheidung zwischen Fehlercodes, die unmittelbar auf Komponenten zeigen und Fehlercodes, die auf physikalische Größen zeigen. Ein Beispiel für einen Fehlercode, der auf eine Komponente deutet, stellt der Fehlercode „P2643 - Raildrucküberwachung Tank leer“ dar. Diese Information kann als Regel für die Diagnose erfasst werden. Fehlercodes, die auf physikalische Größen zeigen, treten zum Beispiel bei der Überwachung des Ladedrucks des Luftsystems auf: „P1470 Ladedruckregelung Druck zu hoch“ oder „P2632 - Ladedruckregelung Maximalwert überschritten“. Diese Art des Fehlercodes bedarf einer Zuordnung des qualitativen Werts des Diagnoseparameters. Die Parameter- und Wertezuordnung obliegt dem Modellierer. • Beanstandung: Subjektive Betrachtungen des Kunden beziehungsweise des Werkstattpersonals sind in Form von verbalen Aussagen wie „Unruhiger Leerlauf“, „Ungenügende Motorleistung“, „Fehlzündung bei konstanter Drehzahl“, „Klopfen beim Beschleunigen“, „Kraftstoffverbrauch zu hoch“ oder „Beschleunigungsloch“ vorhanden. Analog zum Fehlercode soll die Zuordnung der Beanstandung zu Diagnoseparametern mit qualitativen Werten erfolgen und als Diagnoseregel aufgenommen werden. Der Test einer oder mehrerer Komponenten in einem Diagnosevorgang ist unverzichtbar bei der Verdachtsprüfung beziehungsweise Verdachtsbestätigung. In der Werkstattdiagnose existieren zwei Arten von Tests: • Stellgliedtest: Dies ist ein Test, bei dem eine gezielte Anregung einer Regelstrecke, die im System vorkommt, über einen oder mehrere systemeigene Aktoren vorgenommen wird. Als Ergebnis liefert der Test die Abweichung zwischen dem tatsächlichen Verhalten und dem erwarteten Verhalten der Regelstrecke. Im Fall einer fehlerfreien Regelstrecke ist die Abweichung gleich null. Dann können die Komponenten, die Teil dieser Regelstrecke sind, als fehlerfrei angenommen werden. Die Voraussetzung für diese Folgerung ist die Anregung mit Signalen, unter denen sich alle Fehler im Verhalten äußern. • Komponententest: Beim Komponententest wird das Testobjekt ohne Wechselwirkungen mit benachbarten Komponenten geprüft. Somit können auftretende Symptome eindeutig auf die getestete Komponente zurückgeführt werden. Ziel dieses Tests ist es, zu prüfen, ob die verdächtige Komponente die spezifizierten funktionalen Anforderungen erfüllt. Eine Leckage-Prüfung einer Kraftstoffleitung ist beispielsweise ein Komponententest. Durch die Modellierung der Parameter- und Komponentenzuordung sowie die Abbildung der Diagnoseregel bei Fehlercodes beziehungsweise Kundenbeanstandungen eixistieren mehrere Verlinkungen in dem Basismodell:

53

3.3. KOMPONENTENMODELLIERUNG

• Verlinkungen zwischen systemeigenen Komponenten und Onboard-DiagnoseInformationen: Diese Art der Verbindungen beschreiben die Zusammenhänge zwischen Systemkomponenten und Fehlercodes oder Stellgliedtests. • Verlinkungen zwischen systemeigenen Komponenten und Offboard-DiagnoseInformationen: Die Berücksichtigung der weiteren Messmöglichkeiten, der Komponententests sowie der subjektiven Betrachtungen im Diagnosevorgang wird mit dieser Art der Verbindungen im Modell abgebildet.

3.3

Komponentenmodellierung

Da systemeigene Sensoren alle Eigenschaften systemeigener Komponenten aufweisen und im Vergleich zu anderen Systemkomponenten weitere Rollen bei dem Diagnosevorgang übernehmen, erfolgt als erster Schritt bei der Modellierung der Systemkomponenten die Festlegung verschiedener systemeigener Komponentenarten (Tabelle 3.1). Systemkomponenten

Bezeichnung

Sensor

Tankfüllstand, Kraftstofftemperatursensor, Drucksensor

Aktor

Kraftstoffüberströmventil, Hochdruckpumpe, Injektor

Passiv

Tank, Kraftstoffleitung, Kraftstofffilter, Rücklaufbehälter

Tabelle 3.1: Verschiedene reale Komponentenarten im Kraftstoffsystem

Neben Sensoren, die verschiedene Messgrößen erfassen, existieren im System Aktoren und passive Komponenten. Ein Aktor wandelt die Eingangsgrößen in andersartige Ausgangsgrößen um, womit bestimmte Funktionen des Systems realisiert werden. Passive Komponenten sind Systemkomponenten, die keine Messsignale liefern und nicht aktiv gesteuert werden können, zum Beispiel Behälter, Verbindungen jeglicher Art (elektrisch, mechanisch, hydraulisch, etc.). Es seien mit: COM - Menge aller systemeigenen Komponenten SEN - Menge aller systemeigenen Sensoren ACT - Menge aller systemeigenen Aktoren P AS - Menge aller systemeigenen passiven Komponenten in einem System, das zu modellieren ist, dann gilt: COM =SEN ∪ACT ∪P AS. Wenn comk das k-te systemeigene Komponentenmodell ist, das im Systemmodell abgebildet wird, dann gilt: comk ∈ COM . Aus der Diagnoseanforderung und den Reparaturmöglichkeiten folgt, dass eine Komponente eine kleinste austauschbare Einheit im System ist. In Abbildung 3.3 ist das Komponentenklassendiagramm dargestellt. Dabei sind alle wesentlichen Klassen, die zur Beschreibung des qualitativen Verhaltens einer systemeigenen Komponente notwendig sind, aufgezeigt. Nachfolgend werden all diese Klassen detailliert vorgestellt. Abschließend wird im letzten Abschnitt dieses Kapitels die Darstellung eines beispielhaften Objektsdiagramm zur Erläuterung des Modellierungskonzepts beschrieben.

54

KAPITEL 3. WISSENSERHEBUNG

Verhaltenstabelle 1

Beeinflussungstabelle

Komponente

1

*

Identifikation 1 * Schnittstelle

Verhaltenszustand

1 1 QualitativerWert 1 * QualitativesVerhaltensmodell Parameter

1 1 1

*

Wertebereich

Betriebszustand

1

*

Transportobjekt

Attribut 1 *

Einheit

InterneVariable * Typ

Abbildung 3.3: Klassendiagramm einer systemeigenen Komponente

3.3.1

Komponentenschnittstelle

Nach der Festlegung von verschiedenen systemeigenen Komponentenarten erfolgt die Festlegung der realen und virtuellen Schnittstellen der einzelnen Komponenten. Dabei ermöglichen die realen Schnittstellen die Interaktion und den Informationsaustausch zwischen den systemeigenen Komponenten untereinander sowie zwischen den Systemschnittstellen und Komponenten. Durch virtuelle Schnittstellen kann die Verbindung zwischen systemeigenen Komponenten und virtuellen beziehungsweise externen Komponenten realisiert werden. Es seien mit: P ORTk - Menge aller Schnittstellen einer Komponente comk P ORTkreal - Menge aller realen Schnittstellen der Komponente comk P ORTkvir - Menge aller virtuellen Schnittstellen der Komponente comk portl - Die l-te Schnittstelle einer Komponente comk . Dann gilt: portl ∈P ORTk P ORTk =P ORTkreal ∪P ORTkvir . Die Spezifikation der Schnittstelle erfolgt durch die Festlegung der Flussrichtung sowie die Transportobjekte, die diese Schnittstelle beinhaltet. Es gibt nur zwei mögliche Flussrichtungen: „In“ und „Aus“ (Tabelle 3.2). Es seien mit: P ORTkreal,in - Menge aller realen Eingangsschnittstellen der Komponente comk P ORTkreal,out - Menge aller realen Ausgangsschnittstellen der Komponente comk P ORTkvir,in - Menge aller virtuellen Eingangsschnittstellen der Komponente comk P ORTkvir,out - Menge aller virtuellen Ausgangsschnittstellen der Komponente comk . Dann gilt: P ORTkreal =P ORTkreal,in ∪P ORTkreal,out P ORTkvir =P ORTkvir,in ∪P ORTkvir,out . Für eine Schnittstelle portl existiert eine Menge der Transportobjekte T RANl , die sich in dieser Schnittstelle befinden. Die Zuweisung der Transportobjekte auf eine Schnittstelle erfolgt durch den Modellierer. In den meisten Fällen beinhaltet eine Schnittstelle ein Transportobjekt. Dabei beschreibt ein Transportobjekt das Material, das durch die Schnittstelle in die Komponente einfließt oder aus der Komponente herausströmt. Bei dem Luftsystem wäre dies zum Beispiel Frischluft, im Kraftstoffsystem Diesel oder Benzin und im Abgassystem Abgas. Transportobjekte in Schnittstellen sind nicht nur Materie, sondern auch Mess- und Steuersi-

55

3.3. KOMPONENTENMODELLIERUNG

Systemkomponenten

Bezeichnung

Sensor

Temperatursensor

Aktor

Passiv

Schnittstellen Anzahl

Richtung

Transportobjekt

1

in

Temperatursignal

1

out

Temperatursignal

1

in

Ventilsteuerungssignal

1

in

Kraftstoff

1

out

Kraftstoff

1

in

Kraftstoff

1

out

Kraftstoff

Druckregelventil

Kraftstoffleitung

Tabelle 3.2: Systemeigene Komponenten und deren Schnittstellen gnale, welche für die Modellierung von Sensoren und Aktoren nötig sind. In Tabelle 3.2 werden einige Schnittstellen und deren zugehörige Transportobjekte von stellvertretenden Sensoren, Aktoren und passiven Komponenten des CP3-Kraftstoffsystems beschrieben. Es seien mit: T RANl - Menge aller Transportobjekte einer Schnittstelle portl tranm - Das m-te Transportobjekt einer Schnittstelle portl . Dann gilt: tranm ∈ T RANl . Transportobjekt

Attribut

Abk.

Einheit

CO

CO

mg/m3

X

Druck

P

Pa

X

HC

HC

%

X

Massenfluss

m

g/s

X

NOx

NOx

mg/m3

X

O2

O2

%

X

SOx

SOx

mg/m3

X

Staubgehalt

s

%

X

Temperatur

T

oC

X

Verschmutzungsgrad

V

%

Wassergehalt

W

%

Zündwilligkeit

Z

Dez.

Abgas

Kraftstoff

Luft

X

X

X

X X X

X

X

X X

X X

Tabelle 3.3: Einige Transportobjekte und einige ihrer Attribute Ein Transportobjekt wird durch dessen zugehörige Attribute spezifiziert. Die Attribute eines Transportobjekts sind die physikalischen Größen, die sich durch Systemsensoren oder durch externe Messgeräte bestimmen lassen. Durch Attribute werden die Eigenschaften der Transportobjekte beschrieben; Luft zum Beispiel durch verschiedene Größen wie Druck, Masse, Temperatur, Sauerstoffgehalt. Es seien mit:

56

KAPITEL 3. WISSENSERHEBUNG

AT Tm - Menge aller Attribute eines Transportobjekts tranm attn - Das n-te Attribut eines Transportobjekts tranm . Dann gilt: attn ∈ AT Tm . In Tabelle 3.3 sind einige Attribute von verschiedenen Transportobjekten dargestellt. Es gilt die Regel: Ein Attribut soll nur definiert werden, wenn sich durch Systemsensoren oder Messungen seine Größe ermitteln lässt. Ableitbare Attribute, die sich nicht durch Sensoren oder Messungen bestimmen lassen, sollen nicht definiert werden. Da die Werte eines Attributes in qualitativer Form {hoch, normal, niedrig} vorliegen, soll im Zuge der Spezifikation des Attributes die Zuweisung des Wertebereiches erfolgen. Zum Beispiel kann der Umgebungsdruck alle drei Werte {hoch, normal, niedrig} annehmen, der Staubgehalt der Umgebungsluft kann dagegen nur {hoch, normal} sein. Es seien mit: V ALatt n - Menge aller Wertebelegungen eines Attributes attn att valm - Die m-te Wertebelegung eines Attributes attn . att ∈ V ALatt . Dann gilt: valm n

3.3.2

Interne Variablen einer Komponente

Neben der Spezifikation der Komponentenschnittstellen müssen weitere Eigenschaften der Komponenten definiert werden, denn die Ausgangsgröße einer Komponente ist nicht nur von der Eingangsgröße abhängig. Im Beispiel des Kraftstofffilters ist der Verschmutzungsgrad im Kraftstoff vom Abscheidegrad des Kraftstofffilters abhängig. Eine weitere Aufgabe des Kraftstofffilters ist die Senkung des Wassergehalts. Der Wassergehalt des Kraftstoffs im Ausgang ist von dem W asserstand des Kraftstofffilters abhängig. Solche komponenteneigenen Attribute sind in dieser Arbeit als interne Funktionsvariablen definiert. Als formale Formulierung kann hierfür folgendes definiert werden: V ARkf unc - Menge aller internen Funktionsvariablen der Komponente comk varif unc - Die i-te interne Funktionsvariable der Komponente comk . Es gilt: varif unc ∈ V ARkf unc . Weil der Abscheidegrad bestenfalls der definierten Vorgabe entsprechen kann und bei aufgetretenem Fehler durch Kraftstoffverschmutzung der Abscheidegrad immer niedrig ist, kann der Wertebereich der internen Funktionsvariable Abscheidegrad nur zwei Werte annehmen {normal, niedrig}. Mit einer analogen Überlegung beträgt der Wertebereich der internen Funktionsvariable W asserstand {normal, niedrig}. Es seien mit: V ALfi unc - Menge aller Wertebelegungen einer internen Funktionsvariable varif unc valnf unc - Die n-te Wertebelegung einer internen Funktionsvariable varif unc . Dann gilt: valnf unc ∈ V ALfi unc . Viele Aktoren, wie zum Beispiel Drosselklappe, Injektor, AGR-Ventil, Druckregelventil, besitzen wegen ihrer Funktion definierte interne Zustände. Diese internen Zustände der Komponenten werden durch Steuersignale oder mechanische Steuerung geregelt, wobei die Komponente in Abhängigkeit des Steuerbefehls in verschiedene Zustände gesetzt wird. Dadurch verhält sich die Komponente je nach Zustand unterschiedlich. Diese Zustände müssen ebenfalls im Komponentenmodell abgebildet werden und werden in dieser Arbeit als interne Zustandsvariablen bezeichnet. Im Beispiel des Druckregelventils hat das Druckregelventil bei dem Druckregelungsvorgang im Normalfall zwei stationäre Zustände (Offen und Geschlossen) und zwei Übergangszustände (Öffnen und Schließen). Außer bei dem stationären Zustand Geschlossen

3.3. KOMPONENTENMODELLIERUNG

57

variiert bei allen anderen drei Zuständen der Ausgangsdruck in Abhängigkeit von den verschiedenen Eingangsgrößen und dem internen Verhalten des Ventils. Wegen der stationären Betrachtungsweise in der Werkstatt sollen die zwei stationären Zustände Offen und Geschlossen als Zustandsvariablen im Komponentenmodell des Druckregelventils definiert werden. Es seien mit: V ARksta - Menge aller internen Zustandsvariablen der Komponente comk varista - Die i-te interne Zustandsvariable der Komponente comk . Dann gilt: varista ∈ V ARksta . Da eine Komponente sich nicht gleichzeitig in verschiedenen stationären Zuständen befinden kann, soll bei der Modellierung beachtet werden, dass die Zustandsvariablen sich gegenseitig ausschließen können. Im Unterschied zu internen Funktionsvariablen wie Abscheidegrad und Wasserstand hat die Wertebelegung von internen Zustandsvariablen, die die Komponentenzustände beschreiben, den Charakter eines logischen Terms {true, f alse}. Es seien mit: V ALsta - Menge aller Wertebelegungen einer internen Zustandsvariable varista i valnsta - Die n-te Wertebelegung einer internen Zustandsvariable varista . Dann gilt: valnsta ∈ V ALsta i . Um das Nominalverhalten einer Komponente zu beschreiben, reicht die Spezifikation der Komponentenschnittstellen, der internen Funktionsvariablen und der internen Zustandsvariablen. Um das Fehlverhalten einer Komponente zu beschreiben, wird eine weitere interne Variablenart benötigt. Nachfolgend wird diese Art als interne Fehlervariable bezeichnet. Als Exempel kann hierfür weiterhin das Druckregelventil dienen. Zu beobachten ist, dass der Ausgangsdruck des Druckregelventils von mindestens drei weiteren Größen abhängig ist: • Federkraft der Druckfeder • Anziehungskraft des Elektromagnetfelds • Verstopfung. Ein mechanischer Fehler kann die Federkraft des Ventils beeinflussen. Ein elektrischer Fehler wirkt auf die Anziehungskraft des Ventil-Elektromagnetfelds. Eine weitere Abhängigkeit ist die mögliche Verstopfung des Ventils. Die drei Größen Federkraft, Anziehungskraft und Verstopfung sollen als interne Fehlervariablen im Modell definiert werden. Es seien mit: V ARkf aul - Menge aller internen Fehlervariablen der Komponente comk varif aul - Die i-te interne Fehlervariable der Komponente comk . Dann gilt: varif aul ∈ V ARkf aul . Die Wertebelegungen der internen Fehlervariablen sollen analog zu internen Zustandsvariablen und internen Funktionsvariablen durch den Modellierer festgelegt werden. Beispielsweise ist bei der internen Fehlervariablen Verstopfung die Wertebelegung {hoch, normal}. Das bedeutet: • V erstopf ung = hoch ⇔ Verstopfung vorhanden • V erstopf ung = normal ⇔ Verstopfung nicht vorhanden. Es seien mit: V ALfi aul - Menge aller Wertebelegungen einer internen Fehlervariable varif aul

58

KAPITEL 3. WISSENSERHEBUNG

valnf aul - Die n-te Wertebelegung einer internen Fehlervariable varif aul . Dann gilt: valnf aul ∈ V ALfi aul . Im Unterschied zu Funktionsvariablen und Zustandsvariablen können Fehlervariablen des Komponentenmodells mit Wahrscheinlichkeiten belegt werden. Die Belegung der Wahrscheinlichkeiten von aufgetretenen Fehlern erfolgt in dieser Arbeit in qualitativer Form. Hierfür werden Worte beziehungsweise Wortgruppen vordefiniert, zum Beispiel: „häufig“, „nicht häufig“, „selten“ und „sehr selten“. Mit Wissen über die Wahrscheinlichkeit des Fehlverhaltens der einzelnen Komponenten in einem System kann die Priorisierung der Komponentenprüfungen im Diagnosevorgang verbessert werden. Weiterhin benutzt die Erklärungskomponente des Diagnosetools die Fehlervariablen zur Beschreibung der Eigenschaften der Komponenten im System in Fehlerfällen. In Verbindung mit Beschreibungstexten können Fehlervariablen die Ursache des Fehlverhaltens erklären. Zum Beispiel kann eine Verstopfung des Ventils auf Ablagerung der Schmutzpartikel im Kraftstoff zurückzuführen oder eine niedrige Federkraft des Druckregelventils durch Materialermüdung beziehungsweise durch mechanische Fehler bedingt sein.

3.3.3

Qualitatives Verhaltensmodell

Zur Beschreibung des Verhaltens einer Systemkomponente bei einem bestimmten Betriebspunkt im nominalen Fall und im Fehlerfall werden die Transportobjekte und die zugehörigen Attribute der Schnittstellen sowie die Funktions- und Fehlervariablen genutzt. Es existiert für jedes Ausgangsattribut attout x einer Systemkomponente comk eine qualitative relationale out Übergangsfunktion fk,x , welche den relationalen Zusammenhang zwischen diesem Ausgangsattribut und einer Menge der Eingangsattribute AT Txin , einer Menge der Ausgangsattribute out , einer Menge der internen Funktionsvariablen V ARf unc , einer Menge der internen ZuAT T¬x x standsvariablen V ARxsta und einer Menge der internen Fehlervariablen V ARxf aul beschreibt. Es seien mit: AT Tkin - Menge aller Eingangsattribute der Systemkomponente comk AT Tkout - Menge aller Ausgangsattribute der Systemkomponente comk V ARkf unc - Menge aller internen Funktionsvariablen der Systemkomponente comk V ARksta - Menge aller internen Zustandsvariablen der Systemkomponente comk V ARkf aul - Menge aller internen Fehlervariablen der Systemkomponente comk . Dann gelten folgende Bedingungen: AT Txin ⊆ AT Tkin out out out out / AT T out attout x ∈ AT Tk ∧AT T¬x ⊂ AT Tk ∧attx ∈ ¬x f unc f unc V ARx ⊆ V ARk V ARxsta ⊆ V ARksta V ARxf aul ⊆ V ARkf aul out wird wie folgt definiert: Die qualitative relationale Übergangsfunktion fk,x qual

out :(AT T in , AT T out , V ARf unc , V ARsta , V ARf aul ) → attout | fk,x x x x ¬x x x qual

out (V ALin , V ALout , V ALf unc , V ALsta , V ALf aul ) = V ALout fk,x x x x ¬x x x Es seien mit: Fkout - Menge aller qualitativen relationalen Übergangsfunktionen einer Komponente. out ∈ F out . Dann gilt: fk,x k

Um den relationalen Zusammenhang zwischen Eingangs- und Ausgangsattributen sowie in-

59

3.3. KOMPONENTENMODELLIERUNG

ternen Funktions-, Zustands- und Fehlervariablen in der Übergangsfunktion zu beschreiben, müssen die qualitativen Gleichheitszeichen und die qualitativen Operationen wie Addition, Subtraktion, etc. definiert und zur Verfügung gestellt werden. Im Rahmen von verschiedenen Arbeiten [28], [131], [143] wurde das Konzept der Berechnung mit qualitativen Operatoren beschrieben. Nachfolgend erfolgt eine kurze Ausführung zur Erklärung der qualitativen in Berechnungen anhand einer abstrakten Komponente mit zwei Eingangsattributen attin x , atty und einem Ausgangsattribut attout (Abbildung 3.4). z att xin att

qual

f z : (att , att )  att in x

in y

in y

out z

att zout

Abbildung 3.4: Beispiel einer qualitativen Übergangsfunktion Das Verhalten dieser Komponente wird bestimmt durch die Übergangsfunktion fz : (attin x qual

out out durch eine qualitative Operation der , attin y ) → attz ,welche die Ausgangsattribute attz Eingangsattribute erzeugt. qual

qual

qual

qual

attx

atty

attx + atty = attz

attx − atty = attz

hoch

hoch

hoch

hoch, normal, niedrig

hoch

normal

hoch

hoch

hoch

niedrig

hoch, normal, niedrig

hoch

normal

hoch

hoch

niedrig

normal

normal

normal

normal

normal

niedrig

niedrig

hoch

niedrig

hoch

hoch, normal, niedrig

niedrig

niedrig

normal

niedrig

niedrig

niedrig

niedrig

niedrig

hoch, normal,niedrig

Tabelle 3.4: Rechenbeispiel für qualitative Addition und Subtraktion Bei dem Diagnosevorgang wird anhand der Abweichung der ermittelten beziehungsweise gemessenen Werte der Ausgangsattribute auf die möglichen Ursachen, das bedeutet auf die Werte der Eingangsattribute beziehungsweise den möglichen Fehlerzustand der Komponente geschlossen. Eine qualitative Abweichung in attout liegt dann vor, wenn der zugehörige Zahz lenwert der betrachteten physikalischen Größe entweder zu niedrig oder zu hoch ist. Es gilt: attout,gemessen < attout,erwartet | attout,gemessen > attout,erwartet z z z z ⇒ attout,gemessen − attout,erwartet < 0 | attout,gemessen − attout,erwartet >0 z z z z out out ⇒ ∆attz = (−) | ∆attz = (+). Unter Zuhilfenahme des totalen Differentials der Überführungsfunktion fz kann die Ändein rung ∆attout des Attributwertes attout in Abhängigkeit der Änderungen ∆attin z z x und ∆atty in der Eingangsattributen attin x und atty wiedergeben werden: δf δf in in z z ∆attout z = δattin ∆attx + δattin ∆atty x

y

60

KAPITEL 3. WISSENSERHEBUNG qual

qual

in in in Mit fz (attin x , atty ) = attx + atty gilt für die qualitative Addition: qual

qual

in ∆attout = ∆attin z x + ∆atty qual

qual

in in in Mit fz (attin x , atty ) = attx − atty gilt für die qualitative Subtraktion: qual

qual

in ∆attout = ∆attin z x − ∆atty

Aus diesen Überlegungen gilt für die Berechnung mit qualitativer Addition und Subtraktion die Relationstabelle 3.4. In der qualitativen relationalen Übergangsfunktion wird die physikalische Einheit der Eingangs- und Ausgangsattribute nicht in Betracht gezogen. Diese Vernachlässigung ist notwendig, weil in den meisten Fällen die internen Funktions-, Zustands- und Fehlervariablen mit den Eingangsattributen in Beziehungen zu Ausgangsvariablen stehen und dabei selbst oft keine Einheit besitzen. Zudem ist diese Vernachlässigung berechtigt, da bei dieser Art der qualitativen Verhaltensbeschreibung die Vernachlässigung der Glieder höherer Ordnung möglich ist. Zur Veranschaulichung der Verhaltensmodellierung kann als Beispiel die Verhaltensmodellierung einer Kraftstoffleitung (Abbildung 3.5) betrachtet werden. Eingang Kraftstoff

Kraftstoffleitung

Ausgang Kraftstoff

Abbildung 3.5: Modelldarstellung einer Kraftstoffleitung Die Beschreibung der relationalen Zusammenhänge zwischen Ein- und Ausgangsattributen der Kraftstoffleitung im nominalen Fall unter Verwendung der qualitativen Operationen kann wie folgt definiert werden: Kraf tstof f leitung.Eingang.Kraf tstof f .M assenf luss qual

= Kraf tstof f leitung.Ausgang.Kraf tstof f .M assenf luss Kraf tstof f leitung.Eingang.Kraf tstof f .Druck qual

− Kraf tstof f leitung.Ausgang.Kraf tstof f .Druck qual

= Kraf tstof f leitung.Ausgang.Kraf tstof f .M assenf luss Die erste Übergangsfunktion, die den Zusammenhang zwischen Eingangs- und Ausgangsmassenfluss im nominalen Fall beschreibt, kann durch die Kontinuitätsgleichung mit der Vernachlässigung der Glieder höherer Ordnung erklärt werden. Die zweite Übergangsfunktion kann durch die Bernoulli-Gleichung erklärt werden. Die Anwendung der Bernoulli-Gleichung ist begründet durch die stationäre Betrachtung in der Werkstatt und die Vernachlässigung der Glieder höherer Ordnung beziehungsweise den Abbruch nach dem ersten Glied. Unter Berücksichtigung des Fehlverhaltens bei Leckage in der Kraftstoffleitung wird das Verhalten der Kraftstoffleitung im Fehlerfall wie folgt erweitert: Kraf tstof f leitung.Eingang.Kraf tstof f .M assenf luss qual

− Kraf tstof f leitung.Leckage qual

= Kraf tstof f leitung.Ausgang.Kraf tstof f .M assenf luss Für die passive Komponente Kraftstofffilter, die so konstruiert ist, dass der V erschmutzungsgrad im Kraftstoff am Ausgang direkt von dem Abscheidungsgrad der Komponente abhängt, kann die nominale Verhaltensbeschreibung für V erschmutzungsgrad mit Hilfe der internen Funktionsvariablen Abscheidegrad wie folgt beschrieben werden:

61

3.3. KOMPONENTENMODELLIERUNG Kraf tstof f f ilter.Eingang.Kraf tstof f .V erschmutzungsgrad qual

− Kraf tstof f f ilter.Abscheidegrad qual

= Kraf tstof f f ilter.Ausgang.Kraf tstof f .V erschmutzungsgrad Im Beispiel des Kraftstoffventils sind weitere interne Zustandsvariablen wie Of f en beziehungsweise Geschlossen, die die Komponentenzustände beschreiben, definiert. Hierbei ist die Verhaltensbeschreibung abhängig von dem Wert, den die internen Zustandsvariablen annehmen: qual IF (Kraf tstof f ventil.Of f en = true){ Kraf tstof f ventil.Eingang.Kraf tstof f .M assenf luss qual

= Kraf tstof f ventil.Ausgang.Kraf tstof f .M assenf luss Kraf tstof f ventil.Eingang.Kraf tstof f .Druck qual

− Kraf tstof f ventil.Ausgang.Kraf tstof f .Druck qual

= Kraf tstof f ventil.Ausgang.Kraf tstof f .M assenf luss } ELSE { qual

Kraf tstof f ventil.Ausgang.Kraf tstof f .M assenf luss = null ... }

3.3.4

Verhaltenstabelle einer Komponente comk portin 0

...

portin i

tranx

...

trany

portout 0 varif unc

...

varjsta

...

varkf aul

att0

...

attm

...

att0

H

...

L

...

N

N

...

L

...

H

H

...

N

...

H

N

...

L

...

N

...

...

tranz att0

...

attn

...

L

...

L

L

...

H

...

L

N

...

H

..

L

... H

...

L

...

N

N

...

Tabelle 3.5: Aufbau einer Verhaltenstabelle2 In dieser Arbeit wird die Verhaltensrepräsentation, die für den Diagnosevorgang verwendet wird, nicht in Form von qualitativen relationalen Übergangsgleichungen, sondern in Form von Verhaltenstabellen dargestellt. Dabei wird das Verhalten einer Komponente durch eine zweidimensionale Tabelle repräsentiert. Eine Verhaltenstabelle besteht aus zwei Teilen, dem Tabellenkopf und dem Tabellenrumpf, in welchem die Wertebelegungen stehen, die die Verhaltensrelation beschreiben (Tabelle 3.5). Der Tabellenkopf kann als Baumstruktur betrachtet 2

Jede Zeile der Tabelle 3.5 entspricht einer Abbildung des Tupels:{AT Tkin , AT Tkout , AT Tkf unc , AT Tksta , qual

f aul f unc out AT Tkf aul } → {V ALin , V ALsta }. Zum Beispiel kann die erste Zeile wie folgt k , V ALk , V ALk k , V ALk gelesen werden: in in (comk . portin 0 . tranx . att0 = H )∧ (...)∧ (comk . port0 . tranx . attm = L )∧ (...)∧ (comk . porti . trany . att0 = f unc f aul sta N )∧ (comk . vari = N )∧ (...)∧ (comk . varj = L )∧ (...)∧ (comk . vark = H )∧ (...)∧ (comk . portout 0 . out tranz . att0 = L )∧ (...)∧ (comk . port0 . tranz . attn = L)

62

KAPITEL 3. WISSENSERHEBUNG

werden: Die „Wurzel“ ist die Komponentenbezeichnung. Die erste Verzweigung beschreibt die Eingangs- und Ausgangsschnittstellen, die internen Funktions-, Zustands- sowie die internen Fehlervariablen. In der dritten Ebene stehen die einzelnen Schnittstellen und in der vierten Ebene folgt die Darstellung der Transportobjekte, die sich in den Schnittstellen befinden. Für „Blätter“ stehen die zugehörigen Attribute der jeweiligen Transportobjekte und die einzelnen internen Funktions-, Zustand- und Fehlervariablen. Jede Zeile im Tabellenrumpf entspricht einer Verhaltensrelation, die die Abhängigkeit zwischen Eingangs- und Ausgangsattributen unter Berücksichtigung von internen Fehler-, Zustands- sowie Funktionsvariablen beschreibt und zur Aufklärung der Symptome im Diagnosevorgang dient. Es seien mit: tabbeh - Verhaltenstabelle einer Komponente comk k beh ROWk - Menge aller Zeilen der Verhaltenstabelle tabbeh k rownbeh - Die n-te Zeile der Verhaltenstabelle tabbeh . k Dann gilt: rownbeh ∈ROWkbeh f unc f aul in tabbeh , V ALsta , V ALout k :=T U P EL(V ALk , V ALk k , V ALk k ). Dieses Tupel ist eine Abbildung aus: {AT Tkin , V ARkf unc , V ARksta , V ARkf aul , AT Tkout } qual

f aul f unc , V ALout , V ALsta → {V ALin k }. k , V ALk k , V ALk

Die Verwendung der Verhaltenstabelle ist sinnvoll, weil die Wertebelegung in den Zeilen der Verhaltenstabelle durch die automatische Auswertung der Übergangsfunktionen generiert wird. Die Wertebelegung kann auch durch den Modellierer manuell festgelegt werden, lässt sich doch die Verhaltensbeschreibung der Komponente im Modell nicht immer durch relationale Gleichungssysteme einfach beschreiben. Ein Beispiel dafür ist die Verhaltensbeschreibung des Brennraums: Mit einer Vielzahl von Eingangs- und Ausgangsattributen sowie internen Variablen ist bei dem Brennraum der Aufwand für die relationale Verhaltensbeschreibung im Vergleich zur manuellen Füllung der Tabelle relativ hoch. Ein Vorteil der Verhaltenstabelle bei der Erstellung von Diagnosehypothesen ist, dass nur die Suchmethode und nicht die Analyse der qualitativen relationalen Übergangsfunktionen aufgerufen werden muss. Diese Möglichkeit reduziert den Rechenaufwand und die Rechenzeit während der Diagnose erheblich.

3.3.5

Beeinflussungstabelle einer Komponente

Neben der Möglichkeit zur Verhaltensbeschreibung durch qualitative relationale Übergangsfunktionen und Repräsentation dieses Verhaltens in Tabellenform erlaubt die Modellierung in dieser Arbeit weitere Möglichkeiten zur Abbildung diagnoserelevanter Informationen in Form einer Auswertung des Beeinflussungsgrads aller Ausgangsattribute einer Systemkomponente durch seine erwarteten Funktionen. Aufgrund der Eingangs- und Ausgangsbetrachtungsweise einer Komponente bei der Modellierung und der Tatsache, dass systemeigene Komponenten durch ihre eigenen Funktionen die Ausgangsattribute beeinflussen, ist die Abbildung dieser Informationen im Gegensatz zur Verhaltensmodellierung relativ einfach. Als Beispiel soll die Funktion der Komponente Ladeluf tkuehlung dienen: Die Funktion der Ladeluf tkuehlung ist die Begrenzung der Ladelufttemperatur. Sie ermöglicht die Reduzierung der thermischen Belastung des Motors, die Senkung der Abgastemperatur und damit der NOx-Emission, die Verringerung des Kraftstoffverbrauchs und die Erhöhung der Klopffestigkeit beim Ottomotor. Es ist offensichtlich, dass das Attribut T emperatur des Transportobjekts Luf t in der Ausgangsschnittstelle der Komponente Ladeluf tkuehlung dessen Funktion

63

3.3. KOMPONENTENMODELLIERUNG

im Vergleich zu anderen Attributen wie Druck, M assenf luss des Transportobjekts Luf t am stärksten beeinflusst. Wenn ein Symptom im Diagnosevorgang auftaucht, das in Verbindung zur Abweichung der Ladelufttemperatur gebracht werden kann und sich in der verdächtigen Liste der Komponente Ladeluf tkuehlung befindet, dann sollte in den meisten Fällen zuerst die Ladeluf tkuehlung und deren Funktion überprüft werden. Mit dieser Überlegung und der Anforderung, dass eine Komponente unabhängig von ihrer Umgebung modelliert werden soll, ergibt sich die Modellierung der Beeinflussung der Ausgangsattribute durch die erwartete Komponentenfunktion. Es seien mit: IN Fkout - Menge aller Bewertungsbelegungen des Beeinflussungsgrads aller Ausgangsattribute einer Komponente comk durch seine erwarteten Komponentenfunktionen infnout - die n-te Bewertungsbelegung des Beeinflussungsgrads durch die Komponente comk auf ein Ausgangsattribut attout n . out out Dann gilt: infn ∈IN Fk . comk portout 0 var0sta T

... ...

varista T

tran0

...

tranx

portout 1

...

portout n

tranz

...

tranv

att0

...

attn

...

attm

atti

...

attk

...

attj

+

...

0

...

+

-

...

-

...

+

-

0

...

-

...

-

... F

...

T



...

+

...

Tabelle 3.6: Aufbau einer Beeinflussungsgradtabelle3 Der Aufbau einer Beeinflussungsgradtabelle ist in Tabelle 3.6 dargestellt. Im Unterschied zur Verhaltenstabelle werden nur die interne Zustandsvariablen und die Ausgangsschnittstellen der Systemkomponente, deren Transportobjekte und die zugehörigen Attribute für den Aufbau des Tabellenkopfs benötigt. Jede Zeile im Tabellenrumpf beschreibt den Beeinflussungsgrad der Komponente auf einzelne Ausgangsattribute in Abhängigkeit von den Werten der internen Zustandsvariablen dieser Komponente. Die Festlegung des Beeinflussungsgrads erfolgt durch den Modellierer. Es stehen drei mögliche Belegungen {+, 0, −} zur Verfügung; wobei {+} für stark beeinflusst, {0} für kaum beeinflusst und {−} für nicht beeinflusst stehen. Es seien mit: tabinf - Beeinflussungsgradstabelle einer Komponente comk k inf ROWk - Menge aller Zeilen der Beeinflussungsgradstabelle tabinf k rowninf - Die n-te Zeile der Beeinflussungsgradstabelle tabinf k . Dann gilt: rowninf ∈ROWkinf sta out tabinf k :=T U P EL(V ARk , AT Tk ). qual

out Dieses Tupel ist eine Abbildung aus: {V ARksta , AT Tkout } → {V ALsta k , IN Fk } 3

qual

Jede Zeile der Tabelle 3.6 entspricht einer Abbildung des Tupels:{V ARksta , AT Tkout } → {V ALsta k , IN Fkout }. Zum Beispiel kann die erste Zeile wie folgt gelesen werden: out (comk . var0sta = T )∧ (...)∧ (comk . varista = T )∧ (comk . portout 0 . tran0 . att0 = + )∧ (...)∧ (comk . port0 . out out tran0 . attn = 0 )∧ (...)∧ (comk . port0 . tranx . attm = + )∧ (comk . port1 . tranz . atti = - )∧ (...)∧ (comk . out portout 1 . tranz . attk = - )∧ (...)∧ portn . tranv . attj = + )

64

KAPITEL 3. WISSENSERHEBUNG

VT_1A: Verhaltenstabelle

VZ_1: Verhaltenszustand

Einspritzventil1 Eingang Ausgang Kraftstoff Kraftstoff Verstopfung Massenfluss Massenfluss normal hoch niedrig niedrig normal niedrig

Einspritzventil1.Eingang.Kraftstoff.Massenfluss= normal Einspritzventil1.Verstopfung= hoch Einspritzventil1.Ausgang.Kraftstoff.Massenfluss= niedrig

hoch

normal

UeF_1: Übergangsfunktion

hoch

QV_1: QualitativesVerhaltensmodell Betriebszustand= Volllast

Massenfluss: Attribut

Verstopfung: InterneVariable

Einheit=g/s Wertebereich= {niedrig, normal, hoch}

Typ= Fehlervariable Wertebereich= { normal, hoch}

Einspritzventil1:Komponente

BF_V: Beeinflussungstabelle

Druck +

Ausgang Kraftstoff Massenfluss +

... ...

Einspritzventil1.Eingang.Kraftstoff.Massenfluss Einspritzventil1.Verstopfung= Einspritzventil1.Ausgang.Kraftstoff.Massenfluss

Kraftstoff: Transportobjekt

Eingang: Schnittstelle Richtung= in Visualisierungstyp= material Art=Komponentenschnittstelle

Ausgang: Schnittstelle Richtung= aus Visualisierungstyp= material Art=Komponentenschnittstelle

Abbildung 3.6: Objektdiagramm eines Einspritzventils

3.4. MESSUNGSMODELLIERUNG

65

Die Verwendung der Bewertungsbelegung der Beeinflussung durch die Komponente auf ein Ausgangsattribut ist eine Möglichkeit zur Priorisierung der Liste der verdächtigen Komponenten. Die Priorisierung ist trival: Wenn sich zwei Komponenten mit gleicher Bewertung in der Verdächtigungsliste befinden und eine Komponente eine höhere Bewertungsbelegung des relevanten Attributs als die andere Komponente aufweist, dann soll die erste Komponente eine höhere Priorität als die zweite Komponente haben. Diese Information ist besonders nützlich, da nicht immer das Wissen über die Ausfallwahrscheinlichkeit der systemeigenen Komponenten verfügbar ist.

3.3.6

Ein beispielhaftes Komponentenobjektdiagramm

In Abbildung 3.6 sind einige Instanzen zur qualitativen Verhaltensbeschreibung der Komponente Einspritzventil dargestellt. In der Abbildung beinhaltet das Ventil eine Eingangsund eine Ausgangsschnittstelle, durch welche das Transportobjekt Kraf tstof f fließt. Ein Attribut dieses Transportobjekts ist der M assenf luss, welcher die Masse des Kraftstoff, die sich in einer Zeiteinheit durch einen Querschnitt bewegt beschreibt, und in Gramm je Sekunde angegeben wird ([80]). Die Verstopfung wird hierbei als interne Fehlervariable definiert und beeinflusst direkt das Verhalten des Massenflusses in der Ausgangsschnittstelle. Die Übergangsfunktion U eF _1 beschreibt die Abhängigkeit zwischen dem Ausgangs- und Eingangsmassenfluss sowie der Variable V erstopf ung. Aus dieser Übergangsfunktion können mehrere Verhaltenszustände generiert werden. Die Generierungsoption ist in dem Objektdiagramm als gestrichelte Linie dargestellt. Das Objekt V Z_1 ist einer dieser Zustände und beschreibt eine Zeile der Verhaltenstabelle V T _1A. Das qualitative Verhaltensmodell QV _1 beschreibt das Verhalten des Einspritzventils in dem Betriebszustand Volllast und besitzt die Verhaltenstabelle V T _1A. Die gestrichelte Linie zwischen dem Verhaltensmodell QV _1 und der Übergangsfunktion U eF _1 deutet daraufhin, dass diese Übergangsfunktion für den Betriebszustand Volllast gilt.

3.4

Messungsmodellierung

Die Modellierung der externen Messung und der Messung mittels systemeigenen Sensors ist gleich. Hierbei ist nur die Angabe der Messpunkte sowie der Messgröße wichtig. Nur bei dem Diagnosevorgang wird zwischen den beiden Messarten unterschieden, weil oft die Kosten der Messungsdurchführung der externen Messung viel höher sind als bei der Messung mit Systemsensoren.

3.4.1

Messung mittels Systemsensor

Im Vergleich zu Aktoren und passiven Komponenten enthalten Systemsensoren zusätzliche Messeigenschaften. Ein Systemsensor ermittelt eine physikalische Modellgröße, die sich durch das Transportobjekt und das zugehörige Attribut beschreiben lässt. Der Sensor liefert den aktuellen Wert der Modellgröße und damit die Information zur Verdichtung des Diagnoseergebnisses auf wenige, verdächtige Komponenten. Für die Modellierungsaufgabe ist die Ankopplung zwischen Sensor und physikalischer Modellgröße notwendig. Bei der Formalisierung der Messgröße im Systemsensor (Abbildung 3.7) wird wie folgt vorgegangen:

66

tranb

Signal

KAPITEL 3. WISSENSERHEBUNG

out

porta in

out Sensor

Material

Material

trany

trany senm

portx

portu

Abbildung 3.7: Beispielhafte Visualisierung eines Systemsensors

Druck: Attribut

Kraftstoff: Transportobjekt

Einheit=bar Wertebereich= {niedrig, normal, hoch} Ausgang_S1: Schnittstelle

Drucksignal: Transportobjekt

Richtung= aus Visualisierungstyp= material Ausgang_S2: Schnittstelle Richtung= aus Visualisierungstyp= signal

Drucksensor:Komponente

Eingang_S1: Schnittstelle Richtung= in Visualisierungstyp= material

Kraftstoffsystem: System DS_Meas:Onboardmessung KraftstoffsystemModell: Basismodell

MB220CDI: Fahrzeug

Drucksensor.Eingang_S1.Kraftstoff.Druck= Drucksensor.Ausgang_S2.Drucksignal.Druck; Drucksensor.Ausgang_S2.Drucksignal.Druck= DS_Meas.istwert[0] DS_MK4: Messungswissen Instruktion= {path; filename.html} Sollwertbereich= [min … max]

Abbildung 3.8: Beispielhaftes Objektdiagramm eines Drucksensors

67

3.4. MESSUNGSMODELLIERUNG material .att := sen .portout .transignal .att senm .portin z m c x .trany a b signal out senm .porta .tranb .attc := senm .istwerti .

Die Instruktion zur Abfrage der Istwerte und die Angabe der Sollwertbereiche in verschiedenen Betriebszuständen sind abhängig vom Fahrzeugmodell und sollen mit der Datenbankabfrage in das Sensormodell bei der Diagnose eingebunden werden. In einem Diagnosevorgang wird der gemessene Wert sen.istwert[a] eines Systemsensors durch Anfrage des zuständigen Steuergeräts ermittelt. Nach der Werteermittlung erfolgt die Wertezuweisung des zugehörigen material .att und der Vergleich zwischen den Ist- und Sollwerten. Attributes senm .portin z x .trany Mit diesem neuen Diagnosewissen kann die Einschränkung der Liste der verdächtigen Komponenten fortgesetzt werden. In Abbildung 3.8 ist das Objektdiagramm eines Drucksensors im Kraftstoffsystem des Fahrzeugs MB220CDI beispielhaft dargestellt. Dabei ist das Objekt DS_M eas eine Instanz der Klasse Onboardmessung und beinhaltet die Messinformationen, die soeben beschrieben wurden. Das Messungswissen dieses Sensors, das für das Fahrzeug MB220CDI spezifisch ist, wird durch die Instanz DS_M K4 repräsentiert. Dabei enthält diese Instanz zum einen den relativen Pfad der Messinstruktionsdatei und zum anderen die Sollwertbereiche des Messergebnisses im fehlerfreien Fall.

3.4.2

Abbildung der externen Messung

meask Signal

tranb

MessungVal1

in

porta

out

in Material

trany

portx

Einspritzventil

comk

Material

portu

trany

Abbildung 3.9: Beispielhafte Visualisierung einer Messung Im Unterschied zu den systemeigenen Sensoren erfolgt die Modellierung der externen Messungen ohne eine Verhaltensbeschreibung. Die Schnittstelle des externen Messmodells ist eine virtuelle Schnittstelle, weil der Einbau des Messgeräts in das zu diagnostizierende System das Verhalten des Systems nicht beeinflussen soll. Es seien mit: M EAS - Die Menge aller externen Messungen, die im Modell abgebildet sind meask - Die k-te externen Messung im Modell. Dann gilt: meask ∈ M EAS. Analog zu dem systemeigenen Sensor beinhaltet das externe Messgerät die Messeigenschaften: • Instruktion zur Abfrage des Istwerts

68

KAPITEL 3. WISSENSERHEBUNG • Angabe der Sollwertbereiche in verschiedenen Betriebszuständen.

Eine externe Messung (Abbildung 3.9) ermittelt eine physikalische Modellgröße, die sich durch das Transportobjekt und das zugehörige Attribut beschreiben lässt. Mit dem gemessenen Wert der physikalischen Modellgröße kann die Fehlerhypothese verfeinert werden. Die Instruktion zum Auslesen des Messgeräts und die Angabe der Sollwertbereiche sind abhängig vom Fahrzeugmodell und werden bei der Parametrisierungsphase in das Diagnosemodell integriert. Für die Modellierung der externen Messung ist nur die Ankopplung zwischen externem Messgerät und der physikalischen Modellgröße wichtig. Die Formalisierung der Messgröße im externen Messgerät erfolgt analog zum Systemsensor: comk .portu .trany .attz := meask .istwerti .

Massenfluss: Attribut

Kraftstoffsystem: System

Einheit=g/s Wertebereich= {niedrig, normal, hoch} KraftstoffsystemModell: Basismodell

Kraftstoff: Transportobjekt

Modellverlinkung[1]= (Einspritzventil1, MeasEVentil1} MB220CDI: Fahrzeug

Einspritzventil1:Komponente

Ausgang_V: Schnittstelle Richtung= aus Visualisierungstyp= material

MeasEV1_1: Messungswissen

MeasEVentil1: Offboardmessung

Instruktion= {path; filename.html} Sollwertbereich= [min … max]

Einspritzventil1.Ausgang_V.Kraftstoff.Massenfluss= MeasEVentil1.istwert[0]

Abbildung 3.10: Beispielhaftes Objektdiagramm einer manuellen Messung Analog zur Onboardmessung beinhaltet die Instanz M easEV 1_1 der Klasse Messungswissen einen relativen Pfad zur Messinstruktionsdatei und zu den Sollwertbereichen des Messergebnisses. Da diese Informationen fahrzeugabhängig sind, sind diese mit der Instanz M B220CDI der Klasse Fahrzeug zugeordnet (Abbildung 3.10). Die physikalische Modellierung der manuellen Messung wird durch die Instanz M easEV entil1 repräsentiert und entspricht der oben beschriebenen Formalisierung.

3.5. ABBILDUNG DES FEHLERCODES

3.5

69

Abbildung des Fehlercodes

Zum Grundumfang des Motorsteuergeräts in modernen Kraftfahrzeugen gehört die OnboardDiagnose (OBD). Im Unterschied zur Offboard-Diagnose erfolgt die Onboard-Diagnose durch den permanenten Abgleich der Aktionen und der Reaktionen des Systems im Betrieb mit den Befehlen des Steuergerätes und der Signale der verschiedenen systemeigenen Sensoren untereinander auf ihre Plausibilität. Wenn die Plausibilität nicht gegeben ist, erfolgt ein Eintrag in den Fehlerspeicher (Fehlercode) des Steuergeräts. Dabei ist das Hauptziel der OnboardDiagnose des Motorsteuergeräts und seine Funktion die Überwachung relevanter Komponenten, die bei Fehlverhalten oder Ausfall zur Erhöhung der schädlichen Emissionen führen können. Dieses Ziel ist bedingt durch die Gesetzgebung zur Minderung der Umweltverschmutzung. Andere kundendienstrelevante Diagnoseinformationen können ebenfalls im Fehlerspeicher abgespeichert werden, sind aber von Fahrzeug zu Fahrzeug hinsichtlich des Umfangs und des Detaillierungsgrades verschieden. Der Fehlercode enthält folgende, diagnoserelevante Informationen: • Fehlerpfad: Systembereiche (Komponente beziehungsweise Komponentengruppe), die vermutlich das Fehlverhalten verursachen • Fehlerart: Benennung der Art der Abweichung von der physikalischen Systemgröße in qualitativer Form (zu hoch, zu niedrig, unplausibel); Benennung der Fehlerarten im Stromkreis: Kurzschluss, Masseschluss, Plusschluss, Unterbrechung • Fehlerbeschreibung: Kurzer Text zur Erklärung des Fehlverhaltens und mögliche Tests beziehungsweise Messungen zur Bestätigung der Verdachtshypothese; kann zusätzliche Informationen zu den Randbedingungen enthalten, bei denen der Fehler aufgetreten ist, wie zum Beispiel: Drehzahl, Umgebungsdruck, Umgebungstemperatur, Motortemperatur. Es seien mit: DT C - Menge aller Fehlercodes, die im Modell abgebildet sind dtck - Das k-te Fehlercode im Systemmodell. Dann gilt: dtck ∈ DT C. Zur Veranschaulichung der Diagnoseinformationen des Fehlercodes werden nachfolgend einige beispielhafte Fehlercodes im Motorsystem beziehungsweise in dessen Subsystemen vorgestellt: • P 2352[1] - Fehlercode: – Fehlerpfad: Kraftstoffsystem - Injektoren – Fehlerart: Zu geringe Einspritzmenge – Fehlerbeschreibung: Anzahl Einspritzung - begrenzte Anzahl von Einspritzungen durch zu geringe Einspritzmenge • P 2017 - Fehlercode: – Fehlerpfad: Kraftstoffsystem - Mengenregelventil – Fehlerart: Minimalwert unterschritten

70

KAPITEL 3. WISSENSERHEBUNG – Fehlerbeschreibung: Raildruck - Überwachung über Mengenregelventil; der Raildruck ist zu klein • P 0204[1]- Fehlercode: – Fehlerpfad: Kraftstoffsystem - Injektor Zylinder 4 – Fehlerart: Plusschluss – Fehlerbeschreibung: Bauteil Injektor 4. Zylinder prüfen; Kurzschluss nach Plus • P 0204[2]- Fehlercode: – Fehlerpfad: Kraftstoffsystem - Injektor Zylinder 4 – Fehlerart: Kurzschluss – Fehlerbeschreibung: Bauteil Injektor 4. Zylinder prüfen; Kurzschluss untereinander.

Durch die unterschiedlichen Diagnoseinformationen, die ein Fehlercode beinhaltet, ist es notwendig, eine Abbildung des Fehlercodes im Modell in zwei Arten zu unterschieden: • Fehlercode als weitere Messungen (virtueller Sensor) • Fehlercode als Diagnoseregel.

Signal

tranb

Fehlercode1 in

porta

out

in Material

tranz

dtck

portu

Injektor1

comx

Material

porty

tranz

Abbildung 3.11: Beispielhafte Notation eines Fehlercodes als virtueller Sensor

Material

Material

Material

Material

Die Unterscheidung ist notwendig, weil die modellbasierten Algorithmen nur mit Fehlercodes als virtuellen Sensoren arbeiten können. Der Fehlercode als Diagnoseregel beträgt im Regelfall 50% des gesamten Fehlercodes und muss bei dem Diagnosevorgang berücksichtigt tranz dtck tranerweiterte z werden. Die Verarbeitung und Bewertung eines solchen Fehlercodes erfordert Diagnosealgorithmen und eine Änderung des Diagnoseablaufs im Tester. Diese Erweiterung der Fehlercode4 port port u u comx comSensor Algorithmen kombiniert regel- und modellbasierte Diagnoseansätze. Ein Fehlercode als x in in ist analog einem Systemsensor, der eine physikalische Modellgröße ermittelt, die sich durch in in das Transportobjekt und das zugehörige Attribut beschreiben lässt. Im Unterschied zu einem Injektor1 Signal liefertInjektor1 Signal sondern Systemsensor der Fehlercode nicht den aktuellen Wert der Modellgröße zurück, die Vergleichergebnisse zwischen Soll- und Ist-Werten, wobei die qualitative Wertebelegung der Modellgrößen der out Fehlerart im Fehlercode entnommen werden kann outund der Fehlerort im porty porty tran port b a porta tranb Fehlerpfad gespeichert ist. Die Messgrößen im Fehlercode können Messungen des Systemsensors formalitranz ähnlich wie dietran z siert werden (Abbildung 3.11). Der Unterschied ist, dass die Ergebnisse der Messungen bereits

71

3.5. ABBILDUNG DES FEHLERCODES

Signal

existieren: Fehlercode1 dtck comx .porty .tranztran .attbt := dtck .qualitativwert[i]. Bei der Modellierung von Fehlercode 2352[1] und 2017 soll wie folgt vorgegangen werden: in

porta

• P 2352[1] - Fehlercode:in

out Injektor1

Material

Material

– Ort: Ausgangsschnittstelle der Injektoren

qual

– Abweichung: Injektor1 .Ausgang.Kraf tstof f.M assenf luss = niedrig tranz

portu

comx

porty

tranz

• P 2017 - Fehlercode: – Ort: Ausgangsschnittstelle des Mengenregelventils qual

– Abweichung: M engenregelventil.Ausgang.Signal.Raildruck = niedrig

portu

comx

dtck Fehlercode4 in

tranz

Material

Material

tranz

portu

in Signal

in Injektor1

Injektor1 out

porty

porty

tranz

tranz

Signal

out Material

Material

tranb porta

comx

in

porta tranb

Abbildung 3.12: Beispielhafte Notation eines Fehlercodes als Diagnoseregel Ein Fehlercode als Diagnoseregel zeigt direkt auf systemeigene Komponenten oder eine Komponentengruppe (Abbildung 3.12). Dabei kann die verdächtige Komponente anhand des Fehlerpfads entnommen werden; die Überprüfungsmöglichkeiten werden in der detaillierten Fehlerbeschreibung des Fehlercodes angegeben. In dieser Arbeit hat Fehlercode, der als Diagnoseregel abgebildet werden soll, folgende Form: • Wenn: Fehlercode dtck existiert • Dann: – Verdächtige Komponenten: comi ,..., comi+n – Prüfanweisungen: Folgende Prüfschritte X1 ,..., Xn sollen durchgeführt werden – Erklärungstext: Fehlerhypothesen Y1 ,..., Yn beschreiben, die die Verdächtigungen der Komponenten comi ,..., comi+n erklären Die Diagnoseregel der Fehlercodes 0204[1] und P 0204[2] lautet wie folgt: • Wenn: 0204[1] - Fehlercode existiert • Dann:

72

KAPITEL 3. WISSENSERHEBUNG – Verdächtige Komponenten: Komponente: Kraftstoffsystem - Injektor Zylinder 4 – Prüfanweisungen: Bauteil Injektor 4. Zylinder prüfen – Erklärungstext: Plusschluss; Kurzschluss nach Plus. • Wenn: P 0204[2] - Fehlercode existiert • Dann: – Verdächtige Komponenten: Komponente: Kraftstoffsystem - Injektor Zylinder 4 – Prüfanweisungen: Bauteil Injektor 4. Zylinder prüfen – Erklärungstext: Kurzschluss untereinander.

MB220CDI: Fahrzeug

DTC_J11: Fehlercode

DTC_J12: Fehlercode

Massenfluss: Attribut

Identifikation= P 0206[1]

Identifikation= P 2352[1]

Einheit=g/s Wertebereich= {niedrig, normal, hoch}

R_Injektor1:Regel

ZD_Injektor1:Zuordnung

Fehlerpfad= "Kraftstoffsystem – Injektor1" Fehlerart= "Plusschluss" Fehlerbeschreibung= "Bauteil Injektor1 prüfen; Kurzschluss nach Plus"

Injektor1.Ausgang_J1.Kraftstoff. Massenfluss= niedrig

KraftstoffsystemModell: Basismodell

Kraftstoff: Transportobjekt

Ausgang_J1: Schnittstelle Injektor1:Komponente

Richtung= aus Visualisierungstyp= material Art=Komponentenschnittstelle

Kraftstoffsystem: System

Abbildung 3.13: Beispielhaftes Objektdiagramm einiger Fehlercodes

3.6. ABBILDUNG DER BEANSTANDUNG

73

In Abbildung 3.13 steht ein mögliches Objektdiagramm der Fehlercodes, die oben beschrieben sind. Dabei stellt dieses Diagramm neben den Instanzen von verschiedenen Klassen wie zum Beispiel Basismodell, System, Komponente, Schnittstelle, Transportobjekt, Attribut, auch die Objekte ZD_Injektor1 (Instanz der Zuordnung), R_Injektor1 (Instanz der Regel), DT C_J11 und DT C_J12 (Instanzen der Fehlercodes) dar. Mit dem Objekt M B220CDI sind die beiden Fehlercodeinstanzen jeweils über einen Link verbunden, da die Identifikation der Fehlercodes Fahrzeug abhängig ist. Die Instanz der Regel R_Injektor1 ist direkt an das Objekt Injektor1 und das Objekt ZD_Injektor1 an das Objekt M assenf luss gebunden. Die Verlinkung zwischen den beiden Instanzen Schnittstelle und Zuordnung beschreibt den Ort beziehungsweise die Messpunkte und damit eine indirekte Zuordnung zum Objekt Injektor1.

3.6

Abbildung der Beanstandung

Die Anforderungen an Diagnosetools sind vielfältig, eine davon ist die Verarbeitung der Kundenbeanstandungen. Für das Diagnosesystem, das das Diagnosewissen aus den Modellen abruft, bedeutet dies zum einen die Überführung der subjektiven Beobachtungen beziehungsweise Kundenbeanstandungen in physikalische Größen, die in dem Modell abgebildet sind. Zum anderen sollen die Eigenschaften der Beanstandung, die sehr aufwändig sind beziehungsweise sich nicht in physikalische Größen überführen lassen, in geeigneter Form im Modell abgebildet werden. Als Beispiel wird hierfür eine Kundenbeanstandung, die der Kunde oder das Werkstattpersonal über das Motorsystem äußert, betrachtet. Die Beanstandungen entstehen in der Regel aus Abweichungen der verschiedenen physikalischen Größen oder Parameter, die für die Funktion des zu diagnostizierenden Systems verantwortlich sind. Diese Abweichungen sind Resultate des Fehlverhaltens der Komponenten im System. Die Komponente, die das Symptom verursacht, soll mit Hilfe des Diagnosesystems lokalisiert werden. Die entscheidenden Diagnoseinformationen, die für die Lokalisierung der fehlerhaften Komponenten benötigt werden, sind die Antworten auf folgende Fragen: • Wo im System ist die Abweichung zu beobachten? • Welche Abweichung der physikalischen Größe kann das Symptom erklären? Aufgrund des Systemzusammenhangs und der Interaktion zwischen den Komponenten im System, welche durch die Strukturmodellierung in Form von Graphen abgebildet sind, und da die Fehlerlokalisierung durch Rückwärts- und Vorwärtsverkettung anhand der Struktur des Systems erfolgt, ist die Bestimmung des Ortes der beobachtbaren physikalischen Ursachen bei der Modellierung der Beobachtungen sehr wichtig. Der Ort beeinflusst nicht nur den Rechenaufwand der Diagnosealgorithmen bei der Generierung der Liste der verdächtigen Komponenten, sondern auch die Fehlerlokalisierung. Bei falscher Ortsbestimmung können bei bestimmten Konstellationen wichtige Sensoren, die für die Fehlerlokalisierung relevante Daten liefern, erst zu einem späteren Zeitpunkt durch die Diagnosealgorithmen berücksichtigt werden, obwohl sie zur Verkürzung der Berechnungszeit bereits vorher in Betracht gezogen werden sollten. Die Abbildung der Kundenbeanstandungen soll daher in zwei Schritten erfolgen: • Ort: Bei welchen Komponenten beziehungsweise Systemschnittstellen sind die Abweichungen zu beobachten

74

KAPITEL 3. WISSENSERHEBUNG • Abweichungen in physikalische Ursachen überführen und als qualitative relationale Gleichungen abbilden.

Eine Formalisierung der Eigenschaften von Kundenbeanstandungen hinsichtlich des Beobachtungsortes und der Abweichungsmöglichkeiten der Ausgangs- beziehungsweise Eingangsattribute ist in dieser Arbeit wie folgt definiert: OBS - Die Menge aller Kundenbeanstandungen, die im Modell abgebildet sind obsk - Die k-te Kundenbeanstandung im Systemmodell (obsk ∈ OBS) Ekobs - Menge aller qualitativen relationalen Gleichungen, die die Kundenbeanstandungen beziehungsweise Beobachtungen obsk beschreibt obs obs eobs k,n - Die n-te qualitative relationale Gleichung (ek,n ∈ Ek ) Die qualitative Relation eobs k,n wird folgendermaßen definiert: qual

f unc f unc in out sta in out sta eobs k,n : (AT Tk,n , AT Tk,n , V ARk,n , V ARk,n ) = (V ALk,n , V ALk,n , V ALk,n , V ALk,n ).

comx tranz

portu

porty

LampeLinks

Energie

tranz

obsk

Licht out

in

Beanstandung1

out

in LampeRecht

Energie

tranz

portu

comk

Licht

portl

tranm

Abbildung 3.14: Beispielnotation einer Kundenbeanstandung im Lichtsystem Zur Verdeutlichung wird dieses Vorgehen anhand der Kundenbeanstandung „Starter dreht, Motor springt nicht oder schlecht an“ erläutert. Hier gibt es in einige Interpretationsmöglichkeiten, wie zum Beispiel: • 1. Möglichkeit – Ort: Ausgangsschnittstelle des Abgassystems - Ausgangsschnittstelle des Abgasrückführungsventils dtck qual

– Abweichung: AGRV entils.Ausgangsschnitttstelle.Abgas.M assenf luss = hoch; Fehlercode4

Material

tranz

Material

tranz • 2. Möglichkeit

Injektor1

Injektor1

Ausgangsschnittstelle des Luftsystems - Ausgangsschnittstelle der portuDrallklappe u com–x Ort:port comx qual in in – Abweichung: Drallklappe.Ausgangsschnitttstelle.Luf t.M assenf luss = niedrig. in

Signal

in

out

out porty

port

Ma

Ma

tranb porta

Signal

porta tranb

75

3.6. ABBILDUNG DER BEANSTANDUNG

Im oben genannten Beispiel ist die Abweichung der Modellgröße nur an eine Komponente gebunden. Es existieren Kundenbeanstandungen, die an mehrere Modellgrößen und an verschiedene Komponenten gebunden sind. Ein Beispiel dafür ist die Beanstandung „Leuchtweite unterschiedlich“ (Abbildung 3.14). Hier ist eine Abweichung im Lichtsystem bei den Komponenten „linke Lampe“ und „rechte Lampe“ beobachtet worden und die physikalischen Ursachen sollen in qualitativer Relation stehen: LampeLinks.Ausgang.Licht.N eigungswinkel qual

= LampeRechts.Ausgang.Licht.N eigungswinkel. Da diese Abweichung in Form einer qualitativen relationalen Funktion aufgefasst wird, wird der Algorithmus zur Erzeugung der Verhaltenstabelle verwendet, um alle möglichen Wertebelegungen der Attribute zu berechnen. Es seien mit: tabobs k - Beobachtungstabelle einer Kundenbeanstandung obsk ROWkobs - Menge aller Zeilen der Beobachtungstabelle tabobs k obs - Die n-te Zeile der Beobachtungstabelle . rowk,n Dann gilt: obs ∈ROW obs rowk,n k f unc obs in out , V ALsta tabobs k ). k := T U P EL(Ek , V ALk , V ALk , V ALk Dieses Tupel ist eine Abbildung aus: qual

f unc out , V ALsta (AT Tkin , AT Tkout , V ARkf unc , V ARksta ) → (V ALin k ). k , V ALk , V ALk Für das Beispiel „Leuchtweite unterschiedlich“ wird folgende Tabelle erzeugt:

LampeLinks.Ausgang.Licht. N eigungswinkel

LampeRechts.Ausgang.Licht. N eigungswinkel

H

H

H

N ...

L

L

Tabelle 3.7: Beispiel Inhalts einer Beobachtungstabelle Da sich nicht alle Diagnoseeigenschaften der Beobachtungen mit relativ geringem Aufwand in physikalische Modellgrößen überführen lassen oder im Modell verortet werden können, sollen weitere Modellierungsmöglichkeiten für solche Eigenschaften angeboten werden. Im Beispiel der Kundenbeanstandung „Motor klingelt/ klopft“ existiert unter anderem als Fehlerursache, dass die Geometrie des Brennraums verändert worden ist. Die Abweichung der Brennraumgeometrie kann nur mit höherem Aufwand in Modellgrößen abgebildet werden. Die Existenz dieser Modellgrößen dient nur zur Abbildung einer speziellen Diagnoseinformation der Kundenbeanstandung „Motor klingelt/ klopft“, ansonsten ist die Änderung beziehungsweise Abweichung der Brennraumgeometrie in der Regel selten der Fall. Da das Verhältnis zwischen Aufwand und Nutzen bei der Modellierung und der Diagnose nicht vertretbar ist, soll die Abbildung solcher Diagnoseinformationen nicht über Modellgrößen und den dazugehörigen Ort erfolgen (Abbildung 3.15), sondern durch eine direkte Zuweisung der Kundenbeanstandung auf verdächtige Komponenten (Diagnoseregel), in diesem Fall den Brennraum. Dabei soll ein Erklärungstext mit angegeben werden. Für die Erklärungskomponente des Diagnosetools ist der Erklärungstext notwendig, weil in diesem Fall das Diagnosemodell über kein „tieferes Wissen“ verfügt. Die Diagnoseregel für Kundenbeanstandungen in dieser Arbeit hat folgende

out

in

76

KAPITEL 3. WISSENSERHEBUNG Beanstandung1

Form:

out

in LampeRecht

Energie

Licht

• Wenn: Kundenbeanstandung obsk existiert •tran Dann: z

portu

comk

portl

tranm

– Verdächtige Komponenten: comi ,..., comi+n – Erklärungstext: Fehlerhypothesen Y1 ,..., Yn beschreiben, die die Verdächtigungen der Komponenten comi ,..., comi+n erklären obsk

in2

Material

in1

Material

Material

Material

Beanstandung2

in1

in2 out

Signal

Brennraum1

Brennraumx

out

Signal

out Material

Material

Abbildung 3.15: Kundenbeanstandung als Diagnoseregel Die Formalisierung der Kundenbeanstandung „Motor klingelt/ klopft“ mit der Fehlerhypothese „Änderung der Brennraumgeometrie“ kann wie folgt abgebildet werden: • Wenn: Kundenbeanstandung „Motor klingelt/ klopft“ existiert • Dann: – Verdächtige Komponenten: Brennraum1 ,..., Brennraumx – Erklärungstext: Änderung beziehungsweise Abweichung der Brennraumgeometrie Eine Zuordnung zwischen den Beanstandungen und den verursachenden physikalischen Größen des Modells erfolgt durch eine virtuelle Schnittstelle des Kundenbeanstandungsmodells. Damit können sich die physikalischen Größen für die Abbildung einer bestimmten Systemanregung sowohl eingangsseitig befinden, als auch zur Beobachtung des Antwortverhaltens ausgangsseitig angeordnet sein. Des Weiteren seien: COMk3obs - Menge aller systemeigenen Komponenten, die durch eine Kundenbeanstandung obsk mit Expertenwissen verdächtigt wurde COMk¬obs - Menge aller systemeigenen Komponenten, die durch eine Kundenbeanstandung obsk mit Expertenwissen nicht verdächtigt wurde. Dann gilt: COMk3obs ∩ COMk¬obs = .

77

3.6. ABBILDUNG DER BEANSTANDUNG

Die Möglichkeiten der oben beschriebenen Modellierung der Kundenbeanstandungen sind als Objektdiagramm in Abbildung 3.16 dargestellt. Das Objekt OBS_K1 ist die Instanz der Kundenbeanstandung „Motor klingelt/ klopft“. Die Instanz AttObs_1 der Klasse Zuordnung repräsentiert die Zuordnung der Beanstandung zur physikalischen Größe im Modell. Dabei wurde eine der Ursachen dieser Beanstandung an die Ausgangsschnittstelle (Ausgang_SV _1 der Instanz der Systemschnittstelle) des Kraftstoffsystems gebunden. Die Möglichkeit, eine Beanstandung als Diagnoseregel aufzustellen, wurde mit der Instanz DR_K1 der Klasse Regel dargestellt.

AttObs_1: Zuordnung

Massenfluss: Attribut

Ausgang_SV_1.Kraftstoff.Massenfluss = hoch

Einheit=g/s Wertebereich= {niedrig, normal, hoch}

OBS_K1: Beanstandung DR_K1: Regel Fehlerpfad= "Motorsystem – Brennraum" Fehlerart= "Änderung der Geometrie" Fehlerbeschreibung= "Bauteil Brennraum prüfen" Brennraum:Komponente

Motorsystem: System

Kraftstoff: Transportobjekt

VerbaleBeschreibung= "Motor klingelt/ klopft"

Ausgang_SV_1: Systemschnittstelle Richtung= aus Visualisierungstyp= material KraftstoffsystemModell: Basismodell

MotorsystemModell: Basismodell

Abbildung 3.16: Beispielhaftes Objektdiagramm einer Kundenbeanstandung

78

KAPITEL 3. WISSENSERHEBUNG

3.7

Abbildung der Tests

Auf die Modellierung der verschiedenen Testarten in der Werkstattdiagnose wird in diesem Abschnitt eingegangen. Die Onboard-Diagnose kann eine gezielte Anregung beziehungsweise Ansteuerung von Stellgliedern (Aktoren) der Regelstrecke innerhalb des Systems durchführen. Diese Funktionsfähigkeit der Stellglieder zu überprüfen, ist unverzichtbar in einem Diagnosevorgang und wird im ersten Teil dieses Abschnitts beschrieben. Im zweiten Teil wird die Abbildung des Komponententests erläutert.

3.7.1

Modellierung des Stellgliedtests actTestk

comi Stellmechanik links

VARi

comj

comk VARk

Stellmechanik rechts coml

Stellgliedtest1 Stellmotor links

Stellmotor rechts VARj

VARl

Abbildung 3.17: Beispielnotation eines Stellgliedtests im Modell des Lichtsystems Der Stellgliedtest ist ein Test, bei dem die Regelstrecke in einem System gegen die funktionalen Anforderungen geprüft wird. Die Modellierung des Stellgliedtests ist unkompliziert, da dieser comTest direkt an einek systemeigene Komponententest1 Komponentengruppe gebunden com ist. kDa das Ergebnis des Tests der Nachweis von vorhandenen beziehungsweise nicht vorhandenen Komponentenfehlern sowie die Korrektheit der Komponentenfunktionalität ist, beinhalten die Diagnoseinformationen VARk die Wertebelegungen der internen Funktions-, Zustands- und Fehlervariablen der zugehörigen in out Komponenten in der Regelstrecke (Abbildung 3.17). Es seien mit: Luftleitung Material ActT EST - Material Die Menge aller Stellgliedtests, die im Modell abgebildet sind actT estk - Der k-te Stellgliedtest im Modell. Dann gilt: actT estk ∈ActT EST . Eine Formalisierung der Ergebnisse von Stellgliedtests hinsichtlich der Funktions-, Zustandsund Fehlervariablen ist in dieser Arbeit wie folgt definiert: EkactT est - Menge aller qualitativen Relationen, die die Stellgliedtests actT estk beschreiben est - Die n-te qualitative Relation des Stellgliedtest actT est . eactT k k,n est ∈E actT est . Dann gilt: eactT k,n k est wird wie folgt definiert: Die qualitative relationale Gleichung eactT k,n qual

est :(V ARf unc , V ARsta , V ARf aul ) = (V ALf unc , V ALsta , V ALf aul ). eactT k,n k,n k,n k,n k,n k,n k,n

In Abbildung 3.18 sind drei Instanzen der Klassen InterneVariable, Stellgliedtest und Messungswissen dargestellt. Da die Ergebnisse des Stellgliedtests ST est_1 eine Aussage über die interne Variable M echanischeF ehler der Komponente StellmechanikLinks treffen, existiert eine direkte Verlinkung zwischen den beiden Objekten ST est_1 und M echanischeF ehler. Die Instanz M easEV 11 der Klasse Testwissen beinhaltet Informationen über Sicherheitshinweise, Prüfvoraussetzung und Testauswertung. Diese Informationen sind fahrzeugabhängig,

79

3.7. ABBILDUNG DER TESTS

daher existiert eine direkte Verlinkung zum Objekt GoldV und ein Link zum Objekt ST est1 .

Lichtsystem: System

MechanischeFehler: InterneVariable Wertebereich= {true, false} Beschreibung= “gebrochen bzw. verkleben“

LichtsystemModell: Basismodell

GoldV: Fahrzeug

StellmechanikLinks:Komponente

STest1_1: Testwissen Sicherheitshinweis= {path; filename.html} Prüfvoraussetzung= {path; filename.html} Testauswertung= {path; filename.html}

STest_1: Stellgliedtest StellmechanikLinks.MechanischeFehler= STest_1.ergebniss

Abbildung 3.18: Beispielhaftes Objektdiagramm eines Stellgliedtests im Modell des Lichtsystems

3.7.2

Modellierung des Komponententests

Eine weitere Diagnoseinformation, die nur bei der Offboard-Diagnose verfügbar ist, sind die Komponentenprüfungen. Die Anbindung solcher Prüfungen beziehungsweise Tests ist unkompliziert, da auch sie direkt an eine systemeigene Komponente gebunden sind (Abbildung 3.19). Eine automatische Anbindung zwischen der Komponente und der zugehörigen Prüfung in Form einer Datenbankabfrage ist möglich, wenn die systemeigene Komponente und deren Prüfung den gleichen Identifizierungscode besitzen. Es seien mit: ComT EST - Die Menge aller Komponentenprüfungen, die im Modell abgebildet sind comT estk - Die k-te Komponentenprüfung im Modell. Dann gilt: comT estk ∈ComT EST . Eine Formalisierung der Aussagen von Komponentenprüfungen hinsichtlich der Funktions-, Zustands- und Fehlervariablen ist in dieser Arbeit wie folgt definiert: EkcomT est - Menge aller qualitativen Relationen, die die Komponentenprüfungen comT estk beschreiben est - Die n-te qualitative Relation der Komponentenprüfung comT est . ecomT k k,n est ∈E comT est . Dann gilt: ecomT k,n k

comj

80

Stellmotor links

Stellmotor

KAPITEL 3. WISSENSERHEBUNG rechts VARj

Die

coml

Stellgliedtest1

VARl

est wird wie folgt definiert: qualitative relationale Gleichung ecomT k,n unc f aul est :(V ARf unc , V ARsta , V ARf aul )qual ecomT = (V ALfk,n , V ALsta k,n k,n k,n , V ALk,n ). k,n k,n

Komponententest1

comTestk

comk

VARk in

Luftleitung

Material

out Material

Abbildung 3.19: Beispielnotation eines Komponententests im Modell des Kraftstoffsystems

Luftsystem: System

Leckage: InterneVariable Wertebereich= {hoch, normal}

LuftsystemModell: Basismodell

Verstopfung: InterneVariable Wertebereich= {hoch, normal}

ME7.6_Corsa: Fahrzeug

Luftleitung:Komponente

KTest1_1: Testwissen Sicherheitshinweis= {path; filename.html} Prüfvoraussetzung= {path; filename.html} Testauswertung= {path; filename.html}

KTest_1: Komponententest Luftleitung.Leckage= KTest_1.ergebniss[0] Luftleitung.Verstopfung= KTest_1.ergebniss[1]

Abbildung 3.20: Beispielhaftes Objektdiagramm eines Komponententests im Modell des Lichtsystems

Um den beschriebenen theoretischen Modellierungsansatz des Komponententests zu erläutern, ist in Abbildung 3.19 die Instanz KT est_1 eines Komponententests dargestellt. Die Komponente Luf tleitung im Luf tsystem hat die zwei internen Fehlervariablen Leckage und V erstopf ung. Die Ergebnisse der Prüfung der Luftleitung auf Leckage und Verstopfung sind in dem Objekt KT est_1 abgebildet. Das fahrzeugabhängige Testwissen wird durch das Objekt KT est1_1 repräsentiert.

3.8. SYSTEMMODELLIERUNG

3.8

81

Systemmodellierung

Nachdem die modelltechnische Umsetzung zur Modellierung der Systemkomponente sowie die interne Messung (systemeigener Sensor) beschrieben wurden, wird in diesem Abschnitt auf die Modellierung der Systemschnittstelle und auf die Verbindungen zwischen den Komponenten eingegangen, die notwendig sind, damit das System vollständig modelliert ist.

3.8.1

Systemschnittstelle

In der realen Welt sind die Schnittstellen eines Systems eine Teilmenge der Schnittstellen seiner Komponenten. Daher beinhaltet eine Systemschnittstelle analog zur Komponentenschnittstelle drei Eigenschaften: Orientierung, Transportobjekt und Attribut. Obwohl eine Komponenten- und eine Systemschnittstelle ein und dasselbe reale Objekt repräsentieren, existiert in dem entwickelten Ansatz eine klare Unterscheidung zwischen Komponenten- und Systemschnittstellen. Komponentenschnittstellen sind mit dem Komponentenmodell gebunden, Systemschnittstellen hingegen eigenständige Objekte. Die Unterscheidung ist nötig, da sie zur Verbesserung der Wiederverwendbarkeit des Komponentenmodells und zur Kapselung des Systemmodells dient. Einige Schnittstellen der systemeigenen Komponenten besitzen eine zusätzliche Eigenschaft im Vergleich zu den übrigen Schnittstellen, da sie gleichzeitig Systemschnittstellen sind. Ohne eine Trennung zwischen Komponenten- und Systemschnittstellen wäre die Wiederverwendung des Komponentenmodells mittels Modellbibliothek erschwert, da die genannte Eigenschaft bei der Wiederverwendbarkeit entweder bei der Schnittstelle hinzugefügt oder entfernt werden müsste. Bei einem verhältnismäßig kleinen Systemmodell, das nur eine geringe Anzahl an Systemschnittstellen beinhaltet, ist eine manuelle Modifizierung durch den Modellierer vertretbar. Bei einem komplexen Systemmodell mit einer großen Anzahl an Schnittstellen ist eine manuelle Modifizierung nicht sinnvoll. Eine Lösung dieses Problems ist die Entwicklung eines zusätzlichen Algorithmus, der diesen Unterschied erkennt und das verwendete Komponentenmodell der Modellbibliothek automatisch ändert. Der Aufwand zur Implementierung dieses Algorithmus ist gering, es sinkt damit jedoch die Wartbarkeit des Modells und eine wichtige Eigenschaft der Schnittstelle würde vor dem Modellierer versteckt werden. Mit der Definition der Systemschnittstellen ist sich der Modellierer bewusst, dass er in diesem Schritt die Systemgrenze festlegt (Abbildung 3.21). In der Modellierungsebene, in der die Komponentenmodelle abgebildet sind, ist die Systemschnittstelle mit einem eigenständigen Symbol dargestellt. In der nächst höheren Modellierungsebene werden die Systemschnittstellen in Komponentenschnittstellen umgewandelt, weil in dieser Ebene die modellierten Systeme als Komponenten zu betrachten sind. Die Transformation ist einfach, da Systemschnittstellen alle Eigenschaften einer Komponentenschnittstelle beinhalten. Indem die Systemgrenze nur durch Systemschnittstellen definiert ist, eröffnen sich für den Diagnosevorgang mehrere Möglichkeiten zur Einsparung des Speicherbedarfs und der Rechnerzeit, wird doch nicht das komplette Modell zur Berechnung herangezogen, sondern nur ein Teil des Modells. Erst bei Bedarf werden weitere Teilmodelle geladen, bis die Diagnose abgeschlossen ist. Es seien mit: EXT P - Menge aller Systemschnittstellen extpn - die n-te Schnittstelle eines Systems. Dann gilt: extpn ∈EXT P

82

KAPITEL 3. WISSENSERHEBUNG

Die Spezifikation der Systemschnittstelle erfolgt analog zur Festlegung der Komponentenschnittstellen. Auch hier existieren nur zwei mögliche Flussrichtungen: „In“ und „Aus“. Es seien mit: EXT P in - Menge aller Eingangssystemschnittstellen EXT P out - Menge aller Ausgangssystemschnittstellen Dann gilt: EXT P =EXT P in ∪EXT P out .

Massenfluss: Attribut

Druck: Attribut

Einheit=g/s Wertebereich= {niedrig, normal, hoch}

Einheit=bar Wertebereich= {niedrig, normal, hoch}

Kraftstoff: Transportobjekt

Eingang_M: Schnittstelle

Eingang_V: Schnittstelle

Richtung= in Visualisierungstyp= material

Richtung= in Visualisierungstyp= material

Ausgang_S: Schnittstelle

Ausgang_M: Schnittstelle

Ausgang_V: Schnittstelle

Richtung= aus Visualisierungstyp= signal

Richtung= aus Visualisierungstyp= material

Richtung= aus Visualisierungstyp= material

Drucksensor:Komponente

Kraftstoffsystem: System PhysikalischeVerbindung[2]={Drucksensor. Ausgang_SL, Einspritzventil1.Eingang_V1}

Einspritzventil1:Komponente

Ausgang_SS: Schnittstelle Richtung= aus Visualisierungstyp= signal Art= systemschnittstelle

KraftstoffsystemModell: Basismodell Modellverlinkung[1]= (Ausgang_SV_1, Einspritzventil.Ausgang_V1} Modellverlinkung[2]= (Ausgang_SS_1, Drucksensorl.Ausgang_SM}

Ausgang_SV: Schnittstelle Richtung= aus Visualisierungstyp= material Art= systemschnittstelle

Abbildung 3.21: Beispielhaftes Objektdiagramm der Systemschnittstellen und Verbindungen

3.8. SYSTEMMODELLIERUNG

83

Die systemübergreifende Diagnose kann einfach über Systemschnittstellen erfolgen. Ist zum Beispiel das Symptom „Höchstleistung kann nicht erreicht werden“ im Verbrennungssystem beobachtet worden, liegt nach der Analyse des Verbrennungssystems eine der Ursachen an der Kraftstoffmenge, die in den Brennraum eingeflossen ist. Um die Ursache des Kraftstoffmangels zu bestimmen, wird das darüber liegende Systemmodell „Motorsystem“ analysiert. Anhand der Schnittstellen des Verbrennungssystems können die Analysealgorithmen in das Kraftstoffsystem gelangen und dort die Ursache lokalisieren. Diese Einfachheit der systemübergreifenden Diagnose ist mit Systemschnittstellen realisierbar; der Wechsel zwischen verschiedenen Systemen und Subsystemen bei der Analyse ist Voraussetzung für eine erfolgreiche Diagnose in großen Systemen mit komplexer Steuerung, Querwirkungen und einer großen Komponentenanzahl.

3.8.2

Verbindung

Die Strukturmodellierung eines Systems repräsentiert folgende Eigenschaften: Zum einen die Wiedergabe des kompositionalen Charakters der modellierten Komponenten beziehungsweise der dekompositionalen Eigenschaften des modellierten Systems, zum anderen die Darstellung der Zusammenhänge zwischen den abgebildeten Komponenten und Systemschnittstellen. Die innere Struktur eines Systems, die durch die Dekompositionsbetrachtungsweise entsteht, wird in dieser Arbeit mit Hilfe von Graphen dargestellt. Dabei sind die Knoten eines Graphen die systemeigenen, externen oder virtuellen Komponenten und Systemschnittstellen. Die Zusammenhänge zwischen den Komponentenmodellen untereinander sowie zwischen Systemschnittstellen und Komponentenmodellen werden im Systemmodell durch Verbindungslinien abgebildet und symbolisieren die Interaktion der Komponenten und Systemschnittstellen. Die Verbindungen werden durch Kanten des Graphen dargestellt. Für Verbindungen, die die reale beziehungsweise physikalische Interaktion abbilden, werden Linien ohne Unterbrechung zur Visualisierung verwendet. Dabei kann eine Verbindung (linkx ) nur existieren, wenn folgende Bedingungen gelten: • Nur eine Ausgangsschnittstelle comk .portout einer Komponente comk kann über eine i Verbindung mit einer Eingangsschnittstelle comk0 .portin j einer anderen Komponente comk0 verbunden sein (Abbildung 3.21) • In verbundenen Schnittstellen liegen dieselben transportierten Objekte mit denselben charakterisierenden Attributen vor (Abbildung 3.21). Es gelten: in comk .portout i .T RAN ⊆ comk0 .portj .T RAN in ∧ comk0 .portj .T RAN ⊆ comk .portout i .T RAN out in comk .porti .trann .AT T ⊆ comk0 .portj .trann .AT T out ∧ comk0 .portin j .trann .AT T ⊆ comk .porti .trann .AT T • Seien atty ein Attribut eines transportierten Objekts trann einer Ausgangsschnittstelleportout einer Komponente com und das entsprechende Atk i tribut attz des transportierten Objekts trann an der verbundenen Eingangsschnittstelle portin j der nachfolgenden Komponente comk0 , dann gilt valy = valz , das heißt, der Wert eines Attributs an der Eingangsschnittstelle einer verbundenen Komponente ist gleich dem Wert des gleichen Attributs an der Ausgangsschnittstelle der verbundenen Komponente.

84

3.9

KAPITEL 3. WISSENSERHEBUNG

Parametrisierung und Bedatung des Modells

Das Einbinden weiterer diagnoserelevanter Informationen wie Soll- und Grenzwerte der Sensorensignale, Ausfallwahrscheinlichkeit, entstehende Kosten bei Messung, Prüfung oder Reparatur von systemeigenen Komponenten, etc. erfolgt bei der Parametrisierung beziehungsweise Bedatung des Modells. Die individuellen Komponentendaten beziehungsweise Informationen sind von Fahrzeugtyp zu Fahrzeugtyp unterschiedlich und erschweren die Wiederverwendbarkeit, Pflege und Wartung des erstellten Modells erheblich. Eine Trennung der individuellen Daten von den Komponentenmodellen ist notwendig, weil dies den generischen Charakter der Modelle unterstützt und damit die Variantenvielfalt beherrschbar macht. Die Informationen über Soll- und Grenzwerte sowie Prüfungsmöglichkeiten der Komponenten sind notwendig, da ohne Sollwerte die Verwendung der qualitativen Werte {niedrig, normal, hoch} nicht realisierbar und ohne Prüfungsmöglichkeiten die Ausschließung der verdächtigen Komponenten nicht möglich ist. Dagegen sind Informationen über Ausfallwahrscheinlichkeiten und Kosten optional; diese Informationen dienen zur Optimierung des Diagnosevorgangs aber nicht zur Minimierung der Menge der verdächtigen Komponenten. Der Vorteil dieser Lösung ist die Kompletttrennung zwischen Modellierungs- und Parametrisierungsphase. Zusätzlich erfolgt in der Parametrisierungsphase eine Trennung zwischen Basisund Optimierungsmodellparametern. Dank dieser Aufteilung beschäftigt sich der Modellierer nicht mit technischen Daten wie Testmöglichkeiten, Soll- und Grenzwerten einer Komponente, sondern konzentriert sich darauf, wie das System aufgebaut ist, welche Komponente im betrachteten System verbaut wurde und welches Verhalten sie aufweist. Technische Daten einzelner Komponenten, die in dieser Arbeit als Basismodellparameter bezeichnet werden, können in einer separaten Datenbank eingepflegt werden. Wenn Daten der entsprechenden Hersteller vorliegen, können solche Daten mit geringem Aufwand in die Datenbank importiert werden. Eine Automatisierung des Datenimports ist möglich. Die Existenz einer derartigen externen Datenbank mit den Basismodellparametern der Komponenten ist unbedingte Voraussetzung für das korrekte Arbeiten des Diagnosesystems. Der größte Teil der darin gespeicherten Daten wird bereits in vorhandenen Systemen verwendet, denn diese Informationen sind unverzichtbar, gleichgültig welcher Diagnoseansatz verfolgt wird. Daher ist der erforderliche Aufwand zur Erstellung des neuen Diagnosesystems, das mit dem vorgestellten Modellierungskonzept arbeitet und einer zugehörigen Basismodellparameterdatenbank, relativ gering und der Aufbau ist mit vergleichsweise niedrigem Aufwand verbunden. Das Ergebnis der Trennung von Modellen und komponentenspezifischen Daten führt zu einer enormen Reduzierung der Anzahl benötigter Modelle und gleichzeitig zur Erzeugung getrennter Aufgabenbereiche, welche parallel abgearbeitet werden können. Die Wartung und weitere Entwicklung des Modells sowie der Basis- und Optimierungsmodellparameter können unabhängig voneinander geschehen. Die einzige Voraussetzung dieser Lösung ist die Konsistenz der Fahrzeug- und Komponentenidentifizierungsnummer in allen Datenbanken.

3.10

Behandlung der Variantenvielfalt

Die zunehmende Komplexität und Variantenvielfalt der Systeme im Fahrzeug ergeben sich aus der steigenden Kundenheterogenität und der Kostensenkung durch das Baukastenprin-

3.10. BEHANDLUNG DER VARIANTENVIELFALT

85

zip in der Entwicklung sowie Fertigung ([141], [106], [140], [10]). In der Vergangenheit wurden viele Arbeiten zum Thema Variantenmanagement am mechatronischen System veröffentlicht, in denen jedoch ausschließlich die Beherrschung der Varianten bei der Produktion und im Vertrieb behandelt wurde. Die Beherrschung der Komplexität und Variantenvielfalt der Fahrzeugsysteme/-funktionen in der freien Werkstattdiagnose bezieht sich auf die letzte Phase des Produktlebenszyklus - die Wartung und wird kaum betrachtet. Im Bereich der Softwareentwicklung existieren einige Lösungen zum Variantenmanagement, die speziell für die Wiederverwendung der Modelle geeignet sind ([60], [96], [58], [59], [97], [101], [117], [76]). Des Weiteren wurde in der modellgetriebenen Softwareentwicklung (MDA) der Modelltransformationsansatz vorgestellt. Dieser Ansatz ist zum Teil für die System-/Funktionsmodellierung sowie Wiederverwendung der Submodelle geeignet ([91], [8], [2], [79], [153], [45], [139]). Da die Diagnosemodelle sich durch einen Graphen repräsentiert lassen, sind solche Ansätze auf die Wiederverwendung der Struktur von Diagnosemodellen anwendbar ([123], [98]). Aufgrund der Gegebenheiten bei der Konstruktion und Produktion der Fahrzeugsysteme/-funktionen basiert das Lösungkonzept für die Problematik der Komplexität und Variantenvielfalt in dieser Arbeit auf verschiedenen Lösungsansätzen in der Softwareentwicklung. Neben der Wiederverwendung des Modellwissens in Form von Komponenten- und Systemmodellbibliotheken werden weitere Lösungen entwickelt. Eine Differenz zwischen unterschiedlichen Diagnosemodellvarianten liegt bei der Parametrisierung (siehe Abschnitt 3.9). Hier existiert eine Parallelität zwischen objektorientierter Programmierung und der Erzeugung der Diagnosemodelle (Abbildung 3.22). (Klasse

Instanziierung



Objekt) ⇔

(P hysikalischesSystemM odell

Instanziierung

LuftsystemME7.6.X ... ArrayList DTC; ...

CorsaCLuftsystem: LuftsystemME7.6.X ... DTC[6] = {P1113, DrallklappenPositionssensor, Funktionsstörung} ...



V ollstaendigesSystemM odell) AgilaTwinportLuftsystem: LuftsystemME7.6.X ... DTC[6] = {P1500, Drosselklappenstellmotor, Funktionsstörung} ...

AstraCaravanLuftsystem: LuftsystemME7.6.X ... DTC[6] = {P0505, Leerlaufdrehzahlregelung, Signal unplausibel} ...

Abbildung 3.22: Vollständige Modelle als Instanzen des physikalischen Modells am Beispiel des Luftsystems-ME7.6.x Wegen der unterschiedlichen Konstruktions- und Produktionsanforderungen existieren viele Komponenten in mechatronischen Systemen, die die gleichen Funktionen haben, doch unterschiedlich ausgelegt sind. Zum Beispiel existieren für die Verdichtung der Frischluft im Ansaugtrakt unterschiedliche Aufladekomponenten: Mechanische Kreisel-/Verdrängerlader, Druckwellenlader. Dabei wird die Verdichtungsleistung aus einer mechanischen beziehungsweise strömungstechnischen Koppelung oder einer Kombination beider Ansätze gewonnen.

86

KAPITEL 3. WISSENSERHEBUNG

Für die Modellbildung können all diese Auflader zu einer Komponente Kompressor generalisiert werden (Abbildung 3.23). Der Umgang mit Spezialisierung und Generalisierung in [58] für existierende Source-Codes bei der Softwareentwicklung wird in dieser Arbeit für die Modellentwicklung adaptiert und im Wissenserhebungstool implementiert. I0

Luft

O0

Kompressor

Luft

I1

Verdichtung I 1 .Verdichtung.Leistung : Leistung

I0

O0

Luft

Luft

Abgasturbolader

...

I1

Verdichtung + I 1 .Verdichtung.Temperatur : Temperatur

I0

O0

Luft

Luft

Spirallader

Verdichtung

I1 I2

Steuerung

+ I 2 .Steuerung.Signal : Signal

Abbildung 3.23: Generalisierung der Varianten am Beispiel der Luftlader

I0

O1 I0

Rohr4

Rohr1

O0

I1 O0

O0

I0 Rohr6

Passivkühlung

O0

I0 + Vth : IVariable

+ O1 : Ausgangsschnittstelle

O1 + I 1 : Eingangsschnittstelle + O1 : Ausgangsschnittstelle

Abbildung 3.24: Vererbung der Schnittstelle sowie der internen Variable am Beispiel des Kraftstoffrohrs Ein weiteres Basiskonzept der Objektorientierung, das sich auch in dieser Arbeit wiederfindet, ist die Vererbung. Bei dem Komponentenmodell äußert sich dieses Konzept durch die Vererbung der Komponentenschnittstellen und der internen Variablen der Komponente (Abbildung 3.24). Die Erweiterung der Ausgangsschnittstelle O1 der Komponente Rohr4 oder der internen Variable Vth der Komponenten Passivkühlung bewirkt eine Änderung des vorhandenen Verhaltens. Analog zur Klasse, die eine andere Klasse implementiert, ist die Änderung der Verhaltensbeschreibung gleich der Änderung der Methode in der implementierten Klasse. Zum Beispiel wird das Verhalten des Rohr1 wie folgt durch Rohr4 beziehungsweise Passivkühlung erweitert:

87

3.10. BEHANDLUNG DER VARIANTENVIELFALT 1. Rohr1

V ererbung



Rohr4: qual

Rohr1.I0 .Kraf tstof f.volumenstrom = Rohr1.O0 .Kraf tstof f.volumenstrom qual

Rohr4.I0 .Kraf tstof f.volumenstrom = Rohr4.O1 .Kraf tstof f.volumenstrom 2. Rohr1

V ererbung



V ererbung



qual

Rohr4.O0 .Kraf tstof f.volumenstrom

+

P assivkuehlung: qual

Rohr1.I0 .Kraf tstof f.temperatur = Rohr1.O0 .Kraf tstof f.temperatur

V ererbung



qual

P assivkuehlung.I0 .Kraf tstof f.temperatur P assivkuehlung.O0 .Kraf tstof f.temperatur



qual

P assivkuehlung.Vth

=

Die Wiederverwendung des Diagnosewissens durch Generalisierung und Spezialisierung in der Komponentenmodellebene unterstützt das Modelltransformationskonzept zur Variantenbehandlung in der Systemmodellebene.

Rohr1

TP_Sensor

Kompressor

Kühlung

HFM_Sensor

Filter

Rohr2

O1

I0

O0

I0

Rohr1

O2

O0

O0 I 0

TP_Sensor

I0

HFM_Sensor

Filter

O0 O0

I0 Kühlung

O0

I0 Abgasturbolader

O0

I0 Rohr2

I1

Abbildung 3.25: Modelltransformation am Beispiel eines Teils des Luftsystems mit Lader Eine Art der Modelltransformation in MDA ist die Modellmodifikation (Inplace Transformation). Dabei wird kein neues Modell erzeugt; die Transformation begrenzt sich auf die Modifizierung des Quellmodells ([115]). In Abbildung 3.25 wurde ein Teil des Luftsystems als Beispiel für die Anwendung dieses Ansatzes dargestellt. Das Quellmodell beinhaltet die Komponente Kompressor, die in dem konkreten Diagnosemodell für Mercedes Benz 220CDI (CP3-DS) durch die Komponente Abgasturbolader ersetzt wird. Ein weiterer Ansatz zur Behandlung von Modellvarianten in MDA ist die Modelltransformation. Diesem Lösungsansatz ähnelt die Wiederverwendung eines Teilmodells bei der Modellerzeugung in System- beziehungsweise Subsystemebene in dieser Arbeit. Diese Transformati-

88

KAPITEL 3. WISSENSERHEBUNG

onsart ermöglicht eine komplexere Änderung des Quellmodells. Hierbei werden neue Komponenten hinzugefügt und bestehende Komponenten verändert beziehungsweise entfernt ([139]). Am Beispiel des Lichtsystems mit Kurvenlichtfunktion (Abbildung 3.26) wird das Quellmodell des ALWR-Systems (automatisches Leuchtweitenregulierungssystem) um fünf Komponenten, die für die Kurvenlichtfunktion zuständig sind, erweitert. Weitere Änderungen betreffen die existierenden Komponenten. So ist die Komponente Leistungsmodul rechts um eine Eingangsund eine Ausgangsschnittstelle erweitert worden.

Gasentladungslampe rechts

Höhenstellmechanik rechts

O0

O0

Scheinwerfer rechts

Gasentladungs -lampe rechts

Scheinwerfer rechts

I0 Leitung Gasentladungslampe rechts

I1 +

I0

+

Höhenstellmotor rechts

Höhenstellmechanik rechts

O0 Leitung Höhenstellmotor rechts

Leitung Gasentladungs -lampe rechts

Leistungsmodul rechts

I0

Kurvenstellmechanik rechts I0

I0 O0

O0

Höhenstellmotor rechts

Kurvenstellmotor rechts I0

I0 O0

O0

Leitung Höhenstellmotor rechts

+

Leitung Kurvenstellmotor rechts

I0 O0

+

I0

O1 O2+

Leistungsmodul rechts I0

I1 + O0

+

Leitung Kurvendrehwinkelgeber rechts

I 0 O0

+ Kurvendrehwinkelgeber rechts

I0

Abbildung 3.26: Modellerweiterung am Beispiel eines Teils des Lichtsystems Neben der Spezifikation des Verhaltens in Form von Relationsgleichungen beinhaltet die Wissenserhebung die Modellierung der System-/Subsystemstruktur. Die Präsentation des Strukturwissens in dieser Arbeit ist durch Graphen formalisiert. Es existiert eine Reihe von Veröffentlichungen über Graphentransformation mit dem Ziel der Wiederverwendung des Modellwissens ([1], [18], [13], [48], [49], [75], [116], [119], [120], [142]). Die Modelle, die in verschiedenen Artikeln als Beispiele verwendet werden, sind häufig State-Diagramme beziehungsweise Klassen-Diagramme. Daher sind die Lösungsansätze nicht direkt in dieser Arbeit anwendbar. Ein nützlicher Ansatz für die Wiederverwendung des Diagnosemodells ist die

3.10. BEHANDLUNG DER VARIANTENVIELFALT

89

Markierung der Knoten in Graphen. Im Unterschied zum Variantenmanagement in DMA ist eine Art der Markierung die Verwendung von eindeutigen Funktionsbezeichnern der Knoten (Komponenten beziehungsweise Subsysteme). Im Gegensatz zu [8] werden hierbei nicht nur die eindeutigen Funktionsbezeichnungen für den Vergleich zwischen den Modellen (Graphen), sondern auch die internen Variablen, Komponentenschnittstellen und Zeilen der Verhaltenstabelle verwendet. Die Differenz zwischen den Modellen der Komponenten wird durch die Bildung der Schnittmenge berechnet. Der Abstand zwischen den Komponenten comi und comj , die gleiche Funktion besitzen (F unktion(comi ) ≡ F unktion(comj )), wird wie folgt berechnet: real = P ORT real /P ORT real (Differenz der Komponentenschnittstellen) 1. P ORTj/i j i

2. V ARj/i = V ARj /V ARi (Differenz der internen Variablen) beh = ROW beh /ROW beh (Differenz der Zeilen der Verhaltenstabelle) 3. ROWj/i i j

4. Der Abstand zwischen den Komponenten comi und comj (distance(comi , comj )) ergibt sich aus: real | + v ∗ |V AR | + r ∗ |ROW beh | distance(comi , comj ) = p ∗ |P ORTj/i j/i j/i

wobei p, v und r die Faktoren für Schnittstellen, interne Variablen und die Zeilen der Verhaltenstabelle sind. Die automatisierte Zusammenführung des Modellwissens auf Komponentenebene erfolgt durch die Bildung der Vereinigungsmengen bezüglich Komponentenschnittstellen, internen Variablen sowie Verhaltenstabellen. Analog der Berechnung des Abstands zwischen zwei Komponenten erfolgt die Vereinigung der beiden Komponenten. Es seien mit: comk = comi ∪ comj |F unktion(comi ) ≡ F unktion(comj ) Dann werden die Komponentenschnittstellen, internen Variablen und die Zeilen der Verhaltenstabelle der Komponente comk wie folgt berechnet: 1. P ORTkreal = P ORTjreal ∪ P ORTireal (Schnittmenge der Komponentenschnittstellen) 2. V ARk = V ARj ∪ V ARi (Schnittmenge der internen Variablen) 3. ROWkbeh = ROWibeh ∪ ROWjbeh (Schnittmenge der Zeilen der Verhaltenstabelle) Weitere Markierungen kennzeichnen Komponenten, die in einem System mit bestimmten Funktionen zwingend erforderlich sind ([44]). Zum Beispiel beinhalten alle Luftsysteme des Dieselmotors einen Luftfilter, mindestens einen Luftlader, eine Drosselklappe und einen Drucksensor. Diese Markierung erleichtert die Wiederverwendung des Strukturwissens bei der Modellierung eines neuen Systems, das die gleiche Funktion wie das vorhandene System besitzt. Zu dem unterstützt diese Markierung die Ermittlung der gemeinsamen Teilstrukturen im Modell. Die Differenz zwischen zwei Modellen, die die gleiche Funktion erfüllen (F unktion(M ODi ) ≡ F unktion(M ODj )), wird wie folgt berechnet: 1. COM j/i = COMj /COMi (Differenz der Komponentenmenge) 2. EXT P j/i = EXT P j/EXT P i (Differenz der Systemschnittstellenmenge) 3. LIN Kj/i = LIN Kj/LIN Ki (Differenz der Menge der Verbindungen) 4. Der Abstand zwischen zwei Modellen M ODi und M ODj (distance(M ODi , M ODj )) ergibt sich aus:

90

KAPITEL 3. WISSENSERHEBUNG distance(M ODi , M ODj ) = c ∗ |COM j/i| + e ∗ |EXT P j/i| + l ∗ |LIN Kj/i| wobei c, e und l die Faktoren für Komponenten-, Systemschnittstellen- und die Verbindungenmenge sind.

Bei der Zusammenführung der Systemmodelle werden die erforderlichen Komponenten, die maskiert sind, automatisch mitgenommen. Die Zusammenführung der restlichen Komponenten, Verbindungen und Systemschnittstellen obliegt dem Modellierer. Die letzte Markierungsart in dieser Arbeit markiert Komponenten, die mehrere Spezialisierungen besitzen. Die Komponente Luftlader (Abbildung 3.23) ist ein gutes Beispiel dafür. Diese Art erlaubt die Nutzung von abtrakten Modellen bei der Diagnose. Die Konkretisierung der Komponente für einen bestimmten Fahrzeugtyp beziehungsweise Systemart kann zu einem späteren Zeitpunkt erfolgen.

3.11

Modellprüfung

Die Vollständigkeit und Korrektheit eines Modells kann durch formale Beweise beziehungsweise durch Modellchecking sichergestellt werden. Diese Verfahren sind in der Regel nur auf einfache Modelle mit vertretbarem Aufwand anwendbar. Da das erstellte Diagnosemodell nicht nur physikalische Verhalten, sondern auch heuristisches Wissen beinhaltet, ist das einzige Mittel neben Review, um eine Aussage über die Qualität des erstellten Diagnosemodells mit vertretbarem Aufwand zu treffen, der Modelltest. Der Modelltest ist eine Aktivität, bei der das zu überprüfende Modell oder Teile des zu überprüfenden Modells mit Eingaben stimuliert und ihre Reaktionen beobachtet und bewertet werden ([9], [12], [16], [50], [89], [94], [63], [64], [108], [118]). Aufgrund des kontextfreien, lokalen Modellierungsansatzes der Funktionen und des Verhaltens der Komponenten, Teilsysteme und Systeme können Tests auf verschiedenen hierarchischen Detailebenen beziehungsweise Teststufen stattfinden (Abbildung 3.27): • Der Komponententest testet die kleinsten testbaren Einheiten eines Systemsmodells. Hierfür werden die Komponentenschnittstellen und das Verhalten der Komponenten im Normal- und Fehlerfall geprüft. • Der Integrationstest testet die Interaktionen der Komponenten durch sukzessives Aufbauen und überprüft das Verhalten immer größerer Teilsysteme. • Der Systemtest testet das erstellte Modell als Ganzes. Dabei wird das gesamte Systemmodell im Sinne der Diagnosefähigkeit getestet. Analog zur Methode des Softwaretests kann der Komponententest mit dem White-Box-Test, der Integrationstest mit dem Grey-Box-Test und der Systemtest mit dem Black-Box-Test verglichen werden ([14], [77], [84], [95], [147]). Entsprechend dem White-Box-Test kann der Modellersteller beziehungsweise Modellierer den Testfällen in Bezug auf interne Variablen und Komponentenschnittstellen des Komponentenmodells die Werte zuweisen. Testfälle, die das Komponentenmodell erfüllen muss, beinhalten folgende Überdeckungskriterien: • Schnittstellenüberdeckung: – Überprüfung der Anzahl der Eingangs- und Ausgangsschnittstellen

91

3.11. MODELLPRÜFUNG

– Betrachtung aller Schnittstellen mit ihren Transportobjekten und der beinhalteten Attribute mit dem dazugehörigen abstrakten Wertebereich • Interne Variablenüberdeckung: Untersuchung aller modellierten Variablen und deren qualitativen Auftrittswahrscheinlichkeiten. Testfälle, die die Überdeckungskriterien überprüfen, werden in dieser Arbeit Strukturtestfälle genannt. Diese Testfälle können aus der Funktionsbeschreibung beziehungsweise Spezifikation der Komponente gewonnen werden. Testfall

Strukturtest Komponententest

Verhaltenstest

Komponentenschnittstellentest

Gutverhaltenstest

Integrationstest

Systemschnittstellentest

Gutverhaltenstest

Verbindungentest Komponentenvollständigkeitstest Systemtest

Fehlverhaltentest

Symptomorientierter Test

DTCs-Test

Kundenbeanstandungstest

Systemsensortest

Abnahme der Sichtbarkeit des Modells

Fehlverhaltentest

Externer Sensortest

Abbildung 3.27: Verschiedene Testarten des erstellten Diagnosemodells Analog zum White-Box-Test kann der Modellierer die Erfüllung der Verhaltensspezifikation der modellierten Komponente prüfen (Verhaltenstest). Hierbei kann der Modellierer den Eingangs- und Ausgangsattributen sowie den internen Variablen Werte zuweisen. Anhand der vordefinierten Werte kann der Komponententest angestoßen werden. Die dafür benötigte Methode reduziert die Verhaltenstabelle der Komponente und splittet die Ergebnisse in mehrere Teiltabellen, zum Beispiel Tabelle mit Eingangsfehlern und internen Fehlern, Tabelle mit ausschließlich internen Fehlern, etc. Der Algorithmus, der diese Vorhaben unterstützt, wird in 4.2 beschrieben. Der Test beziehungsweise die Prüfung des modellierten Komponentenverhaltens kann durch Vergleich des erwarteten Komponentenverhaltens mit dem tatsächlich modellierten Verhalten durchgeführt werden. Die Testfälle für das „normale“ Verhalten einer Komponente werden automatisch von der Testplattform generiert. Dabei werden alle

92

KAPITEL 3. WISSENSERHEBUNG

Eingangsattribute sowie interne Variablen auf „normal“ gesetzt, die erwarteten Ausgangsattribute müssen logischerweise auch den Wert „normal“ annehmen. Für eine Komponente comi können die Testfälle für das „normale“ Verhalten wie folgt formal definiert werden: 1. Vorbedingungen: Es seien mit: - ∀portreal,in ∈ P ORTireal,in , wobei P ORTireal,in die Menge der Eingangsschnittstellen j der Komponente comi ist, in in - ∀tranin k ∈ T RANj , wobei T RANj die Menge der Transportobjekte ist, die sich in der Eingangsschnittstelle portreal,in befinden, j in in in - ∀attl ∈ AT Tk , wobei AT Tk die Menge der Attribute ist, die sich in dem Transportobjekt tranin k befinden, j - ∀var ∈ V ARi , wobei V ARi die Menge der internen Variablen der Komponente comi ist, dann: - vallatt,in = normal, wobei vallatt,in die Wertebelegung des Attributes attin l ist, var var - valj = normal, wobei valj die Wertebelegung der internen Variable varj ist. 2. Nachbedingungen: Es seien mit: - ∀portreal,out ∈ P ORTireal,out , wobei P ORTireal,out die Menge der Ausgangsschnittj stellen der Komponente comi ist, out in - ∀tranout k ∈ T RANj , wobei T RANj die Menge der Transportobjekte ist, die sich in der Eingangsschnittstelle portreal,out befinden, j out , wobei AT T out die Menge der Attribute ist, die sich in dem Trans∈ AT T - ∀attout k k l befinden, portobjekt tranout k dann: ist. - vallatt,out = normal, wobei vallatt,out die Wertebelegung des Attributes attout l Wenn eine Abweichung bei den Nachbedingungen existiert, dann liegt bei der Modellierung des Komponentenverhaltens mindestens ein Fehler vor. Ähnlich wie der Komponententest können die Testfälle bei dem Integrationstest in Strukturtestfälle und Verhaltenstestfälle unterschieden werden. Die Strukturtestfälle in dem Integrationstest beinhalten folgende Testarten: • Systemschnittstellentest: Analog zum Komponententest beinhaltet diese Testart die gleichen Überdeckungskriterien wie bei dem Schnittstellenüberdeckungstest • Verbindungentest: – Überprüfung der Anzahl und der Richtung der Verbindungen zwischen den Komponenten – Überprüfung der Kompatibilität der Schnittstellen, die durch eine Verbindung gebunden sind

93

3.11. MODELLPRÜFUNG

• Komponentenvollständigkeitstest: Überprüfung der Anzahl der systemeigenen, virtuellen und externen Komponenten, die das Modell beinhaltet. In dem Integrationstest existieren zwei Möglichkeiten, um den Verhaltenstest durchzuführen: • Erste Variante: Der Tester kann den Eingangs- und Ausgangsattributen sowie den internen Variablen die Werte, die im Testfall vordefiniert sind, zuweisen. Nach den Wertezuweisungen wird eine Simulation mit diesen Werten durchgeführt. Als Ergebniss erhält er für einzelne Komponenten eine reduzierte Verhaltenstabelle, die er mit dem erwarteten Verhalten vergleichen kann. • Zweite Variante: Im Unterschied zur ersten Variante bestehen die erwarteten Ergebnisse nicht aus reduzierten Verhaltenstabellen, sondern aus einer Menge der verdächtigen Komponenten und einer Menge der nicht verdächtigen Komponenten. Ein Testfall in dieser Variante besteht aus drei Teilen: – Vorbedingungen sind aus vordefinierten Beobachtungen, zugewiesenen Sensorwerten oder Fehlercodes zusammengesetzt – Invarianten können aus den im Systembetriebsmodus zugewiesenen Werten der internen Variablen der Systemkomponenten bestehen – Nachbedingungen definieren die erwarteten Ergebnisse in Form von Mengen der verdächtigen Komponenten und nicht verdächtigen Komponenten. Die Formalisierung der zweiten Variante des Integrationstests kann wie folgt beschrieben werden: 1. Vorbedingungen (P reconditionj ): - M ODi - das erstellte Modell, das sich im Integrationstest befindet, - OBSjtestcase ⊆ OBSi , wobei OBSi die Menge der Beobachtungen in dem Modell M ODi ist, - DT Cjtestcase ⊆ DT Ci, wobei DT Ci die Menge der Fehlercodes in dem Modell M ODi ist, qual

- (SENjtestcase → IST W ERTjtestcase,sen )|SENjtestcase ⊆ SEN i, wobei SEN i die Menge der Systemsensoren ist, die sich in dem Modell M ODi befinden; IST W ERTjtestcase,sen ist die Menge der Systemsensoristwerte, die für den Integrationstest zur Verfügung stehen, qual

- (M EASjtestcase → IST W ERTjtestcase,meas )|M EASjtestcase ⊆ M EASi , wobei M EASi die Menge der externen Messungen ist, die sich in dem Modell M ODi befinden. IST W ERTjtestcase,meas ist die Menge der Messungenistwerte, die für den Integrationstest zur Verfügung stehen, qual

- (ActT ESTjtestcase → V ALtestcase,acttest )|ActT ESTjtestcase ⊆ ActT EST i, wobei j ActT EST i die Menge der Stellgliedtests ist, die sich in dem Modell M ODi befinden. V ALtestcase,acttest ist die Menge der qualitativen Wertebelegungen, die für den j Integrationstest zur Verfügung stehen, qual

- (ComT ESTjtestcase → V ALtestcase,comtest )|ComT ESTjtestcase ⊆ ComT EST i, wobei j ComT EST i die Menge der Komponententests ist, die sich in dem Modell M ODi befinden. V ALtestcase,comtest ist die Menge der qualitativen Wertebelegungen, die für dan j Integrationstest zu Verfügung stehen.

94

KAPITEL 3. WISSENSERHEBUNG 2. Invarianten (Invariantj ): qual

- (V ARjtestcase,sta → V ALtestcase,sta ))|V ARjtestcase,sta ⊆ V ARista , wobei V ARista die j Menge der internen Zustandvariablen der Komponenten ist, die in dem Modell M ODi abgebildet sind. V ALtestcase,sta ist die Menge der qualitativen Wertebelegungen, die j für den Integrationstest immer gelten müssen. 3. Nachbedingungen (P ostconditionj ): - COMj¬OK,post |COMj¬OK,post ⊆ COMi , wobei COMi die Menge der Komponenten ist, die in dem Modell M ODi abgebildet sind. COMj¬OK,post ist die Menge der verdächtigen Komponenten, - COMjOK,post |COMjOK,post ⊆ COMi , wobei COMi die Menge der Komponenten ist, die in dem Modell M ODi abgebildet sind. COMjOK,post ist die Menge der nicht verdächtigen Komponenten. Nach der Spezifikation der Testfälle kann eine automatische Testdurchführung und Testauswertung mittels der Testplattform gestartet werden. Die Testauswertung basiert auf dem Vergleich zwischen den erwarteten Komponentenmengen, die in den Nachbedingungen stehen, und den berechneten Komponentenmengen, die durch den Aufruf des Diagnosealgorithmus mit den Vorbedingungen, Invarianten und dem unter Test stehenden Modell als Eingaben entstanden sind. Diese Testauswertung ist analog zu dem Testorakel in der Softwareentwicklung ([121], [82], [129]). Es gelten: - (COMjOK,soll ⊆ COMjOK,post ) ∧ (COMjOK,post ⊆ COMjOK,soll ) - (COMj¬OK,soll ⊆ COMj¬OK,post ) ∧ (COMj¬OK,post ⊆ COMj¬OK,soll ) - COMjOK,soll ∩ COMj¬OK,soll = Analog dazu ist die Menge der verdächtigen Komponenten, die aus der Analyse stammt (COMj¬OK,ist ), und die Menge der nicht verdächtigen Komponenten (COMjOK,ist ) disjunkt: - COMjOK,ist ∩ COMj¬OK,ist = Das Ergebniss der Auswertung des Integrationstests ist abhängig von zwei Schnittmengen. Eine dieser Mengen ist die Schnittmenge zwischen Soll- und Ist-Menge der nicht verdächtigen Komponenten: - COMjOK = COMjOK,soll ∩ COMjOK,ist Die zweite Menge, die für die Auswertung zur Verfügung steht, ist die Schnittmenge zwischen Soll- und Ist-Menge der verdächtigen Komponenten: - COMj¬OK = COMj¬OK,soll ∩ COMj¬OK,ist Analog zur Testnotationssprache TTCN-3 ([57]) besteht das Testurteil in dieser Arbeit aus verschieden Stufen: Bestanden, nicht entscheidbar positiv, nicht entscheidbar, nicht entscheidbar negativ und fehlgeschlagen. Mengenrelation

Testurteil

Bewertung B(COMjOK )

COMjOK,soll = COMjOK,ist

bestanden

++

nicht entscheidbar positiv

+

COMjOK,ist



COMjOK,soll

95

3.11. MODELLPRÜFUNG COMjOK,soll ⊂ COMjOK,ist (COMjOK,ist /COMjOK 6= )∧ (COMjOK,soll /COMjOK 6= )∧ (COMjOK 6= ) COMjOK,soll ∩ COMjOK,ist =

nicht entscheidbar

0

nicht entscheidbar negativ

-

fehlgeschlagen

--

Tabelle 3.8: Testurteil für die nicht verdächtige Menge COMjOK = COMjOK,soll ∩COMjOK,ist Die Unterteilung in verschiedene Stufen ermöglicht die Priorisierung der Bugfixe des Modells. Im Folgenden werden die Testurteile in Abhängigkeit zur Kardinalität der Menge COMjOK und deren Relationen zu den Mengen COMjOK,soll , COMjOK,ist in Form von Tabelle 3.8 dargestellt. Analog zur Auswertung der entstehenden Menge COMjOK wird die Bewertungstabelle 3.9 für COMj¬OK aufgebaut. Der Unterschied zwischen den beiden Auswertungstabellen besteht in den Zeilen 3 und 4, hier werden Zeilen wegen der Negation ausgetauscht. Mengenrelation

Testurteil

Bewertung B(COMj¬OK )

COMj¬OK,soll = COMj¬OK,ist

bestanden

++

COMj¬OK,soll ⊂ COMj¬OK,ist COMj¬OK,ist ⊂ COMj¬OK,soll (COMj¬OK,ist /COMj¬OK 6= )∧ (COMj¬OK,soll /COMj¬OK 6= )∧ (COMj¬OK 6= ) COMj¬OK,soll ∩ COMj¬OK,ist =

nicht entscheidbar positiv

+

nicht entscheidbar

0

nicht entscheidbar negativ

-

fehlgeschlagen

--

Tabelle 3.9: Testurteil für die verdächtige Menge COMj¬OK = COMj¬OK,soll ∩ COMj¬OK,ist Da die Menge COMjOK und die Menge COMj¬OK disjunkt sind, erfolgt das gesamte Testurteil BjM ODi durch die Addition der Bewertungspunktzahl des einzelnen Testurteils: - BjM ODi = B(COMjOK ) + B(COMj¬OK ) Die letzte Testphase des Modells in dieser Arbeit ist der Systemtest. Ziel dieses Tests ist die Überprüfung des Diagnosemodells gegen seine Anforderungen. Ausgehend von Diagnosefunktionsanforderungen werden Testfälle abgeleitet. Da die Diagnose in der Werkstatt symptomorientiert ist, sollen die Testfälle auch symptomorientiert spezifiziert werden. Es existieren drei Vorgehensweisen, wie der Systemtest durchgeführt werden kann: • Testfall im Systemtest besteht aus einer Testsequenz. Ein Test in dieser Sequenz ist analog zur zweiten Variante des Gray-Box-Tests aufgebaut (Test mit Vorbedingungen, Invarianten und Nachbedingungen). Bei der Spezifizierung des einzelnen Tests in der Sequenz müssen folgende Bedingungen beachtet werden. Es seien mit: - T estk - der k.te Test in der Sequenz, - T estk+1 - der (k+1).te Test in der Sequenz, dieser Test muss nach dem k.ten Test durchgeführt werden.

96

KAPITEL 3. WISSENSERHEBUNG Dann gilt: - P reconditionk ⊆ P reconditionk+1 - Invariantk ⊆ Invariantk+1 OK ⊇ COM OK - wobei (COM OK ⊆ P ostcondition OK ⊆ - COMk+1 k+1 ) ∧ (COMk k k+1 P ostconditionk ) ¬OK ⊆ COM ¬OK - wobei (COM ¬OK ⊆ P ostcondition ¬OK ⊆ - COMk+1 k+1 ) ∧ (COMk k k+1 P ostconditionk ).

Das Testurteil eines Testfalls dieser Art ergibt sich aus der gesamten Auswertung der einzelnen Testfälle. • Die zweite Möglichkeit wird in dieser Arbeit Rekursionstest genannt. Es wird nur ein Test definiert, in welchem neben Vor- und Nachbedingungen, die analog zum Gray-BoxTest aufgebaut sind, die Invarianten des Tests erweitert werden, indem in den Invarianten die Abbruchbedingung des Rekursionsaufrufs spezifiziert wird. In dieser Arbeit ist die Abbruchbedingung die Anzahl des rekursiven Aufrufs. Die Testausführung wird wie folgt beschrieben. Es seien mit: - T estk - der k.te Testaufruf; mit n als Anzahl des rekursiven Aufrufs gilt: 0 < k ≤ n - T estk+1 - der (k+1).te Testaufruf ((k + 1) ≤ n). Dann gilt: - (P reconditionk+1 = P reconditionk ∪ P ostconditionk )|(k = 1). Die Reduzierung der verdächtigen Komponenten kann nicht nur durch die Vereinigung der Vor- und Nachbedingungen des k.ten Testaufrufs erfolgen. Weitere Diagnoseinformationen müssen hinzugefügt werden. Da die Durchführung des nächsten Tests automatisiert laufen soll, wird die benötige neue Diagnoseinformation mittels hypothetischer Wertebelegung der Modellgrößen angenommen. Hierbei wird der Diagnosealgorithmus K, der in Kapitel 4 Abschnitt 3 beschrieben ist, gestartet. Die Ausgabe dieses Algorithmus ist eine priorisierte Liste der Messungen und einfachen Tests, die im nächsten Schritt im Diagnosevorgang vom Werkstattpersonal durchgeführt werden soll. Für die hypothetische Wertebelegung wird das erste Element (Elementk ) der Liste ausgewählt und es werden alle möglichen Wertebelegungen (V Al = val1 , ...valm ) angenommen. Die Weiterführung des Tests erfolgt mit einzelnen Werten der möglichen Wertebelegungen. Dabei existiert eine Verzweigung ab dem zweiten Rekursivaufruf. - (P reconditionk+1 = P reconditionk (Elementk−1 = valj ) ∪ P ostconditionk ) ∪ (Elementk = vali )|(1 < k) ∧ (1 ≤ i ≤ m). Wegen der hypothetischen Wertebelegung bestehen die Ergebnisse des Testdurchlaufs (T estResult) aus einer Menge des Ergebniselements (resulti |resulti ∈ T estResult) in Abhängigkeit zur Hypothese. Das Testurteil entsteht durch den Vergleich zwischen resulti und der vordefinierten Nachbedingung P ostcondition. • Eine dritte Möglichkeit ist die Überprüfung direkt am Versuchsträger. Dazu werden zuerst die Fehler am Fahrzeug eingebaut. Unter Werkstattbedingungen werden anhand des erstellten Modells und mittels des Diagnosetools die zuvor eingebauten Fehler gesucht. Für die Auswertung des Testes steht das Diagnoseprotokoll, das alle Aktivitäten des

3.11. MODELLPRÜFUNG

97

Tester protokolliert, zur Verfügung. Diese Vorgehensweise kann auch als Abnahmetest betrachtet werden.

98

4

Inferenzmechanismen noseerstellung

zur

Diag-

Algorithmus-D-Input - Kundenbeanstandungen - Fehlercodes - Messwerte der systemeigenen Sensoren und der externen Messungen - Durchgeführte Stellglied- und Komponententests

D1. Aufbereitung der eingegebenen Diagnoseinformationen Nein

Symptome existieren?

Ja

Defekte Komponenten existieren?

Setzen der Attribute im Modell gemäß der Eingabedaten (Algorithmus A)

D2. Verdachtsgenerierung und -überprüfung Propagierung der Attribute im Modell zur Ermittlung verdächtigter Komponenten (Algorithmus P) Bewertung der verdächtigten Komponenten mit Bewertungspunktzahlen (Algorithmus B)

Änderung der Eingabedaten

Einschränkung der zu diagnostizierenden Komponenten durch direkte Zuordnung (Algorithmus E)

D3. Koordinierung der Sensoren-, Messungseinsätze, der Komponententests und Reparatur oder Austauschen von Komponenten mit Ranking Ermittlung von möglichen Messaktionen und einfachen Komponententests mit Ranking (Algorithmus K) Auswahl komplizierter Komponententests mit Skyline Algorithmus (Algorithmus S)

Algorithmus-D-Output - Liste der Messungen und einfachen Komponententests mit Rangfolge - Liste der verdächtigen Komponenten mit Priorisierung

Messung, Test, Prüfung beziehungsweise Reparatur oder Austausch der Komponente

Abbildung 4.1: Diagnostik-Algorithmus D Neben dem angewendeten Diagnoseansatz und dem System- und Erfahrungswissen des Werkstattmitarbeiters hat auch der Diagnoseprozess große Auswirkung auf die Fehlerlokalisierung und Fehlerbehebung im Bereich der Werkstattdiagnose. Da der Diagnoseprozess direkten Einfluss auf die Entwicklung der Inferenzkomponente in einem Diagnoselaufzeitsystem hat, wird

4.1. AUFBEREITUNG DER EINGABEDATEN (ALGORITHMEN E UND A)

99

in diesem Kapitel der zu entwickelnde Diagnosealgorithmus unter Berücksichtigung des Diagnoseprozesses in der freien Werkstatt anhand der wesentlichen Schritte erläutert. Da der Diagnosealgorithmus D im Kapitel 1 bereits beschrieben ist (Algorithmus 1.1), werden hier die Schritte dieses Algorithmus in Form eines Ablaufdiagramms dargestellt (Abbildung 4.1). Dabei besteht der Input des Diagnosealgorithmus aus folgenden Mengen: - Menge der Kundenbeanstandungen OBS input , die sich bei der Fahrzeugannahme beziehungsweise bei Probefahrt durch das Werkstattpersonal ergaben (OBS input ⊂ OBS). - Menge der vorhandenen Fehlercodes (DT C input ⊂ DT C). - Menge der Modellgrößen mit Wertebelegung, die sich durch systemeigene Sensoren bestimmen lassen (SEN input ⊂ SEN ). - Menge der Modellgrößen mit Wertebelegung, die sich durch externe Messungen bestimmen lassen (M EAS input ⊂ M EAS). - Menge aller Stellglied- und Komponententests, die durchgeführt wurden (ActT EST input ⊂ ActT EST ∧ ComT EST input ⊂ ComT EST ). Als Ergebnisse liefert der Algorithmus zwei Listen. Die erste Liste beinhaltet Systemsensoren, externe Messungen und einfache Tests beziehungsweise Prüfungen mit Rangfolge (zum Beispiel: Stellgliedtests oder Sichtprüfung). Diese Liste ist die Handlungsempfehlung an das Werkstattpersonal und soll abgearbeitet werden, weil das Laufzeitsystem anhand der vorhandenen Diagnoseinformationen den Benutzer bei der Fehlersuche führen soll. Die Führung muss aber weiterhin die Möglichkeit geben, dass der Nutzer frei entscheiden kann. Die zweite Liste enthält die verdächtigen Komponenten und gibt dem Werkstattpersonal einen Überblick über verschiedene Optionen, die für ihn interessant sind, zum Beispiel: Ausfallwahrscheinlichkeit, Prüfzeit, Prüfkosten, Verfügbarkeit der Ersatzteile. Da der Diagnoseprozess in der Werkstatt ein symptomorientierter Diagnoseprozess ist, sind die Abbruchbedingungen dieses Algorithmus die nicht vorhandenen Symptome. Demzufolge besteht die Abbruchbedingung aus folgenden Bedingungen: (OBS input = ) ∧ (DT C input = ) ∧ (parami = (atti , OK)|parami ∈ (SEN input ∪ M EAS input ) ∧ (paramj = (varj , OK)|paramj ∈ (ActT EST input ∪ ComT EST input )) Der Algorithmus wird immer neu aufgerufen, wenn die Ergebnisse der gerade durchgeführten Messungen beziehungsweise Prüfungen oder Tests vorliegen. Mit diesen neuen Diagnoseinformationen kann der Algorithmus die Liste der verdächtigen Komponenten reduzieren und die Komponenten neu bewerten. Außerdem wird mit diesen zusätzlichen Informationen die Rangfolge der Messungen und einfachen Tests beziehungsweise Prüfungen neu berechnet.

4.1

Aufbereitung der Eingabedaten (Algorithmen E und A)

Zu Beginn werden die verfügbaren Diagnoseinformationen in Form von Kundenbeanstandungen, Fehlercodes, Messungen und Komponentenzuständen (Algorithmus-D-Input) analysiert. Dieser Schritt wird in diesem Abschnitt mit den beiden Algorithmen E und A beschrieben. Es ist erforderlich, dass der Algorithmus E vor dem Algorithmus A geschaltet ist, da mechatronische Systeme häufig über eine Onboard-Diagnose-Funktion verfügen, welche die elektrischen Fehler der Sensoren und Aktoren sofort identifiziert und in Fehlerspeichern als

100

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

Fehlercodes ablegt. Diese Diagnoseinformationen verkürzen den Diagnosevorgang, weil damit defekte Komponenten direkt aufgezeigt werden und zuerst bearbeitet werden sollen. Mit den Ergebnissen des Algorithmus E werden die Einschränkungen der zu diagnostizierenden Komponenten berechnet. Dagnach ermittelt der Algorithmus A die möglichen modellgrößenbezogenen Abbildungen der Kundenbeanstandungen, Fehlercodes, Messungen und Tests beziehungsweise Prüfungen. Die Eingabe, die für Algorithmus D zur Verfügung steht, ist auch die Eingabe des Algorithmus E. Dabei wird die Diagnoseinformation zur Einschränkung der verdächtigen Komponenten ausschließlich aus existierenden Fehlercodes (0 < |DT C input |) ermittelt. Algorithmus 4.1 : Diagnostik-Algorithmus (E) Eingabe: (Input Algorithmus E) - Menge der existierenden Fehlercodes, die aus dem Input des Algorithmus D stammen Ausgabe: (Output Algorithmus E) - Menge der systemeigenen Komponenten COM ¬OK , die durch Fehlercodes verdächtig sind. Algorithmus: Wissen für Algorithmus E: Wenn Fehlercodes, die durch die Eigendiagnosefähigkeit des Steuergeräts bei Fehlverhalten des Systems auf bestimmte Komponenten zeigen, exsistieren, dann werden die entsprechenden Fehlercodes im Diagnosemodell und die zugehörigen Komponenten in einer Tabelle erfasst (Tabelle 4.1). DT C input

Komponentenbezogene Diagnoseparameter

{DT Ci }

{com3 , ..., com12 }

{DT Cj }

{com8 } ...

{DT Ck , ..., DT Cm }

{com9 , ..., com13 }

Tabelle 4.1: Darstellung der Menge COM DT C,¬OK in Tabellenform E Die Zuordnung der Fehlercodes zu defekten Komponenten gemäß Wissen erfolgt mittels eines einfache Suchalgorithmus. Algorithmus 4.2 : Diagnostik-Algorithmus (A) Eingabe: (Input Algorithmus A) - Diagnoseinformationen, die aus dem Input des Algorithmus D stammen - Menge der Kundenbeanstandungen - Menge der Fehlercodes, die auf Modellgrößen zeigen - Menge der Modellgrößen mit Wertebelegung, die sich durch Messungen mittes systemeigene Sensoren und externe Messgeräte entstanden sind

101

4.1. AUFBEREITUNG DER EINGABEDATEN (ALGORITHMEN E UND A)

- Menge der entstehenden Diagnoseinformationen aus den Komponententests und Stellgliedtests Ausgabe: (Ouput Algorithmus A) - Menge der attributbezogenen Diagnoseparameter P ARAM . Dabei ist ein Element parami ∈ P ARAM ein Tupel ((AT Tiinput , V ALinput ), (V ARif unc , V ALfi unc ), (V ARista , i f aul f aul V ALsta , V ALi ), (AT Tiout , V ALout i ), (V ARi i )) Algorithmus: Wissen für Algorithmus A Die Abbildungen der Kundenbeanstandungen werden im Modell gesucht. Die Attribute und deren Wertebelegungen werden gefiltert und bilden eine Menge der modellgrößenbezogenen Diagnoseparameter (P ARAM OBS ), die aus Kundenbeanstandungen stammen. Diese Menge der Diagnoseparameter kann in Tabellenform dargestellt werden (Tabelle 4.2). OBS input

Diagnoseparameter {obs1 }

{obs1 , obs2 }

{obs2 }

...

{obs2 , obs3 , ..., obs6 }

{obs6 }

com1 .port2 .tran1 .att4

{H}

{L}



...

{H}



com4 .port3 .tran3 .att2







...

{H}

{L}

{H}

...





... com8 .port3 .tran4 .att1



{L}

Tabelle 4.2: Darstellung der P ARAM OBS in Tabellenform1 Eine Spalte der Tabelle 4.2 entpricht einem Parametersatz paramOBS , der propagiert i werden muss, da die Modellgrößen und deren zugehörige Wertenbelegungen eines Parametersatzes, die sich in paramOBS befinden, eine beziehungsweise mehrere Kundenbeani standungen erklären. Es gilt: paramOBS ∈ P ARAM OBS i Die Fehlercodes, die in Steuergeräten gespeichert sind, werden analysiert. Analog zur Kundenbeanstandung soll für Fehlercodes, die auf Modellgrößen zeigen, ein Tupel der Diagnoseparameter ermittelt werden (Tabelle 4.3). DT C input

Diagnoseparameter dtc2

dtc4

...

dtc7

dtc8

com3 .port1 .tran2 .att1

{L, H}



...





com3 .port3 .tran1 .att2



{H}

...

{H}





...



{L, H}

... com9 .port1 .tran2 .att1



Tabelle 4.3: Darstellung der P ARAM DT C in Tabellenform Die Analyse der Diagnoseinformationen von ausgelesenen systemeigenen Sensoren und 1

comi .portj .trank .attl := i-te Komponente. j-te Schnittstelle. k-tes Transportobjekt. l-tes Attribut {H} := hoch; {L} := niedrig: {N } := normal

102

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG den durchgeführten externen Messungen ist gleich. Die Tabelle 4.4 stellt die Menge der Diagnoseparameter (P ARAM SEN ) dar, die aus der Analyse von Sensoren entstanden sind. Die Tabelle 4.5 stellt die Menge der Messungen mit den zugehörigen Messwerten (P ARAM M EAS ) dar. SEN input

Diagnoseparameter com1 .port2 .tran3 .att1

sensor1

sensor3

...

sensor5

{H}



...





...

{L}

... −

com6 .port2 .tran1 .att3

Tabelle 4.4: Darstellung der P ARAM SEN in Tabellenform M EAS input

Diagnoseparameter messung1

...

messung2

messung6

com2 .port2 .tran3 .att1

{L}

...





com3 .port2 .tran4 .att1



...



{H}

...

{L}



... com5 .port5 .tran3 .att1



Tabelle 4.5: Darstellung der P ARAM M EAS in Tabellenform Aus den Komponenten- beziehungsweise den Stellgliedtests entstehen zwei Komponentenmengen. Dabei ergibt sich eine Menge der systemeigenen Komponenten, die durch einen Test als in Ordnung identifiziert wurden. Analog resultiert eine Menge der Komponenten, die als fehlerhaft befunden wurden. Die Aussagen über die Zustände der Komponenten können aus den Testergebnissen gezogen werden. Diese Informationen müssen bei der Diagnose auch berücksichtigt werden. Die Menge der entstehenden Informationen aus den Komponententests wird als P ARAM ComT EST bezeichnet und die Menge der Informationen aus den Stellgliedtests als P ARAM ActT EST (Tabelle 4.6, Tabelle 4.7). ComT EST input

Diagnoseparameter com3 .var1f unc com3 .var3f aul

comtest2

comtest3

...

comtest5

{L}



...





{N }

...





...

{H}

... com7 .var1f aul



Tabelle 4.6: Darstellung der P ARAM ComT EST in Tabellenform Aus den einzelnen Analyseergebnissen von Kundenbeanstandungen, Fehlercodes aus Steuergeräten, Messwerten der systemeigenen sowie externen Messungen, Komponenten- und Stellgliedtests werden in diesem Schritt die modellgrößenbezogenen Diagnoseparameter

103

4.2. VERDACHTSGENERIERUNG zusammengeführt. Es gilt: (|P ARAM | = |P ARAM OBS ) ∧ (∀parami ∈ P ARAM | parami = paramOBS ∪ P ARAM DT C ∪ P ARAM SEN ∪ P ARAM M EAS ∪ i P ARAM ComT EST ∪ P ARAM ActT EST ) ⇔ parami = ((AT Tiinput , V ARif unc , V ARista , V ARif aul , AT Tiout ) → f aul (V ALinput , V ALfi unc , V ALsta , V ALout i , V ALi i )) i

A Die Zuordnung der Modellgröße und deren Wertenbelegungen gemäß Wissen erfolgt mittels eines einfache Suchalgorithmus. ActT EST input

Diagnoseparameter acttest1

acttest2

...

acttest6

com1 .var1f unc

{N }



...

{N }

com2 .var1f unc



{L}

...





...

{N }

... com3 .var2f aul



Tabelle 4.7: Darstellung der P ARAM ActT EST in Tabellenform

4.2

Verdachtsgenerierung

Aus den Diagnoseinformationen, die der Algorithmus A liefert, wird der Algorithmus P zur Verdachtsgenerierung angestoßen. Nach der Verdachtsgenerierung werden die verdächtigen Komponenten mittels Algorithmus B mit Punktzahlen bewertet. In diesem Abschnitt werden die Algorithmen zur Verdachtsgenerierung und -überprüfung beschrieben.

4.2.1

Ermittlung der verdächtigen Komponenten (Algorithmus P)

Die Ermittlung der verdächtigen Komponenten basiert auf der Modellanalyse der Verhaltenstabellen der Komponentenmodelle und deren Verbindungen unter Berücksichtigung der Diagnoseparameter, die aus den Analyseergebnissen von Kundenbeanstandungen, Fehlercodes aus Steuergeräten, Messwerten der systemeigenen Sensoren sowie externen Messungen und Komponenten-/ Stellgliedtests entstehen. Nachfolgend wird die Propagierung der belegten Attribute im Modell zur Ermittlung verdächtiger Komponenten beschrieben. Algorithmus 4.3 : Diagnostik-Algorithmus (P) Eingabe: (Input Algorithmus P) - Modell mit teilweise belegten Parameter, wobei die Menge der belegten Diagnoseparameter P ARAM die Ausgabe des Algorithmus A ist. Das Diagnosemodell M OD stammt aus der Identifizierung des zu diagnostizierenden Systems beziehungsweise der zu diagnostizierenden Funktion.

104

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

Ausgabe: (Output Algorithmus P) - Menge der verdächtigen Komponenten (COM susp ) mit deren reduzierten Verhaltenstabellen Algorithmus: P1. Für jedes Attribut beziehungsweise jede interne Variable, deren Werte belegt sind, werden die Verhaltenstabellen aller Komponenten, die mit dem Attribut oder der Variable direkt oder indirekt zu tun haben, reduziert. Die Reduzierung der Verhaltenstabelle erfolgt durch Löschung aller Zeilen der Tabelle, die den Wertebelegungen nicht entsprechen. Für eine bestimmte Komponente comx des Diagnosemodells M OD reduziert diese Methode parami,x die vollständige Verhaltenstabelle tabx zu tabx , wenn |parami,x | > 0 ist. Die Reduzierung erfolgt durch die sequentielle Suche der Menge aller Zeilen ROWx der Verhaltenstabelle tabx unter der Vergleichsbedingung, dass einzelne Zeilen mit den Wertebelegungen in parami,x übereinstimmen. Analog wird die Beeinflussungsgradtabelle reduziert; dabei wird nur die Übereinstimmung der Ausgangsattribute berücksichtigt. comx portin 0

...

portin i

trana

...

tranb

portout 0 varif unc

...

varjsta

...

varkf aul

att0

...

attm

...

att0

H

...

L

...

N

N

...

L

...

H

H

...

N

...

H

N

...

L

...

H

...

N

...

N

N

...

N

N

...

N

...

N

N

...

L

...

N

...

H

N

N

...

N

...

N

N

...

trann att0

...

attn

...

L

...

L

L

...

L

...

H

...

N

...

H

...

H

N

...

N

...

N

...

N

...

H

...

N

...

L

...

L

...

L

...

N

...

L

...

L

N

...

N

...

H

...

H

... H

...

L

...

N

N

...

Tabelle 4.8: Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabx einer Komponente comx input f unc sta , V ARf aul , AT T out ) → Als Beispiel besteht parami,x = ((AT Ti,x , V ARi,x , V ARi,x i,x i,x f unc f aul sta out (V ALinput i,x , V ALi,x , V ALi,x , V ALi,x , V ALi,x )) aus folgenden Einträgen: input input - (AT Ti,x = { comx . portin = { H }) 0 . trana . att0 }) ∧ (V ALi,x f unc - (V ARi,x = { comx . varif unc }) ∧ (V ALfi,xunc = { N }) out = { com . portout . tran . att }) ∧ (V ALout = { H }) - (AT Ti,x x n n 0 i,x f unc Demzufolge gilt: parami,x = ({comx . portin }, {comx . 0 . trana . att0 }, {comx . vari out port0 . trann . attn }) → ({H}, {N }, {H}). Damit wird die Verhaltenstabelle tabx (Taparami,x belle 4.8) unter Berücksichtigung der Parameter parami,x zu tabx (Tabelle 4.9) reduziert.

105

4.2. VERDACHTSGENERIERUNG comx portin 0

...

portin i

trana

...

tranb

portout 0 varif unc

...

varjsta

...

varkf aul

att0

...

attm

...

att0

H

...

N

...

H

N

...

L

...

L

H

...

N

...

N

N

...

N

...

N

...

...

trann att0

...

attn

...

L

...

H

N

...

H

...

H

N

...

H

..

H

... H

...

L

...

N

N

...

parami,x

Tabelle 4.9: Beispiel eines Abschnitts der reduzierten Verhaltenstabelle tabx ponente comx mit dem Diagnoseparameter parami,x

einer Kom-

P2. Die Teilmenge der Diagnoseparameter, die sich in den Ausgangsschnittstellen der Komponenten beziehungsweise in den Ausgangsschnittstellen des Systems befinden, wird rückwärts gegen die Richtung der gerichteten Verbindungen im Modell propagiert. Dabei werden alle Zeilen der Verhaltenstabelle der einzelnen Komponenten, die mit der Wertebelegung der propagierten Diagnoseparameter nicht übereinstimmen, entfernt. Wenn das Modell eine Rückkopplung oder mehrere Rückkopplungen beinhaltet, muss der Propagierungsvorgang wiederholt werden, bis keine Änderungen an den Zeilen der Verhaltenstabelle mehr existieren. compre x portin 0

...

portin i

tranx

...

trany

portout 0 varif unc

...

varjsta

...

varkf aul

attl

...

attm

...

attn

N

...

L

...

L

N

...

N

...

H

H

...

N

...

H

N

...

L

...

N

...

L

...

N

N

...

H

H

...

H

...

N

N

...

N

...

N

...

H

N

L

...

N

...

N

N

...

trana att0

...

attm

...

N

...

L

N

...

H

...

N

...

N

...

H

...

L

N

...

L

...

N

...

L

...

H

...

N

...

L

...

L

...

L

...

N

...

N

...

L

N

...

N

...

H

..

N

... H

...

L

...

N

N

...

Tabelle 4.10: Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabpre x einer Komponente compre x

Ein Schrittes in dieser Rückwärtspropagierung wird zur Veranschaulichung in diesem Abpre schnitt anhand der Komponente compre x beschrieben. comx ist eine Komponente in der Wirkkette, die direkt vor der Komponente comx steht. Die Komponente compre x besitzt ei-

106

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG in ne Ausgangsschnittstelle portout 0 , mit der die Eingangsschnittstelle port0 der Komponente comx verbunden ist. Tabelle 4.10 zeigt das Beispiel eines Abschnitts der vollständigen Verpre haltenstabelle tabpre x der Komponente comx vor dem Rückwärtspropagierungsvorgang.

In Tabelle 4.9 existieren folgende Wertebelegungen: in (comx . portin 0 . trana . att0 , comx . port0 . trana . attm )→ ({H}, {N }) in (comx . portin 0 . trana . att0 , comx . port0 . trana . attm )→ ({H}, {L})

Aus diesen Diagnoseinformationen gelten folgende Wertebelegungen für die Ausgangspre schnittstellen portout 0 . der Komponente comx : pre pre out out parampre i,x,j = (comx .port0 .trana .att0 , comx .port0 .trana .attm )→ ({H}, {N }) pre pre out out parampre i,x,j+k = (comx .port0 .trana .att0 , comx .port0 .trana .attm )→ ({H}, {L}) pre Mit den Diagnoseparametern parampre i,x,j und parami,x,j+k wird die Verhaltenstabelle 4.10 zur Tabelle 4.11 reduziert.

compre x portin 0

...

portin i

tranx

...

trany

portout 0 varif unc

...

varjsta

...

varkf aul

attl

...

attm

...

attn

H

...

N

...

H

N

...

L

...

N

N

...

L

...

N

N

...

H

...

N

...

...

trana att0

...

attm

...

H

...

N

N

...

H

...

L

N

...

H

..

N

... H

...

L

...

N

N

...

Tabelle 4.11: Beispiel eines Abschnitts der reduzierten Verhaltenstabelle mit den Diagnosepapre pre rametern parampre i,x,j und parami,x,j+k der Komponente comx P3. Nach dem Beenden der Rückwärtspropagierung wird die Vorwärtspropagierung gestartet. Hierzu wird die Verhaltenstabelle der Komponenten entlang der Richtung der gerichteten Verbindungen im Modell mittels Diagnoseparametern, die sich in den Eingangsschnittstellen der Komponenten des Systems befinden, reduziert. Dieser Vorgang ist analog zur Rückwärtsverkettung, Unterschiede sind die Propagierungsrichtung und dass sich die Modellgröße in den Eingangsschnittstellen der Komponenten des Systems befindet. compost x portin 0

...

portin i

trann

...

tranb

portout 0 varif unc

...

varjsta

...

varkf aul

att0

...

attn

...

att0

L

...

H

...

N

N

...

L

...

H

H

...

L

...

H

N

...

L

...

N

...

H

...

N

N

...

N

...

...

tranl att0

...

attq

...

L

...

H

L

...

L

...

H

N

...

N

...

H

107

4.2. VERDACHTSGENERIERUNG N

...

N

...

N

N

...

N

...

N

...

N

...

N

H

...

H

...

H

N

...

H

...

N

...

H

...

H

N

...

H

...

N

N

...

L

...

N

...

H

...

N

N

...

N

...

L

..

L

... N

...

L

...

N

N

...

Tabelle 4.12: Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabpost einer Komx post ponente comx Es sei mit compost eine Komponente in der Wirkkette, die direkt hinter Komponente x comx steht. Die Komponente compost besitzt eine Eingangsschnittstelle portin x 0 , welche mit out der Ausgangschnittstelle port0 der Komponente comx verbunden ist. Tabelle 4.12 ist ein Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabpost der Komponente x compost vor dem Vorwärtspropagierungsvorgang. x In der Verhaltenstabelle 4.9 existieren zwei Wertebelegungen der Ausgangsattributte der Komponente comx : out (comx . portout 0 . trann . att0 , comx . port0 . trann . attn )→ ({L}, {H}) out (comx . portout 0 . trann . att0 , comx . port0 . trann . attn )→ ({H}, {H})

Demzufolge gilt folgende Wertebelegung für die Ausgangsschnittstellen portin 0 der Kompost ponente comx : post post in in parampost i,x,j = (comx .port0 .trann .att0 , comx .port0 .trann .attn )→ ({L}, {H}) post post in in parampost i,x,j+k = (comx .port0 .trann .att0 , comx .port0 .trann .attn )→ ({H}, {H}) post Die Projektion der Parameter parampost i,x,j und parami,x,j+k auf die Verhaltenstabelle 4.12 tabpost reduziert diese Tabelle zu Tabelle 4.13. x

compost x portin 0

...

portin i

trann

...

tranb

att0

...

attn

...

att0

L

...

H

...

N

portout 0 varif unc N

...

varjsta

...

...

varkf aul

...

tranl att0

...

attq

L

...

H

...

L

...

H

H

...

N

...

H

...

H

... H

...

H

...

H

N

...

Tabelle 4.13: Beispiel eines Abschnitts der reduzierten Verhaltenstabelle mit den Diagnosepapost post rametern parampost i,x,j und parami,x,j+k der Komponente comx P4. Für alle Komponentenzustände aus Schritt P2 wird geprüft, ob ein Fehlerzustand alle Attribute erklären kann. Alle diese Komponenten werden in die Menge der verdächtigen Komponenten (COM susp ) aufgenommen. Falls kein Fehlerzustand gefunden wird, werden die Komponenten, die sich in der Wirkkette befinden, verdächtigt und müssen in die Menge

108

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG der verdächtigen Komponenten (COM susp ) aufgenommen werden. Die Wirkkette ist ein Teil des zudiagnotizierende Systems beziehungsweise des Subsystems und alle Komponenten in diese Wirkkette wird durch die Rückwärstverkettung markiert. Desweiteren wird in diesem Fall die Systemeingangschnitstellen durch die Rückwärstverkettung mit Wertenbelegung hoch oder niedrig belegt, mit diesem Wert wird die Propagierung in benachbaren Systemen, wenn Diagnosemodelle der benachbaren Systeme existiert, fortgeführt.

4.2.2

Bewertung der verdächtigen Komponenten (Algorithmus B)

Der Algorithmus B dient zur Bewertung der verdächtigen Komponenten mit Bewertungspunktzahlen. Algorithmus 4.4 : Diagnostik-Algorithmus (B) Eingabe: (Input Algorithmus B) Output Algorithmus P : - Menge der verdächtigen Komponenten (COM susp ) mit ihren reduzierten Verhaltenstabellen. Ausgabe: (Output Algorithmus B) - Bewertungspunktzahl für verdächtige Komponenten. Algorithmus: ˜

˜

der Komponente comk ∈ B1. Jede Zeile rowibeh der reduzierten Verhaltenstabelle tabbeh k COM susp , die sich in der Verdächtigenliste befindet, wird mit einem Faktor fibeh (s.u.) in Abhängigkeit von der Anzahl der belegten internen Variablen und der belegten Eingangsattribute berechnet und gewichtet. Der Grad der Verdächtigung einer Komponente, der ˜ auf der reduzierten Verhaltenstabelle basiert, ist die gesamte Summe des Faktors fibeh der einzelnen Zeilen: ˜ P|ROW beh | ˜ ˜ fkbeh = i=1 k fibeh Daraus folgt, dass eine Komponente umso stärker gewichtet wird, je mehr Fehlerzustände sie hat, falls keine Wahrscheinlichkeiten der Fehlerzustände bekannt sind. ˜

˜

B2. Jede Zeile rowiinf der reduzierten Beeinflussungsgradtabelle tabinf wird mit einem k ˜

Faktor fiinf (s.u.) in Abhängigkeit von der Anzahl der belegten Ausgangsattribute be˜

rechnet und gewichtet. Analog zur Verhaltenstabelle wird die Summe des Faktors fkinf der einzelnen Zeilen gebildet: ˜

fkinf =

˜ P|ROWkinf |

i=1

˜

fiinf ˜

B3. Der Verdächtigungsgrad der Komponente comk ergibt sich aus der Summe von fkbeh ˜

und fkinf : ˜

˜

fk = fkbeh + fkinf Dieser Wert drückt aus, wie wahrscheinlich die Komponente für die abweichenden Outputvariablen verantwortlich ist.

109

4.3. KOORDINATION DER MESSUNGEN UND TESTS ˜

˜

˜

Der Bewertungsfaktor fibeh der Zeile rowibeh der reduzierten Verhaltenstabelle tabbeh einer k susp Komponenten comk ∈ COM ist abhängig von dem Inhalt dieser Zeile. Nach 3.3.4 ist eine Zeile rowibeh der Verhaltenstabelle rowibeh ein Tupel, welches eine Abbildung ist aus: {AT Tkin , V ARkf unc , V ARksta , V ARkf aul , AT Tkout } qual

f unc f aul → {V ALin , V ALsta , V ALout k , V ALk k , V ALk k }. Daher ist eine Zeile der reduzierten Verhaltenstabelle auch ein Tupel und kann mit folgenden Einschränkungen definiert werden: out out out out out ∀attout / V ALout k,i ∈ AT Tk |(∃attk,i = valk,i ) ∧ (valk,i ∈ V ALk,i ) ∧ (normal ∈ k,i ) ˜

Da mindestens eine Abweichung eines Ausgangsattributes in der Zeile rowibeh existieren muss, ˜ wird der Bewertungsfaktor fibeh wie folgt berechnet: ˜

˜

- Zeile rowibeh wird mit fibeh = f var bewertet, wenn: in in in in in in ∀attin k,i ∈ AT Tk |(attk,i = valk,i ) ∧ (valk,i ∈ V ALk,i ) ∧ (V ALk,i ⊆ {normal})

Dieser Ausdruck sagt aus, dass nur die Abweichung der Wertebelegungen der internen Variablen für die Abweichungen der Ausgangsattribute verantwortlich ist. ˜

˜

- Zeile rowibeh wird mit fibeh = f in,var bewertet, wenn: in in in in in / V ALin (∀attin k,i )∧(1 ≤ i))∧ k,i ∈ AT Tk |∃(attk,i = valk,i )∧(valk,i ∈ V ALk,i )∧(normal ∈ prop prop prop prop (∀vark,j ∈ V ARkprop ∧ prop ∈ {f unc, sta, f aul}|∃(vark,j = valk,j ) ∧ (valk,j ∈ prop V ALprop ) ∧ (normal ∈ / V AL ) ∧ (1 ≤ j)) k,j k,j

Dieser Ausdruck sagt aus, dass durch die Abweichung der Wertebelegungen der Eingangsattribute und der internen Variablen die Abweichungen der Ausgangsattributte hervorgerufen werden. ˜

˜

- Zeile rowibeh wird mit fibeh = f in bewertet, wenn: prop prop prop prop ∈ ) ∧ (valk,j = valk,j ∈ V ARkprop ∧ prop ∈ {f unc, sta, f aul}|∃(vark,j ∀vark,j prop prop V ALk,j ) ∧ (V ALk,j ⊆ {normal})

Dieser Ausdruck sagt aus, dass nur die Abweichung der Wertebelegungen der Eingangsattribute für die Abweichungen der Ausgangsattribute verantwortlich ist. Demnach liefert die Zeile mit dem Bewertungsfaktor f var die Erklärung der vorhandenen Symptome durch Einfachfehler. Die Mehrfachfehler werden durch Zeilen mit dem Bewertungsfaktor f in,var erklärt. Fehler, die ausschließlich weitergereicht werden, sind durch Zeilen mit dem Bewertungsfaktor f in berücksichtigt worden. Da die bisherigen Erfahrungen bei der Werkstattdiagose gezeigt haben, dass Einfachfehler häufiger auftreten als Mehrfachfehler und Komponenten, die die Fehler ausschließlich weiterreichen, nicht verdächtigt werden sollen, gelten folgende Relationen zwischen den Bewertungsfaktoren: f var > f in,var > f in .

4.3

Koordination der Messungen und Tests

Der Teilalgorithmus D3 (Abbildung 4.1) zur Koordinierung der Sensoren- und Messungseinsätze, der Komponententests und der Reparatur oder dem Austausch von Komponenten mit

110

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

Ranking besteht aus zwei Algorithmen. Zum einen ist dies der Algorithmus K, welcher die Messungen und einfachen Tests wie zum Beispiel den Stelltgliedtest priorisiert. Zum anderen gruppiert der Algorithmus S die verdächtigen Komponenten mit verschiedenen Kriterien, die für das Werkstattpersonal bei der Diagnose entscheidend sind. Die Liste der priorisierten Messungen und einfachen Tests dient als Handlungsempfehlung und ist für den Benutzer, der die geführte Fehlersuche in Anspruch nehmen will, ausschlaggebend. Wegen der begrenzten Mess- und Testmöglichkeiten im Fahrzeug und wegen des Assistenzaspekts des Diagnosetools liefert die zweite Liste keine direkte Handlungsempfehlung. Mit dieser Liste kann der Nutzer eigenständig entscheiden, welche verdächtigen Komponenten er zunächst prüfen oder austauschen möchte. Die beiden Listen werden nach jedem Diagnoseschritt, wie zum Beispiel der Durchführung von Messungen, Tests oder Prüfungen neu berechnet.

4.3.1

Koordinierung der Sensoren-, Messungseinsätze und Tests (Algorithmus K)

Die Messungsmöglichkeiten am mechatronischen System, das im Fahrzeug eingebaut ist, sind begrenzt. Die Ermittlung neuer Messpunkte zur Reduzierung der Anzahl der verdächtigen Komponenten im Sinne der Einbringung neuer Sensoren beziehungsweise Messgeräte ist auf Grund des begrenzten Bauraums und der notwendigen Umbaumaßnahmen in freien Werkstätten schwer durchführbar und erhöht damit die Diagnosekosten. Aus diesem Grund werden in dieser Arbeit keine Verfahren, die neue Messpunkte ermitteln, entwickelt. Es werden ausschließlich die vorhandenen Sensoren, Messungen, Tests und Prüfungen berücksichtigt und priorisiert. Da bei dem Diagnosevorgang nach jeder neuen Messung, dem Auslesen des Istwerts des Systemsensors oder der Durchführung von Tests neue Diagnoseinformationen zur Verfügung stehen, beinhaltet der Algorithmus K folgende Schritte: Algorithmus 4.5 : Diagnostik-Algorithmus (K) Eingabe: (Input Algorithmus K) - Teil des Input Algorithmus D: - Menge der Modellgrößen mit Wertebelegung, die sich durch systemeigene Sensoren bestimmen lassen. - Menge der Modellgrößen mit Wertebelegung, die sich durch externe Messungen bestimmen lassen. - Menge aller Stellglied- und Komponententests, die durchgeführt wurden. - Output Algorithmus B: - Menge der verdächtigen Komponenten mit Bewertungspunktzahl Ausgabe: (Output Algorithmus K) - Priorisierte Liste der Messungen und einfachen Tests Algorithmus:

4.3. KOORDINATION DER MESSUNGEN UND TESTS

111

K1. Berechnung der mittleren Reduktion der verdächtigen Komponentenmenge durch zukünftige Ausführung einer Messung oder eines Tests. Diese Berechnung erfolgt über die Mittelwertbildung unter der Annahme, dass Messungen beziehungsweise Tests bestimmte Werte annehmen, da in dem nächsten Diagnoseschritt die Wertebelegung der Modellgrößen, die sich durch Messung bestimmen lassen, sowie die Ergebnisse der durchgeführten Tests nicht vorhersagbar sind. K2. Ermittlung der mittleren Reduktion unter Berücksichtigung der Bewertungspunktzahl der verdächtigen Komponenten, da die reine mittlere Reduktion der verdächtigen Komponentenmenge durch Messungen oder Tests nicht ausreichend ist. Die Menge der verfügbaren Systemsensoren, Messungen und einfachen Tests ergibt sich aus der Differenz zwischen den Mengen, die im Diagnosemodell abgebildet sind, und den Mengen der durchgeführten externen Messungen, ausgelesenen Systemsensor-Istwerten sowie der Menge der durchgeführten einfachen Tests [35]. Es gilt: SEN todo = SEN/SEN todo M EAS todo = M EAS/M EAS todo ActT EST todo = ActT EST /ActT EST todo ComT EST todo = ComT EST /ComT EST todo Da die Wertebelegungen der zu messenden Parameter eines Sensors, der zur Diagnoselaufzeit noch nicht abgefragt wurde, nicht bekannt sind, muss mit allen möglichen auftretenden Werten gerechnet werden. Folglich wird für jede Wertebelegung die Reduktion anhand der Menge der verdächtigen Komponenten ermittelt und der Mittelwert der Reduktion mit Hilfe der Anzahl der Möglichkeiten gebildet. Es seien mit: - seni - der i-te Sensor, der sich in der Menge der noch nicht ausgelesenen Sensoren befindet (seni ∈ SEN todo ) - istwertk - der k-te Istwert, der von dem i-ten Sensor seni gemessen wird - V ALk - die qualitative Wertemenge, in der der k-te Istwert istwertk einen Wert annehmen kann. Für jede mögliche Wertebelegung valj ∈ V ALk |0 ≤ j < |V ALk | wird der Algorithmus D2 mit der hypothetischen Wertebelegung des Istwerts istwertk = valj und die D2-Inputinformation aufgerufen. Die Reduktionsgröße der Menge der verdächtigen Komponenten auf Grund der Hypothese ist die Differenz zwischen der Kardinalität der vorhandenen Verdächtigungsmenge und der Kardinalität der hypothetischen Verdächtigungsmenge [36]: R(istwertk , valj ) = |COM susp | − |COM suspHY P | Die mittlere Reduktion der Menge der verdächtigen Komponenten durch Auslesen eines Istwerts istwertk des systemeigenen Sensors seni mit seni ∈ SEN todo ergibt sich aus dem arithmetischen Mittelwert der einzelnen, oben berechneten Reduktionsgrößen: P|V ALk |

R(istwertk ,valj )

R(istwertk ) = j=1 |V ALk | Die Berechnung der mittleren Reduktion der verdächtigen Komponentenmenge durch externe Messungen erfolgt analog zur Berechnung der Systemsensoren. Die mittlere Reduktion des einfachen Tests erfolgt identisch wie oben. Der Unterschied besteht darin, dass das Argument nicht der Istwert ist, sondern die internen Variablen der zu testenden Komponenten [34]: P|V ALl |

R(varl ,valj )

R(varl ) = j=1 |V ALl | Da die Bewertungspunktzahl der Komponenten in der verdächtigen Menge möglicherweise unterschiedlich ist, ist die Betrachtung der mittleren Reduktionsgröße des Sensoreinsatzes, des Messungseinsatzes beziehungsweise des einfachen Tests im Zusammenhang mit der Bewertungspunktzahl zur Erstellung der Liste der Handlungsempfehlung sinnvoll. Es seien mit:

112

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

- comi - die i-te Komponente, die sich in der Menge der verdächtigen Komponenten befindet (comi ∈ COM sups ) - wi - die Bewertungspunktzahl der Komponenten comi , die aus dem Algorithmus B bezogen auf vorhandene Beanstandungen und durchgeführte Messungen sowie Tests ermittelt wurden. Für jede verdächtige Komponente comi kann die auftretende Wahrscheinlichkeit pi zur Erklärung der vorhandenen Symptome wie folgt berechnet werden: i pi = P|COMwsups | j=1

wj )

Für die Berücksichtigung der Bewertungspunktzahl bei der Erstellung der Handlungsempfehlung kann wie folgt vorgegangen werden [34], [36]: P P pi +···+R(istwertk ,valj=|V ALk | )× m i=n pi |V ALk | P Pm R(varl ,valj=1 )× h i=g pi +···+R(varl ,valj=|V ALl | )× i=n pi Rp (varl ) = |V ALl | Anhand der berechneten Werte (Rp ) der durchzuführenden Messungen und

Rp (istwertk ) =

R(istwertk ,valj=1 )×

h i=g

einfachen Tests

werden die Elemente der Handlungsempfehlungsliste sortiert.

4.3.2

Gruppierung der verdächtigen Komponenten (Algorithmus S)

Algorithmus 4.6 : Diagnostik-Algorithmus (S) Eingabe: (Input Algorithmus S) - Ausgabe des Output Algorithmus B: - Menge der verdächtigen Komponenten Ausgabe: (Output Algorithmus S) - Liste der Komponenten, die in Gruppen zusammengefasst sind Algorithmus: S1. Gruppierung der verdächtigen Komponenten nach Branch-And-Bound-SkylineAlgorithmus3 . Die Gruppierung der verdächtigen Komponenten erfolgt in dieser Arbeit nach dem SkylineKonzept. Dieses Konzept löst das Problem der ungenauen Benutzeranfragen bei der Datenbankanfrage. Es seien mit: obj - Objekt, das im Vergleich steht. Dieses Objekt wird von n-Attributen repräsentiert: - obj = {att1 , att2 , .., attn } n R - n-dimensionaler Raum, wobei jede Dimension ein Attribut atti des Objekts obj repräsentiert OBJ - endliche Menge der Objekte, die im Vergleich zur Verfügung stehen: - obji ∈ OBJ|obji ∈ Rn OBJ s - endliche Menge der Objekte, die als Skyline bezeichnet werden. Dann muss OBJ s folgende Eigenschaften erfüllen: - OBJ s ∈ OBJ - ∀obj s ∈ OBJ s |obj s = {atts1 , atts2 , .., attsn } ∧ ∀obj ∈ OBJ/OBJ s |obj = {att1 , att2 , .., attn } gilt:

4.3. KOORDINATION DER MESSUNGEN UND TESTS

113

∀objis , obji |attsi ≥ atti ∧ ∃objjs , objj |attsj > attj wobei i, j = {1, 2, ..., n}. Die verdächtigen Komponenten werden mit einem Skyline-Algorithmus zu Gruppen zusammengefasst. Dabei werden die Komponenten entsprechend ihrer Punktzahl beziehungsweise ihres Verdächtigungsgrads, ihrer Test-/ Prüfkosten und -zeit, Alterszustand sowie der Verfügbarkeit von zum Austausch notwendigen Ersatzteilen gruppiert. Die vergleichenden Kriterien bei der Diagnose entsprechen einem fünfdimensionalen Raum. Die Entscheidung für den Skyline-Algorithmus beruht auf folgenden Randbedingungen des verfügbaren Diagnosewissens und der Werkstattanforderungen, die mit den Anforderungen an Online-Algorithmen übereinstimmen [73]: • Einfache Anwendung des Algorithmus auf bestehende Diagnosedaten ohne Aufforderung zur Änderung der Datenstruktur • Möglichkeit zur Verarbeitung aller verfügbaren und gegebenenfalls fehlenden Diagnosedatensätze; • Keine Einschränkung der Veränderung der Benutzeranfrage während des Diagnosevorgangs, so dass keine manuelle Anpassung des Algorithmus nötig ist. Der Algorithmus nimmt neue Komponenten in Skyline auf und entfernt Komponenten, die nicht mehr dazu gehören, im Laufe des Diagnosevorgangs unter veränderter Anfrage; • Ein Teil der Gruppierungsergebnisse liegt in kurzer Zeit vor und der Algorithmus liefert die kompletten Ergebnisse in endlicher Zeit. Damit ist die Terminierung des Algorithmus immer garantiert und die Wartezeit des Benutzers wird verkürzt; • Der Algorithmus berücksichtigt alle Vergleichsdimensionen der Datensätze bei der Gruppierung der verdächtigen Komponenten. Dadurch bekommt jeder Benutzertyp seinen Favoriten, unabhängig von unterschiedlichen Präferenzen [19]. Die oben genannten Anforderungen stellen ein klassisches Problem der Anfrageoptimierung dar. Als Maximum-Vektor-Problem wurde dieses Problem in [74] [62] identifiziert, zu dessen Lösung der Algorithmus entwickelt wurde. In dieser Arbeit wurde der Branch-And-BoundAlgorithmus, der in [109], [110] vorgestellt wird, in Java implementiert und für die Berechnung der Skyline im Diagnosevorgang verwendet. Dieser Algorithmus beruht auf dem gleichen Lösungsansatz wie der Nearest-Neighbor-Algorithmus [73] und ist für den höher dimensionalen Suchraum geeignet [21]. 3

Algorithm BBS (R-tree R) Begin BNN 1. S = /*list of skyline points*/ 2. insert all entries of the root R in the heap 3. while heap not empty 4. remove top entry e 5. if e dominated by some point in S discard e 6. else /*e is not dominated*/ 7. if e is an intermediate entry 8. for each child ei of e 9. if ei is not dominated by some point in S 10. insert ei into heap 11. else /*e is a data point*/ 12. insert ei into S 13. end while

114

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

4.4

Anwendungsbeispiele

In diesem Abschnitt werden Beispiele gezeigt, die aus der Evaluierung in den Werkstätten entstanden sind. Nachfolgend wird auf einzelne Algorithmen mit Beispielen eingegangen. Dabei existieren Unterschiede zwischen den Vorgehensweisen in dieser Arbeit im Vergleich zu existierenden Lösungen der funktionalen Klassifikation (vgl. [111]), weil das Diagnosewissen nicht nur in modellbasierter, sondern auch in heuristischer Form vorliegt. Zur Erläuterung der Algorithmen werden in dem ersten und zweiten Diagnosebeispiel die Diagnoseschrittte verbal beschrieben. Zur Veranschaulichung der vorgestellten Diagnosealgorithmen werden in dem dritten Beispiel die Schritte im Diagnosevorgang visualisiert. Die Beispiele sind reale Diagnosefälle, die aus den Feldtestdaten entnommen wurden.

4.4.1

Anwendungsbeispiel mit existierenden Fehlercodes

Als erstes Beispiel wird eine kurze Diagnose eines Teils des Luftsystems (Abbildung 4.2) mit eindeutigem Fehlercode ausgewählt. Mit diesem Beispiel wird die Notwendigkeit des Algorithmus E verdeutlicht. Dabei stehen folgende Diagnoseinformationen zur Verfügung: • Es existiert ein Fehlercode: P0112. • Die Kundenbeanstandung lautet „Schlechte Leistung bei Kaltstart“. Durch den Fehlercode P0112, der im ersten Beispiel direkt auf die Komponente Temperatursensor zeigt, beinhaltet die Tabelle für komponentenbezogene Diagnoseparameter dieses Beispiels folgende Einträge: DT C input

Komponentenbezogene Diagnoseparameter

P0112

{T emperatursensor}

Tabelle 4.14: Darstellung der Menge COM DT C,¬OK = {T emperatursensor} des Fehlercodes P0112 in Tabellenform Bevor die Kundenbeanstandung „Schlechte Leistung bei Kaltstart“ mit dem Algorithmus A analysiert wird, werden durch den Algorithmus E die Prüfschritte des Temperatursensors vorgeschlagen (Abbildung 4.1). In diesem konkreten Beispiel wird die Empfehlung befolgt und die Komponente Temperatursensor geprüft (der Inhalt des Komponententests beziehungsweise der Komponentenprüfung ist in Abbildung 3.20 dargestellt und in Abschnitt 3.7 beschrieben). Hierbei wird zuerst versucht, den Istwert des Sensors im Ansaugtrakt auszulesen. Als Ergebnis liefert der Sensor einen Wert von -40°C. Dieser Wert ist unplausibel, da die Temperatur in der Werkstatt höher als -40°C ist. Dieses Messungswissen ist fahrzeugspezifisch und direkt an die Fahrzeugkomponente gebunden (Kapitel 3 Abschnitt 2). Die Erklärung für die Abweichung ist entweder Kabelbruch, ein loser Sensorstecker oder Wackelkontakt. Mit dieser Erklärung, die in der Komponentenprüfung steht, wurde in diesem Fall eine Prüfung durchgeführt und ein Wackelkontakt als Fehler festgestellt. Als Reparaturmaßnahme wurde der Kontakt des Temperatursensors erneuert. End BNN

115

4.4. ANWENDUNGSBEISPIELE

S1

S0 P1 P4.1

P4.2

S0

S1

Ansaugrohr

S0

S1

P5

Luftfilter S1

S0

Temperatursensor

Luftleitung_TD

Luftleitung_FT S1

S0 S2

S4

S3

P13

S0

S2

Drosselklappe

S2

P10

P11 P0112

S0

P3 S1

Regenerier-Ventil

S1 S0

P12

S0 AGR-Ventil

S1

S2

Luftleitung_DR

S2

S0 AGR_Bypass

S2

S1

Drucksensor S0

S1 S0

S1

S1

RegenerierRückführung

P2

S0 Luftleitung_RA

Luftleitung_VS S1

S0

S2

S1

S1

S0

S0 Gestänge Einlasskanal -abschaltung S4

S0

S3

S3

Luftrohr1

S2

P6.1

S0

S9 S8

Luftverteiler Rohr S7 S6 S5 S4 S3 S2

S1

S0

Drallklappe1

S1

S1

Steller Drallklappe

S1 P6.2

S0

S3

Luftrohr2

Drallklappe2

S1

S0

S1 P7.1

S0

S3

Luftrohr3

Drallklappe3

S1 P7.2

S0

P8.1

S1 P8.2

S0

S3

Luftrohr4 S1 P9.1

S0

Drallklappe4 S1 P9.2

Schlechte Leistung bei Kaltstart

Abbildung 4.2: Modell des Luftsystems ME7.6.x mit Fehlercode und Kundenbeanstandung für das erste Beispiel

116

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

4.4.2

Anwendungsbeispiel mit Kundenbeanstandung, Sichtprüfung und ohne Fehlercode

Anhand des obendargestellten Luftsystems wird ein weiterer Diagnosevorgang, der relativ komplex ist, als zweites Beispiel herangezogen. Folgende Diagnoseinformationen stehen zur Verfügung: • Fehlercode ist nicht vorhanden. • Die Kundenbeanstandung lautet „Schlechte Gasannahme, Übergangsfehler“. • Es existiert keine Leckage in dem System (Sichtprüfung). In diesem Anwendungsbeispiel existieren keine Fehlercodes, daher sind die Analyseergebnisse COM DT C,¬OK der verfügbaren Diagnoseinformationen nach der Anwendung des Algorithmus E eine leere Menge: COM DT C,¬OK = Mit dieser Vorbedingung wird der Algorithmus A gestartet. Die Anwendung des Algorithmus A auf das Beispiel Luftsystem mit der Sichtprüfung „keine Leckage“ (Tabelle 4.15) und der Kundenbeanstandung „Schlechte Gasannahme, Übergangsfehler“ (Tabelle 4.16) ergibt folgende Diagnoseinformationen: ComT EST input

Diagnoseparameter

Sichtprüfung: Keine Leckage

Luf trohr[1..4].Leckage

{N }

Luf tverteiler Rohr.Leckage

{N }

...

...

Ansaugrohr.Leckage

{N }

Tabelle 4.15: Darstellung der Sichtprüfung „Keine Leckage“ in Tabellenform OBS input Diagnoseparameter Luf tsystem.P6.2 .Luf t.m ˙

Schlechte Gasannahme, Übergangsfehler 4

{L}

Luf tsystem.P7.2 .Luf t.m ˙

{L}

Luf tsystem.P8.2 .Luf t.m ˙

{L}

Luf tsystem.P9.2 .Luf t.m ˙

{L}

Tabelle 4.16: Darstellung der Kundenbeanstandung „Schlechte Gasannahme, Übergangsfehler“ in Tabellenform

4

M assenf luss := m ˙

117

4.4. ANWENDUNGSBEISPIELE

S0

P1 P4.1

P4.2

Ansaugrohr

S1

S0

S0

P5

S0

S1

S1

Temperatursensor

Luftleitung_TD

Luftleitung_FT S1

S0 S2

S4

S3

S1

Luftfilter

P13

S0

S2

Drosselklappe

S2

P10

P11

S0

P3 S1

Regenerier-Ventil

S1 S0

P12

S0 AGR-Ventil

S1

S2

Luftleitung_DR

S2

S0

S2

S1

AGR_Bypass

Drucksensor S0

S1 S0

S1

S1

RegenerierRückführung

P2

S0 Luftleitung_RA

Luftleitung_VS S1

S0

S2

S1

S1

S0

S0 Gestänge Einlasskanal -abschaltung S4

S0

S3

S3

Luftrohr1

S2

P6.1

S0

S9 S8

Luftverteiler Rohr S7 S6 S5 S4 S3 S2

S1

S0

Drallklappe1

S1

S1

Steller Drallklappe

S1

S0

S3

S0

Luftrohr2

Drallklappe2

S1

P6.2

S1 P7.1

S3

Luftrohr3

S0

Drallklappe3

S1 P7.2

.

S0

S1

P8.1

P8.2

S0

S3

Luftrohr4 S1 P9.1

S0

Drallklappe4 S1 P9.2

.

Luftsystem.P6.2.Luft.m = L ; Luftsystem.P7.2.Luft.m = L . . Luftsystem.P8.2.Luft.m = L ; Luftsystem.P9.2.Luft.m = L

Abbildung 4.3: Modell des Luftsystems ME7.6.x mit Kundenbeanstandung für das zweite Beispiel

118

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

Im folgenden Abschnitt wird die Funktionsweise der Algorithmen P und B anhand des zweiten Diagnosebeispiels erläutert. Der Algorithmus P besteht aus vier Schritten. Zur Veranschaulichung der Schritte dieses Algorithmus können nicht die einzelnen Komponenten des Modells (Abbildung 4.3) durchgegangen, sondern nur der Hauptpfad und die relevanten Komponenten beschrieben werden. Drallklappe1 S3in

S0in

T ransl

5

S1out ...

Luf t

leckage

f

s

m ˙

...

t

N

N

H

...

...

...

N

N

L

H

...

...

...

...

Luf t m ˙

...

t

...

H

...

...

N

...

H

...

...

... L

L

H

...

...

...

N

...

H

...

...

N

N

N

...

...

...

N

...

N

...

...

N

L

N

...

...

...

N

...

L

...

...

N

N

L

...

...

...

N

...

L

...

...

N

...

L

...

...

... N

L

L

...

...

...

Tabelle 4.17: Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente Drallklappe1 mit Drallklappe1 .leckage = N Anhand der Diagnoseinformation in Tabelle 4.15 wird die Reduzierung der Verhaltenstabelle der Systemkomponenten mittels Schritt P1 des Algorithmus P gestartet. Im Beispiel der Komponente Drallklappe1 wird die Verhaltenstabelle dieser Komponente mit der Diagnoseinformation Drallklappe1 .leckage = N reduziert. Es gilt: P1 : tabDrallklappe1

Drallklappe1 .leckage=N



1 tabPDrallklappe 1

Analog zur Drallklappe1 werden die Verhaltenstabellen aller Systemkomponenten mit dem Ergebnis der Sichtprüfung (Tabelle 4.15) reduziert. Nach der ersten Reduzierung der Verhaltenstabellen der Systemkomponenten durch die Projektion der Wertebelegungen der Diagnoseparameter wird die Rückwärtspropagierung gestartet (Schritt P2). In Beispiel zwei wird die Diagnoseinformation aus Tabelle 4.16 verwendet. Diese Tabelle ist das Ergebnis der Analyse des Algorithmus A. Für die Systemschnittstelle P6.2 gilt: Luf tsystem.P6.2 .Luf t.m ˙ =L Wegen der gerichteten Verbindung von Ausgangsschnittstelle S1 der Komponente Drallklappe1 zur Ausgangsschnittstelle P6.2 des Systems kann durch die Rückwärtspropagierung folgende Schlussfolgerung erstellt werden: 5

T ransl : Translationsbewegung; f : Kraft; s: Weg

4.4. ANWENDUNGSBEISPIELE Drallklappe1 .S1 .Luf t.m ˙ = L.

119

120

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG Drallklappe1 S3in

S0in

T ransl

Luf t

S1out ...

...

leckage

f

s

m ˙

...

t

N

L

N

...

...

...

N

N

N

L

...

...

...

Luf t m ˙

...

t

...

L

...

...

N

...

L

...

...

N

...

L

...

...

... N

L

L

...

...

...

Tabelle 4.18: Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente Drallklappe1 mit Drallklappe1 .leckage = N und Drallklappe1 .S1out .Luf t.m ˙ =L Die Weiterreduzierung der Verhaltenstabelle der Komponente Drallklappe1 kann mit dieser Wertebelegung durchgeführt werden. Als Ergebnis entsteht eine neue reduzierte Verhaltenstabelle 4.18. Analog zur Komponente Drallklappe1 werden die Verhaltenstabellen der Komponenten Drallklappe2 , Drallklappe3 und Drallklappe4 im gleichen Schritt reduziert. Der Vorgang der Rückwärtspropagierung wird bis zu den Eingangsschnittstellen des Luftsystems fortgesetzt. Dabei werden verschiedene Komponenten des Luftsystems verdächtigt, welche in ihren reduzierten Verhaltenstabellen mindestens eine Zeile mit dem Eintrag: (comout ˙ = L) ∧ ((comi .varjf aul = ¬N ) ∨ (comi .varjf aul = T )) i .Luf t.m beinhalten. Zum Beispiel existieren durch die Rückwärtspropagierung der Wertebelegung der Schnittstelle S0 der Komponente Drallklappei mit i ∈ 1, 2, 3, 4 die folgenden Einträge in der reduzierten Verhaltenstabelle (Tabelle 4.19) der Komponente Drosselklappe: Drosselklappe S4in

S0in

Steuerung

Luf t

...

schwergaengig

st

m ˙

...

t

L

L

...

...

...

T

N

N

...

...

...

T

...

S1out

S2out

S3out

Luf t

M esssignal

M esssignal

m ˙

...

t

ms

ms

...

L

...

...

...

...

...

L

...

...

...

...

...

L

...

...

...

...

... L

N

...

...

...

F

Tabelle 4.19: Beispiel eines Abschnitts der Komponente Drosselklappe mit Drosselklappe.schwergaengig = T

reduzierten Verhaltenstabelle Drosselklappe.klemmt = N

Gestänge Einlasskanalabschaltung

der und

121

4.4. ANWENDUNGSBEISPIELE S0in T ransl

...

mechanischerF ehler

...

S1out

S2out

S3out

S4out

T ransl

T ransl

T ransl

T ransl

f

s

f

s

f

s

f

s

f

s

N

N

...

T

...

N

L

N

L

N

L

N

L

N

L

...

T

...

N

L

N

L

N

L

N

L

... N

N

...

N

...

N

N

N

N

N

N

N

N

L

N

...

F

...

L

N

L

N

L

N

N

L

Tabelle 4.20: Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente Gestänge Einlasskanalabschaltung Die Rückwärtspropagierung der Wertebelegung von Schnittstelle S3 der Komponente Drallklappe reduziert die Verhaltenstabelle der Komponente Gestänge Einlasskanalabschaltung zur Tabelle 4.20. Auf die Menge der verdächtigen Komponenten mit ihren reduzierten Verhaltenstabellen wird der Diagnostik-Algorithmus B zur Erzeugung der Bewertungspunktzahl angewendet. In diesem Beispiel erhalten die Komponenten Drossellklappe und AGR−V entil die höchste Punktzahl, weil ihre reduzierten Verhaltenstabellen die meisten Zeilen mit der belegten internen Fehlervariable beinhalten. Das heißt, diese Komponenten haben die meisten Fehlerzustände (vergleiche Algorithmus B ). Die Komponente Drallklappe1 , Drallklappe2 , Drallklappe3 und Drallklappe4 sowie Gestänge Einlasskanalabschaltung bekommen geringere Punktzahlen als die oben genannten Komponenten, weil die Anzahl der Zeilen mit belegten internen Fehlervariablen in ihren reduzierten Verhaltenstabellen kleiner ist als die Anzahl der Zeilen der Komponente Drossellklappe beziehungsweise AGR−V entil. Es existieren drei einfache Komponententests für die verdächtigen Komponenten, die aus den Ergebnissen der Algorithmen P und B entstanden sind: • Test der Komponente Drossellklappe durch Signalspannungs-, Widerstandsprüfung sowie Prüfungen der Drosselklappen-/Pedalpositionssensoren A und B • Test der Komponente AGR−V entil durch Prüfung der Spannungsversorgung, des Komponentenwiderstands und des Istwerts des Ladedrucks • Stellgliedtest für folgende Komponenten der Drallklappengruppe : – Drallklappe1 , Drallklappe2 , Drallklappe3 und Drallklappe4 – Gestänge Einlasskanalabschaltung – Steller Drallklappe (Drallklappenantrieb) Im Luftsystem existiert nur der Drucksensor, welcher mit seinem Istwert über den aktuellen Ladedruck informiert. Da ein direkter Zusammenhang zwischen dem Ladedruck und der aktuell angesaugte Luftmasse in Form der Relationsgleichung qual

qual

Drucksensor1out .Luf t.m ˙ = Drucksensor0in .Luf t.druck −

122

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG Drucksensor1out .Luf t.druck,

existiert, eignet sich dieser Messwert zur Prüfung der Funktionsluftfüllung aller Komponenten des Luftsystems, die vor dem Ducksensor liegen, wie zum Beispiel: Drossellklappe und AGR − V entil. Die Priorisierung der Messaktionen und einfachen Komponententests durch den Algorithmus K ergibt folgende Empfehlungen: • Istwert des Ducksensors auslesen und mit Sollwert vergleichen • Stellgliedtest für Komponenten der Drallklappengruppe durchführen • Komponententest der Komponente Drossellklappe durchführen • Komponententest der Komponente AGR − V entil durchführen Die Positionierung des Auslesens des Drucksensor-Istwerts als erste Handlungsempfehlung liegt darin begründet, dass mit der Auswertung dieses Istwerts die meisten Komponenten einbeziehungsweise ausgeschlossen werden können und die entstehenden Kosten bei der Ausführung der Aktion sehr gering sind. Aus dem gleichen Grund befindet sich der Stellgliedtest an zweiter Stelle. Der Test der Komponente Drossellklappe ist als Drittes, weil die Funktion der Komponente Drossellklappe größeren Einfluss auf den Luftmassenfluss hat als die Komponente AGR − V entil. Die Auswahl der komplizierten Tests beziehungsweise Prüfungen der restlichen Komponenten erfolgt durch den Algorithmus S. Hierbei entsteht eine Liste mit folgenden Eintragungen: • Komponententest der Komponente Luf tf ilter • Komponententest beziehungsweise Verstopfungsprüfung der Rohre im Luftsystem (Dichtheitsprüfung fällt wegen den existierenden Diagnoseinformationen aus) Der Test des Luftfilters auf Verstopfung hat höhere Priorität als die Komponententests der Rohre im Luftsystem, weil die Wahrscheinlichkeit einer Verstopfung der Komponente Luf tf ilter höher ist als die Verstopfungwahrscheinlichkeit der Rohre. Zudem sind die Kosten des Luftfiltertests geringer als die Komponententests der Rohre, da der Ein- und Ausbau dieser Komponente geringeren Aufwand erfordert. In diesem Anwendungsbeispiel befolgt der Nutzer die generierten Handlungsempfehlungen und führt die Druckmessung mittels des systemeigenen Drucksensors durch. Diese Aktion ist der erste Schritt des iterativen Diagnosseprozesses. Dabei muss der Messwert zuerst auf Plausibilität geprüft werden. In diesem Beispiel ist das Messergebniss des Ansaugdrucks plausibel und im Sollbereich. Die neu gewonnene Information wird wie folgt formalisiert: qual

Drucksensor0in .Luf t.druck = N . Mit der neuen Diagnoseinformationen wird der Algorithmus A erneut ausgeführt. Danach werden die Algorithmen P und B zur Verdachtsgenerierung und -überprüfung angestoßen. Die Rückwärtspropagierung der Attribute im Modell entfernt alle Zeilen der Verhaltenstabelle der Komponenten, die vor dem Drucksensor liegen und in deren Verhaltenstabelle der Luftmassenfluss Komponentenout ˙ durch Druckabweichung nicht in Ordnung sein könnte. x .Luf t.m Damit reduziert sich die Anzahl der Zeilen einer Komponente, die vor dem Drucksensor liegt.

4.4. ANWENDUNGSBEISPIELE

123

Die Verhaltenstabellen der Komponenten des Luftsystems, die hinter dem Drucksensor liegen, können hingegen kaum reduziert werden, da alle Zeilen mit Wertebelegungen des Drucks als „in Ordnung“ im Eingang und einer Abweichung am Ausgang nicht entfernt werden können. Auf Basis der neuen reduzierten Verhaltenstabelle wird durch die Algorithmen K und S die Liste der Messaktionen und einfachen Komponententests sowie die Liste komplizierter Komponententests neu sortiert. Dabei entsteht durch den Algorithmus K eine neue Liste der Messaktionen und einfachen Komponententests, die der alten Liste entspricht: • Stellgliedtest für Komponenten der Drallklappengruppe (Steller Drallklappe, Gestänge Einlasskanalabschaltung, Drallklappe1 , Drallklappe2 , Drallklappe3 , Drallklappe4 ) durchführen • Komponententest der Komponente Drossellklappe durchführen • Komponententest der Komponente AGR − V entil durchführen Die Liste der komplizierten Tests beziehungsweise Prüfungen der restlichen Komponenten wird neu sortiert: • Verstopfungsprüftest: Luf tleitung_V S • Verstopfungsprüftest: Luf tverteiler Rohr • Komponententest der Komponente Luf tf ilter • Komponententest der Komponente Regenerier − V entil • Komponententest beziehungsweise Verstopfungsprüfung der Komponenten vor Drucksensor: Ansaugrohr, Luf tleitung_F T , Luf tleitungvT D , Luf tleitung_DR, Regenerier Rückführung, Luf tleitung_RA, AGR − Bypass Im zweiten Iterationschritt dieses Beispiels wird der Stellgliedtest für Komponenten der Drallklappengruppe (Steller Drallklappe, Gestänge Einlasskanalabschaltung, Drallklappe1 , Drallklappe2 , Drallklappe3 , Drallklappe4 ) durchgeführt. In diesem Beispiel wurde der Stellgliedtest nicht bestanden. Damit erhöht sich der Verdächtigungsgrad der Komponenten der Drallklappengruppe im Unterschied zu den übrigen Komponenten. Des Weiteren existieren nur noch Komponententests sowohl in der Liste der Messaktionen und einfachen Komponententests als auch in der Liste der komplizierten Tests beziehungsweise Prüfungen. Wegen dieser Tatsache werden die beiden Listen zusammengefasst: • Komponententest: Gestänge Einlasskanalabschaltung • Komponententests: Drallklappe1 , Drallklappe2 , Drallklappe3 , Drallklappe4 • Komponententest: StellerDrallklappe • Komponententest: Luf tleitung_V S • Komponententest: Luf tverteilerRohr

124

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG

Alle weitere Komponenten des Luftsystems (Drossellklappe, AGR − V entil, Luf tf ilter, Regenerier −V entil, Ansaugrohr, Luf tleitung_F T , Luf tleitung_T D , Luf tleitung_DR, Regenerier Rückführung, Luf tleitung_RA, AGR−Bypass) werden standardmäßig weiterhin verdächtig aufgeführt, allerdings mit niedriger Priorität (in der Benutzeroberfläche sind die Komponenten durch grüne Farbe markiert, das heißt dass diese Komponenten wahrscheinlich in Ordnung sind). Die Priorisierung der Komponentenstests erfolgt durch den Algorithmus S. Zum Beispiel befindet sich der Test der Komponente Gestänge Einlasskanalabschaltung an erster Stelle der Prüfliste, weil nicht nur die Kosten dieses Tests im Vergleich zu den Testkosten der Komponente Steller Drallklappe sowie der Komponenten Drallklappe1 , Drallklappe2 , Drallklappe3 , Drallklappe4 geringer ist, sondern auch die Fehlerwahrscheinlichkeit des mechanischen Fehlers dieser Komponente höher ist als die übrigen Komponenten der Drallklappengruppe. An zweiter Stelle steht die Prüfung der Drallklappe von 1 bis 4, weil die Fehlerwahrscheinlichkeit dieser Komponenten höher ist als die der Komponente Steller Drallklappe. Im dritten Iterationschritt wird die Komponente Gestänge Einlasskanalabschaltung geprüft. Hierbei wurde festgestellt, dass diese Komponente einen mechanischen Fehler hat (die Verbindung zur Drallklappe von 1 bis 4 ist lose). Damit ist der Fehler identifiziert und die Anleitung zur Reparatur wird dem Werkstattpersonal angezeigt.

4.4.3

Anwendungsbeispiel mit Kundenbeanstandung

Das dritte Beispiel betrifft die automatische Leuchtweitenregulierung (Abbildung 4.4). Das ALWR1.0-System ist ein automatisches Leuchtweitenregulierungssystem und hat zwei Aufgaben: Die Vermeidung der Blendung anderer Verkehrsteilnehmer infolge der Verwendung von Gasentladungslampen und die optimale Wegbeleuchtung für den Fahrer. Die Funktion des ALWR-Steuergeräts ist die Korrektur der Leuchtweiten des Scheinwerfers links und rechts. Diese Regelung erfolgt in Abhängigkeit vom Neigungswinkel des Fahrzeugs zur Straße und von der Fahrzeuggeschwindigkeit. Der Neigungswinkel (auch Nickwinkel oder Längsneigung genannt) wird aus Messwerten des Achssensors vorn und hinten berechnet. Der Sensor ist ein Winkelsensor und misst die Relativbewegung zwischen Fahrwerk und Karosserie. Zur Steuerung werden zwei Schrittmotoren verwendet, welche durch Stellmechaniken an die Scheinwerfer gebunden sind. In diesem letzten Anwendungsbeispiel werden die Diagnoseschritte visualisiert und damit ein Diagnosevorgang unter Verwendung der oben beschriebenen Algorithmen komplett erläutert. Im Startvorgang der Werkstattdiagnose wurden Kunden- und Fahrzeugdaten erfasst und die Kundenbeanstandung aufgenommen. Dabei wurde folgende Diagnoseinformation erhoben: • Die Kundenbeanstandung lautet „Leuchtweite zu hoch“. Anhand der Fahrzeugidentifikation und der Kundenbeanstandung wurde das relevante Diagnosemodell geladen. Dabei wird das betroffene System beziehungsweise die betroffene Funktion für den Nutzer dargestellt. Aufgrund des spezifischen Aufbaus des mechatronischen Systems wurde im nächsten Schritt der Fehlerspeicher aus dem Steuergerät ausgelesen (Abbildung 4.4). Als Ergebniss wurde in diesem Beispiel kein Fehlercode ausgegeben (COM DT C,¬OK = ). Mit den Diagnoseinformationen: • Fehlercode ist nicht vorhanden,

125

4.4. ANWENDUNGSBEISPIELE Leuchtweite links = hoch

P1.1

Gasentladungslampe links

P4 Leitung Gasentladungsampe links

Leuchtweite rechts = hoch

P1.2

P2.2

Scheinwerfer links

Scheinwerfer rechts

Stellmechanik links

Stellmechanik rechts

Stellmotor links

Stellmotor rechts

Leitung Stellmotor links

Leitung Stellmotor rechts

P5

ALWR-Steuergerät

P6

DTC‘s = Ø

P2.1 Gasentladungslampe rechts

P3 Leitung Gasentladungsampe rechts

P10

Leitung Achssensor vorn

Leitung Achssensor hinten

Achssensor vorn

Achssensor hinten

Gestänge Achssensor vorn

Gestänge Achssensor hinten

Leitung Klemme 56

Lichtschalter

P9

P8

P7

Fehlerspeichern lesen

Abbildung 4.4: Auslesen der Fehlercodes mittels Steuergerät P1.2.Drehwinkel = hoch

P2.2.Drehwinkel = hoch

• Die Kundenbeanstandung lautet „Leuchtweite zu hoch“, P1.1

P1.2

P2.2

P2.1

wurden die Algorithmen E und A gestartet. Hierbei wurde zuerst die verbale Beschreibung Gasentladungslampe Scheinwerfer links mittels Scheinwerfer derGasentladungslampe Kundenbeanstandung in Modellgrößen der Inhalterechts des Diagnosemodells überführt: links

P4.Drehwinkel • (P1.2

rechts

Stellmechanik rechts =Stellmechanik hoch) ∧ (Plinks 2.2 .Drehwinkel = hoch). Stellmotor links

P3

Stellmotor rechts

Leitung GasentLeitung GasentIm nächsten Schritt konnten folgende Komponenten des Systems durch die Algorithmen P ladungsampe links ladungsampe rechts Leitung Stellmotor links 4.5): Leitung Stellmotor rechts und B ausgeschlossen werden (Abbildung

P5 • Gasentladungslampe links,

P10

ALWR-Steuergerät

DTC‘s = Ø P6 • Leitung Gasentladungslampe links, Leitung Achssensor vorn

Leitung Achssensor hinten

• Leitung Gasentladungslampe rechts,

Achssensor vorn

Achssensor hinten

Gestänge Achssensor • Leitung Klemme 56, vorn

Gestänge Achssensor hinten

• Gasentladungslampe rechts,

Leitung Klemme 56

Lichtschalter

• Lichtschalter. P7

P8

P9

Die Ausschließung ist durch die Nichtbeeinflussung beziehungsweise Nichtbeteiligung dieser Komponenten an der Steuerung beziehungsweise an der Regulierung des Drehwinkels begründet. In diesem System existieren zwei systemeigene Sensoren und ein Stellgliedtest für die Steuerung der Scheinwerfer links und rechts. Zur Koordinierung der Sensoren-, Messseinsätze und einfachen Tests wurde der Algorithmus K angewendet. Als Ergebniss wurde eine Handlungsempfehlung mit folgenden Einträgen ausgegeben:

vorn

hinten

P9

P8

P7

126 KAPITEL Fehlerspeichern lesen 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG P1.2.Drehwinkel = hoch P1.1

Gasentladungslampe links

P4 Leitung Gasentladungsampe links

P2.2.Drehwinkel = hoch

P1.2

P2.2

Scheinwerfer links

Scheinwerfer rechts

Stellmechanik links

Stellmechanik rechts

Stellmotor links

Stellmotor rechts

Leitung Stellmotor links

Leitung Stellmotor rechts

P5

ALWR-Steuergerät

P6

DTC‘s = Ø

Gasentladungslampe rechts

P3 Leitung Gasentladungsampe rechts

P10

Leitung Achssensor vorn

Leitung Achssensor hinten

Achssensor vorn

Achssensor hinten

Gestänge Achssensor vorn

Gestänge Achssensor hinten

P7

P2.1

P8

Leitung Klemme 56

Lichtschalter

P9

Abbildung 4.5: Ermittlung der verdächtigen Komponenten mittels Kundenbeanstandung • Duchführung des Stellgliedtests für folgende Komponenten: – Scheinwerfer links, Stellmechanik links, Stellmotor links und Leitung Stellmotor links, – Scheinwerfer rechts, Stellmechanik rechts, Stellmotor rechts und Leitung Stellmotor rechts, • Istwert des Achssensors vorn und hinten auslesen und mit Sollwert vergleichen. Eine Priorisierung zur Ausschließung der verdächtigen Komponenten wird möglich durch die möglichen ausgeführten Aktionen und deren hypothetische Ergebnisse, da der Aufwand der Durchführung der Aktionen gleichgesetzt werden kann. Hierbei wurde der Stellgliedtest ausgeführt. Das Ergebniss des Stellgliedtests galt als bestanden und damit konnten folgende Komponenten ausgeschlossen und in der dargestellten Wirkkette ausgeblendet werden (Abbildung 4.6): • Scheinwerfer links, Stellmechanik links, Stellmotor links und Leitung Stellmotor links, • Scheinwerfer rechts, Stellmechanik rechts, Stellmotor rechts und Leitung Stellmotor rechts. Da in diesem Beispiel die Handlungsempfehlung streng verfolgt werden sollte, war der nächste Schritt „Achssensor-Istwert auslesen“. Aufgrund der parallen Bearbeitung der Diagnoseinformationen mittels der entwickelten Algorithmen konnten die Istwerte der beiden Achssensoren vorne und hinten abgefragt werden. Es existieren folgende Sensorinformationen:

127

4.4. ANWENDUNGSBEISPIELE

P1.2.Drehwinkel = hoch Stellgliedtest links = in Ordnung P

P2.2.Drehwinkel = hoch

P1.2

1.1

Gasentladungslampe links

Scheinwerfer links

Scheinwerfer rechts

Stellmechanik links

Stellmechanik rechts

Stellmotor links

Stellmotor rechts

Leitung Stellmotor links

Leitung Stellmotor rechts

P4 Leitung Gasentladungsampe links

P2.2

P5

ALWR-Steuergerät

P6

DTC‘s = Ø

Stellgliedtest rechts = in Ordnung

P2.1

Gasentladungslampe rechts

P3 Leitung Gasentladungsampe rechts

P10

Leitung Achssensor vorn

Leitung Achssensor hinten

Achssensor vorn

Achssensor hinten

Gestänge Achssensor vorn

Gestänge Achssensor hinten

Leitung Klemme 56

Lichtschalter

P9

P8

P7

Abbildung 4.6: Ergebnisse des Stellgliedtests P1.2.Drehwinkel = hoch Stellgliedtest links = in Ordnung P

• Achssensor 1.1vorne:

P2.2.Drehwinkel = hoch

P1.2

P2.2

– Istwert = 22,5% ,

Gasentladungslampe –links Istwert ∈

P4

Scheinwerfer links

• Achssensor hinten: Leitung Gasent– Istwert ladungsampe links

Scheinwerfer rechts

Sollbereich = {12,5;...; 50%}, Stellmechanik links

Stellmechanik rechts

Stellmotor links

Stellmotor rechts

= 32,8%, Leitung Stellmotor links

Stellgliedtest rechts = in Ordnung

P2.1

Gasentladungslampe rechts

P3 Leitung Gasentladungsampe rechts

Leitung Stellmotor rechts

– Istwert ∈ / Sollbereich = {50;...; 87,5%}.

P10

ALWR-Steuergerät

P5

In Abbildung 4.7 sind die Ergebnisse der Messungen und deren Auswertungen dargestellt. DTC‘s =Ø P6 Mit diesen Informationen („Ist-/Sollwert Abweichung“) wurde die Analyse mittels der AlgoLeitung Achssensor vorn der Leitung Achssensor hinten Klemme 56 zur rithmen P und B erneut gestartet. Nach Analyse gehören folgende Leitung Komponenten Verdächtigungsliste: Achssensor vorne Achssensor hinten



Ist: 22,5 % Achssensor vorn Soll: 12,5!50%



Achssensor hinten Ist: 32,8 % Soll: 50!87,5%

• ALWR-Steuergerät,Gestänge LeitungAchssensor Achssensor hinten, Achssensor hinten, Gestänge AchssenGestänge Achssensor Lichtschalter vorn hinten sor hinten. P9 Die Komponenten, die sich nicht inPder Verdächtigungsliste Pbefanden, wurden ausgeblendet 8 7 (Abbildung 4.7). Zur Gruppierung beziehungsweise Priorisierung der verdächtigen Komponenten wurde der Algorithmus S erneut ausgeführt. Als Ergebnis entstand eine Liste mit folgenden Einträgen:

• Gestänge Achssensor hinten, • Leitung Achssensor hinten,

Gestänge Achssensor vorn

128

Gestänge Achssensor hinten

Lichtschalter

P9 P8 DIAGNOSEERSTELLUNG P7 KAPITEL 4. INFERENZMECHANISMEN ZUR

P1.2.Drehwinkel = hoch Stellgliedtest links = in Ordnung P

P1.2

1.1

Gasentladungslampe links

P2.2

Scheinwerfer links

Scheinwerfer rechts

Stellmechanik links

Stellmechanik rechts

Stellmotor links

Stellmotor rechts

Leitung Stellmotor links

Leitung Stellmotor rechts

P4 Leitung Gasentladungsampe links

P2.2.Drehwinkel = hoch

P5

ALWR-Steuergerät

P6

DTC‘s = Ø Leitung Achssensor vorn Achssensor vorne Ist: 22,5 % Achssensor vorn Soll: 12,5!50%



Gestänge Achssensor vorn

Stellgliedtest rechts = in Ordnung

P2.1

Gasentladungslampe rechts

P3 Leitung Gasentladungsampe rechts

P10

Leitung Achssensor hinten

Leitung Klemme 56

Achssensor hinten Achssensor hinten Ist: 32,8 % Soll: 50!87,5%



Gestänge Achssensor hinten

P7

P8

Lichtschalter

P9

Abbildung 4.7: Auslesen der Sensor-Istwerte • Achssensor hinten, • ALWR-Steuergerät.

in der Fehlstellung Abbildung 4.8: Istzustand derGestänge Einbaulage Komponente Gestänge Achssensor hinten Zur Prüfung der Komponenten Gestänge Achssensor hinten (Abbildung 4.8) wurde die Diagnose- und Prüfungsinformation der Komponente Gestänge Achssensor hinten (AbbilDefekte Komponente: dung 4.9) abgerufen. Falsche Lage Gestänge hinten!

Es mussten drei Prüfschritte durchgeführt werden: • Befestigung der Komponente mit dem Achssensor, • Leichgängigkeit der Komponente,

129

4.4. ANWENDUNGSBEISPIELE

Funktion: Gestänge hinten Die Komponente Gestänge überträgt die Federwegänderung des Fahrzeugs bei Beladung vom Querlenker auf die Komponente Achssensor. Ebenso wird die Neigungsänderung des Fahrzeugs bei Beschleunigungs- und Verzögerungsvorgängen auf die Komponente Achssensor übertragen. Warnhinweis: Gestänge hinten Die Komponente Gestänge kann nur bei angehobenem Fahrzeug ausgebaut werden. Die Hebeeinrichtungen müssen für die Last geeignet und nachweislich in sicherem Zustand sein. Nach Austausch der Komponente Gestänge muss die Funktion Grundeinstellung Leuchtweitenregulierung durchgeführt werden. Prüfung: Gestänge hinten Korrekte Befestigung der Komponente Achssensor sowie die Leichgängigkeit der Komponente Gestänge kontrollieren. Die Komponente Gestänge darf nicht deformiert sein und die Einbaulage muss der in der Abbildung exakt entsprechen. Die Federwegänderung muss von der Komponente Gestänge spielfrei auf die Komponente Achssensor übertragen werden. Einbaulage: Gestänge hinten

Arbeitswerte: Gestänge hinten

Positionsnummer: Positionstyp: Artikelnummer: Bezeichnung:

1 AW 0 307 859 310 Gestänge Achssensor hinten

Menge: Mehrwertsteuer: Rabatt: Stundenver. Satz: Positionspreis:

Abbildung 4.9: Komponentenbezogenes Diagnosewissen

0,20 19,00% 0,00% 40,00 Euro 8,00 Euro

130

KAPITEL 4. INFERENZMECHANISMEN ZUR DIAGNOSEERSTELLUNG • Prüfung der Einbaulage.

Die Prüfung lieferte das Ergebnis „falsche Lage Gestänge Achssensor hinten“. Als Reparaturmaßnahme wurde die Komponente Gestänge Achssensor hinten wieder in die richtige Lage gebracht. Um den Diagnosevorgang abzuschließen, wurde nach der Reparatur die Exsitenz der Kundenbeanstandung „Leuchtweite zu hoch“ überprüft. Nach der Feststellung, dass keine Kundenbeanstandung bezüglich der Leuchtweiteregulierung mehr existierte, war der Diagnose- und Reparaturvorgang beendet.

131

5

Wissenserhebung mit DMB-System

Der Wissenserhebungsansatz, der in Kapitel 3 beschrieben ist, wurde in dieser Arbeit umgesetzt. Die entwickelte Modellierungsapplikation wird im Folgenden als DMB-System (Diagnostic Model Builder System) bezeichnet. Im ersten Abschnitt dieses Kapitels wird auf den Aufbau von DMB-System und auf die Aktivitäten zur Erstellung eines Diagnosemodells eingegangen. Im zweiten Abschnitt werden die verschiedenen Rollen bei der Modellerstellung definiert. Anschließend wird die entwickelte Diagnoselaufzeitumgebung aus Benutzersicht kurz beschrieben. Abschließend wird die Qualitätssicherung in Form des Modelltests vorgestellt.

5.1 5.1.1

Modellerstellungsprozess, Rollen und Systemarchitektur Modellerstellungsprozess Start

Struktur- und Verhaltensmodell erstellen Kundenbeanstandungen abbilden

Fehlercode integrieren

Externe Messungen modellieren

Test und Prüfmöglichkeiten anbinden

Erstelltes Modell testen

Abbildung 5.1: Die sechs Phasen bei der Modellierung eines Systems Aufgrund der Anforderungsanalyse und des Konzepts zur Modellierung des Diagnosemodells kann der gesamte Modellierungsprozess in sechs Phasen aufgeteilt werden (Abbildung 5.1). Nachfolgend werden die einzelnen Phasen der Modellierung vorgestellt. Zunächst erfolgt in der ersten Phase eine Darstellung der Systemgrenze, der systemeigenen Komponenten, der Subsysteme sowie deren Verbindungen (Abbildung 5.2). Darüber hinaus gilt es, die systemeigenen

132

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM

Komponenten in Sensoren, Aktoren, Steuergeräte und passive Komponenten zu unterscheiden. Systemschnittstellen SS_AussteuerVerhältnis

MS_Tank

MS_Wassergehalt

Tankfüllstand

KraftstoffWassergehalt B9.72

Systemsensoren

KraftstoffFörderpumpe Tankstutzen Tank

Kraftstoffleitung 1 A23.1

Kraftstofffilter J23.2

Kraftstoffleitung 2 A23.1

Rücklauf Verbindungen

Subsystem

Systemkomponenten

Abbildung 5.2: Erste Phase: Struktur- und Verhaltensmodellierung

Um die Hauptaktivitäten bei der Erstellung eines Struktur- und Verhaltensmodells zu beschreiben, wird in Abbildung 5.3 eine mögliche Prozessvariante, die bei diesem Erstellungsvorgang auftreten kann, skizziert. Die einzelnen, dargestellten Schritte sind im Folgenden kurz beschrieben: • „Struktur- und Verhaltensmodell anlegen“: Um eine Diagnose durchzuführen, muss ein Struktur- und Verhaltensmodell angelegt werden. • „Modell aus Bibliothek importieren“: In diesem Schritt können einzelne Modelle aus der Modellbibliothek ausgewählt und importiert werden. • „Komponentenschablone importieren“: Komponenten, die nicht in der Modellbibliothek enthalten sind, müssen modelliert werden. Dazu wird die vordefinierte Schablone aus der Toolbar per Mausklick in das Modell importiert. • „Komponentenschnittstellen festlegen“: Um ein Komponentenmodell zu erstellen, muss der Modellierer die Schnittstellen definieren. Es werden nicht nur Art und Richtung der Schnittstelle festgelegt, sondern auch die Transportobjekte und deren Attribute, welche sich in dieser Schnittstelle befinden, spezifiziert. • „Variablen festlegen“: Dieser Schritt beinhaltet die Definition aller internen Funktions-, Zustands- und Fehlervariablen der Komponente.

5.1. MODELLERSTELLUNGSPROZESS, ROLLEN UND SYSTEMARCHITEKTUR 133 H [weiter]

Struktur- und Verhaltensmodell anlegen

[stop] Modell aus Bibliothek importieren

Komponentenschablone importieren

Komponentenschnittstellen festlegen

Verhalten modellieren

Variablen festlegen

Verbindungen festlegen [weiter]

Systemschnittstellen festlegen [weiter]

[weiter]

Systemverhalten ermitteln

Struktur- und Verhaltensmodell testen

Abbildung 5.3: Detaillierte Aktivitäten zur Erstellung des Struktur- und Verhaltensmodells • „Verhalten modellieren“: Nach der Definition der Schnittstellen und der internen Variablen kann der Modellierer das Verhalten der Komponente in Form einer oder mehrerer qualitativer relationaler Gleichungssysteme modellieren. Aus diesen Gleichungssystemen wird die Verhaltenstabelle automatisch erzeugt. • „Systemschnittstellen festlegen“: In diesem Schritt wird die Systemgrenze definiert. • „Komponentenverbindungen festlegen“: Hier werden die Interaktionen und Beziehungen zwischen Komponenten modelliert. • „Systemverhalten ermitteln“: Die Modellierung des Gesamtverhaltens des Systems kann auf zwei Weisen abgebildet werden. Entweder wird das Systemverhalten aus dem Verhalten der systemeigenen Komponenten und aus der Topologie des Systems generiert beziehungsweise abgeleitet oder das Gesamtverhalten wird manuell definiert.

134

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM • „Struktur- und Verhaltensmodell testen“: Nach der Erstellung des Modells kann durchgehend das Modell gegen die zuvor definierten Testfälle getestet werden. Wenn das Modell alle Testfälle bestanden hat, ist dieser Modellierungsschritt beendet.

Kundenbeanstandungen werden als virtuelle Komponenten in der zweiten Phase in das Modell eingebunden (Abbildung 5.4). Hierbei erfolgt ein Mapping der Beanstandungen auf physikalische Größen des Modells. Dies bedeutet, dass die Kundenbeanstandung an physikalische Größen der Systemein- und Systemausgänge gebunden wird. Zusätzlich können verdächtige Systemkomponenten, die als Ursache des Symptoms beziehungsweise der Kundenbeanstandung dank Expertenwissen bekannt sind, in Verbindung mit der zuvor abgebildeten Kundenbeanstandung gebracht werden. SS_Einspritzung

Rail Y1.25 Rücklauf Verbindung 4 Rücklauf Verbindung 3 Rücklauf Verbindung 2 Rücklauf Verbindung 1

Injektor 1 Y2.1

Injektor 2 Y2.2

Injektor 3 Y2.3

Injektor 4 Y2.4

Brennraum 1

Brennraum 2

Brennraum 3

Brennraum 4

Starke Rauchentwicklung schwarz Kundenbeanstandung

Abbildung 5.4: Zweite Phase: Modellierung der Kundenbeanstandungen Die Abbildung der Informationen der Onboard-Diagnose als virtuelle Komponenten erfolgt in der dritten Phase (Abbildung 5.5). Dabei gilt es, wie in Kapitel 3 beschrieben, zwischen zwei Arten von Fehlerspeichereinträgen zu unterscheiden. Zum einen existieren Fehlercodes, die direkt auf Komponenten zeigen. Zum anderen können die Fehlercodes auf physikalische Größen (zum Beispiel „Kraftstoffmenge zu niedrig“) hinweisen. Darüber hinaus erfolgt eine

5.1. MODELLERSTELLUNGSPROZESS, ROLLEN UND SYSTEMARCHITEKTUR 135 Anbindung der virtuellen Komponenten an die realen Komponenten mit Hilfe von virtuellen Verbindungen.

0190, 2008, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2023, 2047, 2048, 2049, 2050, 2051, 2056

SS_Einspritzung

Fehlercodes

Rail Y1.25

Rücklauf Verbindung 4

Rücklauf Verbindung 3

Rücklauf Verbindung 2

Rücklauf Verbindung 1

Injektor 1 Y2.1

Injektor 2 Y2.2

Injektor 3 Y2.3

Injektor 4 Y2.4

Fehlercodes Brennraum 1

0201, 2141, 2503, 2531, 2561, 2574

Brennraum 2

0202, 2142, 2504, 2532, 2562, 2575

Brennraum 3

0203, 2143, 2505, 2533, 2563, 2576

Brennraum 4

0204, 2144, 2506, 2534, 2564, 2577

Abbildung 5.5: Dritte Phase: Fehlercodes in das Modell integrieren In der vierten Phase werden systemexterne Komponenten wie zum Beispiel externe Messungen modelliert und in das Modell integriert. Diese Phase der Modellierung ist in Abbildung 5.6 dargestellt. Hierbei sind die virtuellen Verbindungen getrennt nach systemexternen und eigenen Komponenten anzulegen. Die Test- beziehungsweise Prüfmöglichkeiten der systemeigenen Komponenten- und Stellgliedtests werden in der fünften Phase dem Modell hinzugefügt (Abbildung 5.7). Dabei wird der Test der einzelnen Komponente direkt an die Komponente gebunden.

136

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM

SS_AussteuerVerhältnis

MS_Tank

MS_Wassergehalt

Tankfüllstand

KraftstoffWassergehalt B9.72

KraftstoffFörderpumpe Tankstutzen Tank

Kraftstoffleitung 1 A23.1

Kraftstofffilter J23.2

Kraftstoffleitung 2 A23.1

Rücklauf Kraftstoffdruck

Kraftstoffdruck

Externe Messungen

Abbildung 5.6: Vierte Phase: Abbildung der externen Messungen

SS_Einspritzung Rail Y1.25 Rücklauf Verbindung 4 Rücklauf Verbindung 3 Rücklauf Verbindung 2 Rücklauf Verbindung 1

Test

Injektor 1 Y2.1

Injektor 2 Y2.2

Brennraum 1

Einspritzmengen Vergleich

Brennraum 2

Injektor 3 Y2.3

Brennraum 3

Injektor 4 Y2.4

Brennraum 4

Injektor Einzelabschaltung

Abbildung 5.7: Fünfte Phase: Komponenten- und Stellgliedtests anbinden

5.1. MODELLERSTELLUNGSPROZESS, ROLLEN UND SYSTEMARCHITEKTUR 137 Demgegenüber muss der Stellgliedtest an eine Komponentengruppe gebunden werden. Die Integration des Komponententests kann durch eine Datenbankabfrage anhand des Identifizierungscodes der Komponente automatisch erfolgen. Die Anbindung beim Stellgliedtest funktioniert analog. Der Unterschied ist, dass nicht ein Identifizierungscode einer Komponente abgefragt wird, sondern alle Identifizierungscodes abgeglichen werden müssen. Dabei gilt es zu berücksichtigen, dass bei den Phasen 2 - 5 diese Reihenfolge nicht zwingend eingehalten werden muss. Obendrein kann, je nach verfügbaren Informationen, die zweite, dritte oder vierte Phase auch weggelassen werden. Dies führt allerdings unmittelbar zu einer geringeren Diagnoseleistung, da das Werkstattpersonal so nicht mit allen vorhandenen Symptomen und diagnoserelevanten Informationen arbeiten kann. Um die zweckgebundenen Diagnoseanforderungen des erstellten Modells zu überprüfen, wird das Modell im sechsten Schritt gegen Testfälle getestet. Auf die Erstellung und die Ausführung der Testfälle sowie die Auswertung der Testergebnisse wird am Ende diese Kapitell detailliert eingegangen. Auf Grund der unterschiedlichen Wissens- und Informationsanforderungen in verschiedenen Phasen der Diagnosemodellerstellung ist es möglich, das Diagnosewissen in einem vollständigen Diagnosemodell mit mehreren Personen zu erheben und danach zusammenfügen. Die verschiedenen Rollen in der Wissenserhebung werden im nächsten Abschnitt beschrieben.

5.1.2

Rollen bei der Modellerstellung

Mit der Aufteilung des Erstellungsprozesses und der Möglichkeit, einige Phasen parallel zu bearbeiten, können verschiedene Rollen von Beteiligten übernommen werden, um das Diagnosemodell zu vervollständigen. In Abbildung 5.8 ist eine mögliche Rollenverteilung, die bei der Modellerstellung auftreten kann, dargestellt. Die Beteiligten können in folgenden Rollen auftreten: • Erste Rolle (Person 1): Datenbankbetreuer - verantwortlich für die Datenverwaltung in den verschiedenen Datenbanken wie Modellbibliothek-, Basisparameter- und Optimierungsparameterdatenbank. • Zweite Rolle (Person 2): Modellierer beziehungsweise Modellverantwortlicher - erstellt das Struktur- und Verhaltensmodell und ist verantwortlich für die Betreuung und Pflege des erstellten Modells. • Dritte Rolle (Person 3): Diagnoseparameterbetreuer - ermittelt und pflegt die Sollwerttabelle, Inhalte und Interpretationsmöglichkeiten der Fehlercodes, die Testmöglichkeiten der systemeigenen Komponenten sowie die Stellgliedtests. Damit ist seine Zuständigkeit die Beschaffung der Basisparameter. • Vierte Rolle (Person 4): Optimierungsdatenbetreuer - sammelt das Wissen über Ausfallwahrscheinlichkeit, Test- und Prüfkosten der Komponenten, Subsysteme und Systeme. • Fünfte Rolle (Person 5): Testfallspezifizierer - definiert die Testfälle für das Basisdiagnosemodell und das Diagnosemodell. • Sechste Rolle (Person 6): Tester - nutzt das erstellte Modell und die zuvor definierten Testfälle unter Verwendung der entwickelten Modellüberprüfungsapplikation, um Testprotokolle zu erzeugen.

138

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM

Abbildung 5.8: Rollen der Beteiligten bei der Modellerstellung

5.1.3

 

Systemarchitektur DMB-System

Ausgehend von verschiedenen Anforderungen an DMB-System, die im Kapitel 2 beschrieben wurden, von dem im Kapitel 3 entwickelten Lösungskonzept und dem oben beschriebenen Modellerstellungsprozess sowie der Aufteilung der unterschiedlichen Rollen bei der Modellerstellung kann eine Systemarchitektur von DMB-System festgelegt werden. In diesem Abschnitt wird die Architektur des entwickelten Systems erläutert. Eine detaillierte Beschreibung der Systemarchitektur ist bedingt durch die umfangreiche Funktionalität des Systems im Rahmen dieser Arbeit nicht möglich. Nachfolgend werden lediglich die Hauptsegmente und die wichtigsten Systemschnittstellen erläutert. In Abbildung 5.9 wird die Struktur des Systemaufbaus in der ersten Ebene der Dekomposition dargestellt. Dabei ist DMB-System das entwickelte System. Um ein Diagnosemodell erstellen zu können, greift DMB-System auf vier verschiedene Datenbanken zu: • Die Identifizierungsdatenbank enthält die Identifikationsinformationen, die für die Zusammenführung des Diagnosewissens entsprechend der oben beschriebenen Modeller-

5.1. MODELLERSTELLUNGSPROZESS, ROLLEN UND SYSTEMARCHITEKTUR 139 stellungsphasen benötigt werden. • Die Wiederverwendung des Diagnose- beziehungsweise des Modellierungswissens wird unter Verwendung der Modellbibliothek realisiert. Eine Datenbank, die ein ContentManagement-System (CMS) besitzt, übernimmt serverseitig die Verwaltung der Modellbibliothek. Clientseitig unterstützt das System die Erzeugung des neuen Diagnosemodells durch Bereitstellung des existierenden Diagnosewissens. DMB-System beinhaltet zusätzliche Funktionen, um das Modell in der Bibliothek zu verwalten, wenn die Rolle des Benutzers zugelassen ist. • Die Testfalldatenbank liefert die Testfälle für die Modellprüfung. Die Testfälle werden durch Testfallspezifizierer mittels einer Testplattform von DMB-System definiert. Die Testergebnisse und deren Auswertung werden archiviert und an die Testfalldatenbank zurückgeschickt. • Wenn ein Diagnosemodell fertig gestellt und geprüft ist, kann der Nutzer mittels einer Schnittstelle von DMB-System das Modell in die Modelldatenbank hochladen. Diese Modelldatenbank verfügt über ein Enterprise-Content-Management-System (ECMS), das verschiedene Aufgaben wie zum Beispiel Verwaltung, Speicherung, Archivierung und Bereitstellung des Diagnosewissens in Form von Modellen übernimmt.

Modellbibliothek

Modelldatenbank

Identifizierungsdatenbank

DMB-System Benutzer

Testfalldatenbank

Abbildung 5.9: DMB-System und seine Umgebung Die Zerlegung von DMB-System ist in Abbildung 5.10 dargestellt. DMB-System besitzt insgesamt neun Hauptsegmente beziehungsweise Pakete: • Knowledge Reuse: Die Wiederverwendbarkeit des Diagnosemodellwissens wird mittels dieses Pakets unterstützt. Hierbei existiert eine Reihe von Funktionen, wie zum Beispiel: – Import des Komponenten- beziehungsweise Subsystemmodells

140

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM

Identification Manager

Knowledge Reuse

Control

Behavior Modelling

View

Model Export Consistency Checking

Modelling Framework

Modelling Assistance

Local Repository

Control

Variant Handling

View

Variant Manager Framework

Test Case Import Control

View

Model Checking

Test Result Checking Framework

DMB-System Abbildung 5.10: Dekomposition von DMB-System in Segmente – Spezialisierung des vorhandenen Komponentenmodells – Automatische Erzeugung des Komponentenverhaltens aus dem Simulink-Modell und Import in das Diagnosemodell. • Model Export: Das erstellte Modell wird mittels dieses Pakets in die Modelldatenbank hochgeladen. Das Paket verfügt über eine zusätzliche Extraktionsfunktion, die einen Teil des Modells, das für verwandte Systeme gültig ist, extrahiert und für die Modellbibliothek bereitstellt. • Modelling Framework: Die Architektur dieses Segments basiert auf dem Model-ViewController-Muster. Da das Segment „Datenmodell“ die Daten und die Geschäftslogik enthält, die nicht nur für das Paket „Modelling Framework“ sondern auch für das Paket „Checking Framework“ relevant sind, besteht das Paket „Modelling Framework“ aus zwei Segmenten: – View: Das Paket präsentiert die Daten des zu erstellenden Diagnosemodells und

5.1. MODELLERSTELLUNGSPROZESS, ROLLEN UND SYSTEMARCHITEKTUR 141 nimmt die Benutzereingabe entgegen. – Control: Die Verwaltung der Präsentationsschichten und der Auswertung beziehungsweise Weiterverarbeitung der Interaktionen zwischen dem Benutzer und Modelling Framework sind die Aufgaben dieses Pakets. Dabei ist die Manipulation der Daten abhängig von den Benutzerinteraktionen und der vordefinierten Geschäftslogik. • Modelling Assistance: Dieses Segment unterstützt die Zuordnung des Diagnosewissens und die Modellierung des physikalischen Verhaltens und besteht aus drei Hauptpaketen: – Identification Manager: Da das Diagnosewissen aus verschiedenen Quellen stammt und durch unterschiedliche Personen zusammengestellt wird, stellt die Verwaltung des Diagnosewissens neue Anforderung an die Wissenszusammenführung. Die Methoden, die in diesem Paket implementiert sind, unterstützen die Individualisierung und Konsistenzerhaltung von komponenten-, system- beziehungsweise fahrzeugtypenbezogenen Diagnoseinformationen, zum Beispiel Sollwertbereichen oder herstellerspezifischen Fehlercodes. – Behavior Modelling: Dieses Paket wurde entwickelt, um die Erzeugung der Verhaltenstabelle aus qualitativen Relationsbeschreibungen zu automatisieren. – Consistency Checking: Durch die Wiederverwendung des Modellwissens in Form von Modellbibliotheken und die Möglichkeit der Zusammenführung der Teilmodelle entsteht möglicherweise eine Inkonsistenz, wie zum Beispiel bei der Namensgebung der Komponenten im Diagnosemodell. Dieses Paket überprüft die Konsistenz des Modells und gibt Rückmeldung an den Modellierer. • Local Repository: Wenn das Modell in Bearbeitung ist und noch nicht in die Modelldatenbank hochgeladen wurde, erfolgt die Erhaltung der Daten des Modells lokal. Dieses Paket enthält die Modelldaten und die Geschäftslogik für die Modellierungs- und die Modellprüfungsvorgänge. • Test Case Import: Die erstellten beziehungsweise erzeugten Testfälle aus der Werkstattinformationsrückführung können mit den bereitgestellten Funktionen dieses Pakets in das Checking Framework importiert werden. • Checking Framework: Die Architektur dieses Segments ist analog zur Architektur des Segments Modelling Framework und enthält zwei Teilsegmente: – View: Das Paket präsentiert nicht nur die Daten des erstellten Diagnosemodells, sondern auch die Daten der definierten Testfälle. Dieses Segment nimmt hauptsächlich die Benutzereingabe bezüglich der Testdurchführung entgegen. – Control: Das Paket verwaltet die Präsentation der Modelldaten und der Daten der Testfälle. Die Manipulation der Daten ist ausschließlich auf Testfälle beschränkt. • Model Checking: Die Ausführung der erstellten und importieren Testfälle werden durch Funktionen dieses Segments realisiert. Die entstehenden Testergebnisse nach jedem Testlauf werden mit Hilfe der Methoden in diesem Segment als Testreport erstellt, visualisiert und gesichert. • Test Result: Dieses Segment ermöglicht dem Tester, die erstellten Testreporte in der Testfalldatenbank zu archivieren.

142

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM • Variant Handling Framework: Da alle Frameworks in DMB-System auf dem ModelView-Controller-Muster basieren, besteht dieses Frameworks auch aus zwei Teilsegmenten: View und Control. • Variant Handling: Dieses Segment beinhaltet verschiedene Algorithmen, die zum einen die Abstraktion der Struktur beziehungsweise des Verhaltens von vorhandenen Modellen ermöglichen und zum anderen den Abstand zwischen Modellen ermitteln.

5.2

Das entwickelte DMB-System

Im Rahmen der Realisierung wurde eine Modellierungsapplikation zur Erhebung und Verwaltung des Diagnosewissens, das für eine Durchführung der Diagnose in der freien Werkstatt erforderlich ist, entwickelt. Eine grobe Beschreibung der Funktionen der entwickelten Applikation zur Modellierung der Systemkomponente wurde in Abschnitt 1.3.3 beschrieben. Demzufolge werden in diesem Abschnitt nur das Speicherformat des erstellten Modells sowie die entwickelte Umgebung zur Qualitätssicherung und der Variantenmanager erläutert.

5.2.1

Speicherformat des Modells

Modell im XML Format JAVA-Objekt im Binärformat Kompression im JARFormat

Abbildung 5.11: Ergebnisse der Reduktion des Speicherbedarfs Der Austauschbarkeit und Flexibilität wegen wurde das mit DMB-System erstellte Modell im XML-Format gespeichert. Dieses Format führt zu einem relativ großen Speicherbedarf und längeren Ladezeiten beim Diagnosevorgang und ist daher für freie Werkstätten mit schwacher Rechnerinfrastruktur nicht geeignet. Hier ist eine Lösung zur Reduktion des Speicherbedarfs nötig. In dieser Arbeit wurde das XML-Format durch ein Binärformat mit einer Komprimierung für das Diagnoselaufzeitsystem ersetzt. Aus Tabelle 5.1 geht hervor, dass ein durchschnittlicher Komprimierungsfaktor von circa 200 erreicht wurde. Modell

Speicherbedarf

Faktor

OpelCorsa1.4KraftstoffV0.7.mod OpelCorsa1.4KraftstoffV0.7.obj OpelCorsa1.4KraftstoffV0.7.jar

37.995 KB 2.257 KB 196 KB

16.8 193.8

MB220CdiKraftstoffV1.3.mod MB220CdiKraftstoffV1.3.obj MB220CdiKraftstoffV1.3.jar

35.500 KB 2.714 KB 200 KB

13.1 177.5

143

5.2. DAS ENTWICKELTE DMB-SYSTEM OpelCorsa1.4LuftV0.6.mod OpelCorsa1.4LuftV0.6.obj OpelCorsa1.4LuftV0.6.jar

31.899 KB 2.416 KB 143 KB

13.2 223.1

MB220CdiLuftV1.2.mod MB220CdiLuftV1.2.obj MB220CdiLuftV1.2.jar

31.431 KB 2.434 KB 143 KB

12.9 219.8

Durchschnittlicher Verbesserungsfaktor

203.6

Tabelle 5.1: Ergebnisse der Reduktion des Speicherbedarfs

5.2.2

Qualitätssicherung

Modellersteller

Diagnosemodelle

Testfallspezifizierer

Modelltester

Spezifizierung der Testfälle

Auswahl des Diagnosemodells

Testobjekt

Testfälle

Testausführung

Testergebnisse

Testauswertung

Qualität des Diagnosemodells

Qualität der Testfälle

Testarchiv Abbildung 5.12: Testplattform und Testrollen

Testplattform

144

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM

Für die verschiedenen Teststufen, die in 3.11 beschrieben sind, wurde in dieser Arbeit eine Testplattform entwickelt. Mit den entwickelten Funktionen unterstützt diese Plattform alle Testphasen in verschiedenen Entwicklungständen des Modells. Für die Plattform sind drei Benutzerrollen (Abbildung 5.12) vorgesehen: • Modellersteller: Seine Rolle ist die Erstellung des Testobjekts beziehungsweise des Diagnosemodells. Dabei kann das erstellte Modell ein Komponenten-, Teilsystem- oder Systemmodell sein. • Testfallspezifizierer: Analog zum Standard IEEE 829 ist die Aufgabe des Testfallspezifizierers die Spezifizierung und Dokumentierung der Testfälle. • Modelltester: Anhand der Testfälle führt der Tester mittels der entwickelten Testplattform die Überprüfung des Testobjekts durch. Die Ergebnisse der Testausführung werden vom Tester erfasst und ausgewertet.

Unbenannt - 1.ufo

Abbildung 5.13: Ergebnisse des Komponententests In dieser Arbeit wird bei der Modellerzeugung entsprechend des testgetriebenen Softwareentwicklungsansatzes ein testgetriebener Modellentwicklungsansatz unterstützt. Demzufolge wird der Komponententest vom Modellersteller selbst durchgeführt. In dieser Teststufe übernimmt der Modellersteller alle drei oben erwähnten Rollen. Beim Integrationstest sollte die Rolle zwischen Modelltester und Testfallspezifizierer getrennt werden; die Rollen des Modellerstellers und des Modelltesters können in dieser Teststufe zusammengefasst werden. In

5.2. DAS ENTWICKELTE DMB-SYSTEM

145

der Systemsteststufe sollten die drei Rollen komplett getrennt werden, da der Test nicht nur in einer simulierten Werkstattumgebung stattfindet, sondern auch in der realen Werkstatt Unbenannt - 1 durchgeführt werden kann.

Abbildung 5.14: Maske zur Spezifizierung der Modelltestfälle Unbenannt - 2

Abbildung 5.15: Maske zur Darstellung der Modelltestergebnisse In Abbildung 5.13 sind die Ergebnisse eines Komponententests dargestellt. Hier kann der

146

KAPITEL 5. WISSENSERHEBUNG MIT DMB-SYSTEM

Modellierer die Verhaltenstabelle, die aus den von ihm zuvor definierten Verhaltensrelationen generiert wurde, prüfen. Die zweite Testphase des Modells in dieser Arbeit ist der Integrationstest. In Abbildung 5.14 ist die Maske zur Definition des Testfalls im Integrationstest abgebildet. Die letzte Testphase des Modells in dieser Arbeit ist der Systemtest. Neben der Möglichkeit, die Überprüfung des Modells direkt am Versuchsträger durchzuführen, wurde in dieser Arbeit ein Testmodul in der Testplattform entwickelt. Dieses Modul ermöglicht den Automatisierungstest in der Systemtestphase. In Abbildung 5.15 wurden die Testergebnisse in Form von Schnittmengen für den Systemtester dargestellt. Detailierte Ergebnisse wurden in dieser Arbeit in einem Testprotokoll gespeichert.

5.2.3

Variantenmanager

Abbildung 5.16: Variantenmanagement-Modul in DMB-System Die theoretische Grundlage zur Behandlung der Variantenvielfalt, die in Kapitel 3 Abschnitt 11 beschrieben ist, wurde in dieser Arbeit in DMB-System in das VariantenmanagementModul implementiert. In Abbildung 5.16 ist ein Screenshot dieses entwickelten Moduls dargestellt. Mit der graphischen Oberfläche kann der Benutzer die erstellten Modelle abstrahieren und generalisieren. Des Weiteren kann der Nutzer neue Modelle durch Vererbung beziehungsweise Variantenbildung erzeugen. Die Verwaltung der erstellten Modelle in der Modellbibliothek erfolgt zum einen durch Versionierung und Kategorisierung mittels existierender Datenbankfunktionen und zum anderen durch Verfolgung der Beziehungen zwischen den Modellen, welche zum Beispiel voneinander abgeleitet sein können oder über ein gemeinsames Abstraktmodell verfügen. Die Berechnung der Distanz zwischen Modellen erleichtert verschiedene Entscheidungen bei der Analyse und Verwaltung der Varianten. Mit der Distanzberechnung können Entschei-

5.2. DAS ENTWICKELTE DMB-SYSTEM

147

dungen über generische und spezielle Eigenschaften der Diagnosemodelle, wie zum Beispiel Schnittstellen, interne Variablen oder Verhalten getroffen werden. Die Grundlage der Distanzberechnung ist in Abschnitt 11, Kapitel 3 beschrieben und die Implementierung erfolgt durch das Modul Variant Handling in DMB-System (Abbildung 5.17).

Abbildung 5.17: Berechnung der Distanz zwischen Modellen

148

6

Diagnose mit DRT-System

Der in Kapitel 4 beschriebene Diagnoseansatz wurde in dieser Arbeit umgesetzt. Das daraus entstandene Diagnoselaufzeitsystem wird im Folgenden als DRT-System (Diagnostic Runtime System) bezeichnet. Im ersten Teil dieses Kapitels wird auf den Aufbau des entwickelten DRTSystems eingegangen. Danach wird die entwickelte Diagnoselaufzeitumgebung aus Benutzersicht beschrieben und anhand zweier kleiner Beispiele die Vorgehensweise im Diagnosevorgang erläutert. Abschließend werden verschiedene Migrationskonzepte vorgestellt und bewertet.

6.1

Diagnoseprozess und Systemarchitektur

Da der Diagnoseprozess direkten Einfluss auf der Entwicklung der Systemarchitektur hat, wird in diesem Abschnitt zuerst der Diagnoseprozess in der freien Werkstatt mit DRT-System erläutert. Anschließend wird die entwickelte Systemarchitektur beschrieben.

6.1.1

Diagnoseprozess mit DRT-System Start

Fahrzeug annehmen

Diagnose und Reparatur durchführen

Fahrzeug zurückgeben

Abbildung 6.1: Die drei Hauptschritte im Werkstattdiagnoseprozess Ein symptomorientierter Diagnoseprozess in einer Werkstatt wird ausgelöst, indem sich ein Kunde wegen einer beziehungsweise mehrerer Beanstandungen bei der Werkstatt meldet. Hierbei kann der Diagnoseprozess in der freien Werkstatt in drei Prozessabschnitte gegliedert werden (Abbildung 6.1). Im ersten Prozessabschnitt „Fahrzeug annehmen“ werden Aktivitäten (Abbildung 6.2) durchgeführt, die für die erste Diagnoseiteration zur Erzeugung der Diagnosehypothese notwendig sind. Die Fahrzeugannahme beginnt mit der Erfassung der Kunden- und Fahrzeugdaten.

149

6.1. DIAGNOSEPROZESS UND SYSTEMARCHITEKTUR

Dazu werden die Beanstandungen des vorliegenden Fahrzeugs des Kunden mittels einer vordefinierten Symptomliste aus der Datenbank des Diagnosesystems aufgenommen. Zusätzlich können die Umgebungsinformationen aufgenommen werden. Diese diagnoserelevanten Informationen können als zusätzliche Messungen betrachtet werden. Alle Informationen über die Fahrzeughistorie werden dokumentiert. Die Informationen über frühere Reparaturen und den alten Zustand der verbauten Komponenten dienen zur Optimierung der Fehlersuche. Weitere Diagnoseinformationen liefern die Steuergeräte durch die Eigendiagnosefähigkeiten. Um die verbauten Steuergeräte nach möglichen vorhandenen Fehlercodes auszulesen, wird der Diagnosetester an das Fahrzeug angeschlossen. Darüber hinaus kann das Werkstattpersonal einige Funktionskontrollen durchführen, zum Beispiel durch eine Probefahrt oder Sichtkontrolle, durch Überprüfung der Kabel-, Steck- oder Schlauchverbindungen. Start

Kunden- und Fahrzeugdaten erfassen

Kundenbeanstandung aufnehmen

Fahrzeughistorie abfragen

Diagnosetester anschließen und DTCs auslesen

Funktions- und Sichtkontrolle durchführen

Abbildung 6.2: Aktivitäten bei der Fahrzeugannahme Der nächste Prozessabschnitt „Diagnose und Reparatur durchführen“ beginnt mit der Analyse der Diagnoseinformationen, die im ersten Schritt gesammelt wurden. Eine Handlungsempfehlung wird anhand der vorhandenen Informationen ausgegeben. Hierbei können verschiedene Aktivitäten durchgeführt werden (Abbildung 6.3): • Abfragen der Istwerte von Systemsensoren • Durchführung von Messungen mit externen Messgeräten • Ausführung von Stellgliedtests • Prüfung der Systemkomponenten. Die Ergebnisse von Messungen, das Auslesen von Istwerten sowie Stellgliedtests dienen zur Verfeinerung der Diagnosehypothese. Die Komponentenprüfung bestätigt fehlerhafte Komponenten oder schließt sie endgültig aus. Anschließend werden die defekten Komponenten ausgetauscht beziehungsweise die Reparatur nach Vorgabe abgearbeitet. Danach werden vom Werkstattmitarbeiter mit Hilfe des Diagnosetesters alle Fehlercodes aus den Steuergeräten

150

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM Start

Diagnoseinformation in das Diagnosesystem übertragen

Anweisung des Diagnosesystems ausführen (Messungen, Prüfungen)

Istwert des Systemsensors auslesen

Mess- und Prüfergebnisse in dem Diagnosesystem aktualisieren

Externe Messung durchführen

Stellgliedtest

Komponentenprüfung

nein Fehlerursache gefunden ja Fehler beseitigen

ja DTCs vorhanden nein ja Istwert außerhalb Sollbereich nein ja

Kundenbeanstandung noch aktuell

Abbildung 6.3: Aktivitäten bei der Diagnosedurchführung und Reparatur

Diagnose- und Reparatur durchführen gelöscht, da durch die Arbeiten am Fahrzeug eventuell neue Fehlercodes entstanden sind. Der nächste Schritt ist die Prüfung der Existenz der vorliegenden Beanstandungen zum Beispiel durch eine Probefahrt beziehungsweise Funktionstests. Abweichende Istwerte, die während der Diagnose gefunden werden, sollen mit Hilfe eines Diagnosetesters nochmals ausgelesen

6.1. DIAGNOSEPROZESS UND SYSTEMARCHITEKTUR

151

und mit dem Sollwertbereich verglichen werden. Ein Wiedereinstieg in den zweiten Prozessabschnitt ist notwendig, wenn Symptome, Fehlercodes oder Sollwertabweichungen weiterhin existieren. Der letzte Prozessabschnitt startet mit der Übergabe des reparierten Fahrzeuges und dem Diagnoseprotokoll vom Werkstattpersonal an den Kunden. Anschließend können die Prüfschritte und die Reparatur beziehungsweise der Austausch der Komponente aus dem Diagnoseprotokoll dokumentiert, archiviert und gegebenenfalls mit Zustimmung des Werkstattpersonals an den Hersteller des Diagnosetools gesendet werden.

6.1.2

Systemarchitektur DRT-System

In diesem Abschnitt wird die Systemarchitektur von DRT-System in rudimentärer Form unter Verwendung von UML-Notation beschrieben. Die im Kapitel 2 beschriebene Problematik in der freien Werkstattdiagnose und die daraus resultierenden Anforderungen sowie das in Kapitel 3 und 4 entwickelte Lösungskonzept ermöglichen es, eine Systemarchitektur zu entwerfen. Dabei existieren zwei Hauptanforderungen an die Systemarchitektur: • Bei entsprechender Realisierung soll DRT-System die Anforderungen der freien Werkstattdiagnose erfüllen. • Das entwickelte Diagnoselösungskonzept in DRT-System soll den Servicebereich bezüglich der Qualitätssicherung geeignet unterstützen. Ausgehend von diesen Anforderungen werden mittels des Dekompositionsansatzes das System und die Schnittstellen zwischen den einzelnen Segmenten beziehungsweise Bestandteilen des Systems erläutert. In der ersten Ebene der Dekomposition des Systems wird die Struktur des Systemaufbaus in Abbildung 6.4 grob dargestellt. Die adäquate Systemarchitektur beinhaltet sieben Teilsysteme, die in Folge beschrieben werden. Dabei ist DRT-System das zu entwickelnde System. Um eine Diagnose erstellen zu können, greift DRT-System auf fünf Wissensdatenbanken zu: • Die erste Datenbank ist die Modelldatenbank, in der die erstellten Modelle abgelegt sind. • Die Fahrzeugparameterdatenbank enthält die Sollwertbereiche, Test- und Prüfanweisungen, Arbeitswerte, etc. Mit der Modelldatenbank und der Fahrzeugparameterdatenbank wird nach der Fahrzeugidentifikation das Diagnosemodell für das konkrete Fahrzeug erstellt. • Die Übersetzungsdatenbank beinhaltet verschiedene Schlüssel zur Decodierung der Diagnoseinformationen, die aus den Fahrzeugsteuergeräten stammen. • Die Ersatzteildatenbank liefert die Informationen über die Verfügbarkeit der Ersatzteile im Lager der Werkstatt, Ersatzteilkataloge mit entsprechenden Bestellformularen und die benötigte Zeit, um die Teile zu liefern. • Um das Wissen vom Feld zurückzuführen, existiert eine weitere Datenbank, die DRTSystem die Rückmeldeinformationen liefert:

152

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM – Die Rückmeldungsdatenbank bekommt Informationen über Fehler beziehungsweise aufgelaufene Bugs von DRT-System während des Einsatzes in Form von TroubleTickets. – Wenn ein Diagnosevorgang abgeschlossen ist, kann der Nutzer mittels einer Schnittstelle von DRT-System das Diagnoseprotokoll an die Rückmeldungsdatenbank senden. Diese Informationen können zu verschiedenen Zwecken, zum Beispiel zur Verbesserung der Modelle, zur Auswertung der Ausfallwahrscheinlichkeit, etc. genutzt werden.

Fahrzeugparameterdatenbank

Modelldatenbank

Übersetzungsdatenbank

Ersatzteildatenbank

DRT-System Rückmeldungsdatenbank

Benutzer

J-Integra for COM

CAS-KTS 500

Abbildung 6.4: DRT-System und seine Umgebung Neben der Benutzerschnittstelle, die die Interaktion zwischen dem Benutzer und DRT-System ermöglicht, benötigt das System eine weitere Schnittstelle, über die das entwickelte System mit dem Fahrzeug kommuniziert. Hierbei steuert DRT-System mit Hilfe von „J-Integra for COM“ die Testerschnittstelle der Software des CAS-KTS500 (CAS - Computer Aided Service Eigendiagnose-Software von Bosch; KTS500 - Steuergeräte-Diagnose-Tester) an, um damit die

153

6.1. DIAGNOSEPROZESS UND SYSTEMARCHITEKTUR

Messungen mit systemeigenen Sensoren sowie Stellgliedtests anzustoßen. Die Ergebnisse der Messungen und Tests werden auch von „J-Integra for COM“ an DRT-System weitergereicht. „J-Integra for COM“ ist ein Produkt von Intrinsyc Software International Inc. und ermöglicht die Integration von komplexen Softwaresystemen über Systemplattformen hinweg. Mit dieser Komponente lässt sich aus DRT-System heraus auf COM-Komponenten zugreifen.

Translation

Onboard Diagnostics Bridge

Diagnostic Trouble Code Abstraction

Control

View

Embedded Sensor Abstraction Observation Abstraction

Model Explorer

Test Abstraction External Measurement Abstraction

Model Analyse

Measurement

DRT-System Abbildung 6.5: Dekomposition von DRT-System in Segmente In Abbildung 6.5 ist die Zerlegung von DRT-System dargestellt. DRT-System besitzt insgesamt fünf Segmente beziehungsweise Pakete: • Model Analyse: Dieses Paket ist in der Lage, die erzeugten Modelle mit den eingegebenen Diagnoseinformationen zu analysieren. Das Paket stellt Methoden für die Fehleranalyse, die Erzeugung von Listen der verdächtigen Komponenten und den optimalen Arbeitsablauf dem Paket „Model Explorer“ zur Verfügung. • Model Explorer: Dieses Paket stellt das Benutzerinterface für das Diagnosetool dar. Es basiert auf zwei Teilsegmenten: „Control“ und „View“. Es unterstützt die Interaktionen zwischen dem Benutzer und dem Diagnosetool im Diagnosevorgang und steuert und protokolliert den Ablauf der Fehlersuche.

154

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM • Onboard Diagnostics Bridge: Diese Brücke ist nötig, um die Methodenaufrufe aus der DRT-System-Umgebung in die Fahrzeugumgebung mittels „J-Integra for COM“ weiterzuleiten und zurückzuerhalten.

Vehicle Identification Observations Load Model DTCs Embedded Sensors

Call Model Information

External Measurements Component Tests

Diagnostic Input Informations

Display Model Content Revalidate View Vehicle Repair History Diagnostic Output Informations Information Manager Diagnosis Result Execute Diagnostic

Workflow

Load Diagnostic Results

Diagnosis Protocol Display Result

Encode Protocol

View Control

Model Explorer

Abbildung 6.6: Dekomposition des Segments „Model Explorer“ in Pakete • Translation: Das Paket ermöglicht es, die kodierten Textbausteine der CAS-Schnittstelle mit Hilfe einer Übersetzungsdatenbank in Klartext zu übersetzen. Deshalb besitzt das Paket Schnittstellen zur Übersetzungsdatenbank und Schnittstellen zum Measurement-

155

6.2. DIAGNOSE MIT DRT-SYSTEM

Paket. Die Messergebnisse und ausgelesenen Fehlercodes werden vom MeasurementPaket über eine Schnittstelle an das Translation-Paket weitergereicht und im Klartext zurückgegeben. • Measurement: Das Measurement-Paket beinhaltet fünf Segmente. Dabei führen das Paket „Embedded Sensor Abstraction“ die angeforderten Istwert-Messungen, das Paket „Diagnostic Trouble Code Abstraction“ die Fehlerspeicherabfrage und das Paket „Test Abstraction“ die Stellgliedtests eigenständig aus und bedienen sich jeweils der Schnittstelle des Pakets „Onboard Diagnostics Bridge“. Die Interpretation der Kundenbeanstandungen, die von dem Paket „Model Explorer“ aufgenommen wurden, ist Aufgabe des Pakets „Observation Abstraction“. Die Ergebnisse der Komponententests, die durch den Benutzer ausgeführt und durch das Paket „Model Explorer“ aufgenommen wurden, werden in dem Paket „External Measurement Abstraction“ verarbeitet und an das Paket „Model Analyse“ weitergereicht. Das Segment beziehungsweise Paket „Model Explorer“ besitzt zwei Hauptpakete: „Control“ und „View“ (Abbildung 6.6). Das Paket „Control“ stellt sämtliche Funktionsmodule bereit, die zur Durchführung und Protokollierung des Diagnosevorgangs in der freien Werkstatt benötigt werden. Dabei stellt dieses Paket nicht nur die Verbindung zu den oben genannten Datenbanken her, sondern verwaltet auch die Diagnoseinformationen, die vom Benutzer mittels des Paketes „View“ eingegeben wurden und jenen, die aus der Onboard-Diagnosefunktion des Fahrzeugs zur Verfügung stehen. Zudem verfügt dieses Paket über Kodierungsverfahren, über die das Diagnoseprotokoll mit Zustimmung des Benutzers an die Rückmeldedatenbank gesendet wird. Das Paket „Control“ besitzt natürlich weitere Funktionen wie Fahrzeugidentifikation, Laden des Modells, Anstoßen der Modellanalyse und Abholen der Analyseergebnisse sowie deren Erklärungen für das vorgelegte Problem. Das Paket „View“ repräsentiert das Diagnosewissen, das sich im Modell befindet, und die Diagnoseergebnisse nach jedem Arbeitschritt, der in dem Diagnosevorgang durchgeführt wurde. Die bislang grobe Strukturbeschreibung der Architektur von DRT-System wird im Folgenden um eine detaillierte Betrachtung aus Benutzersicht ergänzt. Hierbei werden die Ergebnisse der Umsetzung der Systemarchitektur auf die Wahrnehmung des Benutzers reduziert.

6.2

Diagnose mit DRT-System

Die entwickelten Algorithmen, die in Kapitel 4 beschrieben sind, und die Systemarchitektur, auf die in Abschnitt 6.1 eingegangen wurde, wurden in dieser Arbeit als Grundlage für die Entwicklung eines Diagnosetools genommen. Im Abschnitt 1.3.4 wurden die Ergebnisse der Realisierung und die Bedienung von DRT-System aus Benutzersicht grob vorgestellt. Deshalb wird in diesem Abschnitt nur die Diagnose mit der entwickelten Applikation beschrieben. In Tabelle 6.1 und Tabelle 6.2 wurden zwei Versuche mit ihren Abläufen unter Benutzung von DRT-System dargestellt. Beobachtung/Messung/Test/Prüfung

Handlung und Ergebnis

1

Kundenbeanstandung

schlechte Gasannahme und Übergangsfehler

2

DTCs

keine

156

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM

3

Istwert Saugrohr-Drucksensor

normal

4

Drosselklappen Istwert Positionssensor 1, 2

normal

5

Istwert Ansaugluft-Temperatursensor

normal

6

Stellgliedtest Drallklappen

in Ordnung

7

Unterdruckleitung von Drallklappe

Leckage gefunden

Tabelle 6.1: Ablauf eines Diagnoseversuchs an einem ME7.6-Benzinsystem mit DRT-System Beobachtung/Messung/Test/Prüfung

Handlung und Ergebnis

1

Kundenbeanstandung

Kraftstoffverbrauch zu hoch und Abgas ist schwarz

2

DTCs

P0110

3

Ladeluft-Temperatursensor

Signal unplausibel → Unterbrechung

Tabelle 6.2: Ablauf eines Diagnoseversuchs an einem CP3-Dieselsystem mit DRT-System Zu Beginn werden die Einstiegsinformationen aus Kundenbeanstandungen und ausgelesenen Fehlercodes durch Diagnosealgorithmen ausgewertet. Die Ergebnisse der Auswertung bestehen aus einer Liste der verdächtigen Komponenten und einer Liste der Messungs- oder Prüfungsvorschläge. Die verdächtigen Komponenten sind Komponenten gemäß Kapitel 4, die die eingegebenen Symptome am ehesten durch ihren Defekt beziehungsweise ihr Fehlverhalten verursachen können. Die Komponenten erhalten eine Gewichtung gemäß ihrer Fähigkeit, bei ihrem Ausfall diese Symptome hervorzurufen, und ihrer Ausfallwahrscheinlichkeit, die durch statistische Erhebungen entstanden sind. Die Handlungsempfehlung ist eine Liste der Messungen und Prüfungen, mit welcher der Benutzer die zunächst noch sehr umfangreiche Liste der verdächtigen Komponenten eingrenzen kann. Im ersten Beispiel existiert kein Fehlercode, sondern es gibt nur zwei Kundenbeanstandungen. Mit diesen Einstiegsinformationen berechnet DRT-System den nächsten optimalen Schritt „Istwert des Saugrohr-Drucksensors auslesen“. Bei der nächsten Iteration soll die am höchsten gewichtete Messung oder Prüfung abgearbeitet werden. Im ersten Beispiel (Tabelle 6.1) wird durch einen Doppelklick die hinter dem Sensor liegende Anleitung geöffnet (Abbildung 6.7). In der Anleitung befinden sich Informationen, unter welchen Randbedingungen die Messungen erfolgen, wie die Messungen ablaufen und zu welchem Sollwertergebnis die Messungen gelangen sollen. Die erstellten Anleitungen weisen ein Textfeld für die direkte Eingabe von Messwerten aus, so dass auch ohne Ansteuerung der Tester das Ergebnis der Prüfung eingegeben werden kann. Diese Möglichkeit ist für die manuelle Messung mittels Oszilloskop, Voltmeter, etc. erforderlich. Sollte in das Formular kein oder ein ungültiges Ergebnis eingetragen werden, wird automatisch über systemeigene Sensoren der Diagnosetester angesteuert und die Messwerte automatisiert übernommen. Das gewonnene Ergebnis der Prüfungen kann vom Diagnose-Algorithmus nicht direkt verwendet werden, da es sich um Realwerte handelt. Diese Werte müssen nun bewertet werden, so dass dem Algorithmus die Tendenz (niedrig, normal oder hoch) übergeben werden kann. Die Bewer-

6.2. DIAGNOSE MIT DRT-SYSTEM

157

tung kann teilweise automatisch erfolgen, wenn Grenzwerte vorliegen. In den anderen Fällen muss die Bewertung vom Werkstattpersonal erfolgen.

Abbildung 6.7: Beispiel: Instruktion zum Auslesen eines Systemsensor-Istwertes Im Gegensatz zum ersten Beispiel gibt es bei dem zweiten Beispiel einen Fehlercode, der direkt auf eine Komponente zeigt. In diesem Fall ist der zweite Schritt der Diagnose die Prüfung des Ladeluft-Temperatursensors. Analog zu den Messungen liegen hinter den Systemkomponenten die jeweiligen Prüfanleitungen (Abbildung 6.8). In diesen Anleitungen stehen auch die Randbedingungen sowie die Schritte der Prüfungen. Per Doppelklick wird der Komponententest aufgerufen und kann abgearbeitet werden. Im Unterschied zur Messung sind die Ergebnisse der Komponentenprüfung immer mit „in Ordnung“ oder „nicht in Ordnung“ zu bewerten. Wenn das Ergebnis mit „in Ordnung“ bewerten wurde, werden alle internen Fehlervariablen der geprüften Komponente auf „normal“ gesetzt. Das Ergebnis der Messung beziehungsweise Prüfung wird an die Diagnosealgorithmen übergeben, es werden neue Listen berechnet und die nächste Iteration beginnt. Bei jeder Iteration wird das Modell mit immer umfangreicheren Diagnoseinformationen berechnet. Der Vorgang wird so lange fortgeführt, bis keine weitere Messung oder Prüfung in der Handlungsempfehlungsliste mehr vorgeschlagen werden kann und sich damit die Liste der verdächtigen Komponenten nicht weiter eingrenzen lässt. Falls die Liste der Handlungsempfehlungen komplett abgearbeitet wurde und keine Komponenten bei den bisherigen Prüfungen als nicht fehlerhaft identifiziert wurden, wird die Liste der verdächtigen Komponenten in der Reihenfolge der Gewichtung abgearbeitet, bis die defekte Komponente gefunden ist. Im Beispiel des CP3-Dieselsystems wurde die Komponente Ladeluft-Temperatursensor geprüft. Da diese Komponente ein Systemsensor ist, existieren eine Reihe elektrischer Prüfungen. Im Unterschied zu systemeigenen Sensoren gibt es bei den Aktoren nicht nur elektrische Prüfungen, sondern auch Stellgliedtests, die mit Steuergerätefunktionen geprüft werden können. Im ersten Beispiel sollten die Istwerte weiterer verfügbarer Sensoren ausgelesen werden, bevor DRT-System eine Komponentenprüfung vorgeschlug. Die Prüfanleitung der Unterdruckleitung der Drallklappe ist hierbei sehr einfach gehalten. Aus den definierten möglichen Fehlern kann die Prüfanweisung generiert werden. Wenn das Komponentenmodell keinen vordefinierten Fehler beinhaltet, wird eine allgemeingültige Prüfanweisung für passive Komponenten der bestimmten Domäne aufgerufen. Natürlich ist es auch möglich in den Listen weiter unten

158

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM

aufgeführte Konponenten zu bearbeiten, allerdings wird in den meisten Fällen die optimale Prüfreihenfolge nicht erreicht. Das punktuelle Bearbeiten einzelner Prüfschritte kann aber erforderlich sein, um spezielle Funktionen am Fahrzeugsystem zu prüfen.

Abbildung 6.8: Beispiel: Instruktion einer Komponentenprüfung

Nach der Realisierung soll nun zum einen ein Migrationskonzept entwickelt werden, durch welches das entwickelte Diagnosetool in die bestehende Tool-Landschaft integriert wird und zum anderen eine Evaluierung unter Werkstattbedingungen durchgeführt werden. Daher werden im nachfolgenden Abschnitt verschiedene Migrationskonzepte vorgestellt. Bei den Evaluierungen soll das entwickelte DRT-System am Realsystem erprobt und die Bewertung seiner Leistungsfähigkeit bei der geführten Fehlersuche in Bezug auf Diagnosegüte und Diagnosedauer erstellt werden. Zu diesem Zweck werden in Kapitel 7 Abschnitt 2 die Bewertungskriterien definiert und die Versuchdurchführung sowie deren Ergebnisse beschrieben.

159

6.3. MIGRATION IN DAS BESTEHENDE LAUFZEITSYSTEM

6.3

Migration in das bestehende Laufzeitsystem

Aus wirtschaftlicher Sicht ist es eine große Umstellung vom fall- beziehungsweise regelbasierten Diagnoseansatz zum modellbasierten Ansatz. Zum einen fordert die Einbettung des Modellierungstools in den vorhandenen Wissenserhebungsprozess eine Erweiterung und ein Umdenken der vorhandenen Mitarbeiter. Zum anderen wurde der Umstieg auf das neue Diagnosetool noch keiner kompletten ergonomischen Überprüfung unterzogen. Trotz seiner intuitiven Bedienung bedarf es möglicherweise einer Umschulung oder kurzen Einführung für die Werkstattmitarbeiter. Bedingt durch die gleichzeitigen erforderlichen Änderungen bei der Wissenserhebungs- und Diagnosevorgehensweise entstehen verschiedene Einführungsszenarien, welche mit Aufwand, Nutzen und Risiko verbunden sind. Es existieren drei Szenarien: • Totalumstieg: Bei einem Totalumstieg (Abbildung 6.9) werden existierende Autorenund Diagnosesysteme durch das neue Wissenserhebungs- und Diagnosetool ersetzt. Zunächst wird das neue Tool komplett entwickelt. Nach der Schulung der Autoren erfolgt die komplette Umstellung aller Fehlersuchanleitungen auf die modellbasierte Diagnose. Anschließend erfolgt die Markteinführung der neuen Testersysteme bei den Kunden. Servicebereich

Werkstatt

Fehlersuchanleitung Datenbank

Modellierungstool

Modelle Datenbank

Markteinführung

Modellbasierter Tester

Abbildung 6.9: Szenario für den Totalumstieg Servicebereich

Werkstatt

• Parallelbetrieb: Beim Parallelbetrieb (Abbildung 6.10) wird das neue Wissenserhebungsund Diagnosetool parallelFehlersuchzu den existierenden Autoren- und Diagnosesystemen betrieHeuristischer Autorensystem Markteinführung Tester ben. Nachdem die neuen Tools komplett entwickelt sind, werden die neu zu erstellenanleitung Datenbank den, geführten Fehlersuchen mit dem neuen, modellbasierten System erzeugt. Das neue Diagnosetool läuft parallel zum alten auf der gleichen Hardware. Nach der Fahrzeugbeziehungsweise Systemidentifikation wird entweder das alte oder das neue Diagnosetool angezeigt. Modellbasierter Modelle Markteinführung Tester Datenbank • Integration: Bei der Integration in die existierende Tool-Landschaft baut das neue Wis-

Modellierungstool

senserhebungstool auf die existierenden Datenbanken auf. Hier lässt sich zum Beispiel das Textbausteinkonzept für die Erstellung der System- oder Komponentenbeschreibungen und Prüfanweisungen weiterverwenden. Neben dieser Integration bestehender SoftServicebereich Werkstatt warekomponenten müssen hingegen einige entscheidende Softwarekomponenten nach dem Schichtkonzept des Wissenserhebungstools entwickelt werden (zum Beispiel auHeuristischer tomatisierte Einbindung der Steuergerätediagnose und Fehlercodes oder automatisierte FehlersuchAutorensystem Markteinführung Tester anleitung datenbankgestützte Sollwert-Einbindung). Im Diagnosetool sind mehrere Varianten der Datenbank Integration möglich. Konverter

Modellierungstool

160

Modelle Datenbank

Fehlersuchanleitung Datenbank

Servicebereich Markteinführung

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM Servicebereich

Modellierungstool Autorensystem

Modelle FehlersuchDatenbank anleitung Datenbank

Markteinführung Markteinführung

Servicebereich Modellierungstool Autorensystem

Werkstatt Modellbasierter Tester

Modelle Datenbank Fehlersuchanleitung Datenbank

Markteinführung Markteinführung

Werkstatt Modellbasierter Tester Heuristischer Tester

Werkstatt Modellbasierter Tester Heuristischer Tester

Abbildung 6.10: Szenario für den Parallelbetrieb Servicebereich

Werkstatt

Nach Abwägung des Aufwands und insbesondere des Risikos der verschiedenen Szenarien Modellbasierter Modelle Modellierungstool Markteinführung kommt nur das integrative Konzept als Einführungsszenario infrage. Hierbei kann die IntegraHeuristischer FehlersuchTester Datenbank Autorensystem Markteinführung Tester tion wiederum in drei Szenarien anleitung aufgeteilt werden, wobei sich die drei integrativen Konzepte Datenbank nur in der Entwicklung und Einführung des Diagnosesystems in der Werkstatt unterscheiden: Konverter

Autorensystem

Modellierungstool

FehlersuchModellbasierter anleitung Tester Datenbank

Servicebereich

Werkstatt

Markteinführung

Heuristischer Tester

Konverter Modelle Datenbank Modellbasierter Tester

Modellierungstool

Modelle Datenbank

Abbildung 6.11: Integration mit dem Konvertierungsansatz • Integration durch ein Konvertierungstool (Abbildung 6.11): Eine der Integrationsmöglichkeiten ist die Generierung der Fehlersuchanleitung aus Modellem mittels Analysealgorithmen und deren Import in die Fehlersuchanleitungsdatenbank. Hierbei wird das bestehende Diagnosetool nicht verändert und die Fehlersuchanleitung bleibt im alten Format. Dieses Konzept hat den Vorteil, dass kein Einführungs- und Entwicklungsaufwand bei dem Diagnosetool anfällt. Leider ist dieser Vorteil auch der Nachteil, da eine dynamische Optimierung der Fehlersuche unter Verwendung der Diagnosemodelle nicht ausgenutzt werden kann.

161

6.3. MIGRATION IN DAS BESTEHENDE LAUFZEITSYSTEM Servicebereich

Fehlersuchanleitung Datenbank

Autorensystem

Modellierungstool

Modelle Datenbank

Markteinführung

Markteinführung

Werkstatt

Heuristischer Tester

Modellbasierter Tester

Abbildung 6.12: Integration mit dem Plug-in-Ansatz Servicebereich Servicebereich

Werkstatt Werkstatt

• Plug-in-Ansatz (Abbildung 6.12): Ein weiterer Ansatz ist der Plug-in-Ansatz, bei welHeuristischer Fehlersuch- ein zusätzliches Plug-in für die Analyse Heuristischer chem für bestehende Diagnosetools und DarAutorensystem Markteinführung Tester anleitung FehlersuchTester stellung der Analyseergebnisse des Diagnosemodells entwickelt und integriert wird. Der Autorensystem Markteinführung Datenbank anleitung Vorteil dieses Ansatzes istDatenbank die verbesserte Diagnoseunterstützung durch den modellbasierten Ansatz für ein neues System beziehungsweise einen neuen Fahrzeugtyp. Weiterhin benötigt dieser Ansatz einen geringeren Entwicklungsaufwand, weil das Framework Modellbasierter Modelle durch das vorhandene Diagnosetool bereits gegeben ist. Der Nachteil des Plug-ins Modellierungstool Modell-basierterist, Markteinführung Tester Datenbank Modelleohne ein vorhandenes Tester Modellierungstool dass die modellbasierte Diagnose Diagnosetool nicht funktionsfäMarkteinführung Datenbank hig ist. Dies bedeutet, dass die Altlast immer weiter mitgenommen werden muss, selbst wenn das Diagnosewissen später überhandnimmt. Servicebereich

Autorensystem

Modellierungstool

Fehlersuchanleitung Datenbank

Modelle Datenbank

Markteinführung

Markteinführung

Werkstatt Heuristischer Tester

Modell-basierter Tester

Abbildung 6.13: Integration mit der Entwicklung eines neuen Diagnosetools • Integration durch ein neu erstelltes Diagnosetool (Abbildung 6.13): Der letzte Integrationsansatz erfolgt durch die Entwicklung eines neuen Diagnosetools, das die modellbasierte Diagnose vollständig unterstützt und die Möglichkeit der Integration des vorhandenen Diagnosetools anbietet. Aus den vorgestellten Integrationsansätzen wurde der letzte Ansatz durch Fach- und Führungskräfte des Servicebereichs als sinnvoll und realisierbar bewertet. In der Entwicklung der

162

KAPITEL 6. DIAGNOSE MIT DRT-SYSTEM

neuen Diagnosegeneration ab 2012 wird der entwickelte Ansatz umgesetzt und in die ToolLandschaft integriert. Dabei ist die vorgestellte Lösung ein Alleinstellungsmerkmal (USP unique selling point) des neuen Produkts.

163

7

Evaluierung des Lösungsansatzes

Dieser Abschnitt beschreibt die Vorgehensweise zur Evaluierung der in Kapitel 3 und 4 erarbeiteten Lösungen auf zwei Gebieten: • Aufwandsabschätzung für die Erstellung und Pflege von Diagnosemodellen mit dem entwickelten Modellierungstool • Diagnosegüte der geführten Fehlersuche unter Verwendung des erstellten Diagnosemodells und des Diagnosetools. Anhand der Ergebnisse sollen die Leistungsfähigkeit der Lösungen bewertet sowie ihre Stärken und Schwächen erfasst werden, um die weiterführenden Arbeiten planen zu können. Mit den Ergebnissen soll langfristig auch untersucht werden, wie sich das entwickelte Expertensystem in die bestehende Struktur des Servicebereichs einführen ließe.

7.1

Evaluierung der Wissenserhebung

Die Bewertungskriterien der Aufwandsabschätzung für die Modellierung können in zwei Kategorien aufgeteilt werden ([51]): • Den Erstellungsaufwand eines neuen Systems oder Subsystems • Das Einpflegen einer neuen Variante eines bestehenden Systems beziehungsweise Subsystems. Die Beherrschung der Variantenvielfalt kann durch diese Aufteilung untermauert werden, da bei existierenden Redaktionssystemen auch die Möglichkeit zur Wiederverwendung des Diagnosewissens existiert. Um einen Vergleich zwischen der DMB-Applikation und existierenden Redaktionssystemen durchzuführen, erfolgt zunächst die Modellierung von Beispielsystemen, die auch für die Analyse der Diagnosengüte benötigt werden. Während der Modellierung wird der Aufwand festgehalten, der für die Modellierung beziehungsweise Erstellung eines neuen Systems und für dessen Variantenbildung anfällt. Anschließend erfolgt eine Abschätzung der Gültigkeit der Wiederverwendbarkeit für die Gesamtwissensbasis. Abschließend wird der Aufwand pro System beziehungsweise pro Subsystem abgeleitet. Dabei wird der Aufwand für nicht modellierte Anteile der Fehlersuchanleitung (wie zum Beispiel Sicherheitshinweise, Bildrecherche, Fahrzeugerprobung, Administration) mit dem gleichem Aufwand wie bei den vorhandenen Redaktionssystemen bewertet. Analog zu existierenden Redaktionssystemen gibt es in der Modellierungsphase zwei Arten von Projekten: Leit- und Folgeprojekte. Im Unterschied zum Leitprojekt wird im Folgeprojekt das vorhandene Modell in der Modelldatenbank verwendet. Das Leitprojekt wird in zwei Arten unterschieden: Leitprojekt mit Grundmodell

164

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES

und Leitprojekt mit Variantenmodell. Dabei wird das Variantenmodell aus dem bestehenden Grundmodell abgeleitet. Die Wissenserhebung in einem Leit- und Folgeprojekt besteht aus folgenden Schritten ([37], [38], [53]): • Leitprojekt: – Grundmodell ∗ Systemgliederung in Subsysteme und Komponenten ∗ Anlage fehlender Komponentenmodelle in der Modelldatenbank ∗ Anlage der Modellstruktur mit Komponentenmodellen aus der Modelldatenbank ∗ Parametrisierung der Modelle mit fahrzeugspezifischen Daten – Modellvariante ∗ ∗ ∗ ∗

Ableitung des neuen vom bestehenden Modell Anlage fehlender Komponentenmodelle in der Modelldatenbank Ergänzung des bestehenden Modells um fehlende Komponentenmodelle Parametrisierung der Modelle mit fahrzeugspezifischen Daten

• Folgeprojekt: – Parametrisierung der Modelle mit fahrzeugspezifischen Daten (Istwerte, DTCs, Abbildungen, etc.). Für existierende Redaktionssysteme wurden Referenzdaten erfasst. Diese Erfassung erfolgte durch die Befragung von Servicemitarbeitern. Hierbei wurden Arbeitsschritte und Aufwand aufgenommen für: • Anlegen eines neuen Systems (Leitprojekt) • Variantenbildung eines Systems und Aktualisierung von Komponentendaten (Folgeprojekt). Bei der ersten Evaluierung mit DMB-System wurde zunächst mit der Modellierung eines CP3-Diesel-Systems begonnen. Die Diagnoseinformationen für die Modellerstellung wurden in Interviews mit Werkstattmitarbeitern und Fachexperten gesammelt. Danach wurden die Informationen mit Hilfe von Fachliteratur ergänzt, abschließend die Modelle verschiedenen Reviews unterzogen. Die Prüfanweisungen, Testanleitungen, Soll- & Istwerte, Fehlercodes und Abbildungen für die Komponenten wurden aus existierenden Komponentendatenbanken entnommen und aufbereitet. Der entstehende Aufwand wurde dabei erhoben und in Tabelle 7.1 dargestellt. Die Komponenten-, Subsystem- und Systemmodelle wurden von Grund auf neu angelegt und stehen zur Fertigstellung und Prüfung für weitere Modelle in einer Modelldatenbank zur Verfügung. Als weiteres System wurde ein ME7.6-Benzin-System modelliert. Dabei konnte auf bereits modellierte Komponenten aus der Datenbank zurückgegriffen werden. Durch diese Wiederverwendung konnten circa 70% der Komponenten der Datenbank entnommen werden. Bei den verbleibenden Komponenten konnte wiederum eine Einsparung von 50% für die Erfassung von Systemen und Subsystemen sowie 40% bei Komponenten in Struktur und Verhalten protokolliert werden. Somit war der Erstellungsaufwand des ME7.6-Benzin-Systems deutlich geringer als bei dem CP3-Diesel-Modell.

165

7.1. EVALUIERUNG DER WISSENSERHEBUNG

CP3-Diesel mit DMB-System

1

Wissenserhebung

1.1 1.2 1.3 1.4

Erfassung System und Subsystem Erfassung der Komponenten Integration von Kundenbeanstandungen und Test Erfassung von Sollwert und DTCs

2

Wissensprüfung

2.1 2.2

Verifizierung gegen Testfälle Evaluierung in der Werkstatt

3

Administration

3.1

Allgemeine Verwaltung Summe

Aufwand in h

Anzahl d. Komp.

Komp. in h

35,0 57,6 25,9 21,5

40 57 22 24

0,88 1,01 1,18 0,9

86

2,11

13,9 18,5 9,2 181,6

Tabelle 7.1: Aufwandserhebung bei der Erstellung des CP3-Diesel-Systems ME7.6-Benzin mit DMB-System Aufwand in h

Anzahl d. Komp.

Komp. in h

15,0 30,6 29,0 27,6

19 8 13 30

0,79 3,83 2,23 0,92

86

1,66

1

Wissenserhebung

1.1 1.2 1.3 1.4

Erfassung System und Subsystem Erfassung der Komponenten Integration von Kundenbeanstandungen und Test Erfassung von Sollwert und DTCs

2

Wissensprüfung

2.1 2.2

Verifizierung gegen Testfälle Evaluierung in der Werkstatt

3

Administration

3.1

Allgemeine Verwaltung

13,7

Summe

142,7

10,3 16,5

Tabelle 7.2: Aufwandserhebung bei der Erstellung des ME7.6-Benzin-Systems Für die abgeleitete Modellierung des Benzinsystems vom Dieselsystem wurde der Aufwand in Tabelle 7.2 erhoben ([52], [54], [151]). Um ein reines Folgeprojekt bewerten zu können, wurde ein CP3-Diesel-System für vier und sechs Zylinder verglichen. Hierfür waren zum Beispiel circa 15% der Komponenten in Struktur und Verhalten und 10% der Prüfanleitungen, Sollwerte, Istwertabfragen für einen SechsZylindermotor zu ergänzen oder zu ändern. Dabei ergab sich der in Tabelle 7.3 aufgelistete

166

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES

Aufwand für das Folgeprojekt des CP3-Diesel-Systems. CP3-Diesel mit DMB-System

1

Wissenserhebung

1.1 1.2 1.3 1.4

Erfassung System und Subsystem Erfassung der Komponenten Integration von Kundenbeanstandungen und Test Erfassung von Sollwert und DTCs

2

Wissensprüfung

2.1 2.2

Verifizierung gegen Testfälle Evaluierung in der Werkstatt

3

Administration

3.1

Allgemeine Verwaltung Summe

Leitprojekt in h

Folgeprojekt in h

35,0 57,6 25,9 21,5

10,4 8,7 7,2 2,2

13,9 18,5

9,8 15,7

9,2

6,3

181,6

60,3

Tabelle 7.3: Aufwandserhebung des CP3-Diesel-Systems bei Leit- und Folgeprojekt Es soll im Zuge der Evaluierung der Aufwand für die Erstellung der Diagnosemodelle mittels DMB-System mit dem Aufwand zur Erstellung der geführten Fehlersuchanleitung unter Zuhilfenahme existierender Autorensysteme gegenübergestellt und bewertet werden. Da das Diagnosewissen bei DMB-System anhand von Modellen präsentiert, in existierenden Autorensystemen hingegen in Form von Fehlersuchbäumen mit Textbausteinen dargestellt wird, ist ein direkter Vergleich nicht möglich. Es existieren jedoch viele Aktivitäten bei der Wissenserhebung, die gleich sind: • Die Erfassung der eingebauten Systeme, Subsysteme und Komponenten: Struktur, Einbaulage, Funktionsbeschreibung, Pinbelegungen, Abbildung, etc. • Onboard-Diagnose-Informationen: Fehlercodes, Stellgliedtests • Die Informationen über Sollwertbereiche und Möglichkeiten zur Istwertabfrage der Systemsensoren beziehungsweise externen Messungen • Die Prüfanweisungen der Komponenten oder Systeme • Wissensprüfung und Administration. Einige Aktivitäten, die - bedingt durch den angewendeten Ansatz - unterschiedlich sind: • Die Struktur- und Verhaltensmodellierung mittels DMS-System • Die Erstellung der Prüfabläufe in existierenden Autorensystemen.

167

7.1. EVALUIERUNG DER WISSENSERHEBUNG Leitprojekt I (CP3-Diesel)

Leitprojekt II (ME7.6-Benzin)

DMBSystem

Autorensysteme

DMBSystem

Autorensysteme

35,0 57,6 25,9

17,6 25,6 25,9

15,0 30,6 29,0

21,1 36,0 29,0

21,5

21,5 43,0

27,6

27,6 55,3

7,9 18,5

13,9 18,5

6,3 16,5

10,3 16,5

1

Wissenserhebung

1.1 1.2 1.3 1.4 1.5

Erfassung System und Subsystem Erfassung der Komponenten Integration von Kundenbeanstandungen und Test Erfassung von Sollwert und DTCs Erstellung von Prüfabläufen

2

Wissensprüfung

2.1 2.2

Verifizierung gegen Testfälle Evaluierung in der Werkstatt

3

Administration

3.1

Allgemeine Verwaltung

15,2

9,2

17,7

13,7

Summe

181,6

175,2

142,7

210,0

Tabelle 7.4: Aufwandserhebung der Leitprojekte im Vergleich In Tabelle 7.4 werden die Aktivitäten und deren Aufwand bei der Erstellung der Leitprojekte einander gegenüber gestellt. Anhand des Aufwands der beiden Leitprojekte mit DMB-System lässt sich erkennen, dass für den Aufbau der Komponenten- und Systemmodelle ein Initialaufwand nötig ist. In nachfolgenden Leitprojekten mit dem selben Umfang wie die beiden Leitprojekte sollte nach Fertigstellung der Modellbibliothek mit mindestens 15% Aufwandsreduzierung beim gesamten Umfang des Projekts beziehungsweise 48% bei der Modellierungsaktivität zu rechnen sein. Dies entspricht gegenüber dem Aufwand für Leitprojekte gemäß der Auswertung der durchschnittlichen Erstellzeiten der geführten Fehlersuche in existierenden Autorensystemen für Diesel-Systeme einer Einsparung von circa 18% und 32% bei BenzinSystemen ([39], [7]). In der zweiten Evaluierung ist ein weiteres System - ALWR1.0-System - als Leitprojekt modelliert worden. Das Ziel der Modellierung eines ALWR1.0-Systems ist die Überprüfung der Übertragbarkeit des Modellierungsansatzes auf weitere Systeme beziehungsweise Domänen im Fahrzeug, da das System viele elektrische Komponenten und wenige Sensoren besitzt. Leitprojekt ALWR 1.0 DMBSystem 1

Wissenserhebung

1.1 1.2 1.3 1.4

Erfassung System und Subsystem Erfassung der Komponenten Integration von Kundenbeanstandungen und Test Erfassung von Sollwert und DTCs

11,6 13,4 21,7 37,8

Autorensysteme



10,4 18,3 21,7 37,8

168

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES 1.5

Erstellung von Prüfabläufen

2

Wissensprüfung

2.1 2.2

Verifizierung gegen Testfälle Evaluierung in der Werkstatt

3

Administration

3.1

32,5 14,7 17,2

23,8 17,2

Allgemeine Verwaltung

15,4

12,3

Summe

131,8

174,0

Tabelle 7.5: Aufwandserhebung des ALWR1.0-Systems bei Leitprojekten Aufgrund des symmetrischen Aufbaus des ALWR1.0-Systems ist die Wiederverwendung bei der Modellierung nicht nur auf Komponentenebene, zum Beispiel elektrischen Leitungen oder Achssensoren möglich, sondern es können Teilsysteme wiederverwendet werden. Beispielsweise kann nach Fertigstellung des Wirkkettenmodells des linken Scheinwerfers dieses Teilmodells sofort für die Wirkkette des rechten Scheinwerfers verwendet werden. Die Anpassung des Modells beschränkt sich auf die Namensänderung. Aus diesem Grund ist selbst bei Leitprojekten eine Einsparung von circa 24,3% möglich (Tabelle 7.5), obwohl in der Modellbibliothek vorher keine Komponentenmodelle beziehungsweise Subsystemmodelle des ALWR1.0-Systems existieren ([40]). Der Vergleich bei reinen Folgeprojekten gestaltet sich schwierig, da die Abweichung unterschiedliche Auswirkungen bei der Wissenserhebung hervorruft. Es reicht von der Änderung einer Abbildung der Einbaulage bis hin zu Umstrukturierungen der geführten Fehlersuche in existierenden Autorensystemen. Um einen durchschnittlichen Aufwand für die Folgeprojekte zu erhalten, wurde von verschiedenen Servicebereichen die durchschnittliche Ratio für ein Folgeprojekt auf circa 50% geschätzt. Folgeprojekt DMBSystem

Autorensysteme

10,4 8,7 7,2 2,2

7,0 9,0 9,0 7,0 14,0

9,8 15,7

12, 0 15,0

1

Wissenserhebung

1.1 1.2 1.3 1.4 1.5

Erfassung System und Subsystem Erfassung der Komponenten Integration von Kundenbeanstandungen und Test Erfassung von Sollwert und DTCs Erstellung von Prüfabläufen

2

Wissensprüfung

2.1 2.2

Verifizierung gegen Testfälle Evaluierung in der Werkstatt

3

Administration

3.1

Allgemeine Verwaltung

6,3

7,0

Summe

60,3

80,0

Tabelle 7.6: Aufwandserhebung des ALWR1.0-Systems bei Leitprojekten

7.1. EVALUIERUNG DER WISSENSERHEBUNG

169

Aus Tabelle 7.6 geht hervor, dass in einem Folgeprojekt mit einer möglichen Einsparung von 24,6% bei Verwendung von DMB-System bei der Wissenserhebung zu rechnen ist. Anhand der exemplarischen Modellierung des CP3-Diesel-Systems und des ME7.6-BenzinSystems kann als Hochrechnung der Aufwand zur Modellierung der Common-RailDieselsysteme und Saugrohreinspritzung-Ottomotoren mit einer Abdeckung von 90% ermittelt werden. Hierbei wird zunächst berechnet, wie viele Modelle für die Beschreibung des Komponenten- und Systemverhaltens notwendig sind. Abschließend wird der Aufwand für die Erstellung der Gesamtmodelle bestimmt. Die Common-Rail-Dieselsysteme (ab 1998) können in 12 Modellen in Form von Leitprojekten abgebildet und somit diagnostiziert werden ([55]). Es sind circa 100 Komponentenmodelle erforderlich. Da ein Komponentenmodell im Durchschnitt 2,1 Personenstunden benötigt (siehe Tabelle 7.1), beträgt die Erstellungszeit aller benötigten Komponentenmodelle circa 210 Personenstunden. Für die Erfassung der Systeme und Subsysteme sowie die Strukturerstellung der einzelnen Modelle kann ein Aufwand von circa 22,5 Personenstunden pro Modell veranschlagt werden. Insgesamt müssen 480 Personenstunden für die Erstellung der Common-RailModelle aufgewendet werden. Die erstellten Modelle der Common-Rail-Dieselsysteme lassen sich mit geringfügigen Änderungen für die Diagnose von Benzin-Direkt-Einspritz-Systemen (BDE) wieder verwenden. Mit 16 Modellen können mehr als 90% aller Systeme mit Saugrohreinspritzung (ab 2003) bei Verwendung von DMB-System abgedeckt werden. Für die Modellierung der System-Varianten sind circa 110 Komponenten erforderlich. Hier lassen sich die Komponenten des Diesel-Systems wieder verwenden, so dass maximal 30 Komponenten neu erstellt werden müssen. Wenn hier von einer Erstellzeit von circa 2,1 Personenstunden pro Komponente ausgegangen wird, so wird die Modellbibliothek in circa 63 Personenstunden erweitert. Für die Erzeugung eines Systemmodells werden circa 22,5 Personenstunden veranschlagt, so dass für die Erstellung der Benzin-Saugrohreinspritzung-Modelle insgesamt circa 423 Personenstunden erforderlich sind. Die Evaluierung hat gezeigt, dass sich mit DMB-System ein Teil des Aufwands für die Wissenserhebung einsparen lässt. Die Höhe der Einsparung wurde durch die Analyse der Erstellprozesse und eine exemplarische Modellierung ermittelt. Die Aussage konnte durch den grundlegenden Vergleich des Erstellprozesses ermittelt und für drei Systeme verifiziert werden. Hochgerechnet auf den Gesamtdatenbestand ist die Ersparnis nur für gleiche Verhältnisse von Leit- und Folgeprojekten gültig. Für die Wissenserhebung mit DMB-System sind allerdings wesentlich weniger Leitprojekte erforderlich. Dafür steigt der Anteil der Folgeprojekte. Die Folgeprojekte erfordern einen geringeren Aufwand. Deshalb wird ein erheblich höheres Einsparpotential bei der Erstellung vieler Systeme vermutet. Da die Modellerstellung durch einen eingeschränkten Expertenkreis (6 Personen) erfolgte, wurde ein dreitägiger Modellierungsworkshop durchgeführt, um weitere qualifizierte Beurteilungen des entwickelten Modellierungsansatzes durch Expertise der Fehlersuchanleitungsersteller und Systemverantwortlichen zu bekommen. Die Praxistauglichkeit des Ansatzes ist durch die Erstellbarkeit der Modelle durch vorhandene Mitarbeiter mit deren Wissen verifiziert worden. Eine weitere Verifizierung erfolgte durch die Prüfung, ob und wie das Wissen in den existierenden Fehlersuchanleitungen als Modell abgebildet und integriert werden kann. Dabei diente das Modell des automatischen Leuchtweitenregulierungssystems als Beispiel, bei welchem wie folgt vorgegangen wurde ([138]):

170

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES • Vorstellung des Modellierungstools (DMB-System) • Strukturmodellierung, Verhaltensmodellierung • Integration des heuristischen Diagnosewissens • Modellprüfung zwecks Qualitätssicherung • Live-Demo am Fahrzeug mit dem erstellten Modell.

Nach Abschluss des Workshops wurde von den Teilnehmern ein Bericht verfasst. In diesem wurden folgende Aussagen getroffen: • Die Modellierung ist mit vorhandenem Fachwissen machbar, die Übernahme der Modellierungsaufgaben ist von den Experten gewollt. • Es existiert eine hoher Initialaufwand zur Erstellung der Modelle. Der Aufwand kann durch Verwendung einer Modellbibliothek deutlich reduziert werden. Die Modellbibliothek soll aufgebaut und kontinuierlich erweitert werden. • Die Verwendung der bestehenden Daten zur Erstelllung der Diagnosemodelle ist möglich. • Komponenten- und Systemwissen ist für die Modellierung erforderlich und es existiert kein Datenkaufpotenzial. Das Wissen für die Modellierung betrifft hauptsächlich die Verhaltensbeschreibung und die Vernetzung der Komponenten, sprich die Systemstruktur. Da diese Informationen nicht einfach eingekauft werden können und somit auch Wettbewerbern nicht zur Verfügung stehen, ist diese Vorgehensweise ein Alleinstellungsmerkmal für die neue Diagnose. • Je besser die Onboard-Diagnose die auftretenden Fehlerfälle lokalisiert, desto weniger Aufwand muss in die geführte Fehlersuche investiert werden. Es ist zum heutigen Zeitpunkt so, dass aufgrund begrenzter Rechen- und Speicherkapazitäten nur gesetzlich vorgeschriebene Diagnosefunktionen beziehungsweise die wichtigsten Diagnosefunktionen in Steuergeräten ausgeführt werden. Es ist zu erwarten, dass aus Kostengründen auch zukünftig keine vollständige Onboard-Diagnose zur Verfügung stehen wird. • Der Einsatz des entwickelten Ansatzes ist sinnvoll, wenn die Symptome durch Kunden erlebbar sind. Insbesondere dann, wenn nicht auf Fehlercodes für den Einstieg in die Fehlersuche zurückgegriffen werden kann und daher die Kundenbeanstandungen als Einstiegsmöglichkeit zur Verfügung stehen, ist der entwickelte Ansatz nützlich. • Die unerfahrenen Anwender werden besser geführt und erhalten durch Visualisierung der Systemstruktur ein besseres Systemverständnis. • Die entwickelte Lösung hat das Potenzial zur Beherrschung der Systemkomplexität. Die Systemkomplexität spiegelt sich in dem zunehmenden Vernetzungsgrad der Komponenten wieder. Da die Abbildung der Systemstruktur und damit auch der Vernetzung im Diagnosemodell erfolgt und diese automatisch ausgewertet wird, wird die Vernetzung in der Diagnose beherrschbar.

7.2. EVALUIERUNG DER DIAGNOSE

171

• Die Fahrzeugbetrachtung aus Funktionssicht und nicht aus Systemsicht ist durch den neuen Ansatz möglich. Bisher werden häufig einzelne Systeme unabhängig voneinander betrachtet, obwohl viele Funktionen im Fahrzeug mittlerweile systemübergreifend realisiert sind. Durch die explizite Modellierung der Verbindungen zwischen den unterschiedlichen Systemen können durch den entwickelten Ansatz auch Wechselwirkungen, die sich auf das Fehlerbild einer bestimmten Funktion auswirken, berücksichtigt werden. Als Empfehlungen für die Leitung des Servicebereichs wurden folgende Schlussanmerkungen gegeben: • „Trotz mehr Initialaufwand bei der Erstellung sehen wir, dass der Mehrnutzen durch den entwickelten Ansatz und die Key Features den Mehraufwand deutlich übersteigt.“ • „Modell wird durch den Ersteller visuell aufgebaut, dadurch Übersicht über System erkennbar. Die Darstellung der Wirkkette könnte zentrales Element für die Anleitung werden, insbesondere durch: Einblendung der Einbaulagen, Funktionsbeschreibungen, Steckerbelegungen, Aufruf der Prüfschritte, optische Darstellung der Prüfreihenfolge usw.“ • „Die bisherige Programmfunktionalität bei der Erstellung der Fehlersuchanleitungen wird sich in 5 Jahren nicht mehr tragen. Mit dem Zusammenspiel all dieser Bausteine für eine dynamische, geführte Fehlersuche könnten die Servicebereiche einen neuen Produktlebenszyklus bei der Fehlerdiagnose einleiten.“

7.2

Evaluierung der Diagnose

Die Leistungsfähigkeit der Diagnose, welche durch DRT-System (Diagnostic Runtime System) bereitgestellt wird, wurde mit verschiedenen Referenzsystemen verglichen. Die Evaluierung erfolgte am Beispiel eines Benzin- und eines Dieselmotorsystems, dabei umfasste das Motorsystem die Subsysteme Luftaufbereitung-, Einspritz-, Zünd-, Verbrennungs-, Abgas- und Kühlsystem. Es wurde darauf geachtet, allgemein gültige Modelle zu erstellen, die nicht für den Feldtest optimiert wurden. Für die Referenzsysteme wurden Systeme und deren Anleitungen der geführten Fehlersuche, die bezüglich der Diagnosegüte von guter Qualität sind, ausgewählt. Das heißt, alle für die Anleitung relevanten Daten liegen vor, sind geprüft und es gibt keine Beanstandungen bezüglich der Diagnosequalität auf Seiten der freien Werkstätten. Die Anleitungen der geführten Fehlersuche sollten es dem Werkstattpersonal ermöglichen, leicht und systematisch Fehlerursachen zu finden. Dabei sollten keine Falschursachen ermittelt werden, da inkorrekte Diagnosen nicht nur zu erhöhten Kosten- und Zeitaufwendungen führen, sondern sich auch negativ auf das Vertrauen in DRT-System und somit in die neu entwickelte Lösung auswirken. Durch die geführte Fehlersuche sollten alle Fehler gefunden werden, um eine vollständige Diagnose zu ermöglichen. Dies ist besonders wichtig, um Folgefehler aufgrund nicht gefundener Defekte und somit höhere Kosten zu vermeiden. Des Weiteren war es wichtig, mit Hilfe der geführten Fehlersuche alle Fehler mit möglichst geringem Aufwand zu finden. Mit der oben genannten Prämisse lassen sich folgende Bewertungskriterien ableiten, die im Rahmen einer Versuchsdurchführung erfasst wurden ([56]): • Anzahl der Fehldiagnosen - das Diagnosesystem identifiziert eine falsche Fehlerursache

172

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES • Anzahl der nicht gefundenen Ursachen - das Diagnosesystem kann die Ursache des Fehlers nicht identifizieren • Anzahl der erfolgreichen Diagnosen - das Diagnosesystem identifiziert eindeutig den zuvor injizierten Fehler • Anzahl der durchgeführten Prüfschritte - die Anzahl der Prüfschritte, die benötigt werden, um die Fehlerursache zu lokalisieren • Durchführungszeiten - die Zeit zur Durchführung der gegebenen Prüfschritte bzw. Prüfanweisungen.

Die Auswahl der zu injizierenden Fehler unter Berücksichtigung verschiedener Fehlerarten erfolgte in Abstimmung mit Werkstattmitarbeitern. Zudem wurden die erzeugten Fehler erst vor Ort von den unabhängigen Werkstattmitarbeitern festgelegt. Somit waren ähnliche Ergebnisse auch bei Vergleichen mit anderen Fahrzeugsystemen zu erwarten. Folgende Fehler wurden in den CP3-Dieselmotor eingebaut: • D1: Mechanischer Defekt des Druckregelventils (über Ersatzlast) • D2: Kraftstoffleitung zwischen Kraftstofffilter und Hochdruckpumpe verengt • D3: Ansteuerung der Zumesseinheit unterbrochen • D4: Verstopfung zwischen HFM-Sensor und Turbolader. Für den ME7.x-Ottomotor wurden ebenfalls vier Fehler injiziert: • O1: Ansteuerung des Injektors 1 unterbrochen • O2: Signal des HFM-Sensors verfälscht (R-800Ohm) • O3: Signal des Ansaugluft-Temperatur-Sensors auf konstant 120◦ C verfälscht (R120Ohm) • O4: Signal der Lambdasonde verfälscht (Übergangswiderstand). Versuch

Eingebauter Fehler

O4

Signal der Lambdasonde verfälscht, Übergangswiderstand Signalleitung

DRT-System Nr.

Symptom, Messung, Prüfung

Zeit[min]

Ergebnis

1

Leerlaufprobleme) (Drehzahl, Abgas)

2

Eigendiagnose

2

keine DTC

3

Luftmassenmesser Istwert

2

i.O.

4

Lambdasonde B1

2

Signal der

173

7.2. EVALUIERUNG DER DIAGNOSE

Lambdasonde entspricht nicht den Vorgaben 5

Lambdasonde B1 Signalspannung prüfen

3

Übergangswiderstand Signalleitung

Tabelle 7.7: Protokoll des Versuchs mit DRT-System für den ME7.x-Ottomotor Für die Versuchsdurchführung wurde zunächst mit DRT-System diagnostiziert und anschließend der Fehler anhand der Vorgaben der existierenden Diagnosetools gesucht. Um den Aufwand für die Prüfzeiten zu ermitteln, wurde die Dauer jedes Prüfschrittes ermittelt beziehungsweise geschätzt. Die Zeiten hängen stark vom jeweiligen System oder Fahrzeug ab. Die Prüfzeit eines Prüfschrittes ist für beide Diagnosesysteme gleich und wird für beide Diagnosesysteme gleich bewertet. In Tabelle 7.7 stehen die detaillierten Prüfungsschritte, die bei dem Diagnosevorgang eines ME7.x-Ottomotors mit dem Symptom „Leerlaufprobleme (Drehzahl, Abgas)“, um die Ursache beziehungsweise die defekten Komponente zu finden, benötigen wurden. Hierbei brauchte das entwickelte DRT-System fünf Schritte und insgesamt neun Minuten, dagegen benötigten existierende Diagnosesysteme im Durchschnitt dreizehn Schritte und fünfunddreißig Minuten (Tabelle 7.8). Die Unterschiede bei den Prüfungsschritten und Prüfzeiten liegen daran, dass in dem entwickelten Ansatz die einzelnen Systeme nicht unabhängig voneinander betrachtet werden. Die Wechselwirkungen zwischen den Systemen wurden durch die Modellierung der Verbindungen zwischen den unterschiedlichen Systemen berücksichtigt. Damit erfolgt die Diagnose aus Funktionssicht und nicht aus Systemsicht. Versuch

Eingebauter Fehler

O4

Signal der Lambdasonde verfälscht, Übergangswiderstand Signalleitung

Existierendes Diagnosesystem Nr.

Symptom, Messung, Prüfung

Zeit[min]

Ergebnis

1

Leerlaufprobleme (Drehzahl, Abgas)

2

Eigendiagnose

2

keine DTC

3 3

Istwerte Drosselklappensteuereinheit

2

i.O.

4

DrosselklappenStellmotor

1

i.O.

5

Luftmassenmesser Istwert

2

i.O.

6

Stellgliedtest Drallklappen

2

i.O.

6

Unterdruckleitung

2

i.O.

174

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES von Drallklappe 8

Temperatursensor Istwert

2

i.O.

9

Einspritzzeit

4

i.O.

10

Einspritzventile

6

i.O.

11

Kraftstoffdruck Istwert

2

i.O.

12

Kraftstoffverdunst. -Regenerationsventil

5

i.O.

13

Lambdasonde B1

2

Signal der Lambdasonde entspricht nicht den Vorgaben

14

Lambdasonde B1 Signalspannung prüfen

3

Übergangswiderstand Signalleitung

Tabelle 7.8: Protokoll des Versuchs mit einem existierenden Diagnosesystem für den ME7.xOttomotor Tabelle 7.9 gibt die entscheidenden Versuchsergebnisse wider. Dabei ist die Durchführungszeit der Messungen beziehungsweise Prüfschritte in Minuten angegeben und die Einsparung als prozentuale Ersparnis der Prüfzeit von DRT-System gegenüber Referenzsystemen. Versuch

DRT-System

Referenzsysteme

Anzahl der Prüfschritte

Durchführungszeit [min]

Anzahl der Prüfschritte

Durchführungszeit [min]

D1

6

9

14

26

D2

6

18

5

24

D3

3

5

3

5

D4

4

7

6

13

O1

3

4

3

4

O2

7

12

8

25

O3

7

18

5

19

O4

5

9

14

35

Tabelle 7.9: Zusammenfassung der ersten Evaluierungsergebnisse Es sind folgende Aussagen festzustellen: • Alle Diagnosesysteme fanden alle Fehler. Dies war allerdings nur bei Einstieg in die Diagnose mit korrekter Kundenbeanstandung der Fall. Eine falsche Kundenbeanstan-

7.2. EVALUIERUNG DER DIAGNOSE

175

dung führte dazu, dass die Fehlerursache mit Hilfe der Referenzdiagnosesysteme nicht gefunden werden konnte. Bei DRT-System war die Fehlersuche nicht erfolglos, die dafür benötige Zeit jedoch bedeutend länger. • Es kam zu keiner Fehldiagnose während der Evaluierung. Das bedeutet, es wurde keine intakte Komponente als fehlerhaft ausgewiesen und ausgetauscht. Aus den Ergebnissen geht hervor, dass bei der Diagnose mit DRT-System eine mittlere Reduzierung der Prüfzeit um 45% (Tabelle 7.9) gegenüber den Referenzsystemen erreicht wurde. Der maximale Wert lag bei 74% und der minimale Wert bei 0%. Die Reduzierung der Prüfzeit hat in der Werkstatt eine immense Kostenminimierung zur Folge. Die Reduzierung der Prüfzeit ergibt sich durch eine optimale Reihenfolge der Prüfschritte, die dynamisch von DRT-System berechnet und dem Werkstattmitarbeiter vorgeschlagen wird. Daher lässt sich auch die minimale Reduzierung der Prüfzeit (Versuch D3 und O1) erklären: In diesen Fällen zeigte ein Fehlercode auf die defekten Komponenten. Dieser Fehlercode wurde frühzeitig abgerufen und der Prüfvorgang nach der Komponentenprüfung abgeschlossen. Hierbei ergaben sich keine Unterschiede in den Vorgehensweisen der Systeme.

   

Abbildung 7.1: Ergebnisse der Prüfschritte bei der Evaluierung

In einer Vielzahl der Fälle hatte der optimierte Prüfablauf auch eine Reduzierung der Prüfschritte zur Folge. Dies muss aber nicht immer der Fall sein (Abbildung 7.1 und 7.2 - Versuch D2 und O3), da auch mehrere kleine Schritte statt eines komplexen, lang andauernden Prüfschrittes zum Ziel führen. Bei dem Diagnosevorgang war festzustellen, dass in den Referenzsystemen schnell zur Prüfung von Komponenten übergegangen wird. DRT-System hingegen versucht zunächst über die Erfassung von Istwerten und anderen Messergebnissen die defekte Komponente einzugrenzen, bevor Komponentenprüfungen den Verdacht verifizieren. Dieses Vorgehen lässt sich in Referenzsystemen sehr schwer realisieren, da in den meisten Referenzsystemen Fehlersuchbäume verwendet werden. Damit ein Referenzsystem für jedes Messergebnis eine entsprechende Handlung vorschlagen kann, würde ein Suchbaum schnell sehr komplex werden.

 

176

 

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES

 

   

Abbildung 7.2: Ergebnisse der Prüfzeit bei der Evaluierung

 

Als ein weiterer Vorteil stellte sich heraus, dass DRT-System jeden Prüfschritt vorgab und   nach vollständiger Abarbeitung der vorgeschlagenen Prüfschritte zur Liste der verdächerst tigen Komponenten mit ihren Komponenten-Tests überging. Im Gegensatz dazu wird in den   Referenzsystemen nach jedem Diagnoseschritt eine ähnliche Liste mit den weiteren Fehlermöglichkeiten angeführt. Hier obliegt es dem Werkstattmitarbeiter, ob er dieser Liste oder   dem nächsten Prüfschritt folgen soll. Der Umstand, dass alle Prüfschritte vom System vorge  geben werden, ermöglicht es auch Personal, das weniger mit dem fehlerhaften System vertraut ist, effizient eine Diagnose durchzuführen. Im Anschluss an die erste Evaluierung wurde die Leistungsfähigkeit von DRT-System durch die beteiligten Experten und Werkstattmitarbeitern folgendermaßen beurteilt: • Die Diagnosegüte beziehungsweise Diagnosequalität hinsichtlich der Diagnosegenauigkeit und -vollständigkeit wurden anerkannt und herausgehoben. • DRT-System ist für die freie Werkstatt gut geeignet, da die Erfahrung und das Systemwissen des freien Werkstattpersonals nicht ausreicht, um bei der Vielfalt der Fahrzeuge, die in die freie Werkstatt kommen, jeden Fehler ohne weitere Hilfsmittel zu entdecken. Insbesondere die in der Evaluierung erzeugten Fehler ohne Fehlercodeeintragung sind nur von einem erfahrenen Werkstattmeister, der sich tagtäglich mit solchen Fehler auseinandersetzen muss und sich mit dem Autotyp bzw. den eingebauten Systemen auskennt, zu finden. Das Personal der freien Werkstatt jedoch, das in drei Monaten vielleicht ein- oder zweimal mit solchen Fehlern konfrontiert wird, hat keine Chance den Fehler zu finden und zu beheben. • Der Vorteil des DRT-Testers im Gegensatz zu heutigen Testern sind die Vorschläge der Handlungsempfehlung und die Liste der verdächtigen Komponenten, die für den Diagnoseschritt relevant sind. Das Werkstattpersonal muss nicht überlegen, welche Istwerte ausgelesen, beziehungsweise welche Komponente getestet werden sollte. Die dadurch

7.2. EVALUIERUNG DER DIAGNOSE

177

gesparte Zeit ist sehr wichtig, weil sie die Kundenzufriedenheit steigert und Kosten reduziert. • DRT-System kann ohne konkrete Soll- und Ist-Werte eine Diagnose für existierende Systeme erstellen. Die Plausibilisierung der Messergebnisse obliegt dabei dem Werkstattmitarbeiter. Die nötigte Diagnosetiefe kann deshalb nicht immer garantiert, aber immerhin können neue Fahrzeuge beziehungsweise Systeme damit diagnostiziert werden. • Es existiert kein Tool, das eine solche Diagnoseleistung, insbesondere eine systemübergreifende Diagnose erbringt. Bei einigen existierenden Diagnosesystemen ist eine systemübergreifende Diagnose nur möglich, wenn Fehlercodes gesetzt worden sind. Hierbei versuchen solche Systeme die Fehlercodes miteinander zu kombinieren. Als Ergebnisse erhält man die verdächtigen Systeme oder Komponenten, die sich mit Hilfe der vorhandenen Fehlercodeeinträge am besten erklären lassen. Als kritische Punkte wurden die Bedienung und die Übersichtlichkeit der Testeroberfläche angesehen. Für den Einsatz in der Werkstatt müsste die Bedienung einfacher gestaltet und die Übersichtlichkeit verbessert werden. Die erste Evaluierung hat gezeigt, dass der entwickelte Diagnoseansatz und DRT-System in der Werkstatt die Diagnoseanforderungen bezüglich Korrektheit und Vollständigkeit erfüllt haben. Bei der Kostenminimierung bezüglich der Diagnosedauer und damit dem Aufwand der Fehlersuche konnte gegenüber Referenzsystemen durch die Reduzierung der Prüfzeit eine erhebliche Einsparung erreicht werden. Diese erzielte Kostenminimierung und die verbesserte Nutzerführung mit optimierter Abfolge der Prüfschritte führen zu einer schnelleren Diagnose, von der in erster Linie die Werkstätten profitieren und damit die Marktpositionierung der Diagnosehersteller sichern. Die zweite Evaluierung ([41]) sollte weitere qualifizierte Beurteilungen der Leistungsfähigkeit, Praxistauglichkeit und des Kundennutzens des entwickelten Ansatzes durch Werkstattmitarbeiter und Fachexperten mit umfangreichen Werkstatterfahrungen bringen. Hierfür wurden insgesamt achtzehn Teilnehmer mit unterschiedlichem Profil ausgesucht: • Mitarbeiter aus freien Werkstätten und Vertragswerkstätten sowie der Hotline • Trainer aus dem Diagnoseschulungszentrum • Autoren der Fehlersuchanleitungen • Mitarbeiter verschiedener Gruppen und Abteilungen des Servicebereichs. Die drei Diagnosemodelle, die zur Verfügung stehen, decken folgende Fahrzeuge ab ([42]): System

Typ

Variante

ALWR1.0

VW-Touran VW-Golf V

1.4 TSI; 1.6[i,FSI]; 1.9 TDI; 2.0 [i,Eco Fuel,FSI,TDI] 1.4[i,Variant,FSI,FSI Variant,TSI,TSI Variant] 1.6[i,Variant,FSI]; 1.9 [TDI,TDI Variant,TDI 4Mot] 2.0 [FSI,FSI 4Mot,GTI,GTI Variant,SDI] 2.0 [TDI,TDI Variant,TDI 4Mot]; 3.2 R32 4 Mot 1.4 [i,FSI,TSI]; 1.6[i,FSI]; 1.9 TDI; 2.0 [FSI,TDI] 1.4[i,TSI]; 1.6; 1.8 TSI; 1.9 TDI 2.0 [FSI,T FSI,T FSI Free,TDI,TDIFree]

VW-Golf Plus SEA-Altea

178

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES

CP3

ME 7.6.x

SEA-Leon SEA-Toledo SKO-Octavia

1.4[i,TSI]; 1.6; 1.8 TSI; 1.9 TDI; 2.0 [FSI,TFSI,TDI] 1.4[i,TSI]; 1.6;1.8 TSI;1.9 TDI; 2.0[FSI, TDI,TFSI] 1.4[i,Combi]; 1.6[i,FSI,Combi,FSI Comb] 1.9 [TDI, TDI 4X4, TDI Comb]; 2.0 [Combi RS] 2.0[FSI Comb, TDI Comb, FSI 4X4, RS, TDI]

CDI Vito CDI Sprinter C 200 C 220 CLC 200 CLK 220 E 200 E 220 Viano

109[kW: 65, 70] ; 111[kW:80, 85]; 115 209; 211; 213; 215; 309; 311; 313; 315 411; 415; 509; 511;515 CDI[Sportcoupe, i kW:75,90,100, T-Modell kW:75,90,100] CDI[Sportcoupe, i kW:100,125, T-Modell kW:110,125] CDI[kW:90,110] CDI Coupe[kW:110] CDI[T-Modell, kW:75,90,100] CDI[T-Modell kW:100,110,125, i kW:100,110,125] CDI 2.0[kW:80,85,110]

Agila Twinport Corsa Twinport Astra Twinport Astra Sonstiges

1.0; 1,2 1.0[C,D]; 1.2i[C,D]; 1.4[C,D] 1.2 C; 1.2 i; 1.4 [G,H] 1.4 Caravan Tw[G,H]; 1.4 GTC Twinpo[H] Combo 1.4i; Meriva 1.4i; Tigra 1.4i

Tabelle 7.10: Liste der abgedeckten Fahrzeuge

Fehlereinbau

Proband

Tester DTCs Sensordaten Messdaten

OBDSchnittstelle DTC-Auslesen Messungen, Stellgliedtest

Versuchsträger

Prüfung, Reparatur

Kundenbeanstandung

Test-/Prüfergebnisse Testprotokoll DRT-SystemBediener DRT-System

Prüfprozedur

Beobachter

Abbildung 7.3: Szenario des zweiten Feldtests In Abbildung 7.3 ist das Szenario beziehungsweise die Vorgehensweise des zweiten Feldtests dargestellt. Die Aktivitäten können grob in drei Phasen aufgeteilt werden: • Erste Phase: Der Proband baute reale Fehler in Abwesenheit des Bedieners von DRTSystem in den Versuchsträger ein. Die Kundenbeanstandungen wurden von dem Pro-

179

7.2. EVALUIERUNG DER DIAGNOSE banden benannt und in ein Protokoll eingetragen. Start

DTCs auslesen DTCs löschen Reproduzieren der DTCs DTCs auslesen

Kundenbeanstandungen aufnehmen

Anweisung des DRT-Systems ausführen (Messungen, Prüfungen, Tests)

Messung durch Auslesen der systemeigenen Sensoren mit Tester ausführen

Stellgliedtest mit Tester ausführen

Komponenten-/ Subsystemprüfungen durchführen

Mess- und Prüfergebnisse in DRT-System übernehmen/ eingeben

nein

Fehlerursache gefunden ja Fehler beseitigen

ja DTCs vorhanden nein Kundenbeanstandung noch aktuell

ja

nein

Abbildung 7.4: Diagnoseablauf bei dem zweiten Feldtest

180

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES • Zweite Phase: Die Diagnose erfolgte mit DRT-System (Abbildung 7.4). Dabei befolgte der Bediener genau die Anweisungen von DRT-System und der Proband protokolierte die Schritte. Das Auslesen der Fehlercodes sowie der Istwerte der Systemsensoren und die Durchführung des Stellgliedtests erfolgte mittels eines Diagnosetesters, welcher durch die OBD-Schnittstelle an das Fahrzeug gebunden wurde. Bei dem Diagnosevorgang wurde durch den Beobachter die Objektivität der Versuchsdurchführung und deren Ergebnisse garantiert. • Dritte Phase: Nach Ablauf eines Versuchs wurde der Diagnosevorgang durch den Probanden mit einem Fragenbogen (Abbildung 7.5) bewertet.

Abbildung 7.5: Beispiel eines Versuchprotokolls bei der zweiten Evaluierung Der Evaluierungszeitraum des Diagnosetools am Fahrzeug mit realen Fehlern aus dem Feld betrug zwei Wochen und die Versuche wurden an drei Fahrzeugen durchgeführt: • Mercedes Benz 220CDI (CP3-DS) • Opel Corsa 1.2 (ME7.6 -GS)

181

7.2. EVALUIERUNG DER DIAGNOSE • Golf V 1.4 Variant (ALWR1.0).

Als Ergebnisse des zweiten Feldtests existieren fünfundvierzig auswertbare Fragenbogen mit einunddreißig unterschiedlichen Fehlerfällen. Die vierzehn Fehlerüberlappungen wurden von verschiedenen Probanden eingebaut. Dies lässt sich nicht vermeiden, weil die Versuche unabhängig voneinander durchgeführt wurden und bei diesem Feldtest stets versucht wurde, Fehler ohne Fehlercode zu initialisieren. Die Fehlerfälle enthalten: • Neun Fehler mit eindeutigem Fehlercode • Einen Fehler mit nicht eindeutigem Fehlercode • Einundzwanzig Fehler ohne Fehlercode (in Leerlauf und Teillast) • Fünf doppelte Fehler. Bei Fehlerfall mit eindeutigen Fehlercodes wurde im ersten Durchlauf des Versuchs eine Diagnose ohne Berücksichtigung der existierenden Fehlercodes aufgestellt, das heißt, es wurden nur die Kundenbeanstandungen beziehungsweise Symptome als Diagnoseeinstieg herangezogen und die Fehlercodes nicht berücksichtigt. Im zweiten Durchlauf wurden die Fehlercodes als Einstieg in die Diagnose verwendet. Diese Vorgehensweise diente zur Bestätigung des Vorteils des entwickelten Ansatzes; dass der Diagnosevorgang auch ohne Fehlercodes beziehungsweise mit unbekannten Fehlercodes funktioniert. Diese Eigenschaft ist wichtig für die freie Werkstattdiagnose, weil die Fehlercodes, die nicht abgas- oder sicherheitsrelevant sind, von Fahrzeugherstellern nicht freigegeben werden müssen. Die Fehler mit nicht eindeutigem Fehlercode „Grundeinstellung nicht möglich“ entstanden bei den Versuchen mit dem ALWR1.0-System. Bei solcher Art des Fehlercodes erfolgte die Diagnose ohne dessen Berücksichtigung. Die doppelten Fehler wurden unabhängig voneinander erzeugt. Das bedeutet, dass keine Folgefehler in diesem Feldtest existierten. 45

45

Fehler gefunden

42

35

35

Fehler nicht gefunden

20 15

3

0

10 5

Wird die defekte Komponenten gefunden?

8,9%

0

nicht zufrieden

25

6,7%

93,3%

20

5

weiß nicht

4,4%

25

10

39

30

30

15

zufrieden

40

86,7%

40

2

4

Wie bewerten Sie den Diagnoseablauf insgesamt?

Abbildung 7.6: Feldtestergebnisse zur Auswertung der Diagnosefähigkeit 45 45 40 35

36

ja

40

weiß nicht

35

ja nein

36

10

20,0%

15

80,0%

10

30

13,3%

15

6,7%

30

86,7%

In drei Fällen wurden die defekten nicht gefunden (Abbildung 7.6). Folgende nein Komponenten 25 25 20 für die erfolglosen Fehlersuchen verantwortlich Gründe sind ([43]): 20 5 • Nicht 5gefundene Komponenten sind nicht in verfügbaren Unterlagen enthalten und da9 6 3 0 0 her nicht im Modell abgebildet, zum Beispiel: Es existiert keine Luftleitung zwischen Erfolgt die Fehlersuche der CP3-System. Hätten Sie mit Ihrer Erfahrung Drucksensor und Saugrohrinim

erwarteten Reihenfolge?

die Suche anders durchlaufen?

eher niedrig

eher kurz 30

normal

30

normal

182

KAPITEL 7. EVALUIERUNG DES LÖSUNGSANSATZES • Die Festlegung der Systemgrenze von Modellierer und Proband sind unterschiedlich, zum Beispiel beinhaltet das Diagnosemodell nicht die elektrische Sicherung für das ALWRSteuergerät und den Steckverbinder zwischen Batterie und dem ALWR-Steuergerät.

45

8,9%

4,4%

86,7%

6,7%

93,3%

Die Ergänzung der fehlenden Komponenten wurde vor Ort vorgenommen. Nach der Erweite45 45 rung der Modelle funktionierten problemlos und die defekten Kompo40 40 Fehler die Diagnosevorgänge zufrieden 42 39 gefunden 35 35 nenten wurden gefunden. Die Unzufriedenheit mit dem Diagnoseablauf beruhte weiß nicht zum einen auf 30 30 den nicht gefundenen defekten Komponenten und 25zum anderen auf nicht eindeutige FehlerFehler nicht nicht zufrieden 25 codes, da die aus Vertragswerkstätten kamen, eine präzise Erklärung in Form 20 Probanden, die 20 gefunden 15 15 von Fehlerpfad und Fehlerart des Fehlercodes erwarteten. Diese Problematik ist bei der freien 10 10 Werkstattdiagnose bekannt und kann nur durch gesetzliche Regelungen verbessert werden, 5 5 4 2 3 0 da die Fahrzeughersteller großes Interesse haben, ihr0 eigenes Diagnosegerät zu verkaufen. Ein Wird Wie bewerten Sie den weiteres Defizit istdie diedefekte Darstellung der Einbaulage der Komponenten, hier soll in Zukunft die Komponenten gefunden? Diagnoseablauf insgesamt? Einbaulage mit Bildern dargestellt werden. 45

25

13,3%

86,7%

15 10

15

3

6

5 0

ja nein

36

30

nein

25 20

weiß nicht

35

6,7%

36

30

40

20

10

20,0%

35

ja

80,0%

40

5

9

0

Erfolgt die Fehlersuche in der erwarteten Reihenfolge?

Hätten Sie mit Ihrer Erfahrung die Suche anders durchlaufen?

Abbildung 7.7: Feldtestergebnisse zur Überprüfung der vorgeschlagenen Prüfschritte eher niedrig

eher kurz

11,1%

26,7%

62,2%

13,3%

26,7%

60,0%

Wegen30der fehlenden Komponenten im Modell und normal über Ausfall30 des Verzichts auf das Wissen normal 25 25 wahrscheinlichkeiten wurden in eher sechs Fällen die Diagnosedauer als „lang“eher undhoch die erwartete lang 20 20 Reihenfolge als „nicht optimal“ bewertet (Abbildung 7.7, 7.8). In den meisten Fällen, in denen 15 15 die Dauer der Diagnose im Vergleich zum Werkstattalltag als normal empfunden wurde, er10 10 5 5 zeugte der Fehler einen eindeutigen Fehlercode. Bei Fehlern mit eindeutigem Fehlercode 27 12 6 28 10 nicht 5 0 0 beziehungsweise ohne Fehlercode ist die Stärke des entwickelten Ansatzes durch die erwartete Wie lange dauert Wie bewerten Sie Reihenfolge und damit verbundene Diagnosedauer zu erkennen. die die Diagnose? diedeutlich Reparaturkosten?

nein

20

20

26,7%

15,5%

57,8%

53,3%

8,9%

37,8%

Die Reparaturkosten, die hier abgefragt wurden (Abbildung 7.8), ergeben sich aus der Diaja Verbesserung gnosedauer und den Prüfmittelkosten (zum Beispiel: Lecksuchspray, elektronische Ersatzsi30 30 weiß nicht cherung, Überbrückungskabel, etc.). 25 25 keine

Aus diesem Grund stimmen die Ergebnisse bei der den Ergebnissen 15 15 Reparaturkostenfrage mit Verbesserung 24 10 10 der Diagnosedauer fast zu hundert Prozent überein. Die Fälle mit höheren Reparaturkosten 17 5 5 sind analog zur längeren Diagnosedauer durch nicht modellierte Komponenten, Verzicht auf 26 7 12 4 0 0 Erfahrungswissen und Ungenauigkeit der Diagnosewissensbasis über Fehlercodes begründet. Wurden während der Wie bewerten Sie den Diagnose neue

Nutzen und die Akzeptanz des

Folgende Erkenntnisse wurden während der Diagnose gewonnen (Abbildung 7.9): Erkenntnisse gewonnen? vorgestellten Diagnoseansatzes? • Die Darstellung der Wirkkette in der Erklärungskomponente ist nicht nur für Werkstattpersonal, das wenig Erfahrung mit dem zu diagnostizierenden System hat, sondern auch für erfahrene Mitarbeiter eine große Hilfe.

10 0

5

Erfolgt die Fehlersuche 6 in der 3 erwarteten Reihenfolge? EVALUIERUNG DER DIAGNOSE Erfolgt die Fehlersuche in der erwarteten Reihenfolge? 0

7.2.

9

80

5 15

6

3

20

13,3

10 0

6,7

86,

5 15

5 9 Erfahrung Hätten Sie mit Ihrer 0 die Suche anders durchlaufen? Hätten Sie mit Ihrer Erfahrung die Suche anders durchlaufen?

eher niedrig

eher kurz

10 20 5 15 0 10

5 0

53,3%53,3%

20 30 15 25

8,9% 8,9%

25

lange 12 dauert 6 die Diagnose? Wie lange dauert Diagnose? 7.8:die Feldtestergebnisse

37,8%37,8%

Abbildung 30

0 10

5

24 17

0

zur Auswertung

ja

ja nein -

nein

30 25 20 30

24

17

Wurden während der 4 Diagnose neue Erkenntnisse gewonnen? Wurden während der Diagnose neue Erkenntnisse gewonnen?

10

eher hoch

Wie bewerten Sie 28 10 5 die Reparaturkosten? Wie bewerten Sie dieEffektivität Reparaturkosten? der des entwickelten Ansatzes Verbesserung

26

7

12

10 20

0 10

normal eher niedrig eher hoch normal

5

15 25 5 15

4

28

11,1%11,1%

5 15

6

Wie 27

0

10 20

26,7%26,7%

5

12

20 30 15 25

26,7%26,7%

27

0 10

25

15,5%15,5%

5 15

eher lang

30

62,2%62,2%

10 20

normal eher kurz eher lang normal

57,8%57,8%

20 30 15 25

13,3%13,3%

60,0%60,0%

25

26,7%26,7%

30

183

weiß nicht Verbesserung keine weiß nicht Verbesserung keine Verbesserung

5

Wie Sie12den 26 bewerten 7 Nutzen und die Akzeptanz des vorgestellten Diagnoseansatzes? Wie bewerten Sie den Nutzen und die Akzeptanz des vorgestellten Diagnoseansatzes? 0

Abbildung 7.9: Feldtestergebnisse zur Überprüfung des Nutzens und der Akzeptanz des entwickelten Ansatzes • Die vorgeschlagenen Messungen beziehungsweise Prüfungen beschleunigen die Fehlersuche, da der Nutzer nicht selbst suchen und entscheiden muss, welche Schritte sinnvollerweise als nächste durchzuführen wären. Der Nutzen und die Akzeptanz des entwickelten Diagnoseansatzes wurden als Verbesserung hinsichtlich Diagnosetiefe, Effizienz, Benutzerführung und Fehlererklärung bewertet. Aus neu eingebauten Fehlern mit eindeutigem Fehlercode, die direkt auf die defekte Komponente zeigten und drei Fällen, in denen die defekte Komponente nicht im Modell enthalten war, entstanden zwölf Fälle, die keine Verbesserung durch den vorgestellten Ansatz hervorbringen konnten. Sieben Fälle, bei denen mit „weiß nicht“ geantwortet wurde, stammen zum Teil aus der Befragung der Vertragswerkstattmitarbeiter und zum Teil von Autoren, die die Fehlersuchanleitungen schreiben und durch ihre Erfahrung die fehlerhafte Komponente möglicherweise schneller hätten finden können. In vielen Fällen, in denen die Komponentenfehler keine Fehlercodes hervorriefen, mussten selbst die Vertragswerkstattmitarbeiter und die Fehlersuchanleitungsautoren zugeben, dass der entwickelte Ansatz eine große Verbesserung und Erleichterung bei der Fehlersuche gebracht hat.

184

8

Zusammenfassung und Ausblick

In diesem Kapitel werden in Abschnitt 8.1 die Ergebnisse der Arbeit zusammengefasst. Dabei wird die Lösung aus verschiedenen Sichtweisen bewertet. Diese Bewertung beruht auf den Ergebnissen der durchgeführten Feldtests, der Modellierungsworkshops und der Aufwandsabschätzung durch Autoren und Techniker, die die Diagnosemodelle erstellt haben. Obwohl die Arbeit als abgeschlossen gilt, existieren weitere Möglichkeiten, um die Erstellung des Diagnosemodells und den Diagnosevorgang zu verbessern. In Abschnitt 8.2 wird zuerst ein Ausblick über die weiterführende Arbeit im Bereich der Wissenserhebung vorgestellt. Im Anschluss wird eine der Möglichkeiten zur Integration der entwickelten Lösung im Zusammenhang mit der fallbasierten Diagnose kurz erläutert.

8.1

Zusammenfassung

Die Grundlage qualitativer Diagnosemodellbildung im Verbund mit heuristischem Wissen, die Mechanismen zur Auswertung dieses Diagnosewissens und die Implementierung wurden in der vorliegenden Arbeit beschrieben. Die Validierung des entwickelten Ansatzes erfolgte in mehreren Schritten und dient als Bewertungsbasis. Es existieren Ergebnisse aus folgenden durchgeführten Aktivitäten: • Modellerstellung, Aufwandserhebung und Aufwandsabschätzung durch Autoren und Techniker, die die bisherigen Fehlersuchanleitungen erstellt haben, Ende 2007 und Mitte 2009 • Zwei Modellierungsworkshops Anfang 2008 und Mitte 2009 • Drei Feldtestdurchführungen: – Feldtest 2007 mit Diesel- und Benzinsystem – Feldtest 2009 mit Licht- und Benzinsystem – Feldtest 2009 mit Licht-, Diesel- und Benzinsystem • Vier Live-Demos im Jahre 2009. Aus interner Sicht des Servicebereichs existieren eine Reihe von Kriterien zur Bewertung des Lösungsansatzes, die mit der Bewertungsbasis untersucht und ausgewertet wurden: • Erstellungsaufwand und Variantenvielfalt: Die Zeit und Kosten für Beschaffung, Aufbereitung, Erstellung und Pflege des Diagnosewissens ist selbst bei dem benötigten Initialaufwand vertretbar. Mit sukzessivem Aufbau einer Modellbibliothek verringert sich der Erstellungsaufwand mit der Zeit. Die Modellierung von Varianten erfolgt objektorientiert; durch die Eigenschaften der Generalisierung, Spezialisierung und Vererbung ist der Grad der Wiederverwendung von Modellwissen hoch.

8.1. ZUSAMMENFASSUNG

185

• Robustheit und Abdeckungsgrad: Die Sensitivität der erstellten Modelle bezüglich Serienstreuung und deren Übertragbarkeit auf andere Fahrzeuge wurde durch die Feldtests bestätigt. Der Umgang mit fehlenden Informationen und die Integrierbarkeit unterschiedlicher Informationsquellen bei der Modellerstellung wurden durch die Kombination von Modellwissen und heuristischem Wissen bewiesen. • Validierungsmöglichkeit und Überprüfbarkeit: Einzelne Modellteile können mit der entwickelten Überprüfungsmöglichkeit separat getestet werden. Das gesamte Diagnosemodell ist im Simulationsmodus validierbar. Die automatisierten Tests des gesamten Diagnosemodells können angestoßen werden, sobald die Testfälle definiert sind. Diese Testfälle können nicht nur durch Experten definiert werden, sondern auch durch Analyse der Feedback-Informationen aus dem Feld gewonnen werden. Eine weitere Validierungsmöglichkeit ist die Prüfung der Auswirkungen von Fehlern am Fahrzeug und deren Übereinstimmung beim Analysemodus, da in diesem Modus Fehler gesetzt werden können. • Performance und Ressourcenbedarf: Der erforderliche Speicherbedarf der Modelle, um eine Abdeckung von 96% aller Fahrzeuge auf dem Markt zu erreichen, beträgt in der aktuellen Abschätzung ca. 4,5 GB. Auf existierender Hardware (2,1 GHz und 2,0 GB RAM) benötigte der Diagnosevorgang pro Auswertungsschritt zwei bis fünf Sekunden. • Kompetenzen und Rollen: Das erforderliche Fachwissen zur Modellerstellung ist in dem existierenden Autorenteam vorhanden. Die externe Beauftragung der Modellbildung ist nach Meinung der Experten, die bereits mit externen Autoren gearbeitet haben, möglich. Die Anpassung und Erweiterung der existierenden Prozesse und Rollen in der Wissenserhebungsphase ist machbar und fordert keine Strukturänderung im Servicebereich. • Altdatenmigration und Selbstlernpotenzial: Die einhundertprozentige Nutzbarkeit bestehender Diagnosedaten ist bestätigt worden. Wegen des hybriden Ansatzes ist die Migration der Altdaten in die erstellten Modelle nahtlos und fordert kaum Aufwand. Mit der Möglichkeit zur Nutzung der heuristischen Informationen, zum Beispiel der Ausfallwahrscheinlichkeit der Komponenten beziehungsweise der Abhängigkeit zwischen Fehlern und Symptomen und der Anpassung der Benutzerführung in Form von Benutzerprofilen hat das Diagnosetool ein großes Selbstlernpotenzial. • Wissensaufbau und Wissenserhaltung: Steigerung des Systemverständnisses der Autoren durch Modellierungsaktivitäten, zum Beispiel Struktur- und Verhaltensmodellierung. Das Diagnosewissen ist besser nachvollziehbar und dokumentierbar durch die Strukturierung das Wissen mittels funktions- beziehungsweise komponentenorientierter Paradigmen. • Zukunftssicherheit: Mit dem Sichtkonzept ist die Flexibilität und Erweiterbarkeit der Datenstrukturen für Zukaufdaten und Feedback-Informationen garantiert. Der Modellierungsansatz ermöglicht verschiedene Sichtweisen auf das Fahrzeug: Systemsicht, Steuergerätesicht und Funktionssicht. Nur mit dieser Möglichkeit ist die Diagnose in der Werkstatt in der Zukunft durchführbar. • Vermarktbarkeit: Die schrittweise Vermarktung einzelner Aspekte des Diagnoseansatzes ist möglich. Die Sichtbarkeit der Veränderungen und des Nutzens für den Kunden im Diagnosevorgang eröffnet weitere Möglichkeiten der Markterschließung.

186

KAPITEL 8. ZUSAMMENFASSUNG UND AUSBLICK • Produktreife und Umsetzungsaufwand: Es existiert ein Initialaufwand zur Realisierung des Wissenserhebungstools und des Laufzeitsystems (Diagnosetool). Für das Wissenserhebungstool müssen die Datenbankschnittstellen definiert und implementiert werden. Für das Laufzeitsystem müssen die Schnittstellen zum Diagnosetester wegen der veränderten Implementierung und die Bedienungsoberfläche mit neuem Layout umgesetzt werden. Schulungskonzepte und Unterlagen für die Modellerzeugung müssen erstellt werden. Die Erstellung der Modellbibliothek ist notwendig und teilweise für Diesel-, Benzinund Lichtsystem vorhanden.

Die Bewertung des Diagnoseansatzes aus Markt- beziehungsweise Kundensicht wird anhand verschiedener Kriterien durchgeführt und ausgewertet: • Effizienz: Die Reduzierung der Prüfdauer und damit der Prüfkosten beim Fehlerfinden wurde anhand der Feldtestergebnisse nachgewiesen. • Diagnosequalität: Im Vergleich zu heutigen Diagnosetools ist die Verbesserung der Eindeutigkeit der Diagnoseergebnisse deutlich zu erkennen. Die Vollständigkeit bezüglich der Abdeckung aller Zweige des Fehlersuchbaums durch ein Modell und die Robustheit bezüglich ungenauer und fehlender Informationen ist durch Feldtests bewiesen. • Einstiegsmöglichkeit: Die Diagnoseinformationen in Form von Kundenbeanstandungen, Fehlercodes, Sensorwerten und Messungen können unabhängig voneinander aber auch kombiniert als Einstieg in der Diagnose genutzt werden. Diese Möglichkeit ist für das Werkstattpersonal entscheidend, da es nicht selbst gewichten und entscheiden muss, welche Informationen als Einstieg genommen werden sollen. • Auswertung der Diagnoseinformationen: Die gleichzeitige Auswertung mehrerer Eingaben (Beanstandungen, Fehlercodes, Sensorwerte, Messwerte) ist hilfreich im Diagnosevorgang. Zum einen wird das Überdeckungsproblem zwischen verschiedenen Beanstandungen und zwischen Beanstandungen und Fehlercodes gelöst, zum anderen können Arbeitschritte wie zum Beispiel Auslesen der Sensorwerte, Ergebnisvergleich zwischen Ist- und Sollwert bei der Messung und Durchführung von Stellgliedtests automatisiert werden. • Bedienbarkeit: Neben der benutzerangepassten Bedienung (Spezialisten/Anfängermodus) existiert die Möglichkeit, Mess-/Testvorschläge zu überspringen. Damit ist die Individualisierung des Nutzerprofils möglich. Das schnelle Auffinden gewünschter Informationen (Einbaulage, Funktionsbeschreibung, etc.) ist durch den Komponenten- u. funktionsorientierten Modellierungsansatz deutlich verbessert worden. Die Darstellung der Wirkkette ist eine leistungsstarke Erklärungskomponente, die nicht nur für Anfänger, sondern auch für Spezialisten brauchbar ist. • Lernkurve des Kunden: Durch die Visualisierung der Wirkkette baut der Kunde Systemund Funktionsverständnis stetig auf. Damit steigt die Akzeptanz für das neue Diagnosetool. Mit dem entwickelten Diagnosetool kann der Benutzer vom Anfänger zum Spezialisten durch Selbstlernen ausgebildet werden. • Zukunftssicherheit: Mit der automatischen Durchführung von vorgeschlagenen Messungen und Stellgliedtests in optimaler Reihenfolge ist die Verbindung von geführter Fehlersuche und Steuergerätediagnose sichergestellt worden. Die Individualisierung der Diagnose durch Berücksichtigung regionaler Unterschiede bei der Ausfallwahrscheinlichkeit,

8.2. AUSBLICK

187

Werkstattinfrastruktur in Form von vorhandenem Test- und Prüfequipment sowie Reparaturhistorie einzelner Fahrzeuge sichert die Zukunft des entwickelten Ansatzes. Bei vorhandener Falldatenbank ist durch den hybriden Ansatz die Integration der fallbasierten Diagnose möglich. Durch Evaluation und Auswertung wurde in dieser Arbeit gezeigt, wie eine Diagnoselösung für freie Werkstätten mittels des modellbasierten Ansatzes im Verbund mit heuristischem Diagnosewissen umgesetzt und als Erfolg versprechend betrachtet werden kann. Damit ist der Weg zur Produktumsetzung und dem praktischen Einsatz in freien Werkstätten sichergestellt. Nichtsdestotrotz sind noch viele Hindernisse, nicht nur theoretischer, sondern auch wirtschaftlicher Natur, zu überwinden. Nachfolgend werden weiterführende Ansätze, die die erarbeiteten Ergebnisse in eine neue Offboard-Diagnose-Generation einbringen, erläutert.

8.2

Ausblick

Der vorgestellte Ansatz hat sich bereits in der Praxis bewährt. Trotzdem ergeben sich zahlreiche Perspektiven, die Arbeit weiterzuführen und zu verbessern. In diesem Abschnitt werden einige Ansätze zur Erweiterung der Wissenserhebung vorgestellt, die teilweise schon prototypisch umgesetzt wurden. Abschließend wird das Vorhaben, die Lösung auf weitere Domänen zu transferieren, kurz erläutert.

8.2.1

Erweiterung des Diagnosewissens

Da die Modellierung in Verbindung mit heuristischem Diagnosewissen unter Berücksichtigung des Erstellungsaufwandes nur einen Teil der Realität in einem Diagnosemodell abbildet, kann das Diagnosetool nicht immer eine exakte Diagnose für die vorhandenen Symptome liefern. Eine Fehlerabdeckung mit der Größenordung zwischen dreiundachzig und einundneunzig Prozent ist mit vertretbarem Aufwand unter Verwendung des entwickelten Ansatzes möglich. Darüber hinaus ist der Aufwand zu hoch und wirtschaftlich nicht sinnvoll. Nachfolgend wird die Überlegung zur Erweiterung des Diagnosewissens mit fallbasiertem Wissen aus der Feedback-Funktion des Diagnosetools vorgestellt und die Erweiterung durch Anbindung weiterer Modellarten und die Abstraktion des quantitativen Modells kurz erläutert. Dabei soll die Erweiterung zum einen die Diagnosegüte erhöhen und zum anderen die Wissenserhebungskosten nicht erheblich steigern. Erweiterung des Diagnosewissens mit Diagnosefallsammlungen Bei der Wissenserhebung kann das Diagnosemodell durch Informationen aus relevanten Fallsammlungen angereichert werden. Diese Überlegung ist nicht neu und wurde mehrfach in der Literatur diskutiert [83], [114], [150], [88]. In dieser Arbeit existieren hierfür zwei Möglichkeiten: • Der Fehlerfall ist durch das Diagnosemodell abgedeckt: Wegen der vorhandenen Abdeckung muss das Diagnosewissen im Modell nicht erweitert werden. Abhängig von der Auftrittswahrscheinlichkeit des Fehlers kann gegebenenfalls die Häufigkeit, die zur Priorisierung in dem Diagnosevorgang verwendet wird, geändert werden.

188

KAPITEL 8. ZUSAMMENFASSUNG UND AUSBLICK • Der Fehlerfall ist durch das Diagnosemodell nicht abgedeckt: Die Gründe für die nicht vorhandene Abdeckung sind vielseitig und erfordern größeren Analyseaufwand. Nachfolgend werden einige Möglichkeiten aufgezeigt und der Umgang mit diesen Informationen erläutert: – Das vorhandene Symptom (Kundenbeanstandung, Fehlercode, etc.) ist nicht in dem Diagnosemodell enthalten. Wenn dieser Fall auftritt, muss je nach relevantem Grad das Symptom und dessen physikalische Bedeutung in das Diagnosemodell aufgenommen oder als separater Fall bei bestimmten Fahrzeugtypen gespeichert werden. – Die Grenze der Sollwertbereiche, die durch systemeigene Sensoren beziehungsweise Messungen ermittelt wurden, stimmen nicht. In diesem Fall muss die Diagnosewissensbasis geprüft und geändert werden. Beachtet werden muss, dass die Änderungen möglicherweise nicht für alle Fahrzeuge dieses Typs gelten. – Das Komponentenmodell beinhaltet nicht den vorhandenen Komponentenfehler beziehungsweise das Modell kann das Fehlverhalten nicht erklären. Dieser unbekannte beziehungsweise nicht abgedeckte Fehler muss einen Bewertungsprozess durchlaufen, in dem eine Abwägung zwischen Aufwand und Nutzen erfolgt. Wenn der Aufwand nicht überwiegt, wird das Modell um den Fehler erweitert. Wenn der Nutzen wegen der Auftrittswahrscheinlichkeit des Fehlers gering ist, kann der Fall gespeichert und mit dem Diagnosemodell verlinkt werden.

Die Fehlerlokalisierung im Diagnosevorgang kann wie folgt realisiert werden: • Zuerst wird die fallbasierte Schlussfolgerung angewandt. Wenn keine bekannten Fälle vorliegen, wird die modellbasierte Schlussfolgerung angewandt. • Die Modellanalyse und deren Schlussfolgerung werden herangezogen, wenn die vorhandenen Symptome im Modell abgebildet sind. Die Diagnoseabläufe sind mit der Entscheidung, dass Fallsammlungen zuerst überprüft werden anstatt modellbasiert zu analysieren, nicht festgelegt. Eine Umpositionierung der Schlussfolgerung von Diagnosestrategien ist möglich. Das Werkstattpersonal hat die freie Entscheidung, welche Strategie es zuerst anwenden möchte. Generierung der Verhaltenstabelle mittels Zustandsdiagramm Eine Möglichkeit zur Erweiterung des Diagnosewissens im Modell ist die Anbindung verschiedener Modellarten. Dadurch werden zum einen unterschiedliche Betrachtungsweisen der Modellierer zugelassen und zum anderen wird die Möglichkeit geboten, unterschiedliche Aspekte der Realität besser abzubilden, miteinander zu kombinieren und das Modellierungswissen so zusammenzuführen. In dieser Arbeit wird zuerst das Verhalten einer Komponente beziehungsweise eines Systems durch qualitative Relationen beziehungsweise Gleichungen beschrieben und durch Verhaltenstabellen dargestellt. Zusätzlich kann das Verhalten im Modellierungstool mittels Zustandsdiagrammen beschrieben werden. Die daraus generierten Verhaltenstabellen und die aus Relationsgleichungen generierten Tabellen werden durch Abgleichalgorithmen zusammengefügt und für die Modellanalyse zur Verfügung gestellt.

8.2. AUSBLICK

189

In Rahmen der Arbeit wurden nur kleine Modelle mit Zustandsdiagrammen erzeugt und mit der entwickelten Modellprüfung getestet (Abbildung 8.1). Als Ergebnis kann festgehalten werden, dass sich die beiden Verhaltensmodelle ineinander fügen lassen und der Modellierungsaufwand wie erwartet nicht doppelt so hoch ist wie bei einer verwendeten Modellierungsart. Trotzdem ist der Modellierungsaufwand deutlich höher im Verhältnis zu einem geringfügigen Mehrwert bei der Diagnose, weil sich die Verhalten aus den unterschiedlichen Modellierungsarten sehr stark überdecken. Der große Vorteil liegt nur darin, dass der Modellierer nicht an eine bestimmte Modellierungsart gebunden ist.

Abbildung 8.1: Prototypische Umsetzung der Generierungsverhaltenstabelle mittels Zustandsdiagramm

Generierung der Verhaltenstabelle mittels Simulink-Modell Eine weitere Überlegung ist die Generierung des qualitativen Modells aus einem quantitativen Modell. Aufgrund der statischen Systembetrachtung in der Werkstattdiagnose und der qualitativen Modellbildung sollen die Übertragungsfunktionen aus existierenden analytischen Simulationsmodellen linearisiert werden. Des Weiteren wurden in dieser Arbeit nur drei Betriebspunkte (Leerlauf, Teillast, Volllast) mit zwei Startvorgängen (Warm- und Kaltstart) betrachtet. Daher müssen die Übertragungsfunktionen der Simulationsmodelle nur an diesen

190

KAPITEL 8. ZUSAMMENFASSUNG UND AUSBLICK

Betriebspunkten berücksichtigt werden. Der Vorteil dieser Vorgehensweise ist die Wiederverwendung des Modellwissens, das zuvor von den Entwicklungsabteilungen beziehungsweise Simulationstool-Herstellern bereitgestellt wurde. In der Diplomarbeit [85] wurde die Methode zur Abstraktion des Komponentenverhaltens aus Simulink-Modellen untersucht. Zur Evaluierung des entwickelten Verfahrens wurden die stationären Komponentenverhalten der Komponenten des ALWR1.0-Systems aus entsprechenden analytischen Modellen abstrahiert und in DMB-System importiert (Abbildung 8.2). Zur Verifizierung wurden die generierten Komponentenmodelle mittels des entwickelten Modelltestermoduls geprüft. Als Ergebnis kann festgehalten werden, dass die Überführung des quantitativen Modells ins qualitative Modell möglich ist. Der Aufwand bei der Überführung des Norminalenverhaltens ist wie erwartet gering. Dagegen beinhalten die Simulationsmodelle in den meisten Fällen keine Fehlverhalten beziehungsweise es wurden kaum Fehlervariablen in der Entwicklung durch die Modellbildung berücksichtigt. Demzufolge ist die Nutzung der generierten Modelle in der Diagnose eingeschränkt. Mathlab/Simulink - Modell

Abbildung 8.2: Prototypische Umsetzung der Generierungsverhaltenstabelle mittels SimulinkModell

8.2.2

Weiterführende Projekte

Nicht nur im Automotivbereich sondern auch im Thermotechnikbereich wird das Gesamtsystem stetig komplexer (Abbildung 8.3). Damit nimmt die Problematik der hohen Anzahl an i.O.-Ausbauten zu (30% i.O.-Ausbauten in Thermotechnikbereich). Bei dem i.O.-Ausbau

191

8.2. AUSBLICK

werden eine oder mehrere nicht fehlerhafte beziehungsweise In-Ordnung-Komponenten in einem Diagnose- und Reparaturvorgang durch neue Komponenten ersetzt. Die Ursache dieser Problematik gilt für beide Bereiche, zum Beispiel: • Durch die Weiterentwicklung der Heizungssysteme mit dem Ziel zur Steigerung der Energieeffizienz beziehungsweise Senkung der Energiekosten steigt die Systemkomplexität exponential an, • Wegen der Kombinationsmöglichkeit der Komponenten beim Aufbau eines Systems existiert eine große Variantenvielfalt. Neben der Ähnlichkeit der beiden Domänen existieren einige Unterschiede, die bei der Diagnose berücksichtigt werden müssen, zum Beispiel: • Heizungssysteme reagieren langsamer auf Anregungen als mechatronische Systeme im Fahrzeug, demzufolge ist die Berücksichtigung der Prüfzeit im Diagnosevorgang entscheidend, • Aufgrund der manuellen Montages eines Heizungssystems können Strukturfehler auftreten. Ein Beispiel für einen Strukturfehler ist das Vertauschen der Ausgangsschnittstellen des Außen- und Innentemparatursensors beim Einbau. Wegen der Gemeinsamkeiten aber auch der Unterschiede ist eines der weiterführenden Projekte der Transfer des entwickelten Diagnoseansatzes vom Automotive- zum Thermotechnikbereich. Automotiv Komplexität, Variantenvielfalt

Thermotechnik Komplexität, Variantenvielfalt

Abbildung 8.3: Parallele Entwicklung der Systemkomplexität im Automotive- und Thermotechnikbereich Der bestehende Onboard-Diagnoseansatz im Kraftfahrzeugbereich basiert auf der Auswertung von Signalverläufen. Damit ist der Anwendungsbereich nur für Komponenten und nicht für Subsysteme beziehungsweise Systeme geeignet. Eines der Probleme bei der Onboard-Diagnose ist die Auswirkung eines Fehlers in einem System in Bezug zu Symptomen in anderen Systemen. Aktuell wurde kein Lösungsansatz zur systemübergreifenden Diagnose im Steuergerät implementiert, obwohl die Verkopplungen der Systeme in der Onboard-Diagnose berücksichtigt werden müssen. Ein weiterführendes Projekt ist die Bereitstellung von Methoden zur

192

KAPITEL 8. ZUSAMMENFASSUNG UND AUSBLICK

Lokalisierung fehlerhafter Systeme. Der Lösungsansatz hierzu ist die Zusammenführung des entwickelten Diagnoseansatzes und der vorhandenen Onboard-Diagnose-Funktionen (Abbildung 8.4). Das Verhalten der Systeme und Subsysteme wird durch qualitative relationale Übergangfunktionen abgebildet, somit können die Lokalisierung fehlerhafter Systeme und Subsysteme sowie die Koordinierung der OBD-Funktionen für die entwickelten Diagnosealgorithmen angewendet werden.

Abbildung 8.4: Einsatzmöglichkeit des entwickelten Ansatzes bei der Onboard-Diagnose Die Vorteile liegen darin, dass durch eine qualitative Modellierung des Systems und Subsystems der Aufwand der Modellierung relativ gering ist und dennoch eine Diagnoseentscheidung, in welchem System das Fehlverhalten liegen könnte, getroffen werden kann. Bei der Lokalisierung und Bestätigung der fehlerhaften Komponente werden die OBD-Funktionen herangezogen. Die Herausforderung bei diesem Projekt ist die Koordinierung der durchzuführenden

8.2. AUSBLICK

193

OBD-Funktionen. Die Einschaltbedingungen der OBD-Funktionen können sehr komplex sein und damit kann die OBD-Funktion oft nur in einem bestimmten Betriebspunkt durchgeführt werden. Zum Beispiel können viele OBD-Funktionen des Luftsystems nur im Leerlauf durchgeführt werden. Die Zeit, in welcher sich das System in diesem Betriebspunkt befindet, wird durch ein Start-Stop-System deutlich verkürzt. Daher steht neben der Optimierung des Diagnosealgorithmus bezüglich der Anforderungen der Onboard-Funktion die Priorisierung der durchzuführenden Tests in Form von OBD-Funktionen im Vordergrund. Zur Lösung von Wissenserhebungsaufgaben benötigen die Mitarbeiter des Service- und Entwicklungsbereichs leistungsfähige und einfach zu bedienende Werkzeuge, die ihre Arbeit unterstützen und erleichtern. Analog brauchen die Mitarbeiter in den Werkstätten ebenso wie die neue Steuergerätgeneration einen leistungsfähigen und effizienten Diagnosealgorithmus bei der Durchführung eines Diagnosevorgangs. Die vorgeschlagenen Lösungsansätze und deren Umsetzung haben in der Evaluierung gezeigt, dass diese Lösung den Anforderungen in diesen beiden Bereichen gerecht wird. Bei der Umsetzung und Weiterentwicklung der Lösungsansätze in der Praxis existieren weitere interessante Herausforderungen.

Literaturverzeichnis [1] Agrawal, A.; Vizhanyo, A., Kalmar, Z., Shi, F., Narayanan, A., Karsai, G.: Reusable Idioms and Patterns in Graph Transformation Languages. Proc. 2nd International Workshop on Graph Based Tools. Rome , 2004. [2] Abi-Antoun, M.; Aldrich, J.; Nahas, N.; Schmerl, B.; Garlan, D.: Differencing and Merging of Architectural Views. Institute for Software Research International School of Computer Science Carnegie Mellon University, 2005. [3] Approxima Advanced Technologies GmbH: WDS - Das wissensbasierte Diagnosesystem. Bad Homburg, 2005. [4] Althoff, K.-D.; Wess, S.; Bartsch-Spörl, B.; Janetzko, D.; Maurer, F.; Voß, A.: Fallbasiertes Schließen in Expertensystemen: Welche Rolle spielen Fälle für wissensbasierte Systeme?. KI, Baden-Baden: FBO Verlag, 1992. [5] Althoff, K.-D.: Fallbasierte Systeme und Anwendungen, Vorlesungsskriptum, WS2010/11, Intelligente Informationssysteme (IIS), 2010. [6] Althoff, K.-D.: Wissensbasierte Systeme, Vorlesungsskriptum, WS2010/11, Intelligente Informationssysteme (IIS), 2010. [7] Ansel, J.; Engel, P.; Dang Duc, N.: Erstellungszeiten der Fehlersuchanleitungen in Kraftfahrzeug in: interne Bosch-Berichte. 2007. [8] Alanen, M.; Porres, I. .: Difference and Union of Models. TUCS Turku Centre for Computer Science, 2003. [9] Berard, B.;Bidoit, M.; Finkel, A.; Laroussinie, F.; Petit, A.; Petrucci, L.; Schnoebelen,P.: Systems and Software Verification: Model-Checking Techniques and Tools. Springer (1 edition), 2001. [10] Bäker, B.: 3. Tagung: Diagnose in mechatronischen Fahrzeugsystemen. TU Dresden, Institut für Automobiltechnik Dresden - IAD, 2008. [11] Biedermann, C.: Der Vertrieb neuer Automobile in Deutschland: Vor dem Hintergrund der GVO 1400/02 und der aktuellen Marktentwicklung. Auflage 1, Europäischer Hochschulverlag 2005. [12] Baier, Ch.; Katoen J.-P.: Principles of Model Checking. The MIT Press,2008 [13] Boerger, E.; Staerk, R.: Abstract State Machines. A method for High-Level System Design and Analysis. Springer, 2003. [14] Beck, K.: Test Driven Development by Example. Addison-Wesley Longman (Amsterdam), 2002 194

LITERATURVERZEICHNIS

195

[15] Borutzky, W: Bond Graphs - A methodology for modeling multi-disiplinary systems. bei society for modeling and simulation international, Erlangen 2004. [16] Broy, M.; Jonsson, B.; Katoen, J.-P.; Leucker, M.: Model-Based Testing of Reactive Systems: Advanced Lectures (Lecture Notes in Computer Science / Programming and Software Engineering). Springer (1 edition), 2005. [17] Bergmann, R.; Althoff, K.-D.; Breen, S.: Developing Industrial Case-Based Reasoning Applications: The INRECA Methodology (Lecture Notes in Computer Science / Lecture Notes in Artificial Intelligence), Springer Berlin Heidelberg, Auflage: 2nd ed., 2003. [18] Bardohl, R.; Ehrig, H.; de Lara, J.; Taentzer, G.: Integrating Meta Modelling Aspects with Graph Transformation for Efficient Visual Language Definition and Model Manipulation. In M. Wermelinger and T. Margaria, editors, Proceedings of FASE 2004. Springer, 2004. [19] Borzsonyi, S.; Kossmann, D.; Stocker, K. The skyline operator. in: proceedings of the 17th International Conference on Data Engineering, Heidelberg, Germany, April 2001. [20] Beger, T.: Modellbasierte Diagnose verteilter Systeme auf Basis ihres Kommunikationsverhaltens. Dissertation, Shaker-Verlag 1999. [21] Balke, W.-T.: Guentzer, U.;Xin Zheng, J.: Approaching the Efficient Frontier: Cooperative Database Retrieval Using High-Dimensional Skylines. DASFAA, 2005. [22] Cunis R.: INDIA -Intelligente Diagnose in der industriellen Anwendung. Shaker Verlag, Aachen, Germany, 2001. [23] DIN ISO 13373-1: Zustandsüberwachung und -diagnostik von Maschinen (Schwingungs-Zustandsüberwachung- Teil 1: Allgemeine Anleitungen). DIN Deutsches Institut für Normung e.V., Berlin, 2002. [24] DIN ISO 17359: Zustandsüberwachung und -diagnostik von Maschinen (Allgemeine Anleitungen). DIN Deutsches Institut für Normung e.V., Berlin, 2003. [25] DIN ISO 13373-2: Zustandsüberwachung und -diagnostik von Maschinen (Schwingungs-Zustandsueberwachung - Teil 2: Verarbeitung, Analyse und Darstellung von Schwingungsmesswerten). DIN Deutsches Institut für Normung e.V., Berlin, 2006 [26] DIN ISO17359: Zustandsüberwachung und -diagnostik von Maschinen. DIN Deutsches Institut für Normung e.V., Berlin, 2007. [27] De Kleer, J.: Local Methods for Localizing Faults in Electronic Circuits, M.I.T. AI Memo 394. Cambridge, MA. 1976. [28] De Kleer, J., Brown, J.S.: A qualitative physic based on confluences, in: Artificial Intelligence.1984. [29] De Kleer, J.: An Assumptionbased TMS, in: Artificial Intelligence.1986.

196

LITERATURVERZEICHNIS

[30] De Kleer, J., Williams, B.C.: Diagnosing Multiple Faults. in: Artificial Intelligence.1987. [31] De Kleer, J., Williams, B.C.: Diagnosis with Behavioral Modes, in: Proc. 11th Intl. Joint Conf. on Artificial Intelligence IJCAI-89..Detroit, 1989. [32] De Kleer, J., Kurien, J.: Fundamentals of Modelbased Diagnosis. in: Artificial Intelligence. 2003. [33] de Lara, J.; Vangheluwe, H.: A Tool for Multi-Formalism Modelling and MetaModelling. LNCS 2306. Springer, 2002. [34] Dang Duc, N.; Bauer, N.; Engel, P.: Optimale Testreihenfolge für Werkstattdiagnose. in: interne Bosch-Berichte CR/AEM. 2005. [35] Dang Duc, N.; Bauer, N.; Engel, P.: Allgemeine Test-Reparatur-Strategie. in: interne Bosch-Berichte CR/AEM. 2005. [36] Dang Duc, N.; Bauer, N.; Engel, P.: Sensoreneinsatz in der Werkstattdiagnose. in: interne Bosch-Berichte CR/AEM. 2005. [37] Dang Duc, N.; Engel, P. ; de Boer, G.: Prozessschritte bei der Wissenserhebung in: interne Bosch-Berichte CR/AEM. 2006. [38]

Dang Duc, N.; de Boer, G.; Engel, P. : Modellbildungskriterien in: interne Bosch-Berichte CR/AEM-AEH. 2007.

[39] Dang Duc, N.; Engel, P.; Weidemann, D. : Modellbildungskriterien in: interne Bosch-Berichte CR/AEM-AEH. 2007. [40] Dang Duc, N.; Engel, P.; Weidemann, D. : Aufwand für die Erstellung und die Pflege von Fehlersuchanleitungen und Modelle in: interne Bosch-Berichte CR/AEMAEH. 2007. [41] Dang Duc, N.; Kaercher, M. : Evaluierungsszenario des 2. Feldtests in: interne Bosch-Berichte CR/AEH. 2008. [42]

Dang Duc, N.; Opfermann, A.; Nitsche, R.: Auswertung und Bewertung des DRT-Systems beim zweiten Feldtest in: interne Bosch-Berichte CR/AEH. 2009.

[43] Dang Duc, N.; Opfermann, A.; Nitsche, R.: Vorstellung der Ergbebnisse in zweitem Feldtest in: interne Bosch-Berichte CR/AEH. 2009. [44] Dickinson, P.J.; Bunke, H.; Dadej, A.; Kraetzl, M. : Matching graphs with unique node labels. Pattern Analysis and Applications, 2004. [45] Delfmann, P.: Adaptive Referenzmodellierung. Methodische Konzepte zur Konstruktion und Anwendung wiederverwendungsorientierter Informationsmodelle. Diss. Univ. Münster, Berlin 2006. [46] Davis, R.: Diagnostic Reasoning Based on Structure and Behavior, in: Artificial Intelligence 24/1-3. 1984.

LITERATURVERZEICHNIS

197

[47] Damic V. und Montgomery J.: Mechatronics by bond graphs: an object-oriented approach to modelling and simulation. Springer-Verlag Berlin Heidelberg New York, 2004. [48] Ehrig, H.; Engels, G.; Kreowski, H.-J.; Rozenberg, G.: Handbook of Graph Grammars and Computing by Graph Transformation. Vol 1. Foundations. World Scientific, 1999. [49] Ehrig, H.; Ehrig, K.; de Lara, J.; Taentzer, G.; Varrio, D.; Varrio-Gyapay, S.: Termination criteria for model transformation. In Proc. Fundamental Approaches to Software Engineering (FASE), Lecture Notes in Computer Science . Springer, 2005. [50] Edmund, M.; Clarke, Jr.; Grumberg, O.; Peled, D. A.: Model Checking. The MIT Press, 2000. [51] Engel, P.; Dang Duc, N.; de Boer, G. : Evaluierungsprogramm des DMB-Systems . in: interne Bosch-Berichte CR/AEM. 2006. [52]

Engel, P. : Auswertung des Modllierungsaufwands in: interne Bosch-Berichte CR/AEM. 2006.

[53] Engel, P.; Dang Duc, N. : Modellierbarkeit der Fahrzeug- systeme/funktionen in: interne Bosch-Berichte CR/AEM-AEH. 2007. [54] Engel, P.; Dang Duc, N.; Weidemann, D. : Vergleich der Aufwände für die Erstellung und Pflege von Fehlersuchanleitungen mit existierenden Autorensysteme und DMB-System in: interne Bosch-Berichte CR/AEM-AEH. 2007. [55] Engel, P.; Dang Duc, N.; Walter, M.; Wambera, T. : Auswertung der Modellanzahlen in: interne Bosch-Berichte CR/AEM-AEH. 2007. [56] Engel, P.; Dang Duc, N.; Walter, M.; Wambera, T.; Schabel, M.; Hess, M.: Auswertung und Bewertung des DRT-Systems beim erten Feldtest in: interne BoschBerichte CR/AEM. 2007. [57] European Telecommunications Standards Institute: Testing and Test Control Notation (TTCN-3). www.etsi.org, 2007. [58] Fowler, M.: Refactoring, Improving the Design of Existing Code. Addison-WesleyLongman, 1999. [59] Fowler, M.; Beck, K.; Brant, J.; Opdyke, W.: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman, Amsterdam; Auflage: illustrated edition, 1999. [60] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [61] Genesereth, M.R.: The Use of Design Descriptions in Automated Diagnosis, in: Artificial Intelligence, 24/1-3. 1984. [62] Godfrey, P. : Skyline Cardinality for Relational Processing: How many Vectors Are Maximal?, FoIKS, 2004.

198

LITERATURVERZEICHNIS

[63] Graf, S.; Mounier, L.: Model Checking Software. Springer (1 edition), 2004. [64] Holzmann, G. J.: The Spin Model Checker: Primer and Reference Manual. AddisonWesley Longman (Amsterdam), 2003. [65] Hattaß, J.: Europäischer Kraftfahrzeugvertrieb zwischen den Zielen des EGV und der neuen Wettbewerbspolitik der Kommission: Die Kfz-GVO 1400/2002. 1. Auflage, Tectum-Verlag 2007. [66] Heiming, B.:Parallele Prozeßdiagnose auf der Grundlage einer qualitativen Systembeschreibung. VDI Verlag, Düsseldorf, 2000. [67] Hamscher, W.: Readings in Model-based Diagnosis. (Hrsg. Hamscher, W., Console, L., de Kleer, J.) , San Mateo, California, 1992. [68] ISO13374-1:2003: Condition monitoring and diagnostics of machines (Data processing, communication and presentation - Part 1: General guidelines). First edition; Geneva Switzerland 2003. [69] ISO13379:2003: Condition monitoring and diagnostics of machines (General guidelines on data interpretation and diagnostics techniques); First edition. Geneva Switzerland 2003. [70] ISO13372:2004: Condition monitoring and diagnostics of machines; First edition. Geneva Switzerland 2004. [71] Kayser, A.: Komponentenorientierte Modellierung elektrischer und mechatronischer Systeme. Fortschr.-Ber. VDI Reihe 20 Nr. 368, VDI Verlag 2003. [72] Kuipers, B.: Qualitative Simulation. Encyclopedia of Physical Science and Technology, Academic Preas 2002. [73] Kossmann, D.; Ramsak, F.;Rost S. Shooting Stars in the Sky: An Online Algorithm for Skyline Queries. in: proceedings of the 28 VLDB Conference, Hong Kong, China, 2002. [74] Kung, H.-T.; Luccio, F.; Preparata, F. P. On Finding the Maxima of a Set of Vectors. in: Journal of the ACM 22 (1975), Nr. 4 [75] Kreowski, H.-J.; Kuske., S.: Graph transformation units with interleaving semantics. Formal Aspects of Computing, 1999. [76] Kerievsky, J.:Refactoring to Patterns. Addison-Wesley Longman, Amsterdam, 2004. [77] Koskela. L.: Test driven: TDD and Acceptance TDD for Java developers. Manning Publications, 2007. [78] Kockskämper, S.; Neumann, B.; Josub, A.; Müller, H.: Die Anwendung modellbasierten Schließens bei der Diagnose schiffstechnischer Anlagen. in: Proc. Expertensysteme 93 (Hrsg. F.Puppe, A.Günter), Springer-Verlag 1993. [79] Keller, U.; Wehren, J.; Niere, J.: A Generic Difference Algorithm for UML Models. In Software Engineering. 2005.

LITERATURVERZEICHNIS

199

[80] Kümmel, W.: Technische Strömungsmechanik: Theorie und Praxis. 3. Auflage, Vieweg+Teubner 2007. [81] Lunzer, J.: Künstliche Inteligenz für Ingenieur. Band 2: Technische Anwendungen Oldenbourg, München 1995. [82] Lehmann E.: Time Partition Testing: Systematischer Test des kontinuierlichen Verhaltens von eingebetteten Systemen. Dissertation, TU-Berlin, 2003. [83] Luger F. G.: Künstliche Intelligenz . Strategien zur Lösung komplexer Probleme. Taschenbuch, Pearson Studium Verlag, 2001. [84] Link, J.: Softwaretests mit JUnit-Techniken der testgetriebenen Entwicklung. Dpunkt Verlag (2. Auflage), 2005. [85] Linnartz, M.: Vertikale Durchgängigkeit in der Diagnose durch funktionale Abstraktion am Beispiel eines mechatronischen Systems. Diplomarbeit, Hochschule Bonn-Rhein-Sieg in Zusammenarbeit mit der Abteilung CR/AEH der Robert Bosch GmbH, 2009. [86] Malik, A.: Autorensystem für Anleitung zur Fehlersuche und Reparatur im Kraftfahrzeug: Anforderungsanalyse und Spezifikation, in: Intelligente Diagnose in der industriellen Anwendung., Shaker-Verlag, 2000. [87] Mauss, J.: Analyse kompositionaler Modelle durch Serien-Parrallel-Stern Aggregation. DISKI 183, infix-Verlag, 1998. [88] Menzel, G.; Zscharnack, H.; Unger, A.; Bäker, B.: Hybride Architekturen für die Offboarddiagnose - Einfluss der Integrationstiefe auf die Diagnoseentwicklung. Diagnose in mechatronischen Fahrzeugsystemen IV: Neue Verfahren für Test, Prüfung und Diagnose von E/E-Systemen im Kfz von Bernard Bäker und Andreas Unger. ExpertVerlag, 2011. bibitemMB88 Meyer, B.: Object Oriented Software Construction. Prentice Hall, 1988. [89] Mordechai, B.-A.: Principles of the SPIN Model Checker. Springer London, 2008. [90] Erdmann, M.: Vertikale Vereinbarungen im Kfz-Sektor: Die neue GVO 1400/2002., 1. Auflage, Kovac-Verlag 2006. [91] Mili, H. ; Mili, A. ; Yacoub, S. ; Addy, E.: Reuse-Based Software Engineering. New York, 2002. [92] Milde, H.: Qualitative Analyse von Störungen in elektrischen Systemen., DISKI 271, Akademische Verlagsgesellschaft Aka GmbH, Berlin 2003. [93] Mozetic, I.: Model-Based Diagnosis: An Overview, in: Advanced Topics in Artificial Intelligence. (Hrsg. Marik, V., Stepankova, O., Trappl, R.), Berlin, 1992. [94] Monin, J.-F.: Understanding Formal Methods (FACIT). Springer (1st Edition), 2003. [95] Meffert, K.: JUnit Profi-Tipps-Software erfolgreich testen. Entwickler.Press (1. Auflage), 2006 [96] Martin, R.C.: Designing Object Oriented Applications using UML. 2d. ed., Prentice Hall, 1999.

200

LITERATURVERZEICHNIS

[97] Martin, R.C.: Design Principles and Design Patterns. www.objectmentor.com, 2000. [98] Melnik, S.; Garcia-Molina, H.; Rahm, E.: Similarity Flooding: A Versatile Graph Matching Algorithm and its Application to Schema Matching. In 18th Intl. Conference on Data Engineering (ICDE), 2002. [99] Müller, T.: Automatische erfahrungsbasierte Diagnose aus Felddaten mit neuronalen Netzen. in 12. Internationaler Kongress Elektronik im Kraftfahrzeug, VDI Verlag 2007. [100] Nyberg, M.: Model Based Fault Diagnosis: Methods, Theory, and Automotive Engine Applications, Dissertation. Linköping, Schweden, 1999. [101] Oestereich, B.: Objektorientierte Softwareentwicklung - Analyse und Design mit der UML. Oldenbourg, Auflage: 5, 2001 [102] Otter, M.: Objektorientierte Modellierung Physikalischer Systeme Teil 1-9. in: at Automatisierungstechnik, 1999-2000. [103] Otter, M.; Elmqvist, H. and Mattson S.E.: The New Modelica MultiBody Library. Proceedings, 3rd International Modelica Conference, Linköping, Schweden, 2003. [104] Otter, M., Elmquist, H.: Advanced Modelica Tutorial: Developing Modelica Libraries. in Proc. Modelica, Linköping, Schweden, 2003. [105] Otter, M., Elmquist, H.: Modelica: Language, Libraries, Tools and Conferences. 2005. [106] Olbrich, R. and Battenfeld, D.: Der markt: Variantenvielfalt und Komplexität kostenorientierte vs. marktorientierte Sicht. Springer, Volume 44 / 2005. [107] Robert Bosch GmbH:Ottomotor-Management: Systeme und Komponenten 3. Auflage, Vieweg 2005. [108] Peled, D. A.: Software Reliability Methods (Texts in Computer Science). Springer (1 edition), 2001. [109] Papadias, D.;Tao, Y.;Fu, G.;Seeger, B.: An optimal and progressive algorithm for skyline queries. in: SIGMOD Conference, 2003. [110] Papadias, D.; Tao, Y.; Fu, G.; Seeger, B.: rogressive Skyline Computation in Database Systems. in: ACM Transactions on Database Systems 30, 2005. [111] Puppe, F: Problemlösungsmethoden in Expertensystemen. Studienreihe Informatik. Springer, Berlin/Heidelberg/New York, 1990. [112] Puppe, F: Wissensbasierte Diagnosesysteme im Service-Support. Konzepte und Erfahrungen. Springer, Berlin/Heidelberg/New York, 2003. [113] Puppe, F; Gappa, U.; Poeck, K; Bamberger, S.: Wissensbasierte Diagnose- und Informationssysteme. Springer, Berlin/Heidelberg/New York, 1996. [114] Puppe, F: Explizites Wissen versus Black Box-Ansätze in der KI. Künstliche Intelligenz, Band 25, Heft 1, Springer-Verlag, 2011.

LITERATURVERZEICHNIS

201

[115] Pietrek, G.; Trompeter, J.: Modellgetriebene Softwareentwicklung. MDA und MDSD in der Praxis. Entwickler-Press, 2007. [116] Pfaltz, J.; Nagl, M.; Boehlen, B.: LNCS: Applications of Graph Transformations with Industrial Relevance Second International Workshop. In Pfaltz et al. Charlottesville, 2003. [117] Pawson, R.; Matthews, R.: Naked Objects. John Wiley and Sons, 2002. [118] Quintarelli, E.: Model-Checking Based Data Retrieval: An Application to Semistructured and Temporal Data (Lecture Notes in Computer Science). Springer (1 edition), 2004. [119] Rensink, A.; Schmidt, A.; Varrio; D.: Model checking graph transformations: A comparison of two approaches. In H. Ehrig, G. Engels, F. Parisi-Presicce, and G. Rozenberg, editors, ICGT Springer, 2004. [120] Rensink, A.; Distefano, D.: Abstract graph transformation. Electronic Notes in Computer Science. Springer, 2006. [121] Robert V. B.: Testing Object-Oriented Systems: Models, Patterns, and Tools. Object Technology Series. Addison-Wesley, 1999. [122] Robert Bosch GmbH:Kraftfahrtechnisches Taschenbuch. 26. Auflage, Vieweg 2007. [123]

Rozenberg, G.: Hrsg. Handbook of Graph Grammars and Computing by Graph Transformation. Foundations, Jgg. 1. World Scientific, 1997.

[124] R.O.S.E. Informatik GmbH: Systematic Computation of Optimized System Architectures, Reliability Analysis and Diagnostics. 2005. [125] Russell, S.; Norvig, P.: Künstliche Intelligenz Ein moderner Ansatz 2. Auflage, München, 2004. [126] Reiter, R.: A Theory of Diagnosis from First Principles, in: Artificial Intelligence, 32/1. 1987. [127] Sachenbacher, M.; Struss, P. and Carlén, Claes M.: A prototype for modelbased on-board diagnosis of automotive systems. AI Communications,2000. [128] Steffen, B.; Levi, G.: Verification, Model Checking, and Abstract Interpretation. Springer (1 edition), 2004. [129] Sokenou D.: UML-basierter Klassen- und Integrationstest objektorientierter Programme. Dissertation, TU-Berlin, 2006. [130] Struss, P., Dressler, O.: Physical Negation - Integrating Fault Models into the General Diagnostic Engine, in: Proc. Intl. Joint Conf. On Artificial Intelligence. Detroit, 1989. [131] Struss, P.: Structuring of models and reasoning about quantities in qualitative physics Dissertation, Universität Kaiserslautern, Fachbereich Imformatik, 1989. [132] Struss, P.: Diagnosis as a Process, in: Readings in Modelbased Diagnosis. (Hrsg. Hamscher, W., Console, L., De Kleer, J.), San Francisco, 1992.

202

LITERATURVERZEICHNIS

[133] Struss, P.: What’s in SD? Towards a Theory of Modeling in Diagnosis, in: Readings in Modelbased Diagnosis (Hrsg. Hamscher, W.; Console, L.; De Kleer, J.), San Francisco, 1992. [134] Struss, P: Modellbasierte Werkzeuge für Diagnose und Fehleranalyse von Fahrzeugsubsystemen in: INDIA - Intelligente Diagnose in der Anwendung/Intelligent Diagnosis for Industrial Applications. (Hrsg. Holtz, l., Struss, P., Guckenbiehl, Th.), Aachen, 2000. [135] Struss, P.; Price, Ch.: Model-Based Systems in the Automotive Industry, in: AI Magazine. 2003. [136] Struss, P.: Modellbasierte Systeme und qualitative Modellierung, in: Handbuch der Künstlichen Intelligenz (Hrsg. Görz G., Rollinger C.-R., Schneeberger J.), OldenbourgVerlag 2003. [137] Struss, P.: Qualitative Modeling for Diagnosis of Machines Transporting Rigid Objects. in The 19th International Workshop on Principles of Diagnosis, Blue Mountains, Australia 2008. [138] Sohnle, S.; Dang Duc, N.; Opfermann, A.: Modellierungsworkshop: Überprüfung der Machbarkeit der Modellerstellung und Abschätzung des Erstellungsaufwands in: interne Bosch-Berichte. 2008. [139] Stahl, T.; Völter, M.; Efftinge, S.; Haase, A.: Modellgetriebene Softwareentwicklung: Techniken, Engineering, Management.Dpunkt Verlag; Auflage: 2., 2007. [140] Zenner, C. : Durchgängiges Variantenmanagement in der Technischen Produktionsplanung. Universität des Saarlandes Schriftenreihe Produktionstechnik Herausgeber: H. Bley und C. Weber, Band 37, 2006 [141] Teltow, G.: Modell- und Distributionsstrategien in der Automobilindustrie: Variantenvielfalt und Verfügbarkeit. Verlag: Diplomica Verlag GmbH, 1999. [142] Taentzer, G: LNCS: A Graph Transformation Environment for Modeling and Validation of Software, Lecture Notes in Computer Science . Charlottesville, 2003. [143] Thole, M.: Qualitative Analyse analoger Schaltungen Dissertation, Technische Universität Carolo-Wilhelnima Braunschweig, Falkutät für Maschinenbau und Elektronik, 1998. [144] Tröltzsch, U.: Modellbasierte Zustandsdiagnose von Gerätebatterien. Universität der Bundeswehr München, Fakultät für Elektrotechnik und Informationstechnik, 2005. [145] VDI-RICHTLINIEN: Einsatz wissensbasierter Diagnosemethoden und -systeme in der Instandhaltung VDI-Handbuch Betriebstechnik (VDI 2889). Teil 4, Düsseldorf, 1998. [146] VDI-RICHTLINIEN: Zustandsorientierte Instandhaltung (VDI 2888).VDI-Handbuch Betriebstechnik, Teil 4, Düsseldorf; 1999. [147] Westphal, F.: Testgetriebene Entwicklung mit JUnit und FIT. Dpunkt Verlag (1. Auflage), 2005. [148] Waleschkowski, N.: Wissensmodellierung und Wissenserwerb am Beispiel der Fahrzeugdiagnose. KI - Zeitschrift Künstliche Intelligenz, 1995.

LITERATURVERZEICHNIS

203

[149] Waleschkowski, N.: WDS - A Knowledge Based Diagnostic System. Technical Paper, Oberursel 2004. [150] Waleschkowski, N.: Lernfähige wissensbasierte Diagnosesysteme. Diagnose in mechatronischen Fahrzeugsystemen IV: Neue Verfahren für Test, Prüfung und Diagnose von E/E-Systemen im Kfz von Bernard Bäker und Andreas Unger. Expert-Verlag, 2011. [151] Wambera, T.; Engel, P.; Dang Duc, N.: Unterschiede zwischen existierenden Autorensysteme und DMB-System in: interne Bosch-Berichte CR/AEM-AEH. 2007. [152] Weber, R.: Intelligente Diagnose bei mechatronischen Systemen im Kraftfahrzeug, in: Intelligente Diagnose in der industriellen Anwendung. Shaker 2000. [153] Zeppenfeld, K.; Wolters, R. .: Generative Software-Entwicklung mit der Model Driven Architecture. Spektrum Akademischer Verlag; Auflage: 1, 2005.

Abbildungsverzeichnis 1.1

Verfahren und Strategien für neue Prüftechniksysteme . . . . . . . . . . . . .

2

1.2

Teilmodell des Kraftstoffsystems . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.3

Grober Aufbau des Diagnosemodells . . . . . . . . . . . . . . . . . . . . . . .

6

1.4

Entwickelte Modellierungsapplikation (DMB-System) . . . . . . . . . . . . . .

16

1.5

Verhaltenseditor von DMB-System . . . . . . . . . . . . . . . . . . . . . . . .

18

1.6

Auswahl des Modells mit DRT-System . . . . . . . . . . . . . . . . . . . . . .

19

1.7

Entwickeltes DRT-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

1.8

Maske zur Darstellung der Handlungsempfehlung . . . . . . . . . . . . . . . .

21

2.1

Prozess der Strategie „Hypothesenerstellung und Hypothesenprüfung“ . . . . .

35

2.2

Architektur des Expertensystems aus funktionaler Sicht . . . . . . . . . . . .

36

2.3

Wissenserhebung für die Kfz-Werkstattdiagnose . . . . . . . . . . . . . . . . .

37

2.4

Diagnose- und Reparaturprozess in der Kfz-Werkstatt . . . . . . . . . . . . .

39

3.1

Kennlinien der Elektrokraftstoffpumpe beim Golf III 1.8 (Quelle: BOSCH Group) 44

3.2

Bestandteile des Basis- und des vollständigen Diagnosemodells . . . . . . . . .

47

3.3

Klassendiagramm einer systemeigenen Komponente . . . . . . . . . . . . . . .

54

3.4

Beispiel einer qualitativen Übergangsfunktion . . . . . . . . . . . . . . . . . .

59

3.5

Modelldarstellung einer Kraftstoffleitung . . . . . . . . . . . . . . . . . . . . .

60

3.6

Objektdiagramm eines Einspritzventils . . . . . . . . . . . . . . . . . . . . . .

64

3.7

Beispielhafte Visualisierung eines Systemsensors . . . . . . . . . . . . . . . . .

66

3.8

Beispielhaftes Objektdiagramm eines Drucksensors . . . . . . . . . . . . . . .

66

3.9

Beispielhafte Visualisierung einer Messung . . . . . . . . . . . . . . . . . . . .

67

3.10 Beispielhaftes Objektdiagramm einer manuellen Messung . . . . . . . . . . . .

68

3.11 Beispielhafte Notation eines Fehlercodes als virtueller Sensor . . . . . . . . . .

70

3.12 Beispielhafte Notation eines Fehlercodes als Diagnoseregel . . . . . . . . . . .

71

3.13 Beispielhaftes Objektdiagramm einiger Fehlercodes . . . . . . . . . . . . . . .

72

3.14 Beispielnotation einer Kundenbeanstandung im Lichtsystem . . . . . . . . . .

74

3.15 Kundenbeanstandung als Diagnoseregel . . . . . . . . . . . . . . . . . . . . .

76

204

ABBILDUNGSVERZEICHNIS

205

3.16 Beispielhaftes Objektdiagramm einer Kundenbeanstandung . . . . . . . . . .

77

3.17 Beispielnotation eines Stellgliedtests im Modell des Lichtsystems . . . . . . .

78

3.18 Beispielhaftes Objektdiagramm eines Stellgliedtests im Modell des Lichtsystems 79 3.19 Beispielnotation eines Komponententests im Modell des Kraftstoffsystems . .

80

3.20 Beispielhaftes Objektdiagramm eines Komponententests im Modell des Lichtsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

3.21 Beispielhaftes Objektdiagramm der Systemschnittstellen und Verbindungen .

82

3.22 Vollständige Modelle als Instanzen des physikalischen Modells am Beispiel des Luftsystems-ME7.6.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

3.23 Generalisierung der Varianten am Beispiel der Luftlader . . . . . . . . . . . .

86

3.24 Vererbung der Schnittstelle sowie der internen Variable am Beispiel des Kraftstoffrohrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

3.25 Modelltransformation am Beispiel eines Teils des Luftsystems mit Lader . . .

87

3.26 Modellerweiterung am Beispiel eines Teils des Lichtsystems . . . . . . . . . .

88

3.27 Verschiedene Testarten des erstellten Diagnosemodells . . . . . . . . . . . . .

91

4.1

Diagnostik-Algorithmus D . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

4.2

Modell des Luftsystems ME7.6.x mit Fehlercode und Kundenbeanstandung für das erste Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.3

Modell des Luftsystems ME7.6.x mit Kundenbeanstandung für das zweite Beispiel117

4.4

Auslesen der Fehlercodes mittels Steuergerät . . . . . . . . . . . . . . . . . . . 125

4.5

Ermittlung der verdächtigen Komponenten mittels Kundenbeanstandung . . . 126

4.6

Ergebnisse des Stellgliedtests . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

4.7

Auslesen der Sensor-Istwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

4.8

Istzustand der Einbaulage der Komponente Gestänge Achssensor hinten . . . 128

4.9

Komponentenbezogenes Diagnosewissen . . . . . . . . . . . . . . . . . . . . . 129

5.1

Die sechs Phasen bei der Modellierung eines Systems . . . . . . . . . . . . . . 131

5.2

Erste Phase: Struktur- und Verhaltensmodellierung . . . . . . . . . . . . . . . 132

5.3

Detaillierte Aktivitäten zur Erstellung des Struktur- und Verhaltensmodells . 133

5.4

Zweite Phase: Modellierung der Kundenbeanstandungen . . . . . . . . . . . . 134

5.5

Dritte Phase: Fehlercodes in das Modell integrieren . . . . . . . . . . . . . . . 135

5.6

Vierte Phase: Abbildung der externen Messungen . . . . . . . . . . . . . . . . 136

5.7

Fünfte Phase: Komponenten- und Stellgliedtests anbinden . . . . . . . . . . . 136

5.8

Rollen der Beteiligten bei der Modellerstellung . . . . . . . . . . . . . . . . . 138

5.9

DMB-System und seine Umgebung . . . . . . . . . . . . . . . . . . . . . . . . 139

206

ABBILDUNGSVERZEICHNIS

5.10 Dekomposition von DMB-System in Segmente . . . . . . . . . . . . . . . . . . 140 5.11 Ergebnisse der Reduktion des Speicherbedarfs . . . . . . . . . . . . . . . . . . 142 5.12 Testplattform und Testrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 5.13 Ergebnisse des Komponententests . . . . . . . . . . . . . . . . . . . . . . . . . 144 5.14 Maske zur Spezifizierung der Modelltestfälle . . . . . . . . . . . . . . . . . . . 145 5.15 Maske zur Darstellung der Modelltestergebnisse . . . . . . . . . . . . . . . . . 145 5.16 Variantenmanagement-Modul in DMB-System . . . . . . . . . . . . . . . . . . 146 5.17 Berechnung der Distanz zwischen Modellen . . . . . . . . . . . . . . . . . . . 147 6.1

Die drei Hauptschritte im Werkstattdiagnoseprozess . . . . . . . . . . . . . . 148

6.2

Aktivitäten bei der Fahrzeugannahme . . . . . . . . . . . . . . . . . . . . . . 149

6.3

Aktivitäten bei der Diagnosedurchführung und Reparatur . . . . . . . . . . . 150

6.4

DRT-System und seine Umgebung . . . . . . . . . . . . . . . . . . . . . . . . 152

6.5

Dekomposition von DRT-System in Segmente . . . . . . . . . . . . . . . . . . 153

6.6

Dekomposition des Segments „Model Explorer“ in Pakete . . . . . . . . . . . . 154

6.7

Beispiel: Instruktion zum Auslesen eines Systemsensor-Istwertes . . . . . . . . 157

6.8

Beispiel: Instruktion einer Komponentenprüfung . . . . . . . . . . . . . . . . . 158

6.9

Szenario für den Totalumstieg . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

6.10 Szenario für den Parallelbetrieb . . . . . . . . . . . . . . . . . . . . . . . . . . 160 6.11 Integration mit dem Konvertierungsansatz . . . . . . . . . . . . . . . . . . . . 160 6.12 Integration mit dem Plug-in-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . 161 6.13 Integration mit der Entwicklung eines neuen Diagnosetools . . . . . . . . . . . 161 7.1

Ergebnisse der Prüfschritte bei der Evaluierung . . . . . . . . . . . . . . . . . 175

7.2

Ergebnisse der Prüfzeit bei der Evaluierung . . . . . . . . . . . . . . . . . . . 176

7.3

Szenario des zweiten Feldtests . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

7.4

Diagnoseablauf bei dem zweiten Feldtest . . . . . . . . . . . . . . . . . . . . . 179

7.5

Beispiel eines Versuchprotokolls bei der zweiten Evaluierung . . . . . . . . . . 180

7.6

Feldtestergebnisse zur Auswertung der Diagnosefähigkeit . . . . . . . . . . . . 181

7.7

Feldtestergebnisse zur Überprüfung der vorgeschlagenen Prüfschritte . . . . . 182

7.8

Feldtestergebnisse zur Auswertung der Effektivität des entwickelten Ansatzes

7.9

Feldtestergebnisse zur Überprüfung des Nutzens und der Akzeptanz des entwickelten Ansatzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

8.1

Prototypische Umsetzung der Generierungsverhaltenstabelle mittels Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

183

ABBILDUNGSVERZEICHNIS

207

8.2

Prototypische Umsetzung der Generierungsverhaltenstabelle mittels SimulinkModell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

8.3

Parallele Entwicklung der Systemkomplexität im Automotive- und Thermotechnikbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

8.4

Einsatzmöglichkeit des entwickelten Ansatzes bei der Onboard-Diagnose . . . 192

Tabellenverzeichnis 1.1

Beispiel für Aufbau einer Verhaltenstabelle . . . . . . . . . . . . . . . . . . . .

7

1.2

Ein Abschnitt der Verhaltenstabelle des Rohres . . . . . . . . . . . . . . . . .

11

1.3

Ein Abschnitt der reduzierten Verhaltenstabelle mit Leckage = N des Rohres 12

1.4

Ein Abschnitt der reduzierten Verhaltenstabelle mit Leckage = N des Druckregelventils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Weitere Reduzierung der Verhaltenstabelle durch Wertebelegung der Ausgangsqual schnittstelle des Rohres (Rohr.S1 .Kraf tstof f.V˙ = L) . . . . . . . . . . . .

14

1.5 1.6

qual

qual

der Verhaltenstabelle des DruckreRückwärtspropagierung (Diagnoseparameter qual ˙ Druckregelventil.S5 .Kraf tstof f.V = L) . . . . . . . . . . . . . . . . . . .

14

Relationen des Volumenstroms (V˙ ) in der reduzierten Verhaltenstabelle des Druckregelventils bei Vorwärtspropagierung (Diagnoseparameter qual Druckregelventil.S0 .Kraf tstof f.V˙ = N ) . . . . . . . . . . . . . . . . . . .

15

3.1

Verschiedene reale Komponentenarten im Kraftstoffsystem . . . . . . . . . . .

53

3.2

Systemeigene Komponenten und deren Schnittstellen . . . . . . . . . . . . . .

55

3.3

Einige Transportobjekte und einige ihrer Attribute . . . . . . . . . . . . . . .

55

3.4

Rechenbeispiel für qualitative Addition und Subtraktion . . . . . . . . . . . .

59

3.5

Aufbau einer Verhaltenstabelle . . . . . . . . . . . . . . . . . . . . . . . . . .

61

3.6

Aufbau einer Beeinflussungsgradtabelle . . . . . . . . . . . . . . . . . . . . . .

63

3.7

Beispiel Inhalts einer Beobachtungstabelle . . . . . . . . . . . . . . . . . . . .

75

3.8

Testurteil für die nicht verdächtige Menge COMjOK = COMjOK,soll ∩ COMjOK,ist 95

3.9

Testurteil für die verdächtige Menge COMj¬OK = COMj¬OK,soll ∩ COMj¬OK,ist 95

4.1

Darstellung der Menge COM DT C,¬OK in Tabellenform . . . . . . . . . . . . . 100

4.2

Darstellung der PARAMOBS in Tabellenform . . . . . . . . . . . . . . . . . . 101

4.3

Darstellung der P ARAM DT C in Tabellenform . . . . . . . . . . . . . . . . . . 101

4.4

Darstellung der P ARAM SEN in Tabellenform . . . . . . . . . . . . . . . . . . 102

4.5

Darstellung der P ARAM M EAS in Tabellenform . . . . . . . . . . . . . . . . . 102

4.6

Darstellung der P ARAM ComT EST in Tabellenform . . . . . . . . . . . . . . . 102

4.7

Darstellung der P ARAM ActT EST in Tabellenform . . . . . . . . . . . . . . . 103

1.7

Weitere gelventils

Reduzierung durch

208

209

TABELLENVERZEICHNIS 4.8

Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabx einer Komponente comx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.9

i,x Beispiel eines Abschnitts der reduzierten Verhaltenstabelle tabx einer Komponente comx mit dem Diagnoseparameter parami,x . . . . . . . . . . . 105

param

4.10 Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabpre x einer Kompre ponente comx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.11 Beispiel eines Abschnitts der reduzierten Verhaltenstabelle mit den Diagnosepre pre parametern parampre . . . . . . . 106 i,x,j und parami,x,j+k der Komponente comx 4.12 Beispiel eines Abschnitts der vollständigen Verhaltenstabelle tabpost einer Komx ponente compost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 x 4.13 Beispiel eines Abschnitts der reduzierten Verhaltenstabelle mit den Diagnosepost post parametern parampost . . . . . . . 107 i,x,j und parami,x,j+k der Komponente comx 4.14 Darstellung der Menge COM DT C,¬OK = {T emperatursensor} des Fehlercodes P0112 in Tabellenform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.15 Darstellung der Sichtprüfung „Keine Leckage“ in Tabellenform . . . . . . . . . 116 4.16 Darstellung der Kundenbeanstandung „Schlechte Gasannahme, Übergangsfehler“ in Tabellenform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.17 Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente Drallklappe1 mit Drallklappe1 .leckage = N . . . . . . . . . . . . . . . . . . 118 4.18 Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente ˙ Drallklappe1 mit Drallklappe1 .leckage = N und Drallklappe1 .S1out .Luf t.m = L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 4.19 Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente Drosselklappe mit Drosselklappe.klemmt = N und Drosselklappe.schwergaengig = T . . . . . . . . . . . . . . . . . . . . . . . . 120 4.20 Beispiel eines Abschnitts der reduzierten Verhaltenstabelle der Komponente Gestänge Einlasskanalabschaltung . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.1

Ergebnisse der Reduktion des Speicherbedarfs . . . . . . . . . . . . . . . . . . 143

6.1

Ablauf eines Diagnoseversuchs an einem ME7.6-Benzinsystem mit DRT-System 156

6.2

Ablauf eines Diagnoseversuchs an einem CP3-Dieselsystem mit DRT-System . 156

7.1

Aufwandserhebung bei der Erstellung des CP3-Diesel-Systems . . . . . . . . . 165

7.2

Aufwandserhebung bei der Erstellung des ME7.6-Benzin-Systems . . . . . . . 165

7.3

Aufwandserhebung des CP3-Diesel-Systems bei Leit- und Folgeprojekt . . . . 166

7.4

Aufwandserhebung der Leitprojekte im Vergleich . . . . . . . . . . . . . . . . 167

7.5

Aufwandserhebung des ALWR1.0-Systems bei Leitprojekten . . . . . . . . . . 168

7.6

Aufwandserhebung des ALWR1.0-Systems bei Leitprojekten . . . . . . . . . . 168

7.7

Protokoll des Versuchs mit DRT-System für den ME7.x-Ottomotor . . . . . . 173

210

TABELLENVERZEICHNIS

7.8

Protokoll des Versuchs mit einem existierenden Diagnosesystem für den ME7.xOttomotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

7.9

Zusammenfassung der ersten Evaluierungsergebnisse . . . . . . . . . . . . . . 174

7.10 Liste der abgedeckten Fahrzeuge . . . . . . . . . . . . . . . . . . . . . . . . . 178