Remote Monitoring meets Smart Maintenance – with mtu Go by Rolls-Royce

Today is a personal highlight for me: Since summer 2023, Rolls-Royce has been part of our IoT Use Case network – and today they’re joining me on the podcast. We’re focusing on a very specific area within the context of IoT: the Power Systems business unit. So, we’re not talking about the vehicles you might have in mind.
The spotlight today is on Rolls-Royce Solutions GmbH, based in Friedrichshafen. They are responsible for digital services around connected engines, generators, and other systems in the field – including under the well-known mtu product brand.
You’ll now find out what exactly is behind all this. We’ll talk about the vision Rolls-Royce Power Systems pursues when working with IoT data, which concrete use cases they implement, what technologies they rely on – and how it all works. And: how you could potentially become part of it, too.
These questions will be answered today by two hands-on experts:
Laura Mangold, Head of Business Development Service & Digital, and
Daniel Eberle, Vice President Digital IT – both from Rolls-Royce Power Systems.
You’ll hear how they implement all of this in practice. I’m really looking forward to this session. As always, you can find all the relevant details at iotusecase.com or in the show notes.
Viel Spaß – let’s go!

Hello and welcome, Laura and Daniel. I’m really glad to have you with us today. Daniel, let’s start with you – how are you doing today, and where are you joining us from?

Daniel

I’m doing great. Hello everyone, and hi Madeleine. Today I’m at the beautiful Lake Constance. The weather is a bit cloudy, but since we’re recording this on a Friday, I’m already in weekend mode. I’m very excited to record this podcast and looking forward to our conversation.

That sounds great – I’m looking forward to it as well. Rolls-Royce Solutions GmbH is based right in Friedrichshafen on Lake Constance, correct?

Daniel

That’s right, exactly. We even have a plant directly by the lake.

Fantastic. Laura, how about you? Are you also in Friedrichshafen?

Laura

Yes, I’m in Friedrichshafen as well, not far from Daniel, just in a different building. I’m doing great today too. Right now, we’re reviewing the backlog for our great mtu Go product and optimizing the prioritization – moving away from a manual process.
So, we’re busy at work, and I’m really looking forward to today’s podcast and to talking with you and Daniel about the mtu Go product.

Wonderful, we’ll get to hear more about that in a moment. But first, maybe a quick introduction of the both of you. Laura, you’re Head of Business Development Service and Digital at Rolls-Royce Power Systems. You’ve built your career internationally, with stations in Asia, and today you’re responsible for expanding digital services and new business models around the mtu products. What does your day-to-day job actually look like?

Laura

With pleasure. We’re part of the Rolls-Royce Group, and here in Friedrichshafen we operate as Rolls-Royce Solutions GmbH.
There really isn’t a typical day – and that’s exactly what I love about this job. No two days are the same, because we work in Business Development and every day brings something new. But what we deal with most is responsibility for products – both in the service area and in the area of digital products. That means we’re in constant exchange with internal stakeholders, but also with customers and partners, to understand what our customers need and what their requirements are. From there, we develop the product.
We collaborate closely with colleagues from technical departments, especially with Daniel’s team for digital products. We calculate business cases, design business models, and also work on operational processes. So, we’re involved in all aspects necessary to successfully bring a product to market.

Really interesting! Definitely sounds like a really exciting task. We’ll come back to the topics you just mentioned – especially the customer interactions and business cases – in a moment.
Daniel, over to you. You’re Vice President of Digital IT at Rolls-Royce Power Systems and bring many years of experience in IT and digital transformation. I believe you also worked in Singapore, where you led IT operations. Now you’re driving forward digital products and platforms here, as well as the topic of user experience. Could you explain whether you work directly with Laura, and what your daily responsibilities look like?

Daniel

Just like Laura, I don’t have a standard day either. I’m responsible for digital products, but also for artificial intelligence, user experience, measuring user experience, and software development in our organization. That’s incredibly exciting, because digital products and AI are increasingly merging.
Regarding your question – yes, I work very closely with Laura, because product management and product delivery have to go hand in hand. We look at strategies together, further develop the product, and figure out how to establish it successfully in the market. It’s a very close collaboration.

