DE102012100390A1

DE102012100390A1 - Entwickeln eines Fehlermodells aus Servicebeschreibungen

Info

Publication number: DE102012100390A1
Application number: DE102012100390A
Authority: DE
Inventors: Satnam Singh
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2011-03-10
Filing date: 2012-01-18
Publication date: 2012-09-13
Also published as: CN102708134B; CN102708134A; US20120232743A1; US8527441B2

Abstract

Ein Verfahren und ein System zum Entwickeln von Fehlermodellen von strukturierten Textdokumenten wie Servicebeschreibungen. Eine Servicebeschreibung oder ein anderes strukturiertes Textdokument wird unter Verwendung diagnostischer Regeln zergliedert, um Symptome, Ausfallmoden und Korrelationen zu extrahieren. Testbeschreibungen und Reparaturinstruktionen werden zudem zergliedert, um einen Fehlerbaum und ein Identifizieren zusätzlicher Symptome und Ausfallmoden zu erzeugen. Eine Erreichbarkeitsanalyse wird dann verwendet, um verborgene Abhängigkeiten in dem Fehlerbaum zu finden, und somit zusätzliche Korrelationen zu gewinnen. Die sich ergebenden Symptome, Ausfallmoden und Korrelationen werden dann in einem Fehlermodell zusammengeführt, die für eine Echtzeitfehlerdiagnose innerhalb eines Fahrzeugs oder außerhalb für Diagnosen in Servicebetrieben verwendet werden können.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Diese Erfindung bezieht sich im allgemeinen auf ein Verfahren und ein System zum Entwickeln von Fehlermodellen und insbesondere auf ein Verfahren und ein System zum Entwickeln von Fehlermodellen aus strukturierten Textdokumentquellen, wie Servicebeschreibungen, welche Symptome, Ausfallmoden, reparierbare Teile und Korrelationen unter ihnen aus diagnostischen Fehlerinformationen in dem Dokument extrahieren, und Testbeschreibungen zergliedern, um weitere Fehlermodelldaten zu bestimmen, Erreichbarkeitsanalysen zum Auffinden versteckter Abhängigkeiten verwenden und alle diese extrahierten Daten in ein sich ergebendes Fehlermodell zusammenzufügen.
2. Erörterung des Standes der Technik
Moderne Fahrzeuge sind komplexe elektromechanische Systeme, die viele Untersysteme, Komponenten, Bauteile und Module einsetzen, welche Bearbeitungsinformationen zwischen- und untereinander unter Verwendung von hoch entwickelten Algorithmen und Databussen austauschen. Wie alle Dinge sind diese Arten von Geräteteilen und Algorithmen für Irrtümer und Fehler, die den Betrieb des Fahrzeugs beeinflussen können, anfällig. Um ein Managen dieser Komplexität zu unterstützen, entwickeln die Fahrzeughersteller Fehlermodelle, welche die unterschiedlichen Ausfallmoden den Symptomen, die das Fahrzeug zeigt, zuordnen.
Fahrzeughersteller entwickeln gewöhnlich Fehlermodelle aus einer Vielfalt unterschiedlicher Datenquellen. Diese Datenquellen schließen technische Daten, Servicebeschreibungsdokumente, mündliche Beschreibungen von Kunden und Reparaturtechnikern, Garantiedaten und andere ein. Während all diese Fehlermodelle nützliche Werkzeuge für ein Diagnostizieren und Reparieren von Problemen sein können, kann die Entwicklung der Fehlermodelle zeitaufwändig, arbeitsintensiv und in einigen Fällen etwas subjektiv sein. Zusätzlich können manuell erzeugte Fehlermodelle nicht konsistent alle Ausfallmoden, Symptome und Korrelationen erfassen, die in den Fahrzeugsystemen existieren. Ferner liegen eine Fülle von Fehlermodelldaten in alten Servicedokumenten vor, die häufig nur teilweise extrahiert werden oder sie werden alle zusammen übersehen wegen der Schwierigkeit und der fehlerempfänglichen Natur der manuell übersetzten Texte in Bezug auf Ausfallmoden, Symptome, reparierbare Teile und Korrelationsdaten.
Es gibt einen Bedarf für ein Verfahren zur Fehlermodellentwicklung aus unterschiedlichen Arten strukturierter Textdatenquellen. Ein derartiges Verfahren kann nicht nur den Bedarf an Zeit und Anstrengungen, die erforderlich sind, um Fehlermodelle zu erzeugen, reduzieren, sondern kann auch Fehlermodelle mit mehr und besserem Inhalt erzeugen, und führt somit zu einem genaueren Ausfalldiagnosemodus im Feld, verminderten Reparaturzeiten und -kosten, verbesserten ersten Montagezeitraten und verbesserter Kundenzufriedenheit.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß der Lehren der vorliegenden Erfindung werden ein Verfahren und ein System für ein Fehlermodellentwickeln aus strukturierten Textdokumenten offenbart, wie Servicebeschreibungen. Eine Servicebeschreibung oder andere strukturierte Textdokumente werden unter Verwendung von Diagnoseregeln zergliedert, um Symptome, Ausfallmoden, reparierbare Teile und Korrelationen unter ihnen zu extrahieren. Testbeschreibungen und Reparaturinstruktionen werden auch zergliedert, um einen Fehlerbaum zu erzeugen und zusätzliche Symptome und Ausfallmoden zu identifizieren. Eine Erreichbarkeitsanalyse wird dann verwendet, um versteckte Abhängigkeiten in dem Fehlerbaum zu finden, um somit zusätzliche Korrelationen unter Fehlern und Symptomen hervorzubringen. Die sich ergebenden Symptome, Ausfallmoden, reparierbaren Teile und Korrelationen werden dann zu einem Fehlermodell zusammengefügt, das für Echtzeit-Fehlerdiagnosen innerhalb eines Fahrzeugs oder für Diagnosen außerhalb in Servicebetrieben verwendet wird.
Zusätzliche Merkmale der vorliegenden Erfindung werden durch die nachfolgende Beschreibung und die anhängenden Ansprüche in Zusammenhang mit den begleitenden Figuren verständlich.
KURZE BESCHREIBUNG DER FIGUREN
1 ist ein schematisches Diagramm eines Systems, das strukturierte Textdokumente aufnimmt, sie automatisch unter Verwendung eines geeigneten Prozesses, um ein Fehlermodell zu erzeugen, zergliedert, und welches das sich ergebende Fehlermodell sowohl in Systemen innerhalb als auch außerhalb eines Fahrzeugs verwendet;
2 ist ein Flussdiagramm eines Verfahrens, das verwendet werden kann, um Fehlermodelle von strukturierten Textdokumenten wie Servicebeschreibungen zu entwickeln; und
3 ist ein Diagramm, das zeigt, wie ein Diagnosebaum, der aus einem Servicebeschreibungsdokument erzeugt ist, verwendet werden kann, um versteckte Abhängigkeiten in einem Fehlermodell über Erreichbarkeitsanalysen zu finden.
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Die nachfolgende Erörterung der Ausführungsformen der Erfindung, die auf ein Verfahren und ein System für ein Fehlermodellentwickeln von strukturierten Textdokumenten gerichtet ist, ist nur von beispielhafter Natur und es ist in keiner Weise beabsichtigt, die Erfindung oder ihre Anwendungen oder Verwendungen zu beschränken. Zum Beispiel weist die vorliegende Erfindung insbesondere eine Anwendung für eine Fahrzeugfehlerdiagnose auf. Die Erfindung ist jedoch genauso anwendbar auf Fehlerdiagnosen in anderen Industrien, wie in der Luftfahrt, und für schwere Ausrüstungsgüter und auf Fehlerdiagnosen in jedem mechanischen, elektrischen oder elektromechanischen System, in denen Fehlerdiagnosen verwendet werden.
Fehlermodelle wurden lange Zeit durch Hersteller von Fahrzeugen und anderen Systemen verwendet, um die Korrelation zwischen Ausfallmoden, reparierbaren Teilen und assoziierten Symptomen zu dokumentieren und zu verstehen. Die Ausfallmoden-, Teile- und Symptomdaten, welche die Basis eines Fehlermodells bilden, können in einer Vielfalt von Dokumenten gefunden werden, einschließlich von Textdokumenten. Da jedoch Textdokumente schwierig und zeitraubend sein können, um einen Fehlermodellinhalt zu untersuchen, wurden viele Arten der Textdokumente traditionell nicht verwendet, um Fehlermodelle, insbesondere für bestimmte Fahrzeuge und Systeme, zu entwickeln, und somit haben Hersteller keinen Vorteil von all den Daten, die in den Textdokumenten enthalten sind, gewonnen. Die vorliegende Erfindung stellt durch Vorschlagen eines Verfahrens und eines Systems zur automatischen Fehlermodellentwicklung von strukturierten Textdokumenten eine Lösung des Problems bereit. Ein Fehlermodell, das in dieser Weise entwickelt ist, kann direkt als Fehlerdiagnosewerkzeug verwendet werden, oder es kann als eine Grundlage für eine schnelle Entwicklung eines hochgenauen technischen Fehlermodells verwendet werden.
1 ist ein schematisches Diagramm eines Systems 10, das ein strukturiertes Textdokument als Eingabe verwendet, Textverarbeitungsregeln, Analysetechniken und andere Arten von Analysen anwendet, um ein Fehlermodell zu erzeugen, und welches das sich ergebende Fehlermodell für Diagnosezwecke, sowohl innerhalb eines Fahrzeugs als auch außerhalb eines Fahrzeugs verwendet. Das System 10 wird unter Verwendung eines Servicebeschreibungsdokuments 12 als Eingabe verwendet. Andere Arten von strukturierten Textdokumenten können auch verwendet werden, aber es reicht die Erörterung des Dokumentes 12 aus, um das Konzept der betroffenen Fehlermodellentwicklung zu erklären. Das Servicebeschreibungsdokument 12 kann Diagnose-Fehlerinformations-Tabellen, Schaltungs- und Systemtestbeschreibungen, Scanwerkzeugtabellen und Reparaturinstruktionen zusammen mit vielen anderen Arten von Servicebeschreibungen enthalten.
Ein strukturiertes Textanalysemodul 18 kann das Servicebeschreibungsdokument 12 empfangen und mehrere Überprüfungs- und Analyseschritte durchführen, wie sie unten beschrieben werden, um ein Fehlermodell 22 zu erzeugen. Das Fehlermodell 22 enthält eine Darstellung der Ausfallmoden und Symptome, die im Dokument 12 beschrieben sind. Als eine digitale Datenbasis kann das Fehlermodell 22 in einen Prozessor innerhalb eines Fahrzeugs 24 für eine Echtzeit-Systemüberwachung geladen werden oder in einem Diagnosewerkzeug 26 eines Servicebetriebes verwendet werden. In Form einer Datenbasis kann das Fehlermodell 22 auch in einem Ferndiagnosezentrum für eine Echtzeit-Problemsuche von Fahrzeugproblemen verwendet werden. Zum Beispiel können fahrzeugsymptomatische Daten und Kundenbeschwerden über ein telematisches System zu dem entfernten Diagnosezentrum gesendet werden, wo ein Diagnosebeurteiler eine Diagnose unter Verwendung des Fehlermodells 22 durchführen kann. Dann kann ein Kundenberater den Fahrer des Fahrzeugs 24 über die geeignetste Vorgehensweise beraten. In Form eines druckbaren Dokuments kann das Fehlermodell 22 durch einen Techniker, der einen Fahrzeugservice durchführt, gelesen oder durch Fahrzeugentwicklungspersonal 28 verwendet werden, um verbesserte Servicebeschreibungsdokumente und neue Fahrzeuge und Systementwicklungen zu erzeugen.
Eine einfache Darstellung des Fehlermodells 22 ist eine zweidimensionale Matrix, die Ausfallmoden als Zeilen und Symptome als Spalten und einen Korrelationswert in einem Schnittpunkt von jeder Zeile und jeder Spalte aufweist. Teilebestimmungsdaten sind typischerweise in den Ausfallmoden enthalten. Der Korrelationswert, der an der Schnittstelle einer Zeile und einer Spalte enthalten ist, ist üblicherweise als Ursachenwichtung bekannt. In dem einfachsten Fall haben die Ursachenwichtungen einen Wert entweder als 0 oder 1, wobei eine 0 keine Korrelation zwischen einem besonderen Ausfallmodus und einem besonderen Symptom anzeigt, und eine 1 eine direkte Korrelation zwischen einem besonderen Ausfallmodus und einem besonderen Symptom anzeigt. Jedoch können auch Ursachen-Wichtungswerte zwischen 0 und 1 verwendet werden, um die Größe der Stärke der Korrelation zwischen einem besonderen Ausfallmodus und einem besonderen Symptom anzuzeigen. Die Ursachen-Wichtungswerte von 0 und 1 werden oft als harte Ursachen oder Korrelationen bezeichnet, während Ursachen-Wichtungswerte zwischen 0 und 1 oft als weiche Korrelationen beschrieben werden. Wo mehr als ein Ausfallmodus mit einem bestimmten Symptom oder mit einem Satz von Symptomen assoziiert ist, ist dieses als eine mehrdeutige Gruppe bekannt.
In einer vollständigeren Form kann das Fehlermodell 22 zusätzliche Matrixdimensionen aufweisen, die Informationen wie Signale und Tätigkeiten enthalten, die sich auf Ausfallmoden und Symptome beziehen. Zur Klarheit wird jedoch die textdokumentbasierende Fehlermodell-Entwicklungsmethodik in Begriffen der zwei primären Matrixdimensionen beschrieben, nämlich den Ausfallmoden und Symptomen mit reparierbaren Teileinformationen, die als geeignet enthalten sind.
2 zeigt ein Flussdiagramm 30 eines Verfahrens, das in dem strukturierten Textanalysemodul 18 verwendet werden kann, um das Fehlermodell 22 aus dem Servicebeschreibungsdokument 12 zu erzeugen. In der Box 32 wird das Servicebeschreibungsdokument 12 zur Verfügung gestellt und Informationen über die Quelle des Dokumentes werden aufgezeichnet. Zum Beispiel kann das eine Subjekt eines Beispiels des Servicebeschreibungsdokuments 12 ein besonderer Motor sein, während ein anderes Beispiel des Servicebeschreibungsdokuments 12 sich mit einer Frontaufhängung befasst. Das Servicebeschreibungsdokument 12 muss ein maschinenlesbares Dokument sein, wie beispielsweise ein standardgeneralisiertes mit Zeichen versehenes Sprachdokument (SGML – standard generalized markup language) oder ein erweiterbares mit Zeichen versehenes Sprachdokument (XML – extensible markup language).
In der Box 34 wird ein Satz von diagnostischen Regeln zum Extrahieren der Fehlermodelldaten von der diagnostischen Fehlerinformation, die in dem Servicebeschreibungsdokument 12 enthalten sind, verwendet. Das Servicebeschreibungsdokument 12 enthält normalerweise diagnostische Fehlerinformationen in der Form einer Tabelle, die zeigt, welche Bedingungen existieren können, wenn ein besonderer Diagnoseproblemcode erfasst wird. Ein Diagnoseproblemcode (DTC – diagnostic trouble code) ist ein Fehlercode, der durch ein Steuergerät innerhalb eines Fahrzeugs erfasst wird, wenn ein Parameter oder eine Kombination von Parametern, die außerhalb ihres normalen Bereichs liegen, detektiert wird. Zum Beispiel kann eine diagnostische Fehlerinformationstabelle in dem Servicebeschreibungsdokument 12 Zeilen einschließen, die unterschiedliche Schaltungen aufweisen, wie eine Drucksensorsignalleitung und eine Drucksensor-5 Volt-Referenzleitung. Die gleiche diagnostische Fehlerinformationstabelle kann eine Spalte aufweisen, die unterschiedliche Ausfallmoden für die Schaltungen aufweist, wie einen Massekurzschluss und eine offene Schaltung. Die Kombination einer Zeile und einer Spalte repräsentiert einen vollständigen Ausfallmodus, wie eine Drucksensorsignalleitung mit Massekurzschluss. In der Schnittstelle der Zeile und Spalte sind eine oder mehrere DTCs, falls anwendbar, vorhanden, die das Symptom bzw. die Symptome, das bzw. die mit dem Ausfallmodus assoziiert ist bzw. sind, repräsentieren. Eine Schnittstelle einer Zeile und Spalte kann auch eine Beschreibung eines Nicht-DTC-Symptoms aufweisen, wie unten diskutiert wird. Somit wird eine Korrelation zwischen einem Ausfallmodus und einem oder mehreren Symptomen herangezogen, basierend auf diagnostischen Fehlerinformationen, die in dem Servicebeschreibungsdokument 12 enthalten sind.
Die Diagnoseregeln, die in Box 34 verwendet werden, können relativ einfach sein, zum Beispiel können sie anzeigen, dass eine Ursachenwichtung von 1 festgestellt ist, wo ein Symptom mit einem Ausfallmodus korreliert. Komplexere Diagnoseregeln können auch festlegen, wie eine Situation zu handhaben ist, bei der mehr als ein einzelnes DTC-Symptom in einer Schnittstelle von einer Zeile und einer Spalte existiert. Diese Fehlermodell-Extraktion wird in Box 34 für alle Kombinationen der Symptome und der Ausfallmoden durchgeführt, bei denen die Diagnosefehler-Informationen eine Korrelation anzeigen. Die Diagnoseregeln, die in Box 34 angewendet werden, können auch verwendet werden, um mechanische Fehler und Symptome zu erfassen, falls diese Daten in einer strukturierten Tabelle zur Verfügung stehen, wie in einer Diagnosefehler-Informationstabelle, wie sie oben beschrieben wird. Ein Beispiel eines mechanischen Ausfallmodus ist ”Bremsrotor ist verzogen” und ein assoziiertes Symptom ist ein ”Pulsieren während des Bremsens”. Obgleich mechanische Fehler nicht oft ein DTC-Symptom triggern, können die Fehler und Nicht-DTC-Symptome in einer strukturierten Tabelle enthalten sein, und somit können sie für das Fehlermodell 22 durch die Diagnoseregeln der Box 34 erfasst sein.
In der Box 36 wird ein Satz von Diagnoseregeln verwendet, um Fehlermodelldaten von Scanwerkzeugtabellen, die typischerweise in dem Servicebeschreibungsdokument 12 enthalten sind, zu extrahieren. Eine Scanwerkzeugtabelle kann ähnliche Zeilen und Spalten, wie die Diagnosefehler-Informationstabelle, die oben beschrieben wird, enthalten, so dass Zeilen eine Drucksensorsignalleitung und eine Drucksensor-5 Volt-Referenzleitung enthalten und Spalten einen Massekurzschluss oder eine offene bzw. unterbrochene Schaltung einschließen. Somit kann ein Ausfallmodus durch die Kombination einer Zeile und einer Spalte wie eine Drucksensorsignalleitung, die einen Massekurzschluss aufweist, repräsentiert werden. In dem Fall der Abfragebearbeitungs-Datentabellen ist das Symptom, das auf einer Schnittstelle von einer Zeile und einer Spalte existiert, nicht ein DTC, sondern eher ein Abfragebearbeitungswert. Zum Beispiel für den Drucksensorsignalleitungs-Massekurzschluss ist der Abfragebearbeitungswert 0 Volt. Somit wird eine Korrelation zwischen einem Ausfallmodus und einem Symptom gezogen, die auf den Abfragebearbeitungs-Datentabellen, die in dem Servicebeschreibungsdokument 12 enthalten ist, basiert. Diese Fehlermodell-Extraktion wird in der Box 36 für alle Kombinationen von Symptomen und Ausfallmoden durchgeführt, bei denen die Abfragebearbeitungsdaten eine Korrelation anzeigen.
In der Box 38 werden Schaltungs- und Systemprüfbeschreibungen zergliedert, um Fehlermodelldaten zu erhalten. Das Servicebeschreibungsdokument 12 enthält oft Schaltungs- und Systemprüfbeschreibungen, die entworfen sind, um einen Servicetechniker im Diagnostizieren eines Problems zu assistieren. Zum Beispiel in einem Fall, in dem ein Kraftstofftankdruckablesen nicht korrekt ist, kann die Schaltungs- und Systemprüfbeschreibung verwendet werden, um zu bestimmen, ob ein Problem mit dem Kraftstofftankdrucksensor selbst, ein Problem mit der Verdrahtungsschaltung, ein Problem mit dem Motorsteuermodul, das das Sensorsignal verarbeitet, oder einer Kombination davon besteht.
Die Schaltungs- und Systemprüfbeschreibungen, welche in der Box 38 zergliedert werden, werden typischerweise als eine Sequenz von Schritten beschrieben, der zum Diagnostizieren eines Problems zu folgen ist. Ein Beispiel, das zeigt, wie die Schaltungs- und Systemprüfbeschreibungen zergliedert werden können, um Symptome und Ausfallmoden zu extrahieren, wird unten erörtert. Zusammenfassend ist die Analyselogik wie folgt definiert:

