Overhead Crane Fault Diagnosis Knowledge Graph with Neo4j
Overhead Crane Fault Knowledge Graph — Technical Solution
The knowledge graph transforms scattered fault records, maintenance work orders, spare parts data, and equipment parameters from overhead crane operations into a structured semantic network. The technical pipeline consists of four layers: the data layer (maintenance work orders / fault records / sensor alarms / spare parts replacements / industry standards / equipment manuals), the knowledge extraction layer (BiLSTM+CRF entity recognition + relation extraction with F1=91.2%), the graph storage layer (Neo4j Enterprise 5.x, property graph model, 500K+ nodes), and the application layer (fault diagnosis reasoning / maintenance solution recommendation / similar fault retrieval / intelligent Q&A). The system is deployed in Kelude's internal knowledge base, covering 8 crane types, 243 fault modes, and 1,580 fault cases.
Fault diagnosis for overhead cranes (bridge cranes) has long depended on the personal experience of maintenance engineers. Over a crane's 15–20 year service life from installation to decommissioning, hundreds of maintenance work orders and fault records are generated — yet these structured and semi-structured data points scattered across different systems (ERP, CMMS, Excel) never coalesce into reusable knowledge assets. Knowledge Graph technology, through entity recognition (NER), relation extraction (RE), and graph storage (Neo4j), transforms these fragmented records into a semantic network linking equipment, faults, causes, corrective actions, and spare parts. This article presents a complete engineering implementation — from data collection to graph query and reasoning — based on the fault knowledge base project at Kelude Heavy Industry. The technical approach draws on the Neo4j Graph Data Science Manual v5.x (2024), the HanLP natural language processing toolkit (v2.1, 2023), and hands-on deployment experience from Kelude's internal fault knowledge base project (Project No. KL-KG-2024-001).
Overhead Crane Fault Knowledge Graph: Data Sources and Entity Framework
The overhead crane fault knowledge graph draws on four data dimensions: ① equipment records (model / capacity / span / lifting height / work duty classification / serial number / commissioning date); ② fault work orders (fault time / equipment ID / fault symptom / fault code / troubleshooting process / corrective action / replaced spare parts / maintenance personnel / downtime duration); ③ sensor data (vibration RMS / temperature / current / overload event history); ④ industry standards (fault determination clauses from ISO 4301, TSG 51, FEM 1.001, and related standards). After entity and relation extraction, the model defines 6 entity types and 9 relation types:
| Entity Type | Label Name | Example | Order of Magnitude |
|---|---|---|---|
| overhead crane Equipment | Crane | QD32t-023/ LD10t-156 | 500+ |
| Fault Symptom | Fault | Hoisting load slipping/crane rail gnawing/Brake abnormal noise | 243 Type |
| Fault Cause | Cause | Brake lining wear/Wheel tread pitting/Coupling tooth surface wear | 480+ |
| Maintenance Measure | Action | Replacement Brake Lining/Air Compressor Brake Clearance/Replacement Coupling | 620+ |
| Spare parts Material | Part | YWZ5-315/23Brake/Wheel ZGY-600 | 1,200+ |
| Standard Clause | Standard | ISO 4301 Crane Design Standard-2008《crane Design Specification Interpretation of Core Clauses: Load/Structure/Mechanism/Electrical/Five Major Safety Systems》 5.2.3 | 80+ |
| Relationship Type | Start and End Point | Description |
|---|---|---|
| has_fault | Crane Fault | A Certain Unitoverhead crane Had a Certain Fault |
| has_symptom | Fault | Had a Certain Fault AConcomitant Fault BOccur Simultaneously |
| caused_by | Fault Cause | A Fault Caused by a Certain Reason |
| resolved_by | Fault Action | A Fault Resolved by a Certain Measure |
| uses_part | Action Part | A Measure Requires Replacement of a Certain Component Spare parts |
| ref_standard | Fault Standard | Related to a Certain Fault Standard Clause |
| similar_to | Fault | Had a Certain Fault AWith Fault BSimilar(Cosine Similarity＞0.8) |
| located_in | Crane Location | overhead crane Located at Workshop/Workshop Section |
| occurred_at | Fault Time | Fault Occurrence Time |
Entity Relation Extraction with BiLSTM-CRF
Knowledge extraction is the most critical step in graph construction. The system employs a BiLSTM+CRF (Bidirectional Long Short-Term Memory + Conditional Random Field) sequence labeling model, using HanLP 2.1 as the preprocessing pipeline (tokenization, POS tagging, and dependency parsing). The model was trained on 2,400 manually annotated overhead crane fault records. The BIOES tagging scheme (Begin/Inside/Outside/End/Single) is applied, yielding 30 distinct labels (6 entity types × BIOES).
Neo4j Graph Database Storage & Cypher Queries
The extracted triples (head entity–relation–tail entity) are stored in a Neo4j Enterprise 5.x graph database. The system uses a Labeled Property Graph model, where each node carries a single label, and each relationship has a type and direction. Data scale: ≥58,000 nodes and ≥126,000 relationships (as of June 2026).
Example Cypher query:
// QueryQD32t-023All fault history and corresponding maintenance measures for overhead crane MATCH (c:Crane {id: 'QD32t-023'})-[r1:has_fault]->(f:Fault) OPTIONAL MATCH (f)-[r2:resolved_by]->(a:Action) OPTIONAL MATCH (a)-[r3:uses_part]->(p:Part) RETURN f.name AS fault symptom, a.name AS Maintenance measures, p.name AS Replacement of spare parts ORDER BY f.severity DESC// Graph-path-based fault reasoning：Occurrence on a specific overhead crane"Load slipping during hoisting"，Recommended troubleshooting directions and spare parts MATCH path = (f:Fault {name: 'Load slipping during hoisting'})-[*1..2]-(n) WHERE ANY(label IN labels(n) WHERE n:Action OR n:Part OR n:Cause) RETURN path LIMIT 30// Similar fault retrieval（Based on common root cause+of measuresJaccardSimilarity） MATCH (f1:Fault {name: 'Abnormal noise from brake'})-[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_nodesSemantic Reasoning & Intelligent Q&A
The value of a knowledge graph lies in reasoning. The system supports three reasoning modes:
①Rule-Based Reasoning — Uses a predefined fault diagnosis decision tree (an IF-THEN rule set authored by three senior overhead crane maintenance engineers, covering 8 equipment types × 243 fault modes × 480+ causes, totaling 1,520 rules). Automated diagnosis is performed via Cypher graph traversal.
②Path Ranking Reasoning — Given a fault node, candidate maintenance actions are ranked using random walk with restart (Personalized PageRank, 20 iterations, restart probability 0.15). Top-3 recommendation accuracy reaches 86.4% (validation set N=500).
③Semantic Q&A — Template-based NL2Cypher (natural language to Cypher query conversion) supports 12 question templates (e.g., "What faults has crane XX experienced?" → MATCH(c:Crane)...).
Knowledge Graph vs. Traditional Approaches: A Side-by-Side Comparison
| Comparison Item | Traditional Approach(Relational Database+Keyword Search) | Knowledge Graph Approach(Neo4j+Semantic Reasoning) |
|---|---|---|
| Data Model | Two-Dimensional Table, Foreign Key Association | Property Graph, Node-Relationship-Property |
| Fault Correlation Query | Multiple Tables JOIN(3~5Tables), Response time500ms~3s | Graph Traversal, Response time＜50ms |
| Multi-Hop Reasoning(Such As: Fault Cause and Measure Spare parts) | Requires4Times SQLFault Correlation Query+Application Layer Assembly | Single Cypher Graph Traversal[1..4]Hop |
| Similar Fault Discovery | Based on Label Keyword Matching, Low Precision | Based on Graph Structure Jaccard Cosine Similarity+Page Rank |
| Knowledge Reuse | Dependence on Personal Experience, Knowledge Loss Due to Personnel Turnover | Persistent Storage of Knowledge Graph, Team Sharing |
| Cold Start for New Equipment | Requires Accumulation of Sufficient Fault Records | Can Perform Transfer Reasoning Based on Graph Structure of Similar Equipment |
| Query Flexibility | Predefined Reports, Ad Hoc Queries Require Development | Cypher Ad Hoc Query, Web Self-Service Interface |
Frequently Asked Questions
Q: How much data does the knowledge graph need to deliver practical results?
A: For initial deployment, we recommend at least 500 fault records (each covering symptom + cause + corrective action), which corresponds to roughly 6,000–8,000 entities and 12,000–15,000 relationships. At this scale, Top-3 fault recommendation accuracy reaches 70% or higher. Once the dataset grows to 2,000+ records (the current project size), accuracy improves to 86%. For cold-start scenarios, you can seed the knowledge base with publicly available industry fault data and standard clauses.
Q: What is the core difference between Neo4j and MySQL/PostgreSQL for fault knowledge management?
A: The key difference lies in multi-hop query efficiency. For example, querying "maintenance actions for faults similar to a fault that occurred on a given overhead crane" requires 5–8 JOINs in MySQL (response time in seconds), and once the table schema is fixed, adding new relationship dimensions becomes difficult. Neo4j handles the same query with a single Cypher statement using `[*1..4]` variable-length pattern matching, with response times under 50ms. The graph model also supports horizontal extension by nature — adding new entity types or relationship types requires no schema changes.
Q: How much manually annotated data is needed for entity and relationship extraction?
A: This project uses 2,400 manually annotated records (28,600 entities and 12,400 relationships), with an annotation cost of approximately ¥12,000 (3 annotators × 10 days × ¥400/day). If the annotation budget is limited, you can use Distant Supervision to automatically generate weakly labeled data from existing spare parts BOM tables and fault code lists, followed by manual verification — this reduces annotation volume to 400–600 records, at the cost of F1 score dropping from 91.2% to roughly 85%.
Q: Are the 12 NL2Cypher semantic query templates sufficient?
A: The 12 templates cover approximately 85% of daily fault knowledge base queries (based on Kelude Heavy Industry's internal 3-month operations query log analysis). The templates fall into three functional categories: fault queries (equipment faults, fault causes, corrective actions for a cause), spare parts queries (parts used in a corrective action, actions applicable to a spare part), and statistical analysis (fault frequency TOP N, equipment with the longest maintenance cycles). Natural language queries that fall outside the template scope currently degrade to Cypher syntax hints with manual completion.
