Ein Fehler im Elektroniksystem ist selten dort, wo er sich zeigt. Die App macht die Verbindungen zwischen Symptom, Komponente, Design und Anforderung dort sichtbar, wo sie ohnehin existieren: im Product Knowledge Graph.
Wer schon einmal in einem Engineering-Team Verantwortung für eine Fehleranalyse getragen hat, kennt das Muster. Ein Fehler taucht in der Integration auf, ein Kunde meldet eine Anomalie aus dem Feld, ein Test schlägt im Regressionslauf reproduzierbar fehl. Dann beginnt die Suche, und sie dauert. Wer hat zuletzt etwas an dieser Komponente geändert? Welche Schnittstelle ist betroffen? Welche Anforderung steht dahinter? In welcher Firmware-Version lief das noch sauber? Welche Bauteil-Revision war im fehlerhaften Gerät verbaut?
Das ist nicht ein Problem mangelnder Sorgfalt. Es ist ein Problem fehlender struktureller Verbindungen zwischen den Datenquellen, in denen die Antworten verstreut liegen.
Die Voraussetzung für wirksame KI-Unterstützung ist nicht ein besseres Sprachmodell, sondern eine bessere Datenstruktur. Sobald die Verbindungen zwischen Anforderung, Architektur, Komponente, Bauteil-Revision, Firmware-Stand, Testfall und Fehlermeldung im Knowledge Graph liegen, kann die KI von einem Symptom aus systematisch die wahrscheinlichen Ursachen-Pfade traversieren.
Fehlerbild, betroffene Komponente, Bedingungen unter denen es auftritt. Die App ergänzt automatisch betroffene Bauteil-Revisionen, beteiligte Software-Versionen, kürzliche Designänderungen und verwandte Fehlerberichte aus dem Graphen.
Die KI schlägt Ursachen-Hypothesen vor, geordnet nach Plausibilität, jeweils mit Begründung („diese Hypothese wird gestützt durch eine Änderung an Komponente X vor 14 Tagen, die laut FMEA das Risiko Y einführt").
Auf Anfrage Schaltplan-Auszüge, Test-Ergebnisse, Anforderungs-Historie, ohne dass jemand händisch in fünf Tools suchen muss.
Die identifizierte Ursache wird im Graphen verankert. Die Beziehung „dieser Defekt wurde verursacht durch jene Designentscheidung" wird Teil des Engineering-Wissens, sodass dasselbe Symptom in einem späteren Projekt sofort erkannt wird.
Eine Ursache ist selten ein einzelner Punkt. Zwischen der eigentlichen Wurzelursache und dem sichtbaren Symptom liegt fast immer eine Kette von Zwischenwirkungen: Eine geänderte Toleranz an einem Bauteil verschiebt ein Timing, das Timing verletzt eine Busspezifikation, die Verletzung löst einen sporadischen Reset aus, der Reset zeigt sich dem Kunden als gelegentlicher Funktionsausfall. Wer nur das letzte Glied betrachtet, behandelt das Symptom; wer die ganze Wirkkette (engl. failure chain) sieht, findet die Stelle, an der die Korrektur wirklich greift.
Im Product Knowledge Graph sind diese Wirkketten keine nachträgliche Rekonstruktion, sondern ergeben sich aus den ohnehin vorhandenen Beziehungen. Die App traversiert die Kausalpfade entlang der verknüpften Anforderungen, Komponenten, Schnittstellen und Fehlerereignisse und macht Fehlerfortpflanzung über Domänengrenzen hinweg sichtbar, also genau dort, wo eine domänenfokussierte Analyse die Verbindung oft übersieht. Jedes Kettenglied trägt seine Evidenz mit sich, sodass nachvollziehbar bleibt, warum ein Knoten als Teil der Wirkkette gilt und nicht nur als zufällige Korrelation.
Diese Sicht auf die gesamte Kette hat zwei praktische Effekte. Erstens lassen sich Korrekturmaßnahmen am wirksamsten Glied ansetzen statt am auffälligsten. Zweitens werden gemeinsame Ursachen erkennbar, wenn mehrere scheinbar unabhängige Symptome auf dasselbe frühe Kettenglied zurücklaufen, ein Muster, das ohne durchgängige Wirkkette häufig als mehrere getrennte Probleme fehlinterpretiert wird.
Aus einer Fehlerbeschreibung leitet die App die im Graphen verbundenen Komponenten, Schnittstellen, Anforderungen und Tests ab und identifiziert die wahrscheinlichsten Pfade vom Symptom zur Ursache. Was ein Mensch manuell durch Klicken in DOORS, Polarion, Git und PLM rekonstruieren würde, läuft als zusammengefasste Sicht.
Mehrere Ursachen-Hypothesen mit konkreter Begründung aus dem Graphen: welche kürzlichen Designänderungen, welche bekannten Risiken aus der FMEA, welche ähnlichen Fälle aus der Vergangenheit. Das verschiebt die Diskussion von „wir wissen es noch nicht" zu „wir haben drei begründete Hypothesen".
Klassische Analyse-Methoden bleiben relevant, die App füllt sie mit Daten. Bei 5-Why für jedes „Warum?" die im Graphen verankerten Antworten; bei Ishikawa strukturiert sie die bekannten Einflussfaktoren entlang der Kategorien (Mensch, Maschine, Material, Methode, Mitwelt, Messung).
Eine identifizierte Ursache wird automatisch mit der relevanten FMEA-Analyse verbunden (war das Risiko schon bekannt und wurde übersehen?). Gleichzeitig wird geprüft, ob ein bestehender Testfall das Problem hätte erkennen sollen, und falls nein, wird ein konkreter neuer Test vorgeschlagen.
Software, Hardware und Mechanik separat entwickelt, in der Systemintegration zeigt sich ein Problem, das in keinem Einzeltest aufgetreten ist. Die App nutzt Cross-Domain-Verbindungen im Graphen, um Hypothesen zu generieren, die ein domänen-fokussierter Mensch oft nicht zuerst betrachten würde: Timing-Verletzung im Bus mit kürzlich geänderter Sensor-Konfiguration; EMV-Anomalie mit Layout-Änderung der Stromversorgung.
Kunden melden Defekte aus dem Feld mit lückenhaften Informationen. Die App rekonstruiert fehlende Bauteil-Revisionen und Software-Versionen aus Liefer- und PLM-Daten, findet ähnliche bereits geklärte Fälle. Wenn die Ursache identifiziert ist, lässt sich aus dem Graphen direkt ableiten, welche anderen ausgelieferten Geräte dieselbe Konfiguration tragen, Grundlage für gezielte Service-Aktionen statt pauschaler Rückrufe.
Im Zusammenspiel mit Reklamations- und CAPA-Prozessen ist „was ist die wahre Ursache, was müssen wir am Prozess oder Design ändern" oft die heikelste Frage. Die App verknüpft die Reklamation mit möglichen Design- und Prozessursachen und generiert Vorschläge für die Wirksamkeitsprüfung der Korrekturmaßnahme.
Es gibt mittlerweile mehrere Werkzeuge, die KI für Fehleranalyse einsetzen. Was die Fehlerursachenanalyse-App von ihnen unterscheidet, ist nicht das Sprachmodell. Es ist die Datenbasis, auf der sie operiert.
Der Product Knowledge Graph hält die Beziehungen zwischen Anforderung, Architektur, Komponente, Bauteil-Revision, Firmware-Version, Testfall, FMEA-Eintrag und Fehlerbericht explizit und versioniert vor. Eine Defekt-Meldung ist nicht nur ein Text-String in einem Ticket-System, sondern ein Knoten im Graphen, der mit allen relevanten Engineering-Artefakten verbunden ist. Die Traversierung vom Symptom zur Ursache ist deshalb eine Graph-Abfrage, nicht eine Volltextsuche. Sie liefert nicht „Texte, die ähnliche Wörter enthalten", sondern „Komponenten, die strukturell mit dem Symptom in Verbindung stehen, und die Designentscheidungen, die sie geprägt haben".
Dass das im deutschsprachigen Markt bisher kaum jemand so kombiniert, ist der Grund, warum die App in den ersten Pilotprojekten oft eine deutlich höhere Trefferquote in den ersten Hypothesen liefert als generische KI-Ansätze.
So leistungsfähig die Hypothesen-Generierung ist, die Verantwortung für die identifizierte Ursache und die abgeleitete Korrekturmaßnahme bleibt beim Team. Eine falsche Wurzelursache führt zu einer falschen Korrektur, und im Worst Case tritt der Fehler in einer leicht abgewandelten Form erneut auf. Die App schlägt Hypothesen vor, liefert die Evidenz aus dem Graphen und prüft die Konsistenz der vorgeschlagenen Korrektur mit anderen Anforderungen und Tests. Die Entscheidung, welche Hypothese die richtige ist und welche Korrektur umgesetzt wird, trifft das Engineering-Team. Jede KI-generierte Hypothese und jede vom Menschen bestätigte Ursache trägt im Graphen ihre Provenance: Wer hat wann mit welcher Datenlage entschieden. Damit sind die Voraussetzungen für die in regulierten Branchen (Automotive, Medizintechnik, Aerospace) verlangte Nachvollziehbarkeit gegeben, und die Ergebnisse einer Fehleranalyse können als Teil der Compliance-Argumentation verwendet werden.
Wenn aktuell eine Fehleranalyse stockt oder wiederkehrende Defektarten zu Reklamationen führen, ist das der natürliche erste Use Case.
Anforderungen, Architektur, Test-Ergebnisse, Bauteilstamm, Fehlerberichte. In den ersten Wochen liefert die App die ersten Hypothesen für den konkreten Fall.
Häufig wird sichtbar, wo die Datenbasis selbst noch Lücken hat (etwa fehlende Verknüpfungen zwischen Software-Versionen und Bauteil-Revisionen). Das Team kann gezielt diese Lücken schließen.
Erweiterung auf weitere Fehlerklassen, weitere Produkte und die systematische Speisung des Lessons-Learned-Wissens zurück in die Designentscheidungen.
Eine identifizierte Ursache zeigt oft, dass ein bestehender Testfall das Problem hätte erkennen sollen, oder dass ein neuer Test fehlt. Der Test Case Generator liefert direkt den konkreten Vorschlag.
Mehr zur Test-Case-GenerierungIdealerweise die Anforderungs- und Architektur-Quellen (Polarion, DOORS, Codebeamer, Cameo, Enterprise Architect), die Test- und CI/CD-Systeme (Vector CANoe, MATLAB/Simulink, GitHub, Jenkins, Azure DevOps), den Bauteilstamm aus dem PLM und das Fehler- bzw. Reklamationssystem (Jira, hauseigene Ticket-Systeme). In der Pilotphase reicht eine Teilmenge davon, der Wert wächst mit der Vollständigkeit der Datenbasis.
Die App entfaltet ihren Nutzen erst, wenn die relevanten Beziehungen im Graphen liegen. Der Graph entsteht aber im Zuge der Einführung schrittweise. Schon ein Pilot mit einer Teilmenge der Datenquellen liefert sichtbaren Mehrwert, und der Graph wächst mit jedem zusätzlichen Anwendungsfall.
Die App ersetzt diese Methoden nicht, sie füllt sie mit Daten. Eine 5-Why-Analyse bleibt eine 5-Why-Analyse, nur dass die App für jedes „Warum?" die im Graphen verankerten möglichen Antworten vorschlägt. Eine Ishikawa-Analyse bleibt eine Ishikawa-Analyse, nur dass die Faktoren mit konkreten Engineering-Datenpunkten unterlegt sind.
Eine identifizierte Ursache wird automatisch mit der relevanten FMEA-Analyse verbunden. War das Risiko dort schon bekannt und wurde übersehen, ist das ein wichtiger Befund für die Methodik. War es nicht enthalten, fließt die neue Erkenntnis in die FMEA zurück, sodass das nächste Projekt davon profitiert.
Sie ersetzt sie nicht, sie macht sie schneller und gründlicher. Die App übernimmt die mechanische Datenarbeit (Quellen durchsuchen, Versionsstände rekonstruieren, ähnliche Fälle finden), das Urteil über die wahrscheinlichste Ursache und die richtige Korrektur bleibt bei den Expert:innen.
Ja. Field Failure Analysis ist einer der drei typischen Anwendungsfälle. Aus lückenhaften Kundenmeldungen werden mithilfe von Liefer- und PLM-Daten die wahrscheinlichen Konfigurations-Stände rekonstruiert, und der Graph liefert sowohl die Hypothesen als auch die Liste der weiteren ausgelieferten Geräte, die möglicherweise betroffen sind.
Als Pilotkunde begleiten wir die Einführung von Anfang an und entwickeln die Lösung gemeinsam an Ihrem Use Case weiter.