great to hear! You already touched on it briefly – how the mtu GO brand fits into all of this. Perhaps you could clarify that once again. When I think of Rolls-Royce, I typically associate it with your core businesses in engines, propulsion systems, and also backup generators and so on. You’re now working in a very specific area. Could you explain what this digital area is about and what exactly mtu GO means? What exactly are you doing there?

Laura

mtu Go is essentially our digital platform for asset and fleet management. As you said, we serve various markets and applications with our propulsion solutions – whether it’s in the marine sector, rail transport, mining vehicles, or backup power systems. Many different parties work on these systems, especially in the service area.
That means we have our internal service colleagues, partners, distributors, and also end customers who work on the equipment themselves. The core idea of mtu Go is to create a digital platform where all these parties can come together. Through the platform, they get access to the relevant data, trend analyses, and an overview to keep the equipment operating at the highest possible level of availability. The platform helps reduce downtime and maximize the runtime of the equipment. Essentially, it’s a collaboration platform that uses data to make the service process more efficient for everyone involved.

You’ve basically already said it – it’s about keeping your equipment running. So that means it’s specifically about your own products that are in use at the customer site, right?

Laura

Absolutely, exactly. That’s how we’ve defined it: our primary focus is on the equipment we’ve delivered. Of course, there were ideas to expand the platform into other areas, but we decided to focus on our own equipment for now. If the platform reaches a certain scale, we might consider offering it for non-mtu equipment in the future. But currently, the focus is on the equipment we’ve delivered ourselves.

And Daniel, could you maybe describe – or do you have an example – of what kind of products those typically are? Your portfolio is huge. Maybe an example involving an engine or something from another product area. What kind of products are these exactly, and what in particular do you find interesting about the data from these products?

Daniel

Yes, over the past few years, we’ve worked a lot on our product portfolio and have developed from a traditional engine manufacturer into a system provider. Naturally, that means we now have a systems perspective on the products – especially when it comes to telemetry data and remote control.
One example: We have engines in use, for instance in mining trucks. In that case, we only provide the engine. But we also have gensets in operation – small generators, for example, mounted underneath railcars in the UK to produce electricity and power the train.
At the same time, we provide gas generators for grid balancing – units that produce electricity. In the power generation sector, we also have backup generators that secure data centers around the world. And one last point: very new in our product portfolio are battery storage systems. With these, we want to enter the topic of microgrids – meaning a combination of battery containers, gensets, and photovoltaic systems, to ensure a reliable power supply for our customers.

Quick off-topic question – is it actually true that every third click on the internet is backed up by your emergency generators? I read that online somewhere.

Daniel

Yes, that’s actually true. Every third click on the internet is backed up by our emergency generators in data centers,
to make sure we can all use these internet capabilities.

That means thousands of your emergency generators are installed out in the field.

Daniel

That’s correct!

I don’t know exactly how many, but it’s definitely a huge number. Alright, that brings us straight to the topic of connectivity. How do you actually access all that? Very exciting. Maybe we can now talk about the mtu Go platform. What is the vision behind the platform when it comes to IoT data and digitalization – for you and your customers?
Maybe also a bit about the problem behind it – what do your customers need, what’s happening in your market right now? Could you share what vision you’re pursuing?

Laura

We actually have two use cases. The first one is that mtu Go is very closely integrated with our service division and our service products. Over the past few years, we’ve focused more and more on service contracts. That means we try to bring the equipment we have in the field under our service agreements. In other words, we take care of maintenance, preventive maintenance, and corrective actions for the customer.
We plan spare parts and basically handle all maintenance so the customer doesn’t have to.
And this is exactly where mtu Go comes into play, because to manage that efficiently, we need a digital process and the corresponding data. So mtu Go is primarily a tool for our service divisions – for example, to plan maintenance based on the engine’s operating hours, to detect failures early so we can work on the equipment in time to prevent major breakdowns.
That’s the internal use case. But customers who don’t have a service contract with us and do their own maintenance face the same questions. They also have a strong interest in keeping their equipment running as long as possible. If you imagine taking a ferry in Spain around the Balearic Islands, you definitely don’t want that ferry breaking down because the engine fails.
That’s why operators with lots of machines in use are very interested in monitoring their equipment. And this is where mtu Go comes in. With the data we collect from the engines, we can identify different trends and inform the operators accordingly.
We also have a large partner network. We don’t handle everything ourselves with our own Rolls-Royce employees – we work with distributors and service partners. And we want to offer mtu Go to them as a digital product as well, so they can provide service to the end customer in turn.