• Suche Verben, wie ”Test” oder ”Messung”, in den Testbeschreibungen.
• Identifiziere die Schaltung oder das System, das unmittelbar auf das Verb folgt, um zu bestimmen, welche Schaltung oder welches System zu testen ist und unter welcher Bedingung zu testen ist; dies definiert ein Symptom.
• Finde eine konditionelle Feststellung und eine Aktion, die dem Symptom folgt, wie beispielsweise ”wenn die Messung dieses ist, dann tue jenes”;
– Wenn die Aktion ein Ersetzen einer Komponente ist, repräsentiert dies den Ausfallmodus, der mit dem Symptom assoziiert ist.
– Wenn die Aktion ist, etwas anderes zu testen ist, dann repräsentiert dies ein anderes Symptom, das zu testen ist.

Unter Verwendung der Analysetechniken, die oben beschrieben sind, können Symptome und Ausfallmoden zuverlässig von den Schaltungs- und Systemprüfbeschreibungen in der Box 38 extrahiert werden. Das Servicebeschreibungsdokument 12 kann auch Reparaturinstruktionen enthalten, die in einer gewissen Weise wie oben beschrieben, für Schaltungs- und Systemprüfbeschreibungen zergliedert werden können, um einen Satz von Symptomen und Ausfallmoden zu erzeugen. Die Sequenz der Testschritte und Vorgänge, die in den Testbeschreibungen oder Reparaturinstruktionen enthalten ist, erzeugt zudem einen diagnostischen Baum, der wie unten erörtert ein verbundener Satz von Symptomen und Ausfallmoden ist. In Box 40 wird eine Erreichbarkeitsanalyse durchgeführt, um verborgene oder querfunktionelle Abhängigkeiten in dem diagnostischen Baum festzustellen, die in der Box 38 erfasst wurden.
3 ist ein Diagramm, das zeigt, wie ein diagnostischer Baum 50 aus Schaltungs- und Systemtestbeschreibungen oder Reparaturinstruktionen konstruiert werden kann und wie Daten in dem diagnostischen Baum 50 verwendet werden können, um ein Fehlermodell 70 unter Verwendung der Erreichbarkeitsanalyse zu bestücken. Wie vorher erwähnt, kann das Servicebeschreibungsdokument 12 Schaltungs- und Systemtestbeschreibungen und/oder Reparaturinstruktionen enthalten, die in der Box 38 zergliedert wurden, um Fehlermodellgehalte zu erhalten. Die Testbeschreibungen oder Reparaturinstruktionen enthalten typischerweise eine Sequenz von Schritten, wie die folgenden:

a) Messen der Spannung zwischen Kontakt A und Kontakt B.
b) Wenn die Spannung weniger als X ist, dann die Komponente 123 setzen.
c) Wenn die Spannung größer oder gleich X ist, dann die Spannung zwischen Kontakt C und Kontakt D messen.

Die Sequenz der obigen Schritte a) bis c) plus zusätzlicher Schritte aus dem Servicebeschreibungsdokument 12 können als diagnostischer Baum 50, der die Symptome 52, 54 und 56 und Ausfallmoden 62, 64 und 68 enthält, entworfen werden. In dem diagnostischen Baum 50 führt jedes der Symptome 52 bis 56 entweder zu einem anderen Symptom oder zu einem Ausfallmodus. Zum Beispiel von den obigen Schritten a) und b) kann das Symptom 52 als ”die Spannung zwischen Kontakt A und Kontakt B ist weniger als X” geschrieben werden. Wenn diese Behauptung richtig ist, dann kann der Ausfallmodus 62, Komponente 123 defekt, diagnostiziert werden. Jedoch wenn die Behauptung, die das Symptom 52 beschreibt, nicht wahr ist, dann führt der diagnostische Baum 50 zu einem anderen Symptom, wie in der obigen Behauptung c) beschrieben wird. Auf diese Weise kann der diagnostische Baum 50 von Testbeschreibungen oder Reparaturinstruktionen, die in dem Servicebeschreibungsdokument 12 enthalten sind, erzeugt werden.
Das Fehlermodell 70 kann ein Teilsatz des Fehlermodells 22 sein und kann von dem diagnostischen Baum 50 mit den Symptomen 52 bis 56 als Spalten und den Ausfallmoden 62 bis 68 als Zeilen, wie gezeigt, konstruiert werden. Der nächste Schritt ist, die Korrelationen oder Ursachenwichtungen in jeder Zeilen-Spalten-Schnittstelle zu besetzen. Es ist eine normale Praxis, Daten von diagnostischen Bäumen zu verwenden, um Fehlermodellkorrelationen zu identifizieren, was als direkte Abhängigkeiten bekannt ist, bei denen eine Verifikation eines Symptoms direkt zu einem Ausfallmodus führt. In dem diagnostischen Baum 50 hat das Symptom 52 ein direktes Abhängigkeitsverhältnis mit dem Ausfallmodus 62. In ähnlicher Weise gilt das für das Symptom 54 und den Ausfallmodus 64. Das Symptom 56 weist ein direktes Abhängigkeitsverhältnis sowohl mit dem Ausfallmodus 66 als auch 68 auf. Diese direkten Abhängigkeitsverhältnisse werden mit Ursachen-Wichtungswerten von 1 in dem Fehlermodell 70 gezeigt.
Zusätzliche Daten sind jedoch in dem diagnostischen Baum 50 über die direkten Abhängigkeitsverhältnisse, die oben beschrieben sind, hinaus enthalten. Versteckte oder querfunktionelle Abhängigkeiten können auch existieren und können darüber identifiziert werden, was als Erreichbarkeitsanalyse bekannt ist. Unter Verwendung einer Erreichbarkeitsanalyse werden querfunktionale Abhängigkeiten identifiziert zum Beispiel zwischen dem Symptom 52 und den Ausfallmoden 64, 66 und 68. Es ist ersichtlich, dass jedes der Ausfallmoden 64 bis 68 von mehr als nur der Anwesenheit oder der Abwesenheit von dem Symptom 52 abhängt. Zum Beispiel hängt der Ausfallmodus 64 auch von der Anwesenheit oder Abwesenheit des Symptoms 54 ab. Eine ähnliche Situation existiert zwischen dem Symptom 54 und den Ausfallmoden 66 und 68. Auf Grund der indirekten oder querfunktionellen Natur dieser Abhängigkeiten, können Ursachenwichtungen mit weniger als 1 festgelegt werden.
Das Fehlermodell 70 enthält Ursachenwichtungen 72, 74, 76, 78 und 80, wobei jede Ursachenwichtung 72–80 eine querfunktionelle Abhängigkeit repräsentiert und in einer Schnittstelle einer Ausfallmoduszeile und einer Symptomspalte vorhanden ist. Wie vorher erwähnt, hat jede der Ursachenwichtungen 72–80 einen Wert zwischen 0 und 1, der den Grad der Korrelation zwischen einem besonderen Ausfallmodus und einem besonderen Symptom bezeichnet. Ursachenwichtungen für querfunktionale Abhängigkeiten können, basierend auf wie vielen Stufen ein bestimmter Ausfallmodus von einem bestimmten Symptom entfernt ist, festgelegt werden. Zum Beispiel kann die Ursachenwichtung 72 auf einen Wert von 0,5 festgelegt werden, weil der Ausfallmodus 64 um eine Stufe von dem Symptom 52 entfernt ist. In ähnlicher Weise können die Ursachenwichtung 74 und 76 auf einen Wert 0,25 festgelegt werden, weil die Ausfallmoden 66 und 68 zwei Stufen von dem Symptom 52 entfernt sind. Diese Ursachenwichtungs-Festsetzungsbeispiele sind bloß darstellend, andere objektive Kriterien oder Gegenstände können von Experten verwendet werden, um Ursachenwichtungen der querfunktionalen Abhängigkeiten festzulegen, die über Erreichbarkeitsanalysen offenbart werden. Alle anderen Schnittstellen oder Abhängigkeiten in dem Fehlermodell 70, die nicht durch eine der Ursachenwichtungen 72–80 bestückt sind, haben eine Ursachenwichtung von 0, was keine Korrelation bedeutet, oder 1, was eine direkte Korrelation bedeutet. Die Erreichbarkeitsanalyse in der Box 40 wird typischerweise keine neuen Ausfallmodenzeilen oder Symptomspalten zu dem Fehlermodell 22 hinzufügen, sondern eher die existierenden Zeilen und Spalten mit zusätzlichen Nicht-Null-Ursachenwichtungen bestücken.
In Box 42 des Flussdiagramms 30 wird das Fehlermodell 22 zusammengestellt und als Ausgabe des strukturierten Textanalysemoduls 18 bereitgestellt, das Ausfallmoden, Symptome und Korrelationen enthält, die von den diagnostischen Fehlerinformationen in der Box 34, von Abfragebearbeitungsdaten in der Box 36, den Schaltungs- und Systemtestbeschreibungen in der Box 38 und der Erreichbarkeitsanalyse in der Box 40 identifiziert werden. Das Fehlermodell 22 kann dann für eine Vielfalt von Zwecken sowohl innerhalb des Fahrzeugs 24 als auch außerhalb, wie vorher erörtert, verwendet werden. Das Fehlermodell 22 kann auch als eine Grundlage für eine schnellere Entwicklung eines hochgenauen technischen Fehlermodells verwendet werden.
Um vollständiger die Fehlermodell-Entwicklungsmethodik zu beschreiben, wird ein Beispiel detailliert erörtert. Das Beispiel wird zeigen, wie ein Fehlermodellgehalt unter Verwendung des Verfahrens der 2 extrahiert wird. In diesem Beispiel werden Servicebeschreibungsinformationen, die sich auf Teile eines fahrzeugeigenen Telematik-Systems beziehen, zergliedert. Insbesondere wird eine Interaktion eines Telematik-Steuermoduls mit einem Mikrophon betrachtet.
Das Telematik-Steuermodul stellt dem Mikrophon eine Versorgungsspannung auf einer Signalschaltung bereit. Das Telematik-Steuerungsmodul stellt eine Masse für das Mikrophon für eine Drain-Schaltung bereit. Wenn irgendein Ausfall in der Signalschaltung, der Drain-Schaltung, des Telematik-Steuermoduls oder des Mikrophons auftritt, dann wird ein diagnostischer Problemcode, der als DTC B2455 festgesetzt ist, getriggert. Der DTC B2455 weist eine mehrdeutige Gruppe von sieben Ausfallmoden wie folgt auf:

1. Die Signalschaltung weist einen Massekurzschluss oder eine Unterbrechung auf.
2. Die Signalschaltung weist eine kurzgeschlossene Spannung auf.
3. Der telematische Steuerungsmodul-Signalschaltungsstecker ist fehlerhaft.
4. Der telematische Steuerungsmodul-Drain-Schaltungsstecker ist fehlerhaft.
5. Die Drain-Schaltung ist unterbrochen.
6. Die Drain-Schaltung hat eine kurzgeschlossene Spannung.
7. Das Mikrophon ist fehlerhaft.

Die mehrdeutige Gruppe repräsentiert drei unterschiedliche reparierbare Teile, nämlich den Telematik-Steuerungsmodul-Signalschaltungsstecker, den Telematik-Steuerungsmodul-Drain-Schaltungsstecker und das Mikrophon zusätzlich zu den sieben Ausfallmoden.
Tabelle 1 enthält diagnostische Fehlerinformationen, die sich auf die telematische Systemmikrophon-Schaltung beziehen, wie sie sich in dem Servicebeschreibungsdokument 12 wie oben beschrieben befinden. Tabelle 1

Schaltung Masse-Kurzschluss Unterbrechung kurzgeschlossene Spannung

Mikrophon-Signal B2455 B2455 B2455

