Developing ontology tools with Grundfos
For organisations needing to navigate ever-increasing amounts of information, ontologies are an extremely valuable tool. They allow a machine to work more like a human mind when classifying information, allowing you to navigate it smoothly. Essentially the ontology is the architecture that maps and connects numerous sources of information.
Recently Wallscope worked with Grundfos to help with the development of an ontology to map their product catalogue. Grundfos is the largest water pump manufacturer in the world, based in Denmark, with more than 19,000 employees globally. The aim of their ontology is to map all the parts, sub-parts and how they come together.
Grundfos has an existing ecosystem of open-source tools and proprietary software that works but provides a cumbersome workflow. Most of these tools are separated and the facilities to edit them are too technical for non-technical users to set up and troubleshoot.
Wallscope was asked to co-develop a web-based tool for ontology management based on an open source templating technology - OTTR templates. This provides a simple data entry view which allows users to edit the ontology and build into the product pipeline. The Wallscope team was focused on working with the ‘build’ service that generates an ontology from various sources in a scalable way.
I spoke to Mikkel Brynildsen, Chief Data Scientist at Grundfos, and Michal Hoinca, Software Engineer at Wallscope, about their experiences on this project.
Could you give a bit of background on your role and responsibilities?
Mikkel: I work with data, data models, AI and graphs within the Group Data and AI department. I helped to start this in 2016 as I had a particular interest in improving data quality and enabling data interoperability. I am involved in standardisation work in the Danish Standards Foundation, sit on various advisory boards, and have spoken at several conferences on the topics of AI, industrial data strategy and IoT.
Michal: I joined Wallscope in 2021, and work with different back-end technologies. I’m involved in implementing back-end solutions with a DevOps mindset, meaning I also work on automating infrastructure deployment using cloud tools.
In this particular project, I was a part of the software engineering team developing the build service application. I was involved in designing new solutions, developing and testing the code, setting up Azure resources, and preparing a continuous delivery pipeline for deployment automation.
What are the main sorts of data challenges faced by a large organisation like Grundfos?
Mikkel: We are one of the world’s best companies at producing pumps, but are not as experienced in digital offerings and moving water as a service for instance. Part of our strategy is to help the world manage water systems better, because we have a lot of insights in pumping systems. A Grundfos pump engineer will often know how to save energy in a water system, but we want to scale that knowledge, and to do that we have to go digital. A lot of manufacturing companies encounter challenges with this. Grundfos has been working with this for 20 years but there’s still a lot to do, in particular tying together end-to-end information flow.
What were the things you hoped to achieve with this project? And what were the outcomes?
Mikkel: We are building a product model ontology. The way we built this was using modelling patterns that were developed in the Norwegian oil and gas sector and distributed in something called OTTR templates. Put simply — if you have a table of data with product information, then you can run the data through the templating system and that will generate the graph that constitutes the product model.
At Grundfos we sell 600,000 types of pumps. Historically there are up to 2 million types of pumps we need to manage information on and organise. So that means we have to look at scalability. What we have been exploring in this project is making a web-based tool in Microsoft Azure where product information specialists can type in and curate product information in tables. They can then press a button and the data in the table gets funnelled through the OTTR templates, and that generates a product ontology which we expose for consumption in the RDF graph. So that was the goal and we achieved it.
And how did you find working with Wallscope?
Mikkel: We had a positive experience with Wallscope. We hired them to build the core semantic web service — or microservice — and then a Danish Azure specialist company built the whole table system around it. Wallscope managed to set up a build pipeline for us that takes the data from a table and builds a graph from it using the OTTR templates. It worked and in a pretty short time we had a build service running.
From Wallscope’s perspective, what were the main challenges you faced, and what did you most enjoy about this work?
Michal: Azure is very robust, so it was a big challenge to learn and understand it with minimal guidance. Azure solutions I had to implement sometimes had inaccurate or outdated information in their documentation, or a bug that didn’t allow me to do what I want despite following the documentation to the letter, so both my patience and problem-solving skills were put to the test. Setting up a continuous delivery pipeline without prior experience was also very challenging but also incredibly satisfying when the steps worked as intended. I’ve really enjoyed working with other teams and learned a lot from them.
What are the next steps for this work?
Mikkel: Now it is all about having the first real use cases and the first product model being built in the tool in the autumn, and then we will iterate from there. We are going to be collecting insights and trying to identify issues that can readily be addressed.
