Product digitalization for OEMs: modular development of complex field products

Today on the IoT Use Case Podcast: how to turn IoT solutions in machines and vehicles in the field into reality. In particular, we look at situations where so-called OEMs – original manufacturers of equipment such as trains or agricultural machinery – want to bring digital functions into their products in a safe and sustainable way.
Our guests are Tobias Maier, CEO of ML!PA Consulting GmbH, and Mirko Spitalny, Team Lead Hardware Development at ML!PA. Our conversation shows that when machine manufacturers connect their devices in the field, they repeatedly run into the same three really tough problems. Those who manage to overcome these hurdles can build robust IoT products – and we discuss how this can be done.
Enjoy listening.

Hello and welcome to the IoT Use Case Podcast with your podcast co-host Dr. Peter Schopf. Today we are not talking about shopfloor optimization, meaning factories. Instead, we are talking about digitalized products. Our guests today are Mirko and Tobias. Mirko, why don’t you introduce yourself: where are you today, what’s keeping you busy, and what have you been working on today?

Mirko

Hello Peter. Today I’m at our office. My day started like most of my working days: with a meeting with my team where we briefly discuss current topics, assign tasks, resolve difficulties, and make sure everyone knows what’s coming up for the day. I have been working at ML!PA since 2021, and before that I spent around ten years in research in the aerospace sector. At ML!PA I initially started working on data analysis. Then it became clear that we would also move further toward hardware development. That’s where I expanded my skills. Currently I am Team Lead in Hardware Development and lead a team of engineers with very different skill sets.
That is very exciting because it shows how many different capabilities are needed to build a successful IoT device. It ranges from classic engineering all the way into very digital domains. Every day brings a new challenge, and I enjoy that very much.

That sounds very exciting. I’m looking forward to diving deeper into that. We also have another guest: Tobias. What have you been doing today?

Tobias

Hello, my name is Tobias. I am one of the three founders of ML!PA. I have worked with digital products for a long time before founding ML!PA with two partners ten years ago. My background is physics, but I fairly quickly moved into digital printing about 25 years ago. Back then that was really high-tech – it’s hard to imagine today. Even back then we were already doing quite a lot in the area of product individualization. For a while we were involved in corporate restructuring projects. And I have to say: I’m a little nervous today. Like Mirko, I’m also in the office, just in a different room but on the same floor. You do this all the time, Peter, but I almost never do. This morning I asked my daughter what you should pay attention to when doing something like this, and she said: the most important thing is reach. At first that sounded very positive to me because I thought: reach, KPI – that’s something I can work with. But she also told me what I would need to do to achieve that, and she said: the only thing that really works at your age is true crime. For anything else you’re simply too old. So if you’re expecting true crime today, we’ll have to disappoint you. Unfortunately we can’t offer that today. But maybe we can talk a bit about our story and how we got into designing digital products and eventually building an ecosystem around them.
Let’s go back a bit to the year 2015. We actually started with two things. On the one hand we built price robots for websites. That had nothing to do with IoT. But relatively soon after founding the company we entered the Industrial IoT space – initially, like many others, in the area of shopfloor optimization. That means we connected machines at customer sites, built data integration systems, and at that time we were very software-heavy. Then a large customer from Cologne – a world market leader in energy chain systems – approached us and asked whether we could work together with them to build a digital product. We said: that should probably work similar to shopfloor automation. But we quickly realized that it was completely different. Because when I have a digital product, it is with the customer, which means I no longer have direct access to it. On a shopfloor I can quickly send someone to fix something – even if it’s just unplugging a cable and plugging it back in or rebooting a computer. None of that is possible with a product. The product leaves the building and is usually no longer addressable, unless you do it via the internet. That’s completely different.
Between 2016 and 2020 we developed several products and approached it a bit like IBM built computers in the 1960s. We picked some hardware we liked, built prototypes, assembled small circuits. Then someone developed software for it. Then we tested it and gathered experience, realized something didn’t fit, and started over again. That process was very time-consuming, very slow in development, and also very expensive. Often there were problems we simply couldn’t solve, and we had to tell the customer that we needed to approach things differently.
Then came the year 2020, which some people may still remember: Corona. All our industrial projects ended within three weeks because everyone first had to figure out what was going on. At that time we decided together with the development teams that were working on IoT: we will not stop doing this because it will come back eventually. But please rethink the entire topic of how you want to build IoT for industrial customers on the product side. That was the turning point where our products started to work. Mirko, you joined around that time. We have a major customer in the area of train braking systems – the company Knorr-Bremse. Together with them we are developing the digital freight train for applications in Europe. We have a world market leader in train braking systems as a customer, and together with them we started developing the digital freight train for Europe.