Mikrophon-Drain - B2455 Anmerkung 1
Wie in Tabelle 1 zu sehen ist, wird, wenn die Mikrophon-Signalschaltung einen Massekurzschluss oder einen Spannungsschluss oder eine Unterbrechungsschaltung aufweist, das DTC B2455 getriggert. Wenn die Mikrophon-Drain-Schaltung unterbrochen ist, wird das DTC B2455 auch getriggert werden. Da die Mikrophon-Drain-Schaltung den Masseanschluss repräsentiert, gibt es keinen Fehler, der mit einem Massekurzschluss der Drain-Schaltung verbunden sein kann. Schließlich ist die Situation, in der die Drain-Schaltung eine kurzgeschlossene Spannung aufweist, nicht durch ein DTC charakterisiert, sondern die diagnostische Fehlerinformationstabelle enthält eine Anmerkung, die anzeigt, welches Symptom in diesem Fall auftritt. In diesem Beispiel beschreibt Anmerkung 1 das Nicht-DTC-Symptom wie ”Mikrophone nicht betriebsbereit – Anrufer kann nicht gehört werden”. Wie vorher in Bezug auf die Box 34 des Flussdiagramms 30 beschrieben, kann das Fehlermodell 22 durch erstes Kombinieren eines Schaltungsnamens mit einem Schaltungsfehlertyp bestimmt werden, um einen Ausfallmodus zu erzeugen, wie ”Mikrophon-Signal weist Massenkurzschluss auf”. Dann können sowohl für die DTC-Symptome als auch für die Nicht-DTC-Symptome Korrelationen festgelegt werden, die auf Daten in der diagnostischen Fehlerinformationstabelle basieren. Zum Beispiel kann eine Ursachenwichtung von 1 festgesetzt sein, wann immer ein Symptom für einen besonderen Ausfallmodus präsent ist.
Wird mit dem obigen Beispiel fortgesetzt, können zusätzliche Fehlermodelldaten von den Schaltungs- und Systemtestbeschreibungen in dem Servicebeschreibungsdokument 12 extrahiert werden. Auf Grund der mehrdeutigen Gruppe, die mit dem DTC B2455 assoziiert ist, werden die zusätzlichen Fehlermodelldaten von den Schaltungs- und Systemtestbeschreibungen hilfreich im Diagnostizieren eines Problems sein. Ein Beispiel von Schaltungs- und Systemprüfbeschreibungen, die sich auf das DTC B2455 beziehen, ist wie folgt:

1. Zündung AUS, Entferne den Hauptstecker von dem Mikrophon.
2. Zündung AUS und Abfragebearbeitung getrennt, warte bis alle verbliebenen Zusatzleistungen AUS sind, teste auf weniger als 10 Ohm zwischen dem Drain-Schaltungsstecker und Masse, ermögliche für bis zu 5 Minuten für den Schaltungswiderstand auf seine niedrigsten anzeigbaren Wert zu fallen. ⇒ Falls größer als der spezifizierte Bereich, teste die Schaltung auf einen offenen/hohen Widerstand.
3. Zündung EIN, Test auf 9,5 bis 10,5 Volt zwischen der Signalschaltungsstecker und Masse. ⇒ Wenn geringer als der spezifizierte Bereich, teste die Schaltung auf einen Massekurzschluss oder auf einen offenen/hohen Widerstand. Wenn die Schaltungstests normal sind, ersetze das Telematik-Steuerungsmodul. ⇒ Wenn größer als der spezifische Bereich, teste die Schaltung auf eine Kurzschlussspannung. Wenn der Schaltungstest normal ist, ersetze das Telematik-Steuerungsmodul.
4. Wenn alle Schaltungstests normal sind, ersetze das Mikrophon.

Die Schaltung und Systemtestbeschreibungen, wie sie oben aufgeführt sind, können unter folgenden Regeln zergliedert werden:

