180km Steam Network: Wireless Condition Monitoring with LoRaWAN

Hello, dear IoT enthusiasts, and welcome to the IoT Use Case Podcast. Today we're talking about Smart Dampf – the digitalization of an industrial pipe network at CHEMPARK – essentially a digital twin for the steam supply. Joining me are Murat Mutlu, IoT Portfolio Manager at Currenta Conneqtive, and Dominik Neugebauer, Head of Pipe Network Technology at Currenta. Same company, but different departments and perspectives. Murat brings the IoT and systems integration perspective, while Dominik contributes the operator and pipe network context. Together we want to explore where a historically grown steam network lacks transparency, what value there is in addressing that, and why you can’t simply run cables everywhere.

Welcome to the IoT Use Case Podcast, the channel featuring the latest IoT projects from our implementation partners in the market. Dominik, when you look at the steam pipe network at CHEMPARK – what are your everyday challenges?

Dominik

As pipe network operators, we are responsible for nearly 1,000 kilometers of pipeline, around 180 kilometers of which is steam network. I think that number alone captures it. 180 kilometers is an extremely long asset, subject to an enormous number of influences during operation – a lot can happen.

We at Currenta operate three chemical parks – the CHEMPARK at three locations – with various feed-in and offtake points within the system. We operate both the steam generators and waste heat feed-in points – or rather, those come from the customers – as well as the corresponding steam consumers, all of which are connected to this very static asset: the steam network.

And unlike a wastewater treatment plant or a power plant, not a great deal changes in a steam network under ideal conditions. But it is still complex to operate, because with so many unknown influencing variables, we as operators – with our generation portfolio on the feed-in side – still have to ensure that our customers receive steam at maximum availability and in accordance with specifications. And all of this with an asset that essentially doesn’t move – it’s very static, it just sits there. And it has to be able to handle all network conditions, from minimum demand all the way to peak load coverage in winter.

And yet it must not generate excessive reactive power – meaning minimal losses, minimal condensate losses – what we call steam that is lost due to heat dissipation within the system. The challenge we face is that some customer installations are located very close to the power plant, while others have offtake points far away. A great deal happens along that route. When we’re out in an area where ideal power and data connectivity isn’t available, we as operators face the challenge that precisely at that point, we can’t measure very accurately what’s physically happening to the steam.

Can you give a few examples? What kinds of consumers do you have, how do they work, and what do they use the steam for?

Dominik

Our customers are mostly chemical manufacturing companies within CHEMPARK. They primarily need steam as a heat transfer medium. The steam is superheated – meaning we’re not dealing with conventional water vapor or saturated steam, the wet steam range you’d know from a domestic kettle, but a pressurized system. Our steam is superheated, which allows us to load it with significantly more energy than we could under atmospheric conditions. And our customers primarily want to transfer heat. If they have a chemical process with reactors that requires energy input, that is typically provided via steam.

There are of course also electrified systems, or systems that are supplied directly with fuel. We at Pipe Networks also operate a very broad, wide-ranging natural gas network. Energy could theoretically be introduced through thermal conversion there as well. But if that’s not desired, permitted, or feasible, then steam is a heat transfer medium that Currenta supplies.

And Murat, LoRaWAN is truly a fascinating topic in itself, because many people are considering it. Can you explain a bit more? The cable option on one side, LoRaWAN on the other – were there other contenders in the selection process? How did that look for you?

Murat

Exactly – that was about three or four years ago, when energy prices rose sharply. The question was: do we run cables, do we go with LoRaWAN, or do we use 4G as our IoT or IIoT connectivity?

And we decided on LoRaWAN because we can keep the assets in-house – everything managed within the CHEMPARK fence – with the LNS on-site, the radio infrastructure on-site, and that way offer a secure product to both our customers and ourselves. LoRaWAN turned out to be the best solution for us because we can cover long distances with just a few antenna masts. I think we have four or five outdoor antennas across the large CHEMPARK. Of course, we also have local coverage densifications where needed – for example, in basements with thick reinforced-concrete walls. But with LoRaWAN, we can now monitor assets for four to five years on battery power. That’s very cost-effective for us.