You mentioned the difference between corrective and predictive maintenance – I found that really interesting. If I understood correctly, corrective maintenance is more reactive, and predictive maintenance is more proactive. Would you agree with that, or how do you define it in the context of this use case?

Laura

Exactly. We follow a preventive maintenance philosophy. That means, just like you probably know it from your car: every 1,000 hours – in our case it’s operating hours, for cars it’s kilometers – a specific maintenance task has to be carried out,
like an oil change or replacing a part. That’s basically preventive, based on a fixed schedule.
Corrective means something has already happened – for example, the engine is broken, and we try to repair it. What we want to achieve with mtu Go is predictive: We aim to avoid failures before they even occur. That means we detect a trend – for example, something’s off with the exhaust temperature or other values. Then I’d rather go and check A or B to prevent a bigger failure.
Predictive or condition-based maintenance is something we’re currently working on, and it offers a lot of potential. That’s also exactly what our customers want: They don’t want to do maintenance every fixed 1,000 hours – they want to do it when it’s actually necessary.

[14:22] Challenges, potentials and status quo – This is what the use case looks like in practice

Can you explain a bit what the typical business case or business challenges are in these projects? Because in the end, it’s also about your customers investing in technology – in a product that is now suddenly available – and realizing the added value from it. Could you highlight that added value in more detail and give an example of a typical business case?

Laura

When we talk about our distributors and partners, it’s often about increasing efficiency and reducing costs. Efficiency, because without mtu Go, many processes are manual. I mentioned the example of the maintenance plans:
Without mtu Go, someone had to check a PDF to see what maintenance was due. Then the operating hours were manually extracted and used to calculate what kind of maintenance was needed. After that, they had to look up which parts were needed in the spare parts catalog, and everything had to be entered into the ticketing system. With mtu Go, we were able to automate this entire manual process.
Where it used to take the customer 40 minutes to create a ticket, now it just takes a few clicks, because everything happens automatically. Based on the operating hours sent from the equipment, the next maintenance is calculated,
the matching spare parts are suggested, and the ticket is generated automatically in the system. That’s a massive increase in efficiency and saves a lot of time.
There’s also the classic business case for end customers: downtime costs. Every hour a mining truck isn’t running costs money – because it’s usually hauling resources like gold out of the mine. Every hour the truck stands still because of an engine fault is literally lost money. Every hour of downtime we can reduce with mtu Go saves the customer those costs.

It’s really interesting that you’ve broken it down to the minute. It makes total sense for your service department and your partners to have a clear business case. But with end customers, it’s obvious as well. Still, I can imagine you don’t always have the ROI numbers right at hand, because you might not know all the customer’s internal processes.

Laura

Yes, absolutely. In the beginning, you don’t know the numbers, and it’s always difficult to prove costs or risk avoidance. We can’t say what would have happened without mtu Go. That’s not easy to prove. But there are simpler business cases too. For example, if a customer needs to generate specific reports and requires IoT data for that –
with mtu Go, they can pull that data directly, instead of laboriously gathering it from other systems. Even these simpler cases show how mtu Go already provides huge value.

Great! Do you actually involve your customers in the development of an IoT solution? I imagine you know your own devices very well and understand exactly where the boundaries are. But what you may not fully know is the upstream and downstream process in the customer’s operation. Do you work in partnership with customers? Do you involve them? How does that collaboration look?

Laura