Mirko

During that Corona period the idea emerged to introduce modularization across different products. On the hardware side that means we have various components that we can reuse again and again, which significantly reduces development time for new products. At the same time, with this customer we again faced the classic three questions when dealing with freight wagons: where do I get the energy from, how do I get the data out, and how do I make the system robust enough to survive in the field?

You have already mentioned a whole series of very interesting topics. Coincidentally, energy chains – we recently recorded an episode with igus and Dercks Gartenbau. In industrial-scale horticulture they use energy chains extensively. This development during Corona is really interesting: that you decided to continue investing, to use the slowdown to bring new products to market and build something new. I think that’s very strong.

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

You just mentioned these three problems. Factories have many other issues as well, but especially in the context of OEMs – companies that manufacture their own branded products – this is particularly relevant. You mentioned the example of Knorr-Bremse from the railway industry, which manufactures braking systems for trains. I would like to take another look at these three problems. Mirko, what exactly were they, and how did you approach them? Do you have your own products for this, and what are the complications surrounding them?

Mirko

The challenge is that we are dealing with a system that is not always supplied with energy. Nevertheless, we must ensure that the system can connect to the cloud and provide data such as its position: where am I, what is my current status? At the same time, the periods when there is no external power supply cannot be predicted. That means we need a system that is energy-autonomous and able to harvest energy from its surroundings. In this case we decided on solar cells combined with battery operation. Sending data is also a particular challenge in these systems, which ties into the third point – the ruggedization of the product. In other words: where can I mount an antenna on a freight wagon so that it doesn’t get torn off during operation?

And data transmission is especially important. The freight wagon itself does have energy in some form, but the sensors installed at the brake cannot directly draw power from the train.

Mirko

The specific challenge with freight wagons is that they essentially have no energy supply. They are only supplied with compressed air to release the brakes. Otherwise the system is basically just a big block of steel. But we still want data from it. That’s the big challenge. That’s why the system must work autonomously, almost like on a remote island. The only energy source we can realistically tap into is the sun to recharge the batteries. We also considered ideas like using the airflow while the train is moving with small turbines or extracting energy from the compressed air line. But those approaches were either mechanically too complex, unreliable, or the energy levels were insufficient. This is also a classic starting problem: the customer comes with an idea and we first have to explore what is actually feasible. Often that involves many small feasibility studies until we align on the actual requirements and say: this is how we will do it, and we will now build the first prototype based on these assumptions.

Perfect — energy solved, understood. You chose solar, and depending on the use case you have to analyze what is possible. This can also be transferred to other applications: excavators, vehicles, OEM fleets in the field, construction machinery of all kinds. In this case we have the concrete example of train braking systems. So how did you solve the data transmission?

Tobias

First of all, we are dealing with a safety-critical application because we are performing what is called a brake test. Today this test is done manually. The train driver applies the brakes, walks along one side of the train, checks how many brakes are applied, writes it down on a sheet of paper, walks back along the other side and does the same. Then the brakes are released and the driver checks whether all brakes have been released again. It is not necessary that all brakes are engaged. It is sufficient that a certain number of brakes are applied because based on this number and the weight of the train the driver can calculate the braking distance. From this braking distance the maximum speed of the train can be determined. It must be ensured that if the driver sees a distant signal, the train can stop before reaching the main signal. Such a test takes about 90 minutes if the driver moves quickly. During this time the track is blocked. What we are now doing together with the manufacturer is establishing a digital brake test. That means instead of a person walking along the train, electronics perform the test. The goal is to complete the brake test within four minutes. At the same time this is a safety-critical application. There are Safety Integrity Levels that define different safety requirements. In this case it is SIL Level 2, which is already quite demanding. Certain things are simply not allowed. For example, a direct cloud connection is not permitted. Instead we need wagon-to-wagon communication. That is not trivial because there is a lot of metal involved and the wireless connection must also be reliable. It must not break, otherwise the brake test will not work. We therefore use two types of connectivity. One is the wireless communication between wagons. For that we use our own development from our IoT toolbox, as we call it. We have various functional modules that we have tested in the past. When we have a new application, we can take a module from this toolbox and check whether it fits. But we do not need to develop the hardware and software from scratch because we have already done that. In this case we chose an ISM network in the sub-gigahertz range that connects wagon to wagon all the way to the locomotive. This is what we call train networking. It must always work so that we can perform the brake test. The test must also work when the train is standing in a tunnel where the wagons have no LTE connection to establish a cloud link. In addition, there is the requirement that a wagon should also be accessible in the cloud for firmware upgrades, position transmission and other functions. For that purpose we installed a classic LTE modem in the wagons. However, it is only used occasionally because LTE consumes quite a lot of energy. When working with solar cells we cannot run it continuously. Nevertheless this connection is important because the manufacturer typically sees such a wagon only every seven years. If something needs to be done within those seven years, the wagon might be somewhere in Europe. We also have so-called pioneer trains that run ahead in order to test this technology in real operation.