1. Suche nach den Worten ”Test für”, ”Teste den”, oder ”Beobachte den” in den Testschritten. Übernimm den gesamten Satz, der diese Worte enthält und sichere ihn als einen technischen Test.
2. Wenn es dort einen Satz gibt, der mit dem Pfeilzeichen ”⇒” beginnt, dann wird als eine zweite Stufe der Tests und der Ausfälle berücksichtigt, was ist von den vorhergehenden Tests abhängig. Eine Erreichbarkeitsanalyse kann verwendet werden, um den zweiten Stufentest mit dem ersten Stufen-Ausfallmodus zu korrelieren.
3. Suche nach Worten ”Ersetze den”, um Ausfallmoden und reparierbare Teile zu konstruieren.
4. Wenn es dort Mehrfachsätze unter einem Treffer gibt, der mit dem Pfeilzeichen ”⇒” startet, dann zeigt das, dass dort ein Vielfach-Modus des Ausfallmodus gezeigt ist.
5. Speichere die Sequenz der Tests durch Speichern der Treffernummer mit den Test- und Ausfallmodus-Informationen.

Zusätzlich zu den diagnostischen Fehlerinformationen und den Schaltungs- und Systemtestbeschreibungen ist es auch möglich, die DTC-Einstellungsbedingungen und die laufenden Bedingungen zu analysieren, um negative Korrelationen in dem Fehlermodell zu erfassen; das bedeutet, dass die DTCs nicht mit einem anderen spezifischen DTC gesetzt sind. Reparaturinstruktionen werden auch zergliedert, um reparierbare Teile, die nicht in den Schaltungs- und Systemtestbeschreibungen erwähnt werden, zu erfassen.
Als ein Ergebnis von all dem Zergliedern, das oben erörtert ist, wird ein Abschnitt von dem Fehlermodell 22 entwickelt, der sich auf die Mikrophon-Schaltung für das Telematiksystem, wie es unten mit Tabelle 2 repräsentiert wird, bezieht: Tabelle 2

S1 S2 S3 S4 S5 S6

FM1 1 1 1

FM2

FM3 1

FM4 1 1 1

FM5 1 1

FM6 1 1

FM7 1
Wobei die Symptome S1–S6 sind:

• S1 = DTC B2455
• S2 = ”2.0 – Test auf weniger als 10 Ohm zwischen Telematik-Modul und Drain-Schaltungsstecker und Masse – B2455”
• S3 = ”2.1 – Testschaltung für offenen/hohen Widerstand – B2455”
• S4 = ”3.0 – Test auf 9,5 bis 10,5 Volt zwischen Telematik-Modulsignalschaltungsstecker und Masse – B2455”
• S5 = ”3.1 – Testschaltung für Massekurzschluss oder offen/hohen Widerstand – B2455”
• S6 = ”3.2 – Testschaltung für Kurzschlussspannung – B2455”

Und die Ausfallmoden FM1 bis FM7 sind:

• FM1 = ”Mikrophon-Drain-Schaltung unterbrochen”
• FM2 = ”Mikrophon-Drain-Schaltung mit kurzgeschlossener Spannung”
• FM3 = ”Mikrophon-Ausfall”
• FM4 = ”Mikrophon-Signalschaltung-Massekurzschluss oder unterbrochen
• FM5 = ”Mikrophon-Signalschaltung kurzgeschlossene Spannung”
• FM6 = ”Telematik-Steuermodul-Signalschaltungsstecker-Ausfall”
• FM7 = ”Telematik-Steuermodul-Drain-Schaltungsstecker-Ausfall”