Yes, absolutely. When we have a new product idea – whether it comes from us or from a customer –
we usually start with pilot projects to better understand the customer’s use case. We then also use these pilots as references for other customers. If we were to develop something entirely without the customer, we wouldn’t be taking into account those upstream processes you mentioned. And that’s not always easy, because it can get very specific. The challenge that Daniel often sees is that we want to develop a solution for customer A,
but design it in such a way that it also works for other customers. We try to find a balance between customer-specific solutions and general applicability, because we only have one platform – and over ten sub-applications. Each application has its own specifications and requirements. Bringing those into alignment is the challenge Daniel often deals with.

I’d like to come back to those applications in a moment. Daniel, what are some of the typical challenges you encounter?

Daniel

In my opinion, the biggest challenge is that our products are so high quality that the product lifecycle often spans several decades. We have about 150,000 engines in the field, many of which are not IoT-capable – or not connected at all. We see huge potential here through retrofitting, to make these older products IoT-ready. With newer products that are already IoT-capable, the challenge lies in mobile applications – like in rail, mining, or marine industries. We often rely on cellular networks, and the availability and bandwidth of those networks can pose difficulties. We have to make sure that data can be transmitted reliably.

That leads me to the next question about technical challenges. I can imagine, like you said: some devices are mobile, others are stationary – sometimes located in the middle of nowhere, other times in areas with excellent infrastructure. Do you typically always have access to the data? Do you rely on specific protocols, standards, or interfaces? How do you approach this topic? I imagine you need an entire portfolio of different solution stacks to connect all these devices, right?

Daniel

Exactly, that’s correct.

Our new products – especially in the electronics and battery systems area – are based on best-practice standards like OPC UA. We’re in a pretty good place in terms of protocols. Our own products, like engines, use proprietary protocols on their engine control units, which we have to handle ourselves. That means we use an edge device that we deliver with the system, and through software, we manage to read these protocols and standardize the data before sending it to our IoT backend.

[21:18] Solutions, offerings and services – A look at the technologies used

Let’s talk a bit more about your solution mtu Go – in more detail. I’d really like to understand how the platform works, and maybe you also have some experiences to share. We’ve now gotten a general idea of mtu Go: it’s about maintenance contracts, your digital product connectivity, and all the service systems related to operating and maintaining the machines. But it also covers other areas. What exactly is the digital solution you’ve developed around mtu Go, and what building blocks are included? You just mentioned applications. Could you summarize once more what the solution actually includes?

Daniel

Yes, absolutely. So, at Rolls-Royce Power Systems, when we say “application,” we mean the use of our product in the field – for example, in mining, rail transport, or power generation. It doesn’t refer to a software application in this context. As for the architecture: At the product site, we have an edge device that is either connected directly to the engine control unit or to the local automation system.
First, the data is collected and processed at the edge device.
Then it is transmitted via MQTT to our IoT backend in the Azure Cloud. There, we normalize and standardize the data. The data is then passed from our IoT backend to an application platform. This platform also integrates with our enterprise data – because, as Laura mentioned, we work with maintenance plans that come from our enterprise system. So, the IoT data is combined with the enterprise data on the application platform.
We provide access to this data via applications – in other words, frontend solutions. On one hand, we have a responsive web application, and on the other hand, a native iOS app for service technicians in the field, which runs on iPads or iPhones.

For those hearing this for the first time, I’ll include the link in the show notes. I think it’s available at mtu-solutions.com, or is there a better landing page for what you just described?

Daniel

Yes, mtu-solutions.com is the landing page for our mtu solutions in general. But for mtu Go, we have a dedicated site at mtu-go.com. That page explains what mtu Go is about. However, the actual functionalities for directly using mtu Go are not fully available there yet.

I’m on the site right now and logging in to use mtu Go directly as a platform.

Daniel

Exactly.

Laura

You could register and would first be assigned a demo account. That way, we make sure that basically anyone can sign up at first. But if you want to see your specific engines, you’d have to submit a request, and we’d assign them to you. For a first introduction, you can register and try out the basic functions.

Alright, mtu-go.com – I’ll definitely check that out afterward. Maybe let’s go back briefly to what the user actually wants to solve in the area of maintenance service – for you and your end customers. How do you evaluate the collected data? Do you have your own analytics models, or do you rely on existing tools to generate maintenance recommendations? How does that work?

