Möchtest du unsere Inhalte auf Deutsch sehen?


CO2 & Energy Management with IIoT Software


Click on the button to load the content from Spotify Player.

Load content

Listen to the IoT Use Case Podcast on Spotify.
Listen to the IoT Use Case Podcast on Spotify.
Listen to the IoT Use Case Podcast on other platforms.

IoT Use Case Podcast #64 - AIM, Emerson, B/S/H

Saving fifty percent on energy costs – sounds exciting not only for the wallet, but also for the environment! In this episode of the IoT Use Case Podcast, three companies from our IoT community report on their successful project live from the shop floor.

Episode 64 at a glance (and click):

  • [04:28] Challenges, potentials and status quo – This is what the use case looks like in practice
  • [11:30] Solutions, offerings and services – A look at the technologies used
  • [27:22] Results, Business Models and Best Practices – How Success is Measured
  • [29:39] Transferability, scaling and next steps – Here’s how you can use this use case

Podcast episode summary

Podcast episode number 64 is about detecting and locating air leaks in pneumatic systems and how IoT can be used to prevent energy and power loss. AIM, Emerson Automation Solutions and BSH will show how predictive maintenance really works in practice and which top 3 business potentials are hidden here.

How are the three companies related? Emerson is a global technology company with over 140,000 employees in the mechanical and industrial engineering sectors. For this episode, they brought a project from their Automation Solution business on IoT-enabled pneumatic components. IoT implementation partner of choice is AIM, an expert in industrial AI solutions with a focus on predictive maintenance. Together they are realizing a project with BSH. In this project, the subsidiary of the Bosch Group is supplying real live data from the shop floor of its engine production facility in Bad Neustadt. 500 employees work there and produce three million engines a year. They are already using Emerson’s components and solutions for energy data collection.

At the end of the episode, Madeleine Mickeleit dives into an exciting discussion with her guests in the direction of the IoT app store.

The three podcast guests are:

  • Arvin Arora (General Manager, AIM)
  • Nils Beckmann (Product Manager, Emerson Automation Solutions)
  • Werner Schlembach (Production Manager, BSH)

Podcast interview

Nils, the first question for you as a pneumatics expert: Why is the topic we are talking about today important and what is happening in your market?


That’s where you have to go a little further. In many companies, energy consumption and efficiency are playing an increasingly important role. In other words, we see a great many companies setting themselves goals of being CO2-neutral on the road in the future, of minimizing energy consumption. This brings a wide range of advantages for many companies. That also always depends a bit on the country. Some get tax benefits, for example, grant money that you can take advantage of. There are other countries that say you have to pay a penalty if you don’t meet certain CO2 targets. That’s actually where the issue comes from a bit.

We from our field have always been dealing with leakage, in the field of IIoT. Because we thought the issue is very important to take up. Because simply over the course of a product life cycle, if you imagine a cylinder … there’s movement in it, and of course it’s going to have wear at some point. This wear and tear also eventually leads to leaks, for example. In this context, leakage means that a seal may no longer be completely tight at some point and air escapes – this air is energy that I blow into nothingness. You want to avoid that. Because, on the one hand, this gives me increased costs, which means that you might need larger compressors if you don’t check something like this, because you increase the consumptions. But also this CO2 factor, which plays an increasingly important role at this point.

If you look at a typical production line like this, you can say that statistically 20 to 30 percent of a plant’s energy consumption is due to pneumatics. In other words, energy consumption is converted into air, so to speak, and then you have statistical values again that something like 30 percent of air consumption is really leakage – which is a relatively high value. That’s why it’s an exciting topic for many companies to start there and say, I’m now really actively trying to do something about this and eliminate such leaks, for example.

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

Here in the podcast, we always talk about specific use cases from the field to understand how the technology works on the part of AIM, but also your insights of the data on pneumatics. But you’ve actually already said it – that is, we’re dealing with the issue of localizing air leaks today, that’s what it’s all about in the end, right? That was also the goal of your project?


Exactly, that is our goal.