Great. We can go a bit deeper on how a LoRaWAN network works and what challenges it comes with. But let me ask a more fundamental question: What data are you providing to Dominik so he can operate his steam network more effectively? What are all the data points?

Murat

The data points we can provide to Dominik are, on one hand, temperature readings from within the network. We measure these directly at the network nodes and along the pipelines, which gives him transparency and allows him to improve the simulation he already has – or, in the future, receive a dynamic simulation delivered by us.

And on the other hand, the steam traps: their status, what condition they’re currently in, whether they’re open, operating normally, or have failed, and what the temperatures look like. Combined with this data and our in-house physicist Anton Welker, we can create a simulation that dynamically shows what load profile and temperature levels we’ll be dealing with at different points in the network.

There’s already a lot in there – from steam traps, which we’ll come back to in more detail in a moment, Dominik, where you’ll explain what they are, what they do, and how they work – to temperatures, all the way to your simulation. Maybe, Dominik – how did things work before Currenta Conneqtive started supporting you with additional data points via LoRaWAN? What were the difficulties you were dealing with – and along the way: what actually is a steam trap?

Dominik

As Murat mentioned – several square kilometers of surface area. If you want to install a conventional temperature measurement in the middle of nowhere, so to speak, you need an enormous amount of cabling. Or rather – we are within the chemical park grounds, but connection points are sometimes several hundred meters away because we’re managing such large areas. And it’s simply very expensive to install a measurement device out in the field.

With LoRaWAN technology, we now have the option to install a location-independent monitoring system – Murat can say more about this in a moment – which currently runs on batteries, allowing us to capture values at any location, at a certain transmission frequency, and obtain information about our assets cost-effectively. In the past, that came with enormous costs.

And what does that give you once you have it? Does it mean you can control your network differently, more effectively? If you think about it in terms of opening and closing valves, adjusting pressure and temperature – what are the parameters you’re working with?

Dominik

Steam networks are static, and steam as a medium is relatively slow to respond. That means we can’t actively change the medium the way we would in a chemical production process. Instead, we have to work with very few input parameters and very clever network design. For example, I can change the feed-in temperature of my steam supply, but how much energy the steam loses on its way from the feed-in point to the offtake point is tied to the layered composition of the pipe walls, insulation, flow velocities, and the associated heat losses from the steam system. So as operators, we have very limited influence over what happens to the steam between generation and the customer.

Our job is to design the asset in a way that ensures customers receive steam that meets specifications – and, in the interest of the company and of operating this asset efficiently, to minimize losses as much as possible. And Conneqtive’s LoRaWAN system helps us gain visibility into our asset. Specifically: what is happening right now at exactly this point? We didn’t know that before. Previously, we derived it through simulations, and those simulations are only as good as their input parameters. The more live data we can pull from the system and feed into the simulation, the better the simulation becomes – and the better the investment decisions we can make when it comes to managing the steam network.

So the focus is primarily on investment decisions – in the sense of rebuilding, retrofitting, or expanding – rather than fine-tuning and adjusting ongoing operations in real time? That’s my understanding. And then – what actually are steam traps?

Dominik

All the parameters we can influence, we influence as effectively as possible to minimize losses during operation. But that is extremely difficult with such a large, slow-reacting asset.

What we then derive from this – especially because the CHEMPARK grew out of the former Bayer sites – is that it has changed significantly over the past years: from pharmaceutical production to crop protection, all the way to plastics, paints, and coatings. A very broad spectrum of customers has joined in recent years. And their needs differ from those at the time these steam networks were originally built. That sometimes leads to situations where pipeline sections that had very high flow rates 20 or 30 years ago may now be in a customer area where steam demand is no longer that high. This means slower flow velocities, more heat exchange with the environment, and consequently more condensate formation. That’s where we come to the steam trap.

And on the other side, there are of course new customers settling in areas where the network infrastructure wasn’t previously built out to the extent we’d need today. That means the data and the simulation tell us how we need to change our network as part of a target network strategy and right-size it to deliver steam in line with actual demand.

