ABB researchers are using large language models to turn fragmented engineering data into connected knowledge graphs, creating machine-readable memory for industry.
Factories run on data, but engineers still run on guesswork.
Every motor and drive ships with its own instructions, fault codes, and decades of tribal knowledge found across manuals, databases, and handwritten notes. All the info is there, it’s just not connected in a way that helps a person standing in front of a stalled machine.
ABB’s research team in Mannheim is trying to change that. A recent look inside describes a system that uses LLMs to turn the fragmented history of a powertrain into a single connected memory.
The system reads through service manuals, logs, and maintenance reports, extracts the entities and relationships, and builds a knowledge graph that can reason about faults, causes, and resolutions. The value of this for any engineering team across almost any industry is immediately clear.
The project began with a simple observation that also stretches across industries, information is too siloed.
The researchers explain that field service engineers spend too much time searching across siloed systems that were never designed to talk to each other. Customer requests live in CRM platforms, equipment data sits in IoT clouds, maintenance history is locked away in enterprise asset management systems.
And the engineers who know how to bridge those worlds are often the ones who leave, taking context with them.
ABB’s framework starts with what they describe as an ontology of the powertrain. Experts define how motors, drives, and loads relate, including fault codes, probable causes, and corrective actions. This ontology becomes the grammar of the domain and the LLM uses it to translate free text into “triples” (subject, relationship, object) that together form a web of meaning.
The result is a semantic layer that sits above the raw data, making the relationships explicit and searchable.
To see which tools could best handle industrial data the researchers compared two frameworks: LangChain’s LLM Graph Transformer and Microsoft’s GraphRAG.
Both rely on GPT-4 to extract structure from text, but their behavior under real conditions diverged in interesting ways. They found that LangChain’s transformer gave more control over schema definition but produced variable results from run to run and GraphRAG was steadier, generating consistent graphs with fewer false connections and adding features for summarization and clustering.
In ABB’s tests, GraphRAG’s hallucination rate averaged around 12%, slightly lower than the transformer’s 15%.
The team also discovered how critical prompt design was to the entire process and it turns out, not surprisingly that industrial language is rigid and literal, which creates some issues.
Machine codes and specific information like error codes, for instance can be out of alignment. At times, the ABB team found the model paraphrased or condensed information in ways that broke the logic of the manuals. To fix it, the researchers added detailed instructions showing how to handle codes, preserve full sentences, and record every step of a repair.
With these guides (and manual interventions), the LLM learned to treat each fault and fix as distinct, context-rich entities instead of summarizing them.
The end result was that when queried about, say, a drive overvoltage event, the resulting graph could link the fault code to the affected product line, the relevant service cases, and the repair actions recorded in past incidents. The system did not improvise and followed the relationships defined in the ontology, keeping accuracy and context intact.
In practice, that means field engineers no longer have to rebuild history every time they diagnose a problem.
A knowledge graph generated from manuals, sensor data, and service records can recall how similar failures were solved, what conditions preceded them, and which parts were replaced. Each new repair adds another data point to the collective understanding of the fleet and that graph can become something of a living record of engineering experience.
What this also means is that now even a junior technician can query the system in natural language and receive an answer grounded in verified historical data.
Over time, the database becomes a guide for prescriptive maintenance, offering not just predictions of failure but recommended actions drawn from thousands of resolved cases.
The researchers know hallucination is still a problem, and in a safety-critical environment, a fabricated relationship could lead to real-world damage. To prevent that, ABB includes a verification stage. Domain experts review each generated triple, confirm that relationships match the ontology, and correct reversed or invalid associations. The verified graph is then stored in RDF or property-graph databases through a custom mapping layer that supports multiple formats.
It is a blend of automation and human oversight that keeps the model’s creativity within safe limits.
What this achieves for engineering is a new form of reasoning system. Instead of scrolling through static documents or searching keyword indices, an engineer can ask the system to trace the lineage of a failure, identify common causes across product families, or summarize all historical fixes for a recurring fault.
The system uses semantic search over structured meaning, not word proximity. It answers in the same logic the engineers use.
The implications reach beyond ABB’s powertrain business. Any industry with large unstructured technical archives can apply the same model. Robotics, aerospace, oil and gas, even healthcare all suffer from the same divides between design, operation, and maintenance data.
A knowledge graph that understands how entities relate inside those systems can make every part of the lifecycle from design, build, operation, and service all share the same context. That's elegant engineering.