Mirko

The good thing is that one of them is located in Berlin-Spandau, not far from us. You drive there for about 45 minutes and can access the hardware. But when you stand in front of it, you notice that what you last screwed on is now covered with two centimeters of sand and the screws look very different from when you left them. That’s a classic engineering situation: you quickly think of a solution. Now we have small 3D-printed protective caps that we place on top so we can access the hardware faster. That way we don’t have to blow it free with compressed air and we have fewer problems. The nice thing is that development moves forward very quickly. You can access the hardware and quickly bring a new iteration of the hardware to the customer. We recently successfully completed the first stage with a brake test where both the customer, the manufacturer and the carrier were present. That is always an exciting moment and of course a great success. You see that it worked exactly as planned.

That really sounds great. I’ve also heard before that when you have so many assets in the field like these wagons, sometimes wagons actually get lost. It’s hard to imagine because they are not exactly small.

Tobias

Suddenly 40 tons are gone.

Exactly. And then using IoT together with the brake test – the digital brake test – is really impressive and illustrative. You mentioned that you have a modular toolkit. How did that toolkit come about? What “compartments” are there that you can draw from? How did you structure it? What “compartments” are there that you can draw from? How did you structure it?

Tobias

The toolkit is part of our ecosystem. It’s called L.IoT. This ecosystem addresses various aspects of industrial IoT. Fundamentally, we believe that this topic can only be handled successfully if you work on both the hardware side and the software side. It is very difficult to isolate one from the other. If I look at the edge device, meaning the physical device, then I have a toolkit there that is more hardware-focused. If one of the challenges is to manage energy and first of all to generate energy, then this toolkit contains technologies for converting energy, for example harvesting from solar cells and from other sources. It also contains technologies for storing energy using battery systems. With batteries, the temperature range is always a key issue. We even have batteries that can still be charged at minus 30 degrees Celsius. On the wireless communication side, we have many modules that are relatively straightforward, such as BLE, Bluetooth Low Energy. That is often used to configure a device with a smartphone. That is a typical use case. I have a device that gets installed, for example on a freight wagon. In Europe there are around 600,000 freight wagons. That means a huge number of retrofits need to be installed in existing wagons. Then I somehow have to configure them. I do that with a mobile app, using BLE on the device side. I could develop this from scratch every single time. But if I already have the connectors on the mobile app side and the entire Bluetooth logic for the device, then I simply take it from our toolkit, put it on the board, load the software, and the customer developing the whole solution can focus on what the actual substance is: what we call the Customer Business Application, meaning the actual business function being executed. In principle, it doesn’t matter whether we are talking about the freight transport example or whether our technology is used in hydraulic excavators from a leading German manufacturer. We are active in oil and gas, for example in refinery monitoring, where the focus is on accident prevention. These are very different areas. These are very different areas. Fundamentally, the customer always wants to build this Customer Business Application because that is where the value lies. But they also have to develop a device, develop hardware, develop device driver software. They have to test it, make it robust, manufacture it – in other words, produce it cost-effectively in large quantities, because the business cases are usually very narrowly calculated. And they have to manage the whole thing over its lifecycle.
That is exactly where our ecosystem comes in. Secure software distribution to a device: we had to do that in every application, so we generalized it, built it into the toolkit and into the ecosystem, so that customers can really focus on the Customer Business Application. That means I have hardware-near building blocks that help me set up the edge system. But I also have software building blocks that help me maintain the overall system and keep it running over time.
That sounds very comprehensive. Can you also show where the boundaries are? It always sounds nice when someone says they can do everything, but where are your real focus areas, and where do you draw the line? I understood that OEMs are your focus. And they have to manage the whole thing over its lifecycle. That is exactly where our ecosystem comes in. Secure software distribution to a device: we had to do that in every application, so we generalized it, built it into the toolkit and into the ecosystem, so that customers can really focus on the Customer Business Application. That means I have hardware-near building blocks that help me set up the edge system. But I also have software building blocks that help me maintain the overall system and keep it running over time.