Wenn ein Wert von 1 in einer Zeilen-Spalten-Schnittstelle in Tabelle 2 gezeigt wird, zeigt dieses eine direkte Korrelation zwischen einem besonderen Symptom und einem besonderen Ausfallmodus an. Wenn kein Wert in einer Schnittstelle gezeigt wird, ist keine Korrelation vorhanden. Wie vorher erörtert, kann eine Erreichbarkeitsanalyse durchgeführt werden, um querfunktionale oder indirekte Korrelationen zu entdecken, was zu weichen Korrelationen oder Ursachenwichtungen zwischen 0 und 1 führen kann.
Es ist auch möglich, dass normale Fehler auftreten können. Zum Beispiel kann das Telematik-Steuerungsmodul einen normalen Fehler in der Masse und den Leistungsschaltungen zeigen. Diese Fehlerart wird eine Mehrfach-DTCs triggern, die mit dem Telematik-Steuerungsmodul assoziiert sind – einschließlich der DTC B2455, welche sich auf die Mikrophon-Schaltung sowohl als auch auf andere beziehen. Diese normalen Fehler sind oft in dem Servicebeschreibungsdokument 12 enthalten und können durch die diagnostischen Regeln in der Box 34, wie zuvor erörtert, erfasst werden. In einem derartigen Fall wird das Fehlermodul 22 eine Ausfallmodus-Zeile für den normalen Fehler einschließen und eine Korrelation wird für jedes anwendbare Untersystem des DTC-Symptoms eingerichtet.
Eine Fehlermodellentwicklung aus strukturierten Textdokumenten wie dem Servicebeschreibungsdokument 12 kann ein wertvolles Instrument sein, das in der Lage ist, schnell und vollständig die Breite der Fehlermodellinformationen, die in derartigen Dokumenten vorhanden sind, zu erfassen. Unter Verwendung der Techniken, die oben beschrieben werden, können strukturierte Textdokumente untersucht und zergliedert werden, um das Fehlermodell 22 zu erzeugen. Das Fehlermodell 22 kann dann zum Beispiel verwendet werden, um Echtzeitfehlerdiagnosen in einem fahrzeugeigenen Computer des Fahrzeugs 24 durchzuführen, außerhalb Fehlerdiagnosen unter Verwendung der diagnostischen Bearbeitung 26 oder in einem entfernten diagnostischen Zentrum durchzuführen oder durch das Fahrzeugentwicklungspersonal 28 für ein Aktualisieren der Servicedokumente oder dem Entwerfen zukünftiger Fahrzeugsysteme oder Komponenten zu verwenden.
Die Vorteile, in der Lage zu sein, automatisch Fehlermodelle von Textdokumenten zu entwickeln, sind zahlreich. Ein bedeutender Vorteil ist die Fähigkeit, zuverlässig hochgenaue Fehlermodelle von Textdokumenten mit einem minimalen Personalaufwand zu erzeugen. Fehlermodelle für Fahrzeuge oder komplexe Subsysteme enthalten oft tausende von Symptomen und tausende von Ausfallmoden. Ein Automatisieren des Prozesses der Bildung dieser enormen Dokumente liefert ein hohes Maß an Arbeitskräfteeinsparungen. Auch bei Begrenzung des menschlichen Einsatzes um die Durchsicht und die Disposition einer geringen Anzahl von Grenzlinienpunkten wird die Gelegenheit für menschliche Fehler oder ein menschliches Übersehen größtenteils reduziert. Ein anderer Vorteil ist es, in der Lage zu sein, das Fehlermodell 22 aus Textdokumenten zu entwickeln mit der Fähigkeit, wertvolle alte Servicedaten, die auf andere Weise wahrscheinlich nicht in Fehlermodellentwicklungen verwendet werden, zu erfassen. Das kann erreicht werden, weil, wenn einmal die Diagnoseregeln, wie oben beschrieben entwickelt sind, es nur einen geringen weiteren Einsatz erfordert, um die Fehlermodellentwicklungsmethodik für zusätzliche Dokumente, einschließlich Dokumenten, die in technischen Serviceanleitungen und historischen oder legalen Serviceinformationen enthalten sind, anzuwenden.
Schließlich ermöglichen die Methoden, die hierin offenbart werden, in einem Dokument verborgene oder übersehene Korrelationen zu entdecken und somit die Qualität der sich ergebenden Fehlermodelldaten zu verbessern. Das Fehlermodell 22 ist ein leistungsfähiges Dokument, das einem Fahrzeughersteller ermöglichen kann, die Kundenzufriedenheit zu erhöhen, die Garantiekosten zu reduzieren und die künftigen Produktentwicklungen zu verbessern. Das Fehlermodell 22 kann auch als Grundlage für eine schnelle Entwicklung eines hochgenauen technischen Fehlermodells dienen.
Die vorhergehenden Erörterungen offenbaren und beschreiben nur exemplarische Ausführungsformen der vorliegenden Erfindung. Ein Fachmann kann bereits von einer derartigen Erörterung und von den begleitenden Zeichnungen und Ansprüchen erkennen, dass unterschiedliche Änderungen, Modifikationen und Variationen durchgeführt werden können, ohne den Geist und den Rahmen der Erfindung, wie sie in den nachfolgenden Ansprüchen definiert ist, zu verlassen.

Claims

Verfahren zum Erzeugen eines Fehlermodells für ein Hardware- oder Softwaresystem, wobei das Verfahren aufweist: – Bereitstellen eines strukturierten Textdokumentes, das diagnostische Informationen über das Hardware- oder Softwaresystem aufweist; – Extrahieren von Fehlermodelldaten aus dem strukturierten Textdokument; – Zergliedern von Testbeschreibungen und Reparaturinstruktionen; die in dem strukturierten Textdokument enthalten sind, um einen Fehlerbaum zu erzeugen und um zusätzliche Fehlermodelldaten zu erhalten; – Durchführen von Erreichbarkeitsanalysen an dem Fehlerbaum, um querfunktionelle Abhängigkeiten zu identifizieren; und – Zusammensetzen des Fehlermodells aus den Fehlermodelldaten und den querfunktionellen Abhängigkeiten.
Verfahren nach Anspruch 1, wobei das Extrahieren von Fehlermodelldaten ein Verwenden von diagnostischen Regeln beinhaltet, um die Fehlermodelldaten von diagnostischen Fehlerinformationen und Scanwerkzeugtabellen, die in dem strukturierten Textdokument enthalten sind, zu extrahieren.
Verfahren nach Anspruch 1, wobei das Analysieren von Testbeschreibungen und Reparaturinstruktionen ein Identifizieren eines Tests für ein erstes Symptom und ein Identifizieren eines Ausfallmodus und eines zweiten Symptoms, das von dem Test abgeleitet sein kann, beinhaltet.
Verfahren nach Anspruch 1, wobei das Durchführen von Erreichbarkeitsanalysen an dem Fehlerbaum ein Bestimmen beinhaltet, bei dem Ausfallmoden in dem Fehlerbaum querfunktionell abhängig von mehr als einem Symptom sind.
Verfahren nach Anspruch 1, wobei die Fehlermodelldaten Symptome, Ausfallmoden und Korrelationswerte beinhalten.
Verfahren nach Anspruch 5, wobei die Symptome diagnostische Problemcode (DTC, Diagnostic Trouble Code) Symptome und Nicht-DTC-Symptome beinhalten.
Verfahren nach Anspruch 5, wobei das Zusammensetzen des Fehlermodells ein Erzeugen von Zeilen der Ausfallmoden, ein Erzeugen von Spalten der Symptome und ein Platzieren der Korrelationswerte in Schnittstellen der Zeilen und Spalten einschließt.
Verfahren nach Anspruch 7, das weiterhin aufweist ein Verwenden der querfunktionellen Abhängigkeiten, um zusätzliche Korrelationswerte in dem Fehlermodell zu definieren.
Verfahren nach Anspruch 1, wobei das Hardware- oder Softwaresystem ein Fahrzeug oder ein Fahrzeugsubsystem ist.
Verfahren nach Anspruch 9, wobei das strukturierte Textdokument ein Servicebeschreibungsdokument für das Fahrzeug oder das Fahrzeugsubsystem ist.