And now we come to the steam trap. When we have a section where flow velocities have dropped significantly – the flow velocity is slow. There’s no zero off-take; the flow velocity is simply low. And due to ambient heat losses, more steam undergoes the phase transition from superheated into the saturation phase – the wet steam phase. At some point, condensation occurs in the steam network. During this condensation, the steam turns back into liquid; it collects at the bottom of the pipeline and would continue to fill it until the pipe is eventually full of hot water. And that, of course, is something we want to prevent.

Steam traps help separate the liquid phase from the gas phase, and safely drain the hot water – essentially the loss – ensuring that only steam remains in the pipeline.

And what if one fails? That won’t happen in a catastrophic way immediately – we have a very well-connected, broadly meshed network to prevent that. But it could happen, for example, that a steam trap gets stuck in the open position, meaning steam is passed straight through it. You can think of it a bit like a small float inside a housing that gets stuck open and releases the full diameter, causing steam to be discharged when it shouldn’t be.

And you can imagine that with 180 kilometers of network, we have a very large number of these steam traps – several hundred units. Even though we do our best through inspection rounds and similar measures, it can always happen that a trap reaches the end of its service life, gets stuck, or something else goes wrong. With the Condition Monitoring system we are now setting up with Conneqtive, we receive early information about the current condition of each trap – whether it’s working as intended, or whether it’s letting steam through unintentionally. We then have the ability to schedule maintenance very quickly, keeping loss levels as low as possible – and also, through this data collection, potentially developing further in the area of Predictive Maintenance in the future. Rather than waiting for a trap to reach a failure state, we would be able to make the decision early – based on operating data or vibration measurements – to replace a component proactively.

Especially when it comes to monitoring, you have all kinds of different assets in the field from different manufacturers with different maintenance cycles. That’s probably difficult to coordinate. And then optimizing on top of that – things can still go wrong between maintenance cycles. Murat, how do you deal with that?

Murat

Exactly – for the steam trap inspections, which we’re now also rolling out across the LoRaWAN network, we can move from frequent manual checks to an automated hourly interval. This allows us to monitor far more consistently and drastically reduce loss periods.

That sounds great. And a LoRaWAN network, once it’s in place, can actually do a lot more. I think that’s one of the special things about it – once you’ve built the network, it’s available. Can you talk a bit about the first steps with the LoRaWAN network and what further expansion stages you have planned?

Murat

Exactly – we started the LoRaWAN network for the steam use case, because that’s a very compelling case for us as a CHEMPARK, given the enormous amounts of energy flowing through it. And now we have the advantage of being able to use it as a shared medium. We come from a fiber optics background, where we lay fiber all the way to every building. We already know that approach from the past, and now we want to make LoRaWAN accessible to all our customers across the 11 square kilometers – and beyond the fence.

We’ve built up real expertise in how to achieve coverage – both outdoors and indoors – and can now digitalize many different types of assets quickly: from smart heating systems and temperature sensors to vibration sensors, vapor exhaust fans, multiple-hearth furnaces we also have on-site, and the vertical pumps we have on the steam traps. Really, a wide range of assets can be digitalized rapidly through Retrofit.

Explain the product more precisely. Where does it start and where does it end? If I simplify and interpret it: once sensors are in place – so you install the sensors as the entry point – and then what? What do you offer as a service? Are you providing data points, or connectivity? How would you describe it exactly?

Murat

We take a truly End-to-End approach. We support the engineering process upfront, have partnerships with sensor manufacturers, can jointly evaluate which sensor is best suited, and assist with installation – or work with partners who can handle the on-site mounting at the asset. We then connect these sensors to our LoRaWAN network. You can think of it somewhat like a mobile network, but designed for very long distances with low data volumes – and therefore very long battery life, meaning highly energy-efficient.