Laura

For the maintenance recommendations themselves, we developed our own logic. As Daniel mentioned, we combine the necessary data – engine operating hours, the maintenance plan from the ERP systems, and the requirements for each specific maintenance task. Then we have a logic that we implemented ourselves, which calculates the next due maintenance based on these values and displays it in the mtu Go frontend.
From there, I can confirm that this is the maintenance I want to perform. With one click, a ticket is automatically created in our ticketing system – which is a separate tool. That’s how it works for maintenance planning.
When it comes to analytics and trend monitoring, though, we use a separate analytics platform. Daniel, would you like to add something?

Daniel

We decided that we don’t want to analyze the telemetry data only for digital products like mtu Go,
but also for other use cases – for example, related to product quality or research and development. That’s why we collect the telemetry data through mtu Go and standardize it via the IoT backend. In that backend, jobs also run to handle all the mappings.
From this IoT backend platform, we then transfer the data via an interface to an internal platform,
where our analytics are developed and trend monitoring models are created. The results of that analysis are then sent back into mtu Go.

You work with so many different systems – from your service partners, your own enterprise IT systems, and the live IoT data. How do you ensure that all this data is available in a structured and unified way? Do you use a centralized data model of your own, or do you follow concepts like the “Unified Namespace”? That’s a bit of a buzzword right now, but maybe you’ve had something similar in place for a while. How do you make sure the data can actually be used in a scalable way?

Daniel

Making it scalable is definitely a challenge. But we’ve developed a standardized data model for ourselves. According to the EU Data Act, we will be required in the future to make telemetry data available to all users – at least within the EU. For that, we need a standardized format through which we can make the data accessible to users. At the same time, this model allows us to import data from other products into mtu Go. That’s why we work with standards and apply them consistently.

Yes, that’s an important topic you brought up. Regulatory requirements mean that such data has to be made available, which also highlights the importance of standards. Great to hear that you’re approaching it that way.
And maybe one last question – I hope I’m not hitting a sore spot, sorry in advance. It’s about change management. You have many experienced service staff in the field who have been supporting your customers for years. How do you handle the fact that knowledge is now increasingly being transferred into digital systems? How do you support your service teams in integrating this new system into their daily routines? Do you have special training programs? Because that’s also a change management challenge, isn’t it?

Laura

It really is a major transformation, as you say. Traditionally, we have service sales colleagues who sell maintenance and spare parts – but not necessarily digital products. That’s something new. Right now, we’re addressing it by introducing so-called mtu Go Champions. These are people within the different regions whom we train in depth on the topics, and they then pass on that knowledge within their respective regions. It’s really difficult to bring everyone along at once. With these mtu Go Champions, we’re at least trying to distribute the knowledge to a few key people and bring it into the regions.
Yes, we also conduct trainings to explain how to sell a digital product – the arguments, and how to talk to the customer. There are also other people we need to speak to. The fleet manager or the head of technical service on the customer side might be the one using the mtu Go product. So, we’re dealing with new types of contacts or target groups that we have to approach differently. First, we have to find out who the actual user of the product will be.
So yes, as you said, it’s a change process that has started and is still ongoing. We’re trying to pass this knowledge step by step to our partners as well.

Daniel

I have one more point to add. What you mentioned – we’re seeing that as well. We have many highly experienced field service technicians. But I think a global issue is the so-called “silver tsunami.” In the coming years, a large number of these experienced technicians will retire or leave the workforce. This poses a major challenge for us if we don’t find a way to make that knowledge accessible through digital products. Otherwise, we’ll have a long-term problem: the new service technicians coming in won’t have access to that knowledge anymore. Here too, digital products play a crucial role in making sure that knowledge is preserved.

Exactly. All the better that you have the mtu Go platform – not just for remote monitoring, but also for supporting service processes and making that knowledge usable in a structured way.

[30:34] Transferability, scaling and next steps – Here’s how you can use this use case

Do you already have some early experiences or best practices you could share? Are there pitfalls people should watch out for?