Then let’s jump right into practice. Werner, I’m looking in your direction. I’d love to understand what it’s like on your site. I’ve also been in production a few times and maybe one or two listeners will come from your area as well. But just to classify the topic: What does it look like on site, what machines are there and how do you imagine the processes? Give us an insight into your Daily Job.


We have fully automated production here, which means that we no longer have any manual workstations. The machines are usually set up as lines, where one employee virtually looks after the line, including materials planning, quality checks, repairs – really keeping the line running. That is the task. And there are a lot of pneumatic and electric drives in there, due to automation. Then you also have leakage. This is actually the day-to-day business that we always have. In a maintenance plan, we include air leakage detection. We have that in every six months. This means that an employee now really does walk through every six months, using ultrasound to locate where leaks currently are. With automatic localization, we naturally expect to be told the exact cylinders or valves where a problem has actually occurred. At the moment, we do it like this: We have intervention limits where we receive a message. We always just have that on a whole line – there the employee still has to search, where is the leakage? And with Emerson’s system we really have a detailed evaluation and also a detailed result about it.

Nils has just said that 20 to 30 percent of the potential in this is in compressed air – are these also YOUR challenges here?


We do the whole thing twice a year and we always find, between 18 to 24-25 percent, that’s not uncommon. We are also currently in the process of defining measurement parameters – at what point does it become economical to shut down a leak? If I have a small cylinder and I have 25 percent leakage there, but it costs x times the savings to repair … that’s where we’re currently in the process of establishing a metric. At what point is it really economical to shut it all down? 

Nils, do you have any additions to that from your perspective?


What Werner does in his plant is definitely very exemplary, it must be said at this point. Because, of course, he already does that regularly in his work. We also know other customers, where it works a little differently – up to the fact that such a thing is NOT checked. Then you can certainly imagine that, especially over time, extremely large costs are incurred – and CO2 values, where we have already been able to surprise one or the other customer as to what potential is actually slumbering there that could be leveraged.

I was about to say, that costs real money when you think about downtime. After all, that’s also something that can be easily saved. If such a cylinder fails, in the worst case the whole machine stops?


Exactly, that is actually such a first indicator for it. If you have leakage, that kind of thing, of course, can lead to shutdowns in the long run, or even performance problems of the plant. You can imagine that if the leakages in the overall system become too large at some point and I can no longer get enough air into the overall system via the compressors, a cylinder like this will also slow down at some point. This means that this can also have an influence on the performance of a plant, and thus also on the total output of a plant, for example. 

Again, to understand this leakage in itself. At some point, I think it was the second or third semester of my bachelor’s degree, I had a lecture on fluid mechanics … I can still remember it. I would now like to explain a little bit to the listeners how such a leakage or leakage detection can actually work. After all, the bottom line is pressure, volume flow, you take environment or even the friction partially. How do such leaks actually occur, Werner?


Through obsolescence or life cycles, how long the machine has been running. The movement of the cylinder causes wear. Then leakages appear. What we always detect is also the whole bolting technique. So I screwed in a cylinder, connected a valve – that’s where we find out, there’s the first leaks that we see like that. As Nils said, we definitely notice it in the performance of the system. This means that we lose one, two, three, five tenths of a cycle time somewhere, and the output simply no longer fits. This is the first indicator – if we do not get a warning message, “Attention”. That is, as a rule, we have one monitoring system per line. If we have too much leakage, we need more air. But here, a system needs about 2000 standard liters per minute – we add 10 to 15 percent. And as soon as we’re above that, a message goes out. But the locations, as I said, that’s really a manual thing. That is, there really is an employee walking through with a microphone and locating it via ultrasound. With us it is also like that, everything that is shorter than ten minutes, quarter of an hour, is immediately turned off. What takes longer, like removing a cylinder, which is an hour repair, then you have to plan for.

That is, in the ultrasound process, someone sort of goes through and really looks at leaks like that with a microphone?


Yes, five years ago we did it like this: Someone walked through. He also managed the whole site in two days. Pasted a sticker everywhere. Only, that does not work … the next then comes and repairs and again does not know where to find the leak and must search again. Therefore, you have the right efficiency if you turn them off right away.

Nils, would you agree with that? Do you have any additions from the world of compressed air?