We send the data to our LNS – the LoRa Network Server. From there, we can act as a data hub and route the data to whichever systems are needed. That can be our own IoT platform or simulation platform, which we can offer to the customer – or if the customer already has their own data lake or similar, they can of course use a connector to feed data into their own platform or a third-party system. For example, if you want to control outdoor lighting and have dedicated lighting control software, we can feed data there as well. We have 40 native connectors including MQTT, OPC UA, and so on – we’re relatively flexible. So we can truly deliver everything from sensor to data visualization and analysis from a single source.

And what makes your case particularly interesting is that you have both the problem and the solution within the same organization. That’s genuinely useful, because you can speak openly with each other about what works and what doesn’t – and you learn a lot from that. There’s a saying: ‘Drink your own champagne’ – using what you offer to others, yourself, first. How has that collaboration been between you? Were there ever some candid words, Dominik, from your side – ‘Look, this is what we actually need’ or ‘This really doesn’t work that way’? Can you describe a bit of that?

Dominik

The need for a cable-independent data transmission method had existed for some time. Currenta had already launched various projects on the topic of transmission technologies, as part of several strategic initiatives. And from those efforts, among other things, the Conneqtive team emerged. We were essentially in it together from day one – even before Conneqtive was formally founded, when it was still called INIT – and we’ve developed both ourselves and Conneqtive through this use case. From the start, it worked so well that we didn’t need to bring in external partners.

On the contrary – we just talked about the topic of simulation. What do I actually do with the data that Murat provides? Because data is just numbers until you interpret and process it somehow. And we at Pipe Networks naturally want to derive something actionable from it. And no matter how good and how affordable a transmission technology is – from an operator’s perspective, you can never have enough data. But that also means: because we can’t install 300 LoRaWAN sensors, we still want to gain insight into our network status through dynamic simulation.

Until now, simulations were primarily snapshots of a current state at a given point in time with a given off-take behavior. And we looked at the external market – especially now in the era of AI, where many external vendors and service providers are advertising what AI can do and what projects have already been implemented – and brought our use case to the market. We said: we have data here, we want to derive an operational state from this data, including in areas where there may not be a measurement point. And the whole thing needs to be dynamic – if customer X makes a change, I want to see whether there was an impact on temperature or flow velocity at customer B.

And we tried – multiple times. We received a lot of promises from the external market. And after all those conversations, the service providers unfortunately ended up pulling the plug, so we never made it work. So we sat down with the Conneqtive colleagues and said: let’s try something completely different – let’s build it ourselves. That’s actually something Currenta, as a ‘first follower’ mindset company, doesn’t typically do when it comes to new technologies. But we couldn’t find another way. And now we’re genuinely being innovative.

Our physicist is currently building our own AI-powered simulation model for us, using Conneqtive’s data, for a Currenta network. And so far, it’s working remarkably well.

Murat

Exactly – I think this is truly our real-world stress test here in the CHEMPARK. If we can get something to run reliably here, then we can also offer it as a standardized product as an IoT solutions provider in the external market. And that’s the approach we want to establish: run the stress test in-house, and then release the standardized products externally.

I want to briefly put in a good word for AI here, because many people don’t quite grasp what it means. This kind of classical machine learning – which is what’s needed here, essentially a simulation AI – requires a dedicated, specific model built on many data points. That’s genuinely challenging. On the other hand, generative AI already comes with a large pre-trained model, so you can get a lot done without first having to build such a complex model yourself. I think that’s exactly where the confusion arises for some people. Generative AI simply isn’t applicable in scenarios like this. You need dedicated models and dedicated expertise. We have many people in Germany who can do that. But especially in a case like this, it’s really exciting – this is where you can differentiate yourself. I think that’s great.

Dominik

Just a brief note: for me, it was never really about the technology itself. I don’t know nearly enough about AI to speak to that. It was more our requirements that made the challenge so difficult. We needed someone with expertise in AI, who was also a thermodynamicist and process engineer – and ideally someone who had actually set foot in a real operational environment at some point in their career. That was the difficulty. Many could build a model for us. But validating the plausibility of the results, understanding which parameters to adjust to make it work, and spotting what might not be entirely logical from an engineering perspective – that we couldn’t find. And within Conneqtive – as I mentioned, these are colleagues who came from Currenta – we now have exactly that. People who understand process engineering plants, who have spent a long time in industrial and chemical environments, and who are now taking their path into the external market. That combination works very well.

And Murat, as you mentioned – ‘outside the fence’ – that’s a term I interpret as going beyond the CHEMPARK to other, external customers. Do you already have specific segments in mind where you say this makes a lot of sense? Chemical parks of some kind – or how are you segmenting the market?

Murat

It really depends on the use case. For the steam topic – that’s obviously relevant for large companies: food production, feed production, chemicals, or pharma. These are sectors where large amounts of energy are being processed. We also have some customers who have several hundred steam traps in the field – slightly smaller networks than ours. And there we can genuinely help optimize reliability and costs.

What’s your business model? How do you offer it? Software as a Service or Infrastructure as a Service – what exactly is the package?

Murat

Exactly – we have a combination of Infrastructure as a Service and Software as a Service, where we actually rent out the sensor as well – with a subscription, including analysis and evaluation. To give an example: say you have a smaller steam network with 100 steam traps in the field – we can equip all of them for a set fee. That allows us to maintain the inspection intervals and commission on-demand inspections with the manufacturer – GESTRA, for example, with whom we have a partnership. Beyond that, we can also include the software if desired, and offer the customer a fully integrated product.

And where would you say there’s something particularly unique to the CHEMPARK – something so specific to here that you wouldn’t find it anywhere else? Or do you say: fundamentally there are no real concerns, it always depends on the customer, but the solution is highly transferable?

Murat

The simulation, because it’s dynamic, is obviously optimized for the CHEMPARK at this point. If we were to onboard another customer, there would probably need to be a learning phase to accurately map their network. But other than that, I think we’d be relatively flexible.

Great. What would you recommend to others looking to build a LoRaWAN network? What are the three most important lessons you’d share – where you’d say: if you think about these three things, you’ll save yourself a lot of effort, time, and money?

Murat

Something I’ve learned over the years is that a buy decision is often made upfront instead of a make decision. Because that means less experimentation – which is, of course, easier said than done. But if I were building out a LoRaWAN network today, I’d probably first ask internally where the pain points are. Then you can start relatively cost-efficiently with an LTE gateway that brings LoRaWAN connectivity in-house, sends data from there to a platform, visualizes it, and maybe triggers an alert at a certain threshold. Integration into day-to-day operations is of course not entirely straightforward – there are other challenges involved, and that’s exactly where we can genuinely help. We’ve built a LoRaWAN network with very high availability, guaranteed SLAs, and the ability to ensure data integrity. But I think the pragmatic approach – just getting into the field – is what’s most often missing.

With LoRaWAN, you can deploy a wide variety of sensors from many different manufacturers quickly. They’re battery-powered and require almost no cabling within the facility. You can experiment. And very quickly you see the value. We had some customers who installed the first sensor – and a week later they were already asking about a third and fourth. We also have a combustion plant where, once you start measuring the shaft vibrations, the temperature measurement follows, then the exhaust gas measurement, and so on – and suddenly you go from one measurement point to a fully instrumented system, truly through Retrofit. And that’s the real magic you can unlock there.

Dominik

From an operator’s perspective, I also want to put in a good word for how simple the implementation into day-to-day operations really is. When you compare it to establishing conventional measurements coupled to control systems and requiring extensive wiring – installing a LoRaWAN sensor is just so simple. You need some kind of measurement device. The LoRaWAN unit is mounted on top – and that’s it. The whole thing is battery-powered, and it finds its way into various browser-based dashboards on our end. And within a very short time, I have data I can work with. Achieving the same with conventional measurements integrated into control systems is far, far more involved.

A great, pragmatic approach – and the recommendation to just get started, even with the first measurement points, because that’s when the magic unfolds. That’s a wonderful way to close. Many thanks to both of you. And thank you to all our listeners for tuning in – all the way to the end of our episode on digital steam. Until next time.

Dominik

Thank you.

Murat

Thank you very much.