That sounds very comprehensive. Can you also show where the boundaries are? It always sounds nice when someone says they can do everything, but where are your real focus areas, and where do you draw the line? I understood that OEMs are your focus.

Tobias

From our point of view, digitalizing a product is far more complicated than digitalizing a process. The challenge is that it takes a lot of work to do this properly for a product. With the ecosystem, parts of it become scalable. Everything that can be scaled, licensed or simplified – we have tackled that. We are not completely at the finish line yet, but that is the area where we see ourselves. One of the difficulties is that the lifecycle of an industrial IoT product is much longer than the development cycles in IoT, electronics and information technology. A hydraulic excavator has a 20-year lifetime in the field. If we look back 20 years: what were we doing with IoT back then? Not very much. The question is: what will I be doing in 20 years? From our perspective, it is important that the management system can be carried forward into the future. That is how we came up with the idea that you have an edge device running an operating system – Linux, for example. Ubuntu Core or Yocto or Red Hat or Debian. I may want to switch that at some point, because in five or ten years I might say: development evolved differently than expected. Things like that have to be possible, otherwise you spend far too much time today thinking about what the ideal edge operating system is. There are huge debates around that. Our view is: no matter what it is today, tomorrow it will be something else, and spending too much time obsessing over that is effort invested in the wrong place. Then there are customers who already have existing devices. These devices may already be ten or fifteen years old. They are IoT devices that were installed in a very early phase. Some manufacturers have been doing this for 30 or 40 years. The question is: how can I still integrate them with new management software, with an L.IoT system? There are often limits there. Then we have to say: it works to some extent, but not completely. We try to capture and enable as much as possible, but if the hardware or the connection does not support it, then we cannot do it either. Those are the situations where we need to talk with the customer and find a compromise.

Mirko

Customers often come to us with complex problems or integrated solutions: temperature measurement plus switch monitoring plus location tracking and then also data connectivity. Or they have specific framework requirements, such as ATEX certification in refinery environments, or special shock and vibration requirements, including for freight wagons. Our batteries had to undergo extremely demanding qualification tests. These are the kinds of scenarios where off-the-shelf IoT solutions are no longer a fit.

I really am impressed by the breadth you cover, from software building blocks all the way through to hardware. Hardware is another area that interests me. You even offer series production of hardware components. Mirko, could you briefly explain how you go through this hardware journey together with the customer?

Mirko

At the very beginning there is the customer’s idea and requirement, and a joint look into our toolbox with the customer: which elements do we already have? If we can cover a large part of it, we know that development will move forward very quickly. But we also do not shy away from integrating new things, fully aware that this comes with development time and cost. That is the starting point where the different disciplines in my team begin working together. There is classical engineering: analog circuit development, which you always have. You need to provide operating voltage, and there may be analog inputs you need to take care of. Then there is the digital side: processor selection, digital circuit design, and the topic of transmitting data. We always have antennas, and we design them to the best of our knowledge and belief. The exciting moment is when we get to the first prototype and start running our tests on it: what ranges do we achieve, where can we fine-tune? We have equipment for measuring antennas. And then: how does it actually perform in the field? We have equipment for measuring antennas. And then: how does it actually perform in the field? We can carry out many preliminary tests ourselves. In the end, there is always another step where it goes to a certified testing institute, or our customers have their own test benches and test rigs. In the rail sector, for me the shaker test is always a very impressive test. The standards clearly specify that you have to run through these acceleration levels for so many cycles and sequences, and the hardware has to be shaken accordingly without failing. You sit there watching closely, often at the customer’s site, asking yourself: are the data still coming in? Are the data still coming in? It is a great moment to see how hard the product is being tested. These are requirements that often rule out simply taking hardware that already exists on the market. This sheer number of requirements within one package, combined with harsh environments and standards that have to be met – having all of that come from one source is essential.