Daniel

Yes, of course. There are two things I’d like to point out that have become very important for us:
First, IoT always sounds really simple. There are many providers out there – even large tech companies – who say IoT is easy. You connect a sensor, create a dashboard, and you can already see the data. But in reality, it’s much more complex. We’re dealing with proprietary protocols and have to develop the right business case. Just showing data without a clear use case or purpose behind it doesn’t make much sense. It’s crucial to have the internal know-how to handle those protocols and define the business case,
because IoT also comes with costs. Those costs have to be justified by a clear benefit.
The second point is that when developing digital products, it’s not just about the technology –
that part is relatively manageable. It’s also about having a clean operating model for how to develop a digital product and how to work with IoT. What we’ve learned is that a structured and agile approach – and the ability to communicate that agility to stakeholders – is a key success factor for developing digital products successfully.

Laura

In the beginning, we may have tried too hard to launch mtu Go as a traditional product. That means we had a pricing and business model behind it, worked on it for a long time, and then presented it to the customer. I think one of the biggest learnings was that, especially with digital products – as Daniel mentioned – they should be developed together with the customer. If in doubt, it’s better to share an initial version with the customer and gather feedback based on actual usage.
From my perspective, that’s one of the key learnings: First, get users onto the platform and let them start using mtu Go – because it’s only through usage that new requirements emerge. Only through usage can the user understand the true value of the product. Then you can start thinking about building business models and monetization. Another learning was to increase the adoption rate first, before introducing a price point that might create a barrier and prevent product usage. That was also a mindset shift for our company, since we usually develop products and back them with business cases.

Yes, that makes sense – and that’s such an important point you’ve raised. We actually had a community session this morning, and this exact topic came up. Many went in with a relatively high entry barrier – pricing included right from the start, and so on. But with condition monitoring, it’s really about discovering the actual value, and what you just said really captures it: lowering the barrier to entry and then creating real value together with the customer. That’s a great strategy.
What can we look forward to in the future? Do you have specific innovation steps planned for this year or next? Can you give us a sneak peek behind the scenes – which new features are coming? Or maybe some trends you’re seeing for the coming year?

Laura

Yes, definitely. We now have a stable and very high-performing platform, and there are many ideas in our long backlog of potential features. One of the next topics will be guided troubleshooting, which Daniel already mentioned. That means we’ve compiled all the knowledge of a technician into a knowledge database. When an error occurs, the technician is guided step by step through the repair process. This will be integrated into mtu Go as a kind of digital assistant, which we call “Service Assist.” This assistant helps field technicians resolve corrective issues. That’s the next big feature that will be available soon – and it also helps address the silver tsunami.

Daniel

Yes, and from a technical perspective, that naturally goes hand in hand with AI. That’s my second area of focus besides digital products and user experience – the integration of AI. But we don’t just want to slap the AI label on everything, as many do, even when there’s no real value behind it. That’s why we work closely with user experience and our customers to find out where AI truly creates value – and not just as a label to “be part of it.”

That’s very tangible and clearly adds real value – great to hear! Maybe we’ll do a follow-up episode once guided troubleshooting goes live. It definitely sounds exciting – especially the AI topics. From my side, a big thank you for being here today. It gave us a clear picture of the market you’re in, the challenges you face, and how exactly you’re solving them with your product. Thanks again for your time and all the insights. I’d like to leave the closing words to you. And Thanks again!

Laura

Thank you from my side as well – thanks for the invitation and for having us on the podcast. It was a great experience, and I’m already looking forward to the next episodes.

Daniel

Also from my side, it was a great conversation – and I really enjoyed it. I’m curious to see what comes out of it, especially in terms of new connections and potential follow-up discussions. Depending on how the community responds, I’d be very happy to continue the exchange.

Yes, thank you for bringing that up at the end. I’ll of course include your contact info in the show notes. Feel free to connect with Laura and Daniel – you’re probably working on similar topics, and there’s definitely value in sharing best practices and having these conversations. Thanks again for being here today – and have a great rest of your week. Bye!

Laura

Bye!