In July, I attended PHM Europe 2026 in Oslo. It was my first conference and also a chance to present my Master’s thesis, “ACE – Automating Causal Extraction: Leveraging Large Language Models for Bowtie Diagram Generation in Failure Analysis and System Dynamics.”
My work looks at how large language models can help extract causal information from engineering content and turn it into structured Bowtie diagrams. Presenting it was a valuable experience, but one of the best parts of the conference was seeing what people are working on outside my own area.
Learning outside my own area
Some of the talks I enjoyed most were on topics I knew relatively little about. One was “Frequency-Domain Feature Analysis for Early Gear Damage Detection in Planetary Gearboxes.” Gearbox vibration analysis is not something I work with often, so it was interesting to get a better feel for how frequency-domain information can be used to spot early damage.
I also enjoyed “Learning the Language of Vibration: A Self-Supervised Transformer Foundation Model for PHM.” Foundation models are now common in language and vision, so seeing the same idea applied to vibration data was interesting. It made me think about whether models can learn useful representations of machine behaviour that can be reused across assets and faults.
Another presentation that stayed with me looked at the impact of temporal aggregation on uncertainty in industrial prediction. What I liked about it was the simplicity of the lesson. We often focus on improving the model, but the limitation may have been introduced much earlier. How we sample, aggregate and prepare industrial data can already place a limit on what a model can achieve.
The model is only one part of the system
This idea came up in a different way in a presentation on ontology-grounded LLMs for querying wind turbine inspection knowledge. The inspection reports were first turned into a structured ontology and knowledge graph. The LLM then translated a user’s question into a query over that structure. The generated query was also checked before it was executed.
What stood out to me was that the LLM was not expected to do everything by itself. It was given a clear engineering structure to work with, along with checks around its output. Even with that structure, more complex questions could still cause problems. That feels much closer to the real challenge of using LLMs in industry. Reliability depends not only on the model, but also on the data, context, toolsand checks around it.
Connecting AI to engineering workflows
Another presentation that overlapped closely with some of the work we are exploring at UReason looked at using LLMs to generate prescriptive maintenance reports within a digital twin application. What caught my attention was not simply the use of two LLMs. It was that the models were part of a larger asset health and maintenance workflow.
Industrial information is rarely in one place. Sensor data may sit in one system, maintenance history in another, while useful knowledge is spread across manuals, P&IDs, FMEAs and other engineering documents. There is also the experience of the engineers who work with the equipment.
For me, this is where industrial AI becomes more interesting. An anomaly is useful on its own, but it becomes much more useful when it can be connected to the asset, possible failure modes, relevant documents, process relationships and possible actions. The LLM is then one part of a larger engineering system rather than a standalone chatbot.
Key Takeaway
“The LLM is then one part of a larger engineering system rather than a standalone chatbot.”
How should we test LLMs for engineering?
One question that came up around my own presentation was how we should actually compare LLMs for engineering work. Is there a test bench that can tell us which model is good at which type of question?
I think this is an important question because there probably is not one model that is simply “best” for every industrial task. Extracting a failure mode from a document is different from answering a factual question from a manual. Reasoning across several documents is different again. So is understanding a causal relationship or suggesting a maintenance action.
A useful industrial benchmark could test these tasks separately. It could look at information extraction, document question answering, multi-document reasoning, causal reasoning, grounding and how well a model handles uncertainty. It could also test the same model with and without retrieval, tools or structured engineering context.
That would give us something more useful than a single benchmark score. It would help answer a practical question: which model, or combination of models and tools, is suitable for the job we actually want it to do?
Bringing ideas back from Oslo
The conference was also a great chance to meet people from across the PHM community. It was a pleasure meeting Maneesh Singh, Om Prakash Yadav, Louis Verstraeten and many other researchers and PhD students. Some of the most useful conversations happened outside the formal sessions, when there was time to compare ideas and talk about the problems people are trying to solve.
For my first conference, that mix was probably what I valued most. I could present something I had spent a long time working on, learn about areas I knew very little about, and find links between other people’s research and the problems we are working on at UReason.
A big thank you to the PHME 2026 organisers, session chairs, reviewers, volunteers and everyone who took part.
I came back from Oslo with plenty of new ideas and also more questions. One thought in particular stuck with me: industrial AI will probably not be defined by one model or algorithm. The more interesting challenge is how we bring together engineering knowledge, physical understanding, operational data and AI in a way that engineers can actually use and trust.
Explore the Research
Interested in how LLMs can support causal extraction and Bowtie generation in engineering? Read Priyank’s full Master’s thesis.