What I’d really like to understand is the business model behind it. You build the hardware together with the customer, and also the software packages. One thing you do not do, as I understood it, is Software as a Service, where many companies try to get the customer into a login model so that they pay on a recurring basis – monthly recurring revenue and similar things. Tobias, what is your business model? How do you approach it?

Tobias

We look at it from the customer’s perspective based on the value of the assets. If we take a hydraulic excavator as an example: our technology is installed there, there is a manufacturer building several thousand of these excavators, and they remain in the field for 20 years. Twenty years is a normal timeframe. A freight wagon is in the field for 40 years. The number of these units in the field is what we call the asset value. I have a fleet in the field, and that fleet has a certain value. This value is often in the single-digit or even double-digit billion range. If I now say that I want to digitalize this product and equip it with new features, then digital operation becomes a major risk. There is one thing that absolutely must not happen: after ten years, the system must not fail if it was designed for 20 years of operation. At that point, classic SaaS providers cannot deliver because they cannot say: we will offer our service for 20 years. In 20 years they may be doing something completely different. That means the customer’s digital independence is extremely important. This applies to operating the systems, but also to the political framework conditions. If I have a digital product and it creates digital value that I use for product development or customer services, then I want to make sure that these data remain with me. A certain degree of skepticism toward non-European providers is justified. This is also changing politically. Three, four or five years ago, we might have said: America is a safe bet, you can do everything there. Today some people think differently about that. Political systems change, technologies change, and providers’ economic strategies change. If I add all of that together, then for a customer with high-value assets and obligations toward their own customers, there is really no alternative but to operate the whole thing themselves. L.IoT is not a SaaS system. You can use it as SaaS to try out how it works, or in early product development when you want to keep things simple. But there comes a point when there is real value behind it, value that is being controlled through this system. Then I have to say: I need to run this myself. We understand that and support it. We do not try to force our customers into dependencies through rental models or Software as a Service. That is where we differ from many of our market companions. We say: the customer must have data sovereignty and system sovereignty. Of course, what we do provide is software maintenance and service if there are questions. But fundamentally, a customer must be able to operate this system independently. Because the digital future is also part of digital sovereignty. And if I digitally develop a system or a product, then tomorrow I still need to remain the owner of the product’s intellectual property. That is what we want to ensure.

Very exciting, especially because this is a topic for every OEM manufacturer, and also because of this perspective on what it takes to keep such systems running reliably in the field over many years and decades. Thank you for these insights. Before we wrap up, is there anything you would like to leave with the audience? From your point of view, what is important on such a digitalization journey? What should people keep in mind?

Mirko

I would like to add one point to what Tobias just said. This does not apply only to the software side, but also to the hardware side. We follow the same strategy there. If the customer wants to move out of the development phase and says: we want to do series production somewhere else, or we have our own plant for that, then according to our contractual arrangements we also hand over the circuit diagrams and the fully developed hardware so that, if they want, they can reproduce it elsewhere. At the same time, we also offer series production in-house. The benefit for us is that we can carry the knowledge from development directly into series production. If there is troubleshooting, we are probably faster than others.

Very good. Tobias.

Tobias

After now having developed quite a number of products successfully – and certainly also some that we could not develop successfully – one thing has become very clear to me: if you have the idea of digitalizing a product, then you should not be guided too strongly by technical, software-related or hardware-related issues. Instead, the first question should be: where can I create value? Where can I modernize my product? Where can I digitalize it? You should then focus on what we call the Customer Business Application – in other words, the actual value. We often see broad discussions about which operating system to use, which cloud provider to choose, what kind of system management to put in place, how to transfer software. Starting in 2027 there will be the Cyber Resilience Act, which means that cyber security for IoT devices will become even more complex. You can spend a lot of time and money on those topics. Unfortunately, in the end, nobody really pays for that. An end customer who buys the product expects, just like with their iOS or Android smartphone, that they simply download software and it works. That is the customer expectation. That is what you should focus on. The good thing is that systems now exist that take this manual work – in other words, the entire mechanics behind it – off your hands. That is a major advantage for Industrial IoT, because it allows us to focus on what really matters and enables customers to develop and bring their digital products to market quickly and efficiently.

Thank you very much for these interesting insights into IoT, and especially this fleet-based IoT. Thanks to all listeners for joining us, and see you next time.