Yes, that is also an essential aspect that we see as a great benefit behind such a solution. I’ll say that if you do a leakage test like that twice a year, of course you still have the period in between where something can happen that you might not even notice. But such an algorithm is able to permanently monitor something like this afterwards and give direct feedback: “Watch out, your leakage is in such and such a place, take a look there” Ideally, of course, also connected with indicators. That, by the way, is also the cost of it – that someone like Werner might find it even easier to say, from such and such an amount of euros, it really makes sense for me to stop my machine briefly and replace it. That’s where it flows together at that point.

Solutions, offerings and services – A look at the technologies used [11:30]

Let’s talk about the solutions. In the end, Werner, the requirements were important for you: You had to capture this compressed air, you wanted to locate it and replace these various manual processes with digital ones – that was the initial situation and the requirement from you?


That was our wish, yes. As I said, we have been working with Emerson, AVENTICS, for years. This has always been an issue, with AVENTICS, Emerson as well as with us. We have developed a system at our company – we evaluate all the data via OPC UA, so to speak, and receive a daily report, what number of units did we build and how much energy did we use? You first have to make it handyy, the whole thing. You have to capture it. You have to know what you are consuming to be able to respond. And where do I consume it? And that’s where the partnership with Emerson worked out perfectly for us, and we’re also happy to be involved in such pilot projects because it simply helps us move forward.

This is really a pioneering project and you are also pioneers with digitization to learn and further develop such topics. Arvin, you are now our expert on the software side, including predictive maintenance. What was your goal? How did you come in to tackle the project?


When I think about our first round, the starting point was that Emerson already had approaches – but the challenge with such a complex system is that it can naturally have very different dynamics. A classic approach is to simulate such a plant. Differential equation, for example, is such a topic. But this is very complex. And the exciting thing now with machine learning, at the other end of the scale, to ground it a little bit, is that machine learning or AI models like that ultimately learn patterns from data. In this particular case, you should use as few sensors as possible. In other words, sensors are often not available in abundance, which is also a key issue. This means that the approach here is to create such leakage localization as early as possible and, above all, in a continuous process with as little sensor data as possible, in fact only one central flow sensor and the control signals. Nils and Werner have already described that classical methods are rather low-frequency and also relatively costly. And ideally, you want to locate such leaks as early as possible and continuously monitor your system so that you can also decide exactly when the right time is. That is to say, this is a very special situation: little sensor data and still squeezing out information, to put it a bit bluntly. The other situation is often that there is a lot of data. Systems also spit out several hundred data points in some cases. Then you tend to have the opposite issue – namely, first figuring out where do I even need to look now? So setting thresholds and finding the right places is often the challenge there. But HERE is just the other end of the scale – as much data as possible and still detect the leaks.

Nils, maybe we can shimmy a little bit from the shopfloor, from the hardware into the data analytics world. Can you tell us a bit about what steps are needed to address this issue? You already have an enormous amount of expertise in this field, including in the area of IoT. How does the data acquisition, the processing and then maybe in the last step the analysis work?


We said from the outset as Emerson that it is quite important to us that we can already read data from our components. That means that the first step for us – back when we started with the team – was to also enable our products. To say that we’re now going to bring in interfaces. Because what we often see in the field is that the customer may already have a machine and may not have easy access to the control data – in this case, we have first created ways for us to read data from the valve system, for example, from sensors past the normal control process, which then in turn help us to do something with this data. As Arvin has already mentioned, this means that we don’t have a lot of data points at our disposal, but rather selective data that we record and that we need for the procedure. Our approach is to do this with as little data as possible. After all, you don’t want to add a whole lot of sensors to the system afterwards to make this process possible. Instead, ideally you take the sensors that are already there anyway and work on the existing components. That has also been a very nice case at BSH, that we already have our components in there anyway, so we can access that data very easily. So data acquisition is the first point, and here, of course, protocols such as OPC UA and MQCT play a very important role and are used very frequently. The next point is data processing. We have solved this by pre-processing the data to a certain extent in the valve system. That is, data is already prepared there, correspondingly very high resolution. This has the advantage that we can also process them better afterwards or also get better results. And finally, it goes into data analytics, where we also offer some solutions, but now in the context of leakage detection or leakage localization, we are working with AIM.

