DE102011106550A1

DE102011106550A1 - Methodik zur Wissensextraktion für unstrukturierte Daten mittels ontologiebasiertem Text-Mining

Info

Publication number: DE102011106550A1
Application number: DE102011106550A
Authority: DE
Inventors: Dnyanesh Rajpathak
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2010-07-08
Filing date: 2011-07-04
Publication date: 2012-01-12
Also published as: US20120011073A1; CN102314483B; US8489601B2; CN102314483A

Abstract

Es wird ein Verfahren zum Extrahieren von Daten aus Servicereparatur-Berichtwortlauten in einem Fahrzeugservice-Berichtssystem bereitgestellt. Jeder Servicereparatur-Berichtwortlaut umfasst die Kommentare eines Technikers betreffend ein Bauteil, ein dem Bauteil zugeordnetes Symptom und eine dem Symptom zugeordnete Reparaturmaßnahme. Jeder Servicereparatur-Berichtwortlaut umfasst Informationen betreffend ein identifiziertes Problem im Zusammenhang mit zumindest einem Fahrzeugbauteil. Es wird eine Diagnose- und Prognose-Ontologiedatenbank bereitgestellt, die durch eine Fahrzeugbauteilklassifizierung, eine Fahrzeugbauteil-Unterklassen-Klassifizierung und eine Beziehungsklassifizierung strukturiert ist, wobei die Beziehungsklassifizierung Symptom-Beziehungen und Maßnahme-Beziehungen umfasst. Jeder der Servicereparatur-Berichtwortlaute wird unter Verwendung der Diagnose- und Prognose-Ontologiedatenbank strukturiert. Kombinationen von Informationen werden aus den strukturierten Servicereparatur-Berichtwortlauten in Abhängigkeit von Benutzer-Eingabekriterien extrahiert. Für jede extrahierte Kombination wird eine Häufigkeit bestimmt, mit der diese in den strukturierten Servicereparatur-Berichtwortlauten vorkommt. Die Servicereparatur-Berichtwortlaute werden für jede Kombination jeweils zu einem Cluster gruppiert.

Description

HINTERGRUND DER ERFINDUNG
Eine Ausführungsform betrifft allgemein das Data-Mining von Reparaturdaten in Gewährleistungsserviceabteilungen.
Typische Text-Mining-Werkzeuge erzeugen Suchläufe mit einfachen Suchkriterien wie etwa Suchläufe nach Einzelbegriffen. Viele der derzeit verwendeten Text-Mining-Werkzeuge scheitern am Umgang mit schlecht geschriebenen Sätzen oder unstrukturierten Servicereparaturdaten, die aus verschiedenen Arten von Rauschen, wie beispielsweise abgekürzten Servicereparaturinformationen, unvollständigem Servicereparaturtext und Rechtschreibfehlern bestehen. Außerdem sind die bestehenden Werkzeuge nicht in der Lage, die Anomaliefälle aus den Felddaten zu identifizieren, zu denen es kommen kann, wenn beispielsweise eine gegebene Arbeitscodebeschreibung (welche aus einer 'Bezeichnung des zu reparierenden Bauteils' und einer 'zu treffenden Reparaturmaßnahme' zur Behebung des dem Bauteil zugeordneten Fehlers besteht) mit einem entsprechenden berichtssystemgenerierten Arbeitscode verglichen wird, um so Nichtübereinstimmungen zu identifizieren. Daher gibt es bei einem Suchlauf, der mehr als einen einzigen Begriff bzw. Term erfordert, keine Garantie dafür, dass die Kombination von gesuchten Termen in dem Servicereparatur-Berichtwortlaut eine präzise Beziehung derselben untereinander liefert. Darüber hinaus kann es sein, sofern die gesuchten Terme nicht in jeder einzelnen der verschiedenen Dokumentgruppen vorkommen, dass eine Gruppierung von Servicereparaturtechniker-Berichtwortlauten (d. h. von Dokumenten) zu Clustern im Hinblick auf die Identifizierung von häufig ausfallenden Bauteilen, von diesen Bauteilen zugeordneten Symptomen, sowie von Reparaturmaßnahmen, die durch die Techniker gesetzt werden, um den Fehler zu reparieren, unvollständig ist. Dies würde zu einer nicht beobachtbaren Datendarstellung für die Sachgebietsexpertise führen, die das Data-Mining durchführt und versucht, geeignete Maßnahmen zur Entscheidungsfindung zu treffen.
Ein Vorteil einer Ausführungsform liegt in der Erzeugung von brauchbaren Daten, die einen Benutzer in die Lage versetzen, Gewährleistungsdaten zu analysieren, indem er miteinander verwandte Servicereparaturdokumente durch Clusterbildung gruppiert. Das Text-Mining-Werkzeug extrahiert domänenspezifische Informationen in unterschiedlichen Kombinationen zusammen mit den Beziehungen, die zwischen extrahierten Konzepten existieren. Die extrahierten Informationen werden in weiterer Folge dazu verwendet, drei unterschiedliche Kombinationen von hierarchischen Dokumentclustern zu erzeugen, und zwar so, dass die am häufigsten zur Fehlerreparatur herangezogenen Arten von Reparaturmaßnahmen hervorgehoben werden. Die Bezeichnungen von drei Clusterkombinationen sind – Cluster 1, welcher den Bauteil-Cluster darstellt; Cluster 2, welcher den Bauteil-Symptom-Cluster darstellt; und Cluster 3, welcher den Bauteil-Symptom-Maßnahme-Cluster darstellt. Diese verschiedenen Clusterkombinationen unterstützen die Sachgebietsexpertise bei der Visualisierung von Daten aus unterschiedlicher Perspektive.
In einer Ausführungsform wird ein Verfahren zum Extrahieren von Daten aus Servicereparatur-Berichtwortlauten in einem Fahrzeugservice-Berichtssystem erwogen. Jeder Servicereparatur-Berichtwortlaut umfasst die Kommentare eines Technikers betreffend ein Bauteil, ein dem Bauteil zugeordnetes Symptom und eine dem Symptom zugeordnete Reparaturmaßnahme. Servicereparatur-Berichtwortlaute werden aus einem Fahrzeugservice-Berichtssystem gesammelt. Jeder Servicereparatur-Berichtwortlaut umfasst Informationen betreffend ein identifiziertes Problem im Zusammenhang mit zumindest einem Fahrzeugbauteil. Es wird eine Diagnose- und Prognose-Ontologiedatenbank bereitgestellt, die durch eine Fahrzeugbauteilklassifizierung, eine Fahrzeugbauteil-Unterklassen-Klassifizierung und eine Beziehungsklassifizierung strukturiert ist, wobei die Beziehungsklassifizierung Symptom-Beziehungen und Maßnahmen-Beziehungen umfasst. Jeder der Servicereparatur-Berichtwortlaute wird unter Verwendung der Diagnose- und Prognose-Ontologiedatenbank strukturiert. Kombinationen von Informationen werden aus den strukturierten Servicereparatur-Berichtwortlauten in Abhängigkeit von Benutzer-Eingabekriterien extrahiert. Für jede extrahierte Kombination wird bestimmt, wie häufig sie in den strukturierten Servicereparatur-Berichtwortlauten vorkommt. Die Servicereparatur-Berichtwortlaute werden für jede Kombination in Cluster gruppiert.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1. ist ein Ablaufdiagramm eines erfindungsgemäßen Text-Mining-Systems.
2 ist ein Ablaufdiagramm eines erfindungsgemäßen Strukturierungsprozesses für unstrukturierten Text.
3 ist ein Ablaufdiagramm einer erfindungsgemäßen semantikbasierten Extraktionslogik.
DETAILLIERTE BESCHREIBUNG
In 1 ist ein Ablaufdiagramm eines Rahmensystems für die entweder einzeln oder in Kombination miteinander durch Text-Mining erfolgende Verarbeitung von Bauteil-Termen, Symptom-Termen und Maßnahme-Termen aus Servicereparatur-Berichtwortlauten gezeigt, die in einer Gewährleistungsdatenbank eines Gewährleistungsdatenbank-Berichtssystems abgespeichert sind.
Die Gewährleistungsdatenbank umfasst eine Datenspeichereinheit, die Informationen speichert, durch welche eine Beziehung zwischen einem Fahrzeugproblem und einer Reparatur des Fahrzeugs hergestellt wird. Bei der Gewährleistungsdatenbank handelt es sich vorzugsweise um eine zentrale Datenbank, in welcher Servicereparatur-Berichtwortlaute aller Serviceeinrichtungen eines jeweiligen Herstellers, wie beispielsweise eines Fahrzeugherstellers, empfangen und zusammengetragen werden. In Fahrzeug-Serviceeinrichtungen wird typischerweise die Ursache eines Problems bestimmt und hierfür ein vorbestimmter Arbeitscode an die Gewährleistungsdatenbank übermittelt. Der Arbeitscode umfasst eine vorbestimmte Beschreibung der an dem Fahrzeug vorzunehmenden Reparatur und des Bauteils, das repariert wird. Das System ermöglicht es dem Servicetechniker außerdem, Einzelheiten betreffend die Serviceuntersuchung, die Diagnose und die Servicereparatur einzugeben. Das den Sachverhalt verursachende Bauteil, die Beschreibung des Sachverhalts und die konkrete Reparatur können jeweils als Bauteil, Symptom und Maßnahme bezeichnet werden. In vielen Fällen kann es vorkommen, dass die Einzelheiten eines von dem Servicetechniker eingegebenen Servicereparatur-Berichtwortlauts nicht unbedingt mit dem übereinstimmen, was in der Arbeitscodebeschreibung dargestellt ist. Beispielsweise kann in einem Bauteil-Symptom-Berichtwortlaut eine Reparaturmaßnahme 'Batterierepariert' als {Bauteil Maßnahme}-Kombination angegeben sein. Jedoch gibt der Arbeitscode gemäß Berichtssystem ”Batterie wird ersetzt” an, wohingegen die von dem Servicetechniker eingegebene Beschreibung festhält, dass die Batterie aufgeladen wurde. Als Folge daraus kommt es zu Anomalien im Datenbestand, in welchem die Arbeitscodes gemäß Berichtssystem nicht mit den Eingaben des Servicetechnikers korrelieren. Darüber hinaus können Trends bezüglich der Art und Weise feststellbar sein, in der die Einreichung von Gewährleistungsansprüchen von einer Anzahl von Verkaufsvertretungen oder von einer bestimmten Verkaufsvertretung gehandhabt wird. Daher ist es bei einem Gewährleistungs-Berichtssystem von essentieller Bedeutung, präzise zu beschreiben und zu berichten, welches das fehlerhafte Bauteil ist, wie der Sachverhalt gelagert ist und worin die korrekte Reparaturmaßnahme besteht. Das Vorliegen der korrekten Beschreibungen eines jeden Feldes versetzt die Sachgebietsexperten, welche die Gewährleistungsdaten durchsehen, in die Lage, solche Probleme rasch zu erfassen und angemessene Gegenmaßnahmen zu setzten, um dementsprechend in einen Sachverhalt korrigierend einzugreifen.
In 1, im Spezielleren in Block 10, wird ein Dokumentkorpus aus der Datenbank generiert. Das Dokumentkorpus umfasst sämtliche Auflistungen von Servicereparatur-Berichtwortlauten, welche von allen Fahrzeug-Serviceeinrichtungen an die Gewährleistungs-Berichtdatenbank übermittelt worden sind. Bei den Servicereparatur-Berichtwortlauten handelt es sich typischerweise um unstrukturierten Text, was bedeutet, dass er als Fließtext-Sätze ohne definitive Trennzeichen (z. B. unterscheidende Interpunktionszeichen) zwischen den Sätzen vorliegen kann. Außerdem können Trennzeichen in dem unstrukturierten Text unkorrekt verwendet sein, wodurch es schwierig wird, mit Sicherheit festzustellen, was einen vollständigen Satz in dem Servicereparatur-Berichtwortlaut darstellt. Darüber hinaus bestehen Servicereparatur-Berichtwortlaute aus verschiedenen Arten von Rauschen, wie beispielsweise abgekürzten Servicereparatur-Informationen, unvollständigem Servicereparatur-Text sowie Rechtschreibfehlern.
In Block 20 wird unstrukturierter Text unter Zuhilfenahme einer domänenspezifischen Wissensdatenbank in Form einer Diagnose- und Prognose-Ontologie (D&P-Ontologie) 30 strukturiert. Die D&P-Ontologie 30 wird gespeichert, ausgetauscht und ist maschinenlesbar, so dass sie in verschiedenen Kraftfahrzeug-Anwendungsdomänen gemeinsam genutzt und wiederverwendet werden kann. Als grobe Struktur betrachtet, weist die D&P-Ontologie eine Struktur der Form {C, C_subclass, Rel_Ci>1} auf, wobei C eine Kategorie von Hauptkonzepten wie beispielsweise Bauteilen (z. B. Tür, Steuermodul) darstellt. Jedes in der D&P-Ontologie vorhandene ”Bauteil”-Konzept besteht aus einem Grundwort, welches den angemessensten, domänenspezifischen Bezug zu diesem betreffenden Bauteil-Konzept darstellt. Bei dem Grundwort handelt es sich mehr oder weniger um eine Wurzel des Wortes, für das verschiedene Formen des Grundworts in dem Servicereparatur-Berichtwortlaut vorkommen. So kann beispielsweise das Bauteil-Konzept ”elektronisches Bremssteuermodul” als ”Bremssteuermodul” oder ”EBCM” geschrieben werden. Das Grundwort versetzt einen Sachgebietsexperten oder dergleichen, der die Daten analysiert, in die Lage, eine Disambiguierung zwischen verschiedenen Verwendungsarten, in denen das Teil in dem Servicereparatur-Berichtwortlaut erfasst ist, vorzunehmen.
Zur besseren Unterscheidung der Kategorien basierend auf der weiteren Verfeinerung, in der die Klassen-Konzepte organisiert sind, ist eine Unterklassen-Hierarchie durch C_subclass dargestellt. Schließlich ist eine Beziehung, die zwischen zwei oder mehreren Klassen in der D&P-Domäne existiert, durch Rel_Ci>1 dargestellt, da es erforderlich ist, die Beziehung zwischen der Klasse (Bauteil) und der Klasse (Maßnahme), die an dem betreffenden Teil vorzunehmen ist, herzustellen. Kurz gesagt, die D&P-Ontologie stellt ein systematisches Rahmensystem bereit, um das domänenspezifische Wissen zu formalisieren, indem die Klassen, die Beziehungen zwischen diesen sowie die Unterklassen definiert werden, so dass dieses standardisierte Wissen in unterschiedlichen Diagnoseanwendungen in der Automobiltechnik wiederverwendet werden kann. Als Schlüsselkonzepte, die in der D&P-Ontologie enthalten sind, sind beispielsweise Bauteil, Maßnahme, Symptom, BauteilPosition und ArbeitsCode zu nennen. Als einige der Haupt-Beziehungen in der D&P-Ontologie, die zur Formalisierung des darin enthaltenen, domänenspezifischen Wissens benötigt werden, sind, ohne Anspruch auf Vollständigkeit, die folgenden zu nennen: Bauteil Hat-Eine-Position (Bauteil, BauteilPosition), Maßnahme An-Bauteil-Durchgeführt (Maßnahme Bauteil), Symptom Dem-Bauteil-Zugeordnet (Symptom Bauteil), Maßnahme Behebt-Symptom (Maßnahme Symptom) und Maßnahme Hat-ArbeitsCode (Maßnahme ArbeitsCode).
In Block 20, auf welchen erneut Bezug genommen wird, wird jeder in dem Dokumentkorpus enthaltene Servicereparatur-Berichtwortlaut einer Strukturierung unterzogen. Die Strukturierung umfasst die Tokenisierung, die Stoppwortlöschung, die Wortstammrückführung und die lexikalische Übereinstimmungssuche. Im Rahmen der Dokumentstrukturierung wird jeder Servicereparatur-Berichtwortlaut in eine angemessene Satzstruktur mit auf einfache Weise identifizierbaren Wärtern formatiert, die mit korrelierenden Termen innerhalb der D&P-Ontologiedatenbank verglichen werden können.
In Block 40 wird eine semantikbasierte Extraktion durchgeführt. Die semantikbasierte Extraktion umfasst den Prozess des Extrahierens unterschiedlicher Kombinationen von Informationen für jeden einzelnen Servicereparatur-Berichtwortlaut unter Berücksichtigung von benutzerspezifischen Erfordernissen. Die extrahierten Informationen werden aus den verschiedenen Kombinationen zwischen Bauteilen, Symptomen und Maßnahmen hergeleitet. Die Kombinationen umfassen {Bauteil Symptom}, {Bauteil Maßnahme}, {Symptom Maßnahme} und {Bauteil Symptom Maßnahme}. Durch das Extrahieren von Informationen in unterschiedlichen Kombinationen wird es den Endbenutzern ermöglicht, unterschiedliche Cluster von Servicereparatur-Berichtwortlauten aufzubauen. Als Folge daraus lässt sich durch den Aufbau verschiedener Cluster von kombinierten Daten ein Übersehen von Informationen beträchtlich reduzieren.
In Block 50 wird an den extrahierten Informationen eine Wissenserschließung (Knowledge Discovery) in Form einer Clusterbildung durchgeführt. Bei der Clusterbildung geht es um die Sammlung von Servicereparatur-Berichtwortlauten unter Zusammengruppierung der verwandten Informationen. Das heißt, dass diejenigen strukturierten Servicereparatur-Berichtwortlaute, welche extrahierte semantische Elemente enthalten, die von dem Benutzer ausgewählt worden sind, indexiert werden und so gruppiert werden, dass sie einen Cluster bilden. Es gibt drei Typen von Clustern, die aufgebaut werden können: den bauteilbasierten Cluster, den Bauteil-Symptom-Cluster und den Bauteil-Symptom-Maßnahme-Cluster.
Die bauteilbasierten Cluster werden durch die Verwendung der Bauteil-Terme als Eingabemerkmale aufgebaut. Jeder Bauteil-Cluster besteht aus einem oder mehreren Servicereparatur-Berichtwortlauten, die ein Vorkommen eines von einem Benutzer spezifizierten Bauteils enthalten. Das heißt, ein bestimmter Bauteil-Cluster enthält Servicereparatur-Berichtwortlaute, die sich auf die Bezeichnung eines identifizierten Bauteils beziehen, das vom Benutzer darin ausgewählt worden ist.
Die Bauteil-Symptom-Cluster werden aufgebaut, indem jene Bauteil- und Symptom-Terme als Eingabemerkmale verwendet werden, die häufig gemeinsam in dem Datenbestand vorhanden sind. Jeder Bauteil-Symptom-Cluster besteht aus einem oder mehreren Servicereparatur-Berichtwortlauten, in denen ein spezifisches Bauteil gemeinsam mit einem spezifischen Symptom vorkommt. Ein entsprechender Bauteil-Symptom-Cluster weist Servicereparatur-Berichtwortlaute auf, die eine spezifische Bauteil-Bezeichnung und ein spezifisches, zugeordnetes Symptom enthalten. Dadurch wird es einer Sachgebietsexpertise ermöglicht, die häufigsten Bauteile, die in einem Datenbestand vorkommen, zusammen mit den Symptomen zu erkennen. Durch die Verwendung eines spezifischen Bauteils und eines unterschiedlichen Symptoms können mehrere Cluster aufgebaut werden. Als Beispiele für die Mehrfach-Cluster mit einem spezifischen Bauteil und verschiedenen Symptomen sind, ohne Anspruch auf Vollständigkeit, zu nennen {Batterie-Leer}, {Batterie-Funktionsunf} und {Batterie-Leck}.
Die Bauteil-Symptom-Maßnahme-Cluster werden durch die Verwendung von Bauteil-Termen, Symptom-Termen und Maßnahme-Termen als Eingabemerkmale aufgebaut. Ein jeder Bauteil-Symptom-Maßnahme-Cluster besteht aus einem oder mehreren Servicereparatur-Berichtwortlauten, in denen ein spezifisches Bauteil jeweils gemeinsam mit einem spezifischen Symptom und einer spezifischen Maßnahme vorkommt. Ein entsprechender Bauteil-Symptom-Maßnahme-Cluster weist Servicereparatur-Berichtwortlaute auf, die eine spezifische Bauteil-Bezeichnung, ein dem spezifischen Bauteil zugeordnetes, spezifisches Symptom und eine dem spezifischen Symptom zugeordnete, spezifische Maßnahme enthalten. Als Beispiele für Mehrfach-Cluster unter Verwendung eines spezifischen Bauteils, das gemeinsam mit zugeordneten Symptomen und zugeordneten Reparaturmaßnahmen in dem Servicereparatur-Berichtwortlaut vorhanden ist, sind, ohne Anspruch auf Vollständigkeit, zu nennen {Batterie-Leer-Aufladen}, {Batterie-Leer-Ersetzen} und {Batterie-Leer-Diagnose}.
In Schritt 60 werden die Ergebnisse an den Benutzer zur Analyse ausgegeben. Bei dem Benutzer kann es sich um einen Sachgebietsexperten, einen Techniker, einen Angestellten der Gewährleistungsabteilung, einen Ingenieur, einen Außendienst-Mitarbeiter und um einen Fachtechniker mit Kenntnissen über die technischen Funktionsweisen des Fahrzeugs handeln. Die ausgegebenen Ergebnisse können in Form von grafischen Inhalten, beispielsweise Paretodiagrammen, erzeugt werden, welche zu Analysezwecken verwendet werden können. Die Paretodiagramme stellen eine spezielle Analysemöglichkeit dar, um jene der mit der Abwicklung der häufig vorkommenden {Bauteil-Symptom-Maßnahme}-Fälle befassten Servicezentren zu ermitteln, welche die Probleme binnen kurzer Frist und auf kosteneffiziente Weise beheben. Gleichzeitig wird die Paretoanalyse auch dazu verwendet, diejenigen Servicezentren zu identifizieren, in denen die Reparaturen nicht binnen kurzer Frist und auf kosteneffiziente Weise erledigt werden. Darüber hinaus können Paretodiagramme auch erstellt werden, um {Bauteil-Symptom}-, {Symptom-Maßnahme}- und {Bauteil-Symptom-Maßnahme}-Fälle von Fahrzeugen entsprechend dem Fahrzeug-Produktionsdatum und dem Fahrzeug-Baujahr zu gruppieren. Falls eine spezifische Fahrzeugmarke (bzw. spezifische Fahrzeugmarken) und ein spezifisches Fahrzeugmodell (bzw. spezifische Fahrzeugmodelle) häufig in einem Datenbestand vorkommen und Symptome aufweisen, die mit einer mechanischen Komponente (z. B. dem Motor) in Verbindung stehen, können auch die Produktionsfabriken, in denen die betreffenden Fahrzeuge montiert/hergestellt werden in Form von Paretodiagrammen grafisch dargestellt werden, um den Ursprung eines Problems zu erkennen.
2 veranschaulicht ein Blockdiagramm zum Strukturieren von unstrukturiertem Text in dem Servicereparatur-Berichtwortlaut. In Block 21 wird die Text-Strukturierung eingeleitet, indem jeder Servicereparatur-Berichtwortlaut gegebenenfalls in verschiedene Sätze aufgeteilt wird. Wie weiter oben beschrieben, werden Servicereparatur-Berichtwortlaute unter Umständen als unstrukturierter Text eingegeben, wobei der Techniker Einzelheiten und Erklärungen des aufgetretenen Problems, eine Erklärung, wie der Sachverhalt diagnostiziert wurde, sowie die empfohlene Reparaturmaßnahme angibt. Der Techniker kann diese Einzelheiten nach Belieben in einem strukturierten oder unstrukturierten Format eingeben. Bei der Verarbeitung natürlicher Sprache (Natural Language Processing, NLP) stellt die Satzgrenzenbestimmung insofern ein Problem dar, als es gilt, zu bestimmen, wo der Satz beginnt und endet. Zur Bestimmung der Satzgrenze wird der Punkt als Satzbegrenzungszeichen herangezogen. Um zu bestimmen, dass der Punkt tatsächlich eine Satzgrenze darstellt, im Gegensatz zu Interpunktionszeichen wie etwa bei einer Abkürzung, werden nachfolgend verschiedene Regeln vorgeschlagen, die dazu dienen, die Servicereparatur-Berichtwortlaute in Sätze aufzuteilen:
Regel 1 – Ist ein Term-Token mit einem ”Punkt” verkettet, auf welchen ein Leerraum folgt und handelt es sich bei dem ersten Zeichen eines auf einen solchen Leerraum folgenden Terms um ein großgeschriebenes Buchstabenzeichen, z. B. ”door. Fixed ...”, so wird dieser Punkt als eine gültige Satzgrenze betrachtet.
Regel 2 – Ist ein Term-Token mit einem ”Punkt” verkettet, so wird es mit einer von dem Fahrzeughersteller bereitgestellten Standard-Abkürzungsliste verglichen, um sicherzustellen, dass es sich um eine gültige Abkürzung handelt, z. B. ”PCM.”. Folgt auf die gültige Abkürzung ein Leerraum und handelt es sich bei dem ersten Zeichen eines darauf folgenden Terms um ein großgeschriebenes Zeichen, z. B. ”brkn. Fixed...', so wird ein Punkt als eine gültige Satzgrenze betrachtet.
Regel 3 – Ist eine gültige Abkürzung mit einem ”Punkt” verkettet und ist diese an beiden Seiten von den Phrasen umgeben, z. B. ”the door is brkn. so it is fixed”, so wird der ”Punkt” nicht als eine gültige Satzgrenze betrachtet.
Regel 4 – Ist ein ”Punkt” an seiner linken und rechten Seite mit Ganzzahlen ohne Leerräume dazwischen verkettet, z. B. ”0.5 olh is claimed”, so wird der ”Punkt” nicht als eine gültige Satzgrenze behandelt.
Regel 5a – Ist ein ”Punkt” mit einem Buchstabenzeichen verkettet, dem ohne Leerraum dazwischen ein weiteres Buchstabenzeichen folgt, und ist das zweite Buchstabenzeichen mit einem Punkt verkettet, beispielsweise so wird der ”Punkt” nicht als eine gültige Satzgrenze betrachtet.
Regel 5b – Ist ein ”Punkt” mit einem Buchstabenzeichen verkettet, dem ohne Leerraum dazwischen ein zweites Buchstabenzeichen folgt, das ohne Leerraum dazwischen mit einem ”Punkt” verkettet ist und befinden sich nach dem zweiten ”Punkt” keine Zeichenketten, so wird der zweite ”Punkt” als eine gültige Satzgrenze betrachtet, z. B. ”we haue to meet at 5 p. m.” (Satzende).
Die oben erwähnten Regeln können in modifizierter Form auch für die Handhabung anderer Interpunktionszeichen, wie etwa, ohne Anspruch auf Vollständigkeit, Bindestriche (–), Unterstriche (_), Fragezeichen (?), Rufzeichen (!), Doppelpunkte (:) und Strichpunkte (;) verwendet werden.
In Block 22 wird, nachdem der Servicereparatur-Berichtwortlaut in entsprechende Sätze zerlegt worden ist, ein Tokenisierungsverfahren eingeleitet, indem die Leerräume entfernt werden, während die häufig vorkommenden Begrenzungszeichen, wie weiter oben beschrieben, Berücksichtigung finden.
In Block 23 werden nach der Durchführung des Schritts der Tokenisierung innerhalb des Servicereparatur-Berichtwortlauts vorhandene Stoppwörter gelöscht. Stoppwörter verursachen, während die Daten einer natürlichsprachlichen Verarbeitung (Natural Language Processing) unterzogen werden, ein unnötiges Rauschen in den Daten. Stoppwörter bestehen, ohne Anspruch auf Vollständigkeit, aus Wörtern wie ”ein”, ”einer”, ”eine”, ”der”, ”die”, das”, ”welche/r/s”, ”www”, ”weil” und ”wird”, die als nichtbeschreibend zu betrachten sind. Es versteht sich allerdings, dass Stoppwörter, welche Bestandteil von Symptom-Phrasen sind, nicht gelöscht werden sollen. Daher wird jede erkannte Symptom-Phrase mit einer Stoppwortliste abgeglichen. Stoppwörter, die in der Stoppwortliste identifiziert werden und Bestandteil von Symptom-Phrasen sind, werden von einem Stoppwort-Löschalgorithmus ignoriert.
In Block 24 werden sämtliche Maßnahme-Wörter bzw. -Phrasen und Symptom-Wörter bzw. -Phrasen auf ihren Wortstamm zurückgeführt. Durch die Wortstammrückführung (Stemming) werden flektierte Wörter auf ihre jeweiligen Grundformen reduziert. Es ist jedoch wichtig, zu verstehen, dass nicht alle stammrückgeführten Wörter mit der morphologischen Wurzel des Wortes identisch sind. Als Beispiel für die Wortstammrückführung ist etwa ein Servicereparatur-Berichtwortlaut anzuführen, der ein Symptom enthält, das in verschiedenen sprachlichen Formen, wie beispielsweise ”leaking”, ”leaked” und ”leaks” geschrieben ist. Durch den Wortstamm-Rückführalgorithmus werden alle diese verschiedenen Formen auf ihren Grund-Term ”lenk” zurückgeführt.
In Block 25 wird ein lexikalisches Vergleichsverfahren angewendet, wobei die stammrückgeführten Maßnahme- und Symptom-Token zusammen mit den Bauteil-Token unter Durchführung eines Volltext-Zeichenkettenabgleichs mit den Bauteil-Konzepten aus den entsprechenden Konzepten in der D&P-Ontologie verglichen werden. In verschiedenen Beispielfällen ist dasselbe Bauteil-Token in Form von unterschiedlichen sprachlichen Variationen, z. B. ”Powertrain Control Module”, ”PC Module” und ”PCM” dargestellt. Zum Zweck der Disambiguierung zwischen den Bauteil-Token wird durch das lexikalische Vergleichsverfahren jede sprachliche Variation des Bauteil-Tokens mit ein- und demselben Grundwort in Beziehung gesetzt, welches jeweils den entsprechenden Bauteilen in der D&P-Ontologie zugeordnet wird. Aufgrund der Tatsache, dass die jeweiligen Symptom-Token mehrere Bedeutungen haben (z. B. kann das Token TPS entweder für 'tank Pressure sensor (Tankdrucksensor) oder für 'tire pressure sensor' (Reifendrucksensor) stehen) stellt das lexikalische Vergleichsverfahren eine spezielle Methode zum Identifizieren der korrekten Interpretation eines Symptoms bereit. Das lexikalische Vergleichsverfahren berücksichtigt die Nachbarwörter, die jeweils zusammen mit jeder Bedeutung eines Symptom-Tokens vorkommen.
Das lexikalische Vergleichsverfahren baut zunächst alle möglichen {Symptom_i Bauteil_k}- und {Symptom_i Maßnahme_l}-Paare auf, die in einem Servicereparatur-Berichtwortlaut vorkommen. Anschließend wird eine Überprüfung durchgeführt, um eine Häufigkeit eines jeden (Symptom_i Bauteil_k}- und {Symptom_i Maßnahme_l}-Paars über den gesamten Korpus von Servicereparatur-Berichtwortlauten hinweg zu bestimmen und dadurch zu ermitteln, wie viele Male jedes Paar in dem Korpus vorkommt.
Das Symptom-Token, Symptom_i, welches die höchste Anzahl von Bauteilen und Maßnahmen aufweist, die gemeinsam mit dem Symptom_i vorkommen, wird als der korrekte symptomspezifische Inhalt innerhalb des Servicereparatur-Berichtwortlauts behandelt. Darüber hinaus wird eine spezielle heuristische Regel eingeführt, um repetitive und zeitaufwändige Iterationen bei der Identifizierung der im Servicereparatur-Berichtwortlaut stehenden Störfall-Diagnosecode-Zeichenkette zu vermeiden. So enthält beispielsweise eine Symptom-Abschnitt-Datenbank über 6000 Störfall-Diagnosecodes (Diagnostic Trouble Codes, DTCs) und es müsste somit in einem Schlimmstfall-Szenario der Algorithmus 6000 Iterationen durchlaufen, um die in dem Servicereparatur-Berichtwortlaut verwendete DTC-Zeichenkette abzugleichen. Um diese Anzahl von Iterationen beim Abgleich der DTC-Zeichenkette zu vermeiden, wird eine heuristische Regel, wie etwa die nachfolgende, beispielhafte heuristische Regel eingeführt: ”Handelt es sich bei dem ersten Zeichen eines Tokens um ein Zeichen zwischen ”a bis z”, folgt darauf eine Ziffer zwischen ”0 bis 9” und beträgt die Länge eines Tokens 5 Zeichen, so wird das Token als ein Störfall-Diagnosecode (DTC) neu formatiert”.
3 veranschaulicht ein Blockdiagramm einer semantikbasierten Extraktionslogik. In Block 41 wird der Extraktionsprozess eingeleitet, indem verschiedene Kombinationen aus Bauteil-Termen, Symptom-Termen und Malinahme-Termen extrahiert werden. Die Anzahl verschiedener Kombinationen, die dabei ausgewählt werden, wird von den spezifischen Anforderungen des Benutzers bestimmt. Die semantikbasierte Extraktionslogik erlaubt es Endbenutzern, unter Verwendung der extrahierten Informationen die verschiedenen Cluster von Servicereparatur-Berichtwortlauten aufzubauen. Die semantikbasierte Extraktionslogik erlaubt es dem Benutzer, zu spezifizieren, welche strukturierten Informationen extrahiert werden müssen. Die verschiedenen Kombinationen können in Form von Dreifachkombinationen, Doppelkombinationen oder Einzeltermen extrahiert werden.
In Block 42 ist die semantikbasierte Extraktion in Form eines Einzelterms dargestellt. Im Hinblick auf eine Extraktion nach Termen bedeutet dies, dass Terme als ein Bauteil-Term, ein Maßnahme-Term oder ein Symptom-Term extrahiert werden können.
In Block 43 ist die semantikbasierte Extraktion als eine Paar-Kombination dargestellt. Für eine extrahierte Paar-Kombination können die verschiedenen Kombinationsformen umfassen {Bauteil, Maßnahme}, {Bauteil, Symptom} und {Maßnahme, Symptom}.
In Block 44 ist die semantikbasierte Extraktion als eine Dreifachkombination dargestellt. Für eine extrahierte Dreifachkombination werden alle drei Terme {Bauteil, Symptom, Maßnahme}, oder Kombinationen daraus, wie beispielsweise {Symptom, Bauteil, Maßnahme}, {Maßnahme, Symptom, Bauteil} extrahiert.
Unter Verwendung der extrahierten Terme und/oder Kombinationen werden daraufhin in Block 50 Cluster gebildet. Es versteht sich, dass die Häufigkeit eines/einer jeden der extrahierten Terme oder Kombinationen gesammelt werden, um die wichtigsten Sachverhalte, die in den Servicereparatur-Berichtwortlauten häufig Erwähnung finden, zu identifizieren.
Die Clusterbildung wird dazu verwendet, die Servicereparatur-Berichtwortlaute in Abhängigkeit von den Termen und Kombinationen zu sammeln, die durch semantikbasierte Extraktionslogik extrahiert worden sind. Der Vorteil des hier Beschriebenen liegt darin, dass es durch die Clusterbildung möglich wird, häufig gemeinsam vorhandene Kombinationen, wie sie weiter oben beschrieben sind, zu berücksichtigen. Unter Verwendung der folgenden Schritte werden die Servicereparatur-Berichtwortlaute in Abhängigkeit von den extrahierten Termen und Kombinationen zu Clustern gruppiert.
In Schritt 51 erfolgt die Satzgrenzenbestimmung und wird der Servicereparatur-Berichtwortlaut in verschiedene Sätze aufgeteilt. Jeder aufgeteilte Satz wird auf das Vorhandensein von Termen und Kombinationen hin analysiert.
In Schritt 52 wird der bauteilbasierte Cluster aufgebaut. Jeder extrahierte Bauteil-Term wird mit jedem Satz in jedem Servicereparatur-Berichtwortlaut verglichen. Im Fall einer Obereinstimmung mit dem Bauteil-Term wird ein Index des Servicereparatur-Berichtwortlauts gesammelt und als Bestandteil des Clusters aufgezeichnet. Sämtliche für den betreffenden Bauteil-Term erfassten Indices der gesammelten Servicereparatur-Berichtwortlaute bilden jeweils einen Cluster. Somit bildet jeder Bauteil-Term jeweils einen entsprechenden Cluster.
In Schritt 53 wird der Bauteil-Symptom-Cluster aufgebaut. Der identifizierte Bauteil-Term wird in jedem aufgeteilten Satz als Fokus-Term festgelegt. Eine bestimmte Anzahl von Wörtern links von dem Fokus-Term und eine bestimmte Anzahl von Wörtern rechts von dem Fokus-Term bilden ein Fenster. Die folgenden beiden Schritte werden dazu verwendet, die Paar-Cluster zu bilden.
In Schritt 53a wird das Kombinationspaar aufgebaut, wenn ein einzelnes Symptom in einem Fenster vorkommt. Die Häufigkeit, mit welcher die Paar-Kombination vorkommt, wird aus einem jeden der Servicereparatur-Berichtwortlaute bestimmt, um zu ermitteln, ob die Häufigkeit der Paar-Kombination höher als ein minimaler Häufigkeitsschwellenwert ist. Eine Paar-Kombination mit einer Häufigkeit, die höher als der minimale Häufigkeitsschwellenwert ist, wird als eine gültige {Bauteil_i, Symptome_j}-Paar-Kombination betrachtet. Die Indices aller für die betreffende Paar-Kombination erfassten Servicereparatur-Berichtwortlaute bilden jeweils einen entsprechenden Cluster.
In Schritt 53b wird, sofern mehrere Symptome in einem Fenster vorkommen, die jeweilige Distanz zwischen Bauteil-Term und jedem einzelnen Symptom bestimmt. Das am nächsten bei dem Bauteil-Term gelegene Symptom wird ausgewählt, um die Bauteil-Kombination mit dem Bauteil-Term {Bauteil_i, Symptom_j} aufzubauen. Die Häufigkeit, mit welcher die Paar-Kombination vorkommt, wird aus einem jeden der Servicereparatur-Berichtwortlaute bestimmt, um jeweils zu ermitteln, ob die Häufigkeit der Paar-Kombination höher als ein minimaler Häufigkeitsschwellenwert ist. Eine Paar-Kombination mit einer Häufigkeit, die höher als der minimale Häufigkeitsschwellenwert ist, wird als eine gültige Paar-Kombination betrachtet. Die Indices aller für die betreffende Paar-Kombination erfassten Servicereparatur-Berichtwortlaute bilden jeweils einen entsprechenden Cluster.
In Schritt 54 wird ein Bauteil-Symptom-Maßnahme-Cluster aufgebaut. Ein Fokus-Term (d. h. Symptom) wird in jedem aufgeteilten Satz bestimmt. Eine bestimmte Anzahl von Wörtern links von dem Fokus-Term und eine bestimmte Anzahl von Wörtern rechts von dem Fokus-Term bilden ein Fenster. Die folgenden beiden Schritte werden dazu verwendet, die Paar-Cluster zu bilden.
In Schritt 54a wird, sofern eine einzelne Maßnahme in einem Fenster vorkommt, die Dreifachkombination aufgebaut. Die Häufigkeit, mit welcher die Dreifachkombination vorkommt, wird aus einem jeden der Servicereparatur-Berichtwortlaute bestimmt, um zu ermitteln, ob die Häufigkeit der Paar-Kombination höher als ein minimaler Häufigkeitsschwellenwert ist. Eine Dreifachkombination mit einer Häufigkeit, die höher als der minimale Häufigkeitsschwellenwert ist, wird als eine gültige {Bauteil_i, Symptom_j, Maßnahme_k}-Dreifachkombination betrachtet. Die Indices aller für die betreffende Dreifachkombination erfassten Servicereparatur-Berichtwortlaute bilden jeweils einen entsprechenden Cluster.
In Schritt 54b wird, wenn mehrere Maßnahmen in einem Fenster vorkommen, jeweils der Abstand einer jeden Maßnahme von dem Symptom bestimmt. Die am nächsten zu dem Symptom gelegene Maßnahme wird ausgewählt, um die Dreifachkombination mit Bauteil-Term und Maßnahme {Bauteil_i, Symptom_j, Maßnahme_k) aufzubauen. Die Häufigkeit, mit welcher die Dreifachkombination vorkommt, wird aus einem jeden der Servicereparatur-Berichtwortlaute bestimmt, um jeweils zu ermitteln, ob die Häufigkeit der Dreifachkombination höher als ein minimaler Häufigkeitsschwellenwert ist. Eine Dreifachkombination mit einer Häufigkeit, die höher als der minimale Häufigkeitsschwellenwert ist, wird als eine gültige Dreifachkombination betrachtet. Die Indices aller für die betreffende Dreifachkombination aufgezeichneten Servicereparatur-Berichtwortlaute bilden jeweils einen entsprechenden Cluster.
Nachdem das Clusterbildungsverfahren durchgeführt worden ist, können Dokumente (Servicereparatur-Berichtwortlaute) vorhanden sein, die sich in zwei getrennten Cluster befinden und die dieselben Informationen enthalten. Das heißt, dass aufgrund der ähnlichen definitiven Bedeutung bestimmter Terme Gruppen von Servicereparatur-Berichtwortlauten in verschiedenen Clustern als Dubletten vorhandenen sein können. Cluster 1, der einen Bauteil-Symptom-Kombinationscluster umfasst, enthält beispielsweise einen Servicereparatur-Berichtwortlaut mit der Information {Radio, funktionsunfähig}. Cluster 2 umfasst einen Bauteil-Symptom-Kombinationscluster, der einen Servicereparatur-Berichtwortlaut mit der Information {Compact-Disc-Player, funktionsunfähig} enthält. Unter solchen Umständen enthalten Cluster 1 und Cluster 2 im Wesentlichen dieselben Informationen betreffend dasselbe Elektronik-Modul. In einem solchen Fall werden die beiden Cluster zu einem Meta-Cluster (z. B. Cluster 3) zusammengefasst, der nunmehr aus Servicereparatur-Berichtwortlauten besteht, die dem Elektronik-Modul zugeordnet sind, so dass der Sachgebietsexperte oder dergleichen auf einer aggregierten Ebene eine Gesamteinsicht in das mit dem Elektronik-Modul in Zusammenhang stehende Problem erhält.
Graphen, wie beispielsweise Pareto-Analysen, können von einem Sachgebietsexperten oder dergleichen zu Analysenwecken erzeugt werden. Es folgen Beispiele für gesuchte Terme oder Kombinationen, die in Form von grafischen Inhalten ausgegeben werden können. Die Graphenanalyse ermöglicht es dem Sachgebietsexperten, sich auf spezifische Kombinationen von Termen zu konzentrieren, und dabei auch die Arbeitscodes zu berücksichtigen, um zu bestimmen, ob die Servicereparatur-Berichtwortlaute korrekt gruppiert sind. Ein Sachgebietsexperte kann sich beispielsweise dafür interessieren, nur jene Felddaten durchzusehen, die den Bauteil-Cluster betreffen, was zur Folge hätte, dass die am häufigsten wiederkehrenden Bauteile (d. h. Ursachen) aus der Datenbank ausgewählt werden. Wenn sich der Sachgebietsexperte dafür interessiert, die am häufigsten zugeordneten Symptome (d. h. Problemlagen), die mit jeder Ursache (d. h. jedem Bauteil) verbunden sind, durchzusehen, so wird ein Paretodiagramm der Analyse erzeugt. Es kann sodann ein Graph erzeugt werden, welcher die Paar-Kombination, wie beispielsweise {Batterie-Leer}, {Batterie-Funktionsunf} und {Batterie-Leck} anzeigt. Darüber hinaus werden vom Sachgebietsexperten in jenen Fällen Graphen erzeugt, in denen es darum geht, als Beispiel ohne einschränkenden Charakter, nach folgenden Kriterien auszusondern: Servicezentren, Produktionsdatum, Fahrzeugmodell und Fahrzeugmarke.
Während gewisse Ausführungsformen der vorliegenden Erfindung hier im Detail beschrieben worden sind, sind für den Fachmann auf dem Gebiet, zu welchem diese Erfindung gehört, verschiedene alternative Entwürfe und Ausführungsformen für die Umsetzung der Erfindung erkenntlich, die durch die nachfolgenden Ansprüche definiert ist.

Claims

Verfahren zum Extrahieren von Daten aus Servicereparatur-Berichtwortlauten in einem Fahrzeugservice-Berichtssystem, wobei jeder Servicereparatur-Berichtwortlaut die Kommentare eines Technikers betreffend ein Bauteil, ein dem Bauteil zugeordnetes Symptom, und eine dem Symptom zugeordnete Reparaturmaßnahme umfasst, wobei das Verfahren die Schritte umfasst, dass: Servicereparatur-Berichtwortlaute aus einem Fahrzeugservice-Berichtssystem gesammelt werden, wobei jeder Servicereparatur-Berichtwortlaut Informationen betreffend ein identifiziertes Problem im Zusammenhang mit zumindest einem Fahrzeugbauteil umfasst; eine Diagnose- und Prognose-Ontologiedatenbank bereitgestellt wird, die durch eine Fahrzeugbauteilklassifizierung, eine Fahrzeugbauteil-Unterklassen-Klassifizierung und eine Beziehungsklassifizierung strukturiert ist, wobei die Beziehungsklassifizierung Symptom-Beziehungen und Maßnahme-Beziehungen umfasst; jeder der Servicereparatur-Berichtwortlaute unter Verwendung der Diagnose- und Prognose-Ontologiedatenbank strukturiert wird; Kombinationen von Informationen aus den strukturierten Servicereparatur-Berichtwortlauten in Abhängigkeit von Benutzer-Eingabekriterien extrahiert werden; eine Häufigkeit jeder extrahierten Kombination in den strukturierten Servicereparatur-Berichtwortlauten bestimmt wird, und die Servicereparatur-Berichtwortlaute für jede Kombination zu einem Cluster gruppiert werden.
Verfahren nach Anspruch 1, wobei das Strukturieren jedes Servicereparatur-Berichtwortlauts umfasst, dass jeder betreffende Servicereparatur-Berichtwortlaut jeweils in einen oder mehrere Sätze aufgetrennt wird.
Verfahren nach Anspruch 2, wobei das Strukturieren jedes Servicereparatur-Berichtwortlauts umfasst, dass Bauteil-Wörter, Symptom-Wörter und Reparaturmaßnahme-Wörter in jedem Servicereparatur-Berichtwortlaut identifiziert werden.
Verfahren nach Anspruch 3, wobei das Strukturieren jedes Servicereparatur-Berichtwortlauts eine Tokenisierung umfasst, bei der unwichtiges Wortmaterial, unwichtige Zeichen und Freiräume aus jedem Servicereparatur-Berichtwortlaut entfernt werden.
Verfahren nach Anspruch 4, wobei das Strukturieren jedes Servicereparatur-Berichtwortlauts durch Entfernen unwichtigen Wortmaterials umfasst, dass zumindest einige Stoppwörter aus dem Servicereparatur-Berichtwortlaut entfernt werden.
Verfahren nach Anspruch 3, wobei das Strukturieren jedes Servicereparatur-Berichtwortlauts umfasst, dass für jeden Servicereparatur-Berichtwortlaut bei Symptom-Wörtern und Reparaturmaßnahme-Wörtern eine Wortstammrückführung durchgeführt wird, wobei die Wortstammrückführung umfasst, dass die Symptom-Wörter und Reparaturmaßnahme-Wörter auf ihre Grundform zurückgeführt werden.
Verfahren nach Anspruch 3, wobei das Extrahieren von Kombinationen von Informationen aus den strukturierten Servicereparatur-Berichtwortlauten umfasst, dass Kombinationen von zumindest zwei Termen aus den identifizierten Bauteil-Wörtern, Symptom-Wörtern und Reparaturmaßnahme-Wörtern des Serviceberichtworllauts extrahiert werden.
Verfahren nach Anspruch 2, wobei das Gruppieren der Servicereparatur-Berichtwortlaute zu Clustern umfasst, dass zumindest ein bauteilbasierter Cluster gebildet wird, wobei jeweils ein bauteilbasierter Cluster mit Servicereparatur-Berichtwortlauten aufgebaut wird, die eine entsprechende Bauteil-Bezeichnung in jedem Servicereparatur-Berichtwortlaut aufweisen, wobei Indices jener Servicereparatur-Berichtwortlaute, welche die betreffende Bauteil-Bezeichnung enthalten, gruppiert werden, um den entsprechenden bauteilbasierten Cluster zu bilden.
Verfahren nach Anspruch 2, wobei das Gruppieren der Servicereparatur-Berichtwortlaute zu Cluster umfasst, dass zumindest ein Bauteil-Symptom-Cluster gebildet wird, wobei jeweils ein Bauteil-Symptom-Cluster mit Servicereparatur-Berichtwortlauten aufgebaut wird, die eine entsprechende Bauteil-Bezeichnung samt zugeordnetem Symptom in jedem Servicereparatur-Berichtwortlaut aufweisen, wobei Indices jener Servicereparatur-Berichtwortlaute, welche die betreffende Bauteil-Bezeichnung und das zugeordnete Symptom enthalten, gruppiert werden, um den entsprechenden Bauteil-Symptom-Cluster zu bilden.
Verfahren nach Anspruch 2, wobei das Gruppieren der Servicereparatur-Berichtwortlaute zu Cluster umfasst, dass zumindest ein Bauteil-Symptom-Maßnahme-Cluster gebildet wird, wobei jeweils ein Bauteil-Symptom-Maßnahme-Cluster mit Servicereparatur-Berichtwortlauten aufgebaut wird, die eine entsprechende Bauteil-Bezeichnung samt zugeordnetem Symptom und samt zugeordneter Reparaturmaßnahme in jedem Servicereparatur-Berichtwortlaut aufweisen, wobei Indices jener Servicereparatur-Berichtwortlaute, welche die betreffende Bauteil-Bezeichnung, das zugeordnete Symptom und die zugeordnete Reparaturmaßnahme enthalten, gruppiert werden, um den entsprechenden Bauteil-Symptom-Maßnahme-Cluster zu bilden.