Brückenkran Wissensgraph & Fehlerdiagnose mit Neo4j
Technische Lösung: Wissensgraph für die Fehlerdiagnose von Brückenkranen
Der Wissensgraph transformiert die im Brückenkran-Betrieb verstreuten Fehlerprotokolle, Wartungsaufträge, Ersatzteildaten und Geräteparameter in ein strukturiertes semantisches Netzwerk. Die technische Kette umfasst vier Ebenen: Datenschicht (Wartungsaufträge/Fehlerprotokolle/Sensoralarme/Ersatzteilwechsel/Industrienormen/Gerätehandbücher), Wissensextraktion (BiLSTM+CRF-Entitätserkennung + Relationsextraktion, F1=91,2%), Graphspeicherung (Neo4j Enterprise 5.x, Property-Graph-Modell, Knotenzahl ≥ 500.000) und Anwendungsebene (Fehlerdiagnose-Inferenz/Wartungsempfehlungen/Ähnlichkeitssuche/Intelligente Abfrage). Das System ist in der internen Wissensdatenbank von Kelude Schwerindustrie implementiert und deckt 8 Brückenkran-Typen, 243 Fehlermodi und 1.580 Fehlerfälle ab.
Die Fehlerdiagnose von Brückenkranen war bislang in hohem Maße von der individuellen Erfahrung der Wartungsingenieure abhängig. Über den gesamten Lebenszyklus eines Krans von 15 bis 20 Jahren – von der Installation bis zur Außerbetriebnahme – fallen mehrere hundert Wartungsaufträge und Fehlerprotokolle an. Diese über verschiedene Systeme (ERP, CMMS, Excel) verteilten strukturierten und semistrukturierten Daten wurden jedoch bislang nicht als wiederverwendbares Wissenskapital erschlossen. Die Wissensgraph-Technologie nutzt Entitätserkennung (NER), Relationsextraktion (RE) und Graphspeicherung (Neo4j), um diese fragmentierten Informationen in ein semantisches Assoziationsnetzwerk zwischen Gerät, Fehler, Ursache, Maßnahme und Ersatzteil zu überführen. Dieser Beitrag beschreibt auf Basis des internen Fehlerwissensdatenbank-Projekts der Kelude Schwerindustrie Gruppe die vollständige technische Implementierung von der Datenerfassung bis zur Graphabfrage und Inferenz. Die folgenden technischen Lösungen basieren auf der offiziellen Neo4j-Dokumentation (Neo4j Graph Data Science Manual v5.x, 2024), dem NLP-Toolkit HanLP (Version 2.1, 2023) sowie den praktischen Erfahrungen aus dem internen Fehlerwissensdatenbank-Projekt der Kelude Schwerindustrie (Projektnummer KL-KG-2024-001).
Wissensgraph für Kranfehler: Datenquellen und Entitätssystem
Die Daten für den Wissensgraph der Kranfehler stammen aus vier Dimensionen: ① Gerätedokumentation (Typ/Tragfähigkeit/Spannweite/Hubhöhe/Triebwerksgruppe/Seriennummer/Inbetriebnahmedatum); ② Fehleraufträge (Fehlerzeitpunkt/Gerätenummer/Fehlerbild/Fehlercode/Diagnoseprozess/Wartungsmaßnahme/gewechselte Ersatzteile/Wartungspersonal/Stillstandszeit); ③ Sensordaten (Schwingungseffektivwert/Temperatur/Strom/Historie der Überlastereignisse); ④ Industrienormen (einschlägige Fehlerbewertungsklauseln aus Norm DIN 15018, TSG 51 — Sicherheitstechnische Sondervorschrift für Sonderausrüstung, Norm FEM 1.001 u. a.). Nach der Entitäts- und Relationsextraktion werden insgesamt 6 Entitätstypen und 9 Beziehungstypen definiert:
| Entitätstyp | Tag-Name | Beispiel | Größenordnung |
|---|---|---|---|
| BrückenkranAusrüstung | Crane | QD32t-023/ LD10t-156 | 500+ |
| Fehlerbild | Fault | HebenLastrutschen/Schienenverschleiß des Brückenkrans/BremseUngewöhnliches Geräusch | 243Art |
| Fehlerursache | Cause | BremsbelagVerschleiß/RadlaufflächeGrübchenbildung/KupplungZahnflankeVerschleiß | 480+ |
| WartungMaßnahme | Action | AustauschBremsbelag/EinstellungBremsspiel/AustauschKupplung | 620+ |
| ErsatzteilMaterial | Part | YWZ5-315/23Bremse/LaufradZGY-600 | 1,200+ |
| Normklausel | Standard | Norm DIN 15018《Kran Konstruktion Spezifikation Erläuterung der Kernklauseln: Last/Struktur/Mechanismus/Elektrik/Fünf Sicherheitssysteme》 5.2.3 | 80+ |
| Beziehungstyp | Start- und Endpunkt | Beschreibung |
|---|---|---|
| has_fault | Crane Fault | Eine bestimmteBrückenkranEinen bestimmten Fehler aufgetreten |
| has_symptom | Fault | Einen bestimmten Fehler aufgetretenABegleitstörungBGleichzeitig auftreten |
| caused_by | Fault Cause | Ein Fehler wird durch eine Ursache verursacht |
| resolved_by | Fault Action | Ein Fehler wird durch eine Maßnahme behoben |
| uses_part | Action Part | Eine Maßnahme erfordert den Austausch von etwasErsatzteil |
| ref_standard | Fault Standard | FehlerbezogenNormklausel |
| similar_to | Fault | Einen bestimmten Fehler aufgetretenAMit dem FehlerBÄhnlich(Kosinus-Ähnlichkeit＞0.8) |
| located_in | Crane Location | BrückenkranLokalisiert inWerkstatt/Fertigungsabschnitt |
| occurred_at | Fault Time | Fehlerzeitpunkt |
Entity-Relation-Extraktion mit BiLSTM+CRF
Die Wissensextraktion ist der kritischste Schritt beim Aufbau des Graphen. Das System verwendet das Sequenzlabeling-Modell BiLSTM+CRF (Bidirektionales Langzeitkurzzeitgedächtnis + Conditional Random Fields) mit HanLP 2.1 als Vorverarbeitungspipeline (Tokenisierung + POS-Tagging + Dependency Parsing). Trainiert wurde das Modell auf 2.400 manuell annotierten Brückenkran-Fehlertexten. Das Annotationsschema folgt BIOES (Begin/Inside/Outside/End/Single), woraus sich 6 Entitätstypen × BIOES = 30 Label-Klassen ergeben.
Neo4j-Graphdatenbank und Cypher-Abfragen
Die extrahierten Tripel (Kopf-Entität – Relation – Schwanz-Entität) werden in der Graphdatenbank Neo4j Enterprise 5.x gespeichert. Das Datenmodell folgt dem Labeled Property Graph: Jeder Knoten trägt genau ein Label, Relationen besitzen Typ und Richtung. Datenumfang: ≥58.000 Knoten und ≥126.000 Relationen (Stand: Juni 2026).
Typische Cypher-Abfrage:
// Graphbasierte Fehlerdiagnose：Bei einem Brückenkran tritt auf"Lastrutschen beim Heben"，Empfohlene Fehlersuche und Ersatzteile MATCH path = (f:Fault {name: 'Lastrutschen beim Heben'})-[*1..2]-(n) WHERE ANY(label IN labels(n) WHERE n:Action OR n:Part OR n:Cause) RETURN path LIMIT 30// Ähnlichkeitsbasierte Fehlersuche（Basierend auf gemeinsamen Ursachen+der MaßnahmenJaccardÄhnlichkeit） MATCH (f1:Fault {name: 'Ungewöhnliches Geräusch der Bremse'})-[r1]->(n) MATCH (f2:Fault)-[r2]->(n) WHERE f2 <> f1 WITH f2, COUNT(DISTINCT n) AS common, COLLECT(DISTINCT n.name) AS shared_nodes ORDER BY common DESC LIMIT 5 RETURN f2.name, common, shared_nodesSemantische Inferenz und intelligente Fehlerdiagnose
Der eigentliche Mehrwert des Wissensgraphen liegt in der Inferenz (Reasoning). Das System unterstützt drei Inferenzmodi:
①Regelbasierte Inferenz – basierend auf einem vordefinierten Entscheidungsbaum für die Fehlerdiagnose (IF-THEN-Regelsatz, erstellt von 3 erfahrenen Brückenkran-Wartungsingenieuren, abdeckend 8 Gerätetypen × 243 Fehler × 480+ Ursachen, insgesamt 1.520 Regeln), umgesetzt als automatische Diagnose über Cypher-Graphtraversierung;
②Pfadranking-Inferenz – bei einem gegebenen Fehlerknoten werden Kandidaten für Wartungsmaßnahmen per Random Walk (Personalized PageRank, 20 Iterationen, Restart-Wahrscheinlichkeit 0,15) sortiert; die Top-3-Empfehlung erreicht eine Genauigkeit von 86,4% (Validierungsset N=500);
③Semantische Frage-Antwort – templatebasierte NL2Cypher-Transformation (natürliche Sprache → Cypher), unterstützt 12 Fragetemplates (z. B. „Welche Fehler sind bei Brückenkran XX aufgetreten?“ → MATCH(c:Crane)…).
Klassischer Ansatz vs. Wissensgraph: Vergleich im Überblick
| Vergleichselement | Traditioneller Ansatz(Relationale Datenbank+Stichwortsuche) | Wissensgraph-Ansatz(Neo4j+Semantische Inferenz) |
|---|---|---|
| Datenmodell | Zweidimensionale Tabelle,Fremdschlüssel-Beziehung | Eigenschaftsgraph,Knoten-Beziehung-Eigenschaft |
| Fehlerbezogene Abfrage | Mehrere TabellenJOIN(3~5Tabellen),Reaktionszeit500ms~3s | Graphdurchlauf,Reaktionszeit＜50ms |
| Mehrstufige Inferenz(Zum Beispiel:Fehlerursache-MaßnahmeErsatzteil) | Erfordert4MalSQLFehlerbezogene Abfrage+Zusammenstellung auf Anwendungsebene | EinmaligCypherGraphdurchlauf[1..4]Sprung |
| Ähnliche Fehlererkennung | Basiert auf Tag-Stichwortabgleich,Niedrige Präzision | Basiert auf GraphstrukturJaccardKosinus-Ähnlichkeit+PageRank |
| Wissenswiederverwendung | Abhängig von persönlicher Erfahrung,Wissensverlust durch Personalfluktuation | Persistente Speicherung des Wissensgraphen,Teamweite Freigabe |
| Kaltstart neuer Geräte | Erfordert ausreichende Fehleraufzeichnungen | Inferenz durch Übertragung der Graphstruktur ähnlicher Geräte möglich |
| Abfrageflexibilität | Vordefinierte Berichte,Ad-hoc-Abfragen erfordern Entwicklung | CypherAd-hoc-Abfrage,WebSelf-Service über die Oberfläche |
Häufig gestellte Fragen
F: Wie viele Daten benötigt der Wissensgraph, um praxistaugliche Ergebnisse zu liefern?
A: Für den Einstieg empfehlen wir mindestens 500 Fehlereinträge (jeweils mit Symptom, Ursache und Maßnahme). Das entspricht etwa 6.000–8.000 Entitäten und 12.000–15.000 Beziehungen. In dieser Größenordnung liegt die Trefferquote der Top-3-Fehlerempfehlungen bei über 70 %. Bei einem Datenbestand von 2.000+ Einträgen (dem aktuellen Umfang dieses Projekts) steigt die Genauigkeit auf 86 %. Für die Kaltstartphase können zunächst öffentlich zugängliche Fehlerdaten und Normen als Seed-Wissensbasis importiert werden.
F: Was ist der zentrale Unterschied zwischen Neo4j und MySQL/PostgreSQL bei der Verwaltung von Fehlerwissen?
A: Der entscheidende Unterschied liegt in der Effizienz von Mehrfachverknüpfungsabfragen. Für eine Abfrage wie „Wartungsmaßnahmen für Fehler, die denen eines bestimmten Brückenkrans ähneln“ benötigt MySQL 5–8 JOIN-Operationen (Antwortzeit im Sekundenbereich), und nachträgliche Erweiterungen der Beziehungsebenen sind bei fester Tabellenstruktur nur schwer möglich. Neo4j erledigt dies mit einem einzigen Cypher-Query über variable Pfadmuster wie `[*1..4]` – die Antwortzeit liegt unter 50 ms. Darüber hinaus unterstützt das Graphmodell von Natur aus horizontale Erweiterungen: Neue Entitäts- oder Beziehungstypen erfordern keine Änderung des Datenbankschemas.
F: Wie viele manuell annotierte Daten werden für die Extraktion von Entitäten und Beziehungen benötigt?
A: In diesem Projekt wurden 2.400 manuell annotierte Datensätze verwendet (28.600 Entitäten, 12.400 Beziehungen). Die Annotationskosten beliefen sich auf ca. 1.500 EUR (3 Annotatoren × 10 Tage × 50 EUR/Tag). Bei begrenztem Budget lässt sich alternativ die Methode des Distant Supervision einsetzen: Dabei werden die vorhandenen Ersatzteil-Stücklisten und Fehlercode-Tabellen genutzt, um automatisch schwache Annotationen zu erzeugen, die anschließend manuell geprüft werden. Dadurch reduziert sich der manuelle Aufwand auf 400–600 Datensätze – allerdings sinkt der F1-Score von 91,2 % auf etwa 85 %.
F: Reichen die 12 Vorlagen für die NL2Cypher-Suchabfragen aus?
A: Die 12 Vorlagen decken etwa 85 % der typischen Abfragen im Fehlerwissenssystem ab (basierend auf den internen Wartungsprotokollen von Kelude über 3 Monate). Die Vorlagen gliedern sich in drei Kategorien: Fehlerabfragen (Fehler eines bestimmten Geräts, Ursachen eines Fehlers, Maßnahmen zu einer Ursache), Ersatzteilabfragen (Ersatzteile für eine Maßnahme, Maßnahmen für ein Ersatzteil) sowie statistische Auswertungen (TOP-N-Fehlerfrequenz, Geräte mit den längsten Wartungsintervallen). Natürlichsprachliche Abfragen außerhalb dieser Vorlagen werden derzeit über Cypher-Syntaxhinweise mit manueller Vervollständigung abgefangen.