That means you have also created a kind of new product series for these sensors or for the compressed air components, which are probably also IoT-capable, right? That was the first area where you said you had to create interfaces. That’s also something that you had to enable in your products in the first step, isn’t it?


Correct. With a machine builder, things are always quite different, because he can of course simply access all the data via his control system. You can always solve this relatively easily. In the case of an end customer or a user of the machine, things are often different. They do not have the access, and thus you have to enable this access to the data. And that was exactly this enablement that you were talking about, which we did with our products first.

And in the next step, we also talk about edge computing, which means that you already do the data processing on the machine itself or on the shop floor itself, where you already perform these preliminary analyses in the components themselves, so to speak. And the next step, to say we’re doing data analytics in the IIoT – so that you now really plan to take the next step now, to evaluate these analytics accurately, but also perhaps make them available to others. Arvin, how do you support here in this area? Do you then record the training data, these metrics that Werner had talked about?


This is a nice point to see this close interaction again as well. Nils has already described what Emerson themselves are already doing to get these signals at all and also to be able to carry out analyses on them. In fact, the next step: even from the machine learning or AI point of view, of course, you already have to understand what the characteristics of such signals are. There are such small hurdles and traps that, for example, the timestamps on these signals can vary, or are not synchronous. That’s where it starts. That’s sort of where we take over, if you will. First of all, the data provided is preprocessed and supplemented. And then, as you said, a distinction is made between supported machine learning methods, i.e., they are given explicit training examples. A striking case is of course always, I want to predict a fault – sample from a PLC or from a maintenance system, then I have a historical fault message. I can then use these as explicit training data.

Exactly, I have to have them first, so to speak?


Exactly, I have to have them first. “Unfortunately” – although this is of course the desired state – disturbances do not occur so often. That means I often have little training data. And the other thing is so-called unsupervised methods. That is, the model is not trained, but one has to recognize patterns from the data structures, from the dynamics itself. The exciting thing about what we’re doing with Emerson is that it’s actually a bit in between. Because the problem is, first of all, that I need some kind of reference. On the shop floor, I don’t have such ideal conditions that systems are completely free of leaks – so selectively, “there’s a leak and I can train that now” … that’s not usually how it is in reality. Instead, you somehow have an actual state of the plant, where you say that it’s okay for now. And now I actually have to look, does the behavior change in the pneumatic system? That is, we actually have such a mix here – we kind of need calibration. You have to say once, this is the state of the plant now: And then a model actually learns – that is actually supervised again, if you like – the performance of the plant. And that just gets the control signals and then predicts the flow. What we actually do then is to recognize when the forecast of this model gets worse. This means that, in principle, you can first see that the flow has changed somewhere due to leakage. This is a central building block. But there are a few other things that go with it. Because with it I have not yet made a localization on the individual components. You have to use a few more tricks to get that far.

But the bottom line is that it’s kind of an iterative process? You first have to get the model, as you say, to learn in the first place with the unsupported method, where the training data is not available, so to speak. And if an air flow changes, you have to go in somewhere iteratively probably and say, “this is the condition now, this could lead to leakage in such and such cases,” and then kind of flag that – or how do you say that in the AI environment?


Yes, forecasting, inferring, there are quite wild terms. Predictions. Above all, you always have to keep the user in mind. He’s not interested in all this AI stuff. A little bit figuratively speaking, actually I need two buttons: Now please calibrate yourself to the system and Now monitor the system and just let me know if you think you see a leak on a certain valve there.

Exactly, so Werner … that’s not your core business. After all, you have other issues on your plate and you want to cut your costs. Then you have the two experts in the round. But for that, of course, you first have to set up these laboratory scenes, that is, produce this calibration. To maybe get into the individual solution building blocks: Nils, what do I need now as building blocks, both from you and from AIM, if I want to implement a similar project? Can you summarize that, from the hardware side, from the software side?


From the hardware side, you definitely need an appropriate flow sensor that is capable of accurately enough recording this data flow. And then also a valve system. This valve system of ours is able to pre-process the data there already with very high resolution. Thus, this data is then also passed on from such a valve system directly to a gateway, where it then comes to further processing. That is, that is then also the place where, Arvin, in principle then your software is used.


Yes, exactly. In principle, once the entire process has been worked out – we actually tested a wide range of process variants together …  In the end, a software component comes out of the service. It must actually run hidden in the background. In certain situations, cloud operation is certainly also interesting. But often, of course, that’s not such an ideal option because not everyone wants to transport their machine data to the cloud. That means you have to be able to run these components very close to the shop floor – on the edge, as they say, that is, on an industrial PC, on a gateway. And then there are actually two interfaces, two calls: One is called “Calibrate yourself to the plant” and the other is called “When you’re done with it, monitor!”. This means that it is very important from a craftsman’s point of view that such components can run in very different forms of operation. That you can push them somewhere so that they can also run very close to the machine.

And Nils, if you now locate this again to the initial goal – the bottom line is that you and Werner want to know, where in my machine is the leakage? Fixing of the root cause in the end. Does that solve it? Is that the output with this algorithm? Or where do you stand now?


Exactly, the output is then already that we really say, “behind this valve is the leakage” – that is the output that comes out of there. That is, you can imagine that afterwards you have an image of such a valve system. That is, of the valve system that is installed in the system. And the corresponding position is marked there. Of course, the whole thing is linked to alarms, which are then perhaps automatically sent out to the maintenance team so that they are also informed. Because, let’s say, no one constantly looks at a dashboard and says, “ah, now the red light is on. 

Exactly, that has to be integrated into the maintenance plan.


Exactly, right. From that point of view, it’s a matter of being actively informed, so to speak, when it makes sense. Of course, the whole thing can be linked again with such KPIs as Werner mentioned. That you say, at what point is it worth it? At what point do I even inform my maintenance team to take action? Such links can also be stored there.

Nils, what is the name of your product? You said it’s a valve system. Do you have a name for it? Is this an IoT name or just a regular valve system?


This is not a normal valve system, of course, but a really good, IoT-enabled valve system. The series we usually use for this is the AV series. That means that there is a whole configurator for such a valve system on our site, where the user or our customers can configure their valve system, with the most diverse valves, with the various digital inputs, analog inputs. That is, this is a very flexible system that is built. And in addition, what we have brought in there in the IoT context are these IoT functions, so what you also don’t necessarily find in the market in this form.

Because if I’m a listener now and I say that sounds super exciting, I want to read up on it – I would link that in the show notes, also the contacts to you guys if there’s any queries. Arvin, if I want to implement this issue tomorrow – what’s the best way to get into an issue like this, how do I go about it?


We deliver, on the one hand, a whole range of solution modules. So everything that needs to be done as basis. That is, take the data over from the IoT components, put it into a reasonable data model, which reflects, for example, the structure of the syste, and so on. In other words, the entire basis for being able to process the data from systems and machines cleanly and as standardized as possible. That is an important component. And then it is usually best practice, or advisable, to first understand the system fundamentally at the beginning, like with a quick diagnostic kit. Because, of course, there are all kinds of variations on the shop floor. There are plants that are very clocked, periodically controlled. But even then, if they are very high frequency or the signals are very synchronous, then of course there are limits to where you can detect such interference and wear. Or the events are more event-driven – that’s what we see at BSH. It’s not like the system always spits out an engine so precisely every ten seconds. But you can see that it pulsates a bit and that there are also external influences. For example, coils that unwind. That is also a topic that we had. This means that it is very important to quickly analyze the data at the beginning and get an initial picture of the dynamics of the plant. And also, frankly, whether the use case is IMPLEMENTABLE at a particular plant.

Results, Business Models and Best Practices – How Success is Measured [27:22]

After all, it’s always about return on investment – the business case is paramount. In the end, you want to save processes and, in this case, optimize the maintenance plan and find these leaks. Do you, Nils, have top 3 issues where you say that’s actually the business case for the pneumatics topic? Can you give us some insights?


Well, sure. I had already mentioned it a bit at the beginning. This CO2 aspect is very important for many companies. You can also find energy managers in more and more companies who make sure to meet their targets. Of course, something like this can help enormously. The second point is cost savings – I may need less air because of it, I can ramp my compressors down a little bit further, really save energy because of it, and I have very early detection because of the continuous monitoring, which minimizes the cost. And then, what Werner already mentioned, this manual process – you need appropriate equipment, people have to be trained, I send someone through there to scan for leaks … it all takes time. That is, such an algorithm can replace such a manual process, so that the employee has more time to focus on the actual things, perhaps the actual maintenance, the replacement.

Werner, what is your learning? Do you have any kind of best practices that you can share with listeners? Where you say that was super important to YOU and did you learn from the project?


We learned a lot from the project. We’ve already been working on the issues massively since 2018, because we also recognized – CO2 neutrality, energy costs are going up, and, and, and. Since 2018, we have cut our energy costs by about half. Of course, these projects have also had a significant effect. This simply helps us to ensure competitiveness here in Germany as well. You also owe it to the environment – you’re also doing something good for everyone involved. In this respect, you save money, and everyone has a benefit from it. We would also be ready for new topics at any time, because it is just totally important.

Transferability, Scaling, and Next Steps – Here’s how you can use this use case. [29:39]

Arvin, if I’m a listener now, have challenges, but may not be on the shop floor, but have a pneumatic cylinder installed somewhere else. Or I listen and think, this could be interesting for me, too. Do you have any idea how to transfer this use case, the project that you guys have implemented now, to others?


In fact, we have been confirmed in our conviction that it is necessary to work on these issues in a very focused way. Because pneumatics and flows are something different than vibrations or temperatures. There are also differences according to plant type. The right added value and effect is achieved when you create really specific solutions for this and combine it all together.

But well, WITHIN pneumatics this is of course transferable anyway. So the solution we are developing together here is a pneumatics-specific solution. I think WHERE the cylinders and components work is then not so decisive for the time being. But what we’re doing now, from AIM, is of course transferable per se to other areas. Of course, we also do things in the area of, for example, wear, of rollers, of transport systems, by analyzing vibration patterns, just as an example. Or prediction of the malfunction of a refrigeration system based on relatively many sensor and control signals. So it’s very use case specific, but from our point of view, of course, many of these tools are also generic, and you can transfer them relatively quickly to other use cases.

What is important, I think, is that the user is always clear about which systems have the greatest potential? Also, where do I have data available without having to make a huge effort? And how do I bring that together in the middle?

What I also find totally exciting is that we also have some insurance and reinsurance companies active in the IoT community. They’re also starting to build out new insurance products and ecosystems now, for example on leakage. These are now also completely new players that are suddenly getting involved. Who then also want to leverage added value and potential that the whole topic brings with it. On the one hand, I find that super exciting. And the other, because you just said, specific solutions: I could perhaps also imagine certain scalable solutions developing in this field as well. So that there are apps for certain use cases or for certain areas that might be repetitive. Or do you not see it that way at all, so would you say it’s ALWAYS specific?


In fact, I just talked to Nils about it again yesterday. I think we agreed there that you can actually assume that certain plug-ins will exist. For very specific types of machines or components. Because, as I said, that’s the only way to create solutions. So I don’t think there are these plug-and-play “I’ll just click a bunch of stuff together” things for arbitrary facility types and situations. So for the time being at least. Rather, they will be specific solutions that can be put to use very quickly.

The first app stores are also available for IoT. Nils, do you also think, hey, there’s now an Emerson app for various use cases – leakage, we have three apps there, because that always works similarly in terms of analysis? So scalable issues like that, I think that’s an exciting approach.


We are definitely thinking along those lines. I believe that in the future it will be important to address these issues, as in the B2C market with an Apple or Google Playstore. There have already been one or two developments in this area. Will certainly also exist for such gateways that will perform such a function. Or such a cloud – even the big cloud providers already offer such app platforms, where you can integrate your app. Of course, that’s also an issue for us, definitely.

Maybe we’ll get together again in a year or so, and then you can report on your first app.

Please do not hesitate to contact me if you have any questions.

Questions? Contact Madeleine Mickeleit

Ing. Madeleine Mickeleit

Host & General Manager
IoT Use Case Podcast