Retrofit Utility Networks: Wireless Condition Data, Not Inspection Trips

Fewer inspection trips, more transparency. How utilities can operate their networks based on data. Our guest is WIKA, a company many people know from classic measurement technology. Pressure, temperature, level, flow. Today we look at how these measuring points are integrated into IoT solutions. Into district heating chambers, water distribution, or level measurement. And the central question is: how does a measured value in the field turn into a better decision in network operation?

Today we are talking about IoT at utilities and network operators. So about infrastructure that is often distributed, hard to access, and yet critical for operations. With me is Philipp Lausberger. He is IoT Application Specialist at WIKA. Philipp, let's dive right in. When you look at utilities and network operators, which problem do you encounter most often?

Philipp

Yes, hi Peter, thanks again for the invitation. Well, in principle, when you look at the problems of utilities and network operators – we focus here a lot on German municipalities or Central Europe – we often have the same problem as everywhere else in industry: I have an existing network that wasn't all built to the latest standard. If you think about it, we have wonderful historic town centres all across Germany.

They have district heating networks, gas supply, some of them are decades old. Information on how the network is doing, what condition it's in, I often only get through a visual, physical inspection. That means someone drives out there, climbs down into a district heating chamber or a general maintenance chamber, reads off a value, and climbs back up. So I have a relatively high effort, and with all that ageing – we all know it. Somewhere there's an excavator in the street, burst water mains. And that's always the best case. Gas lines and so on are all part of it too. It's simply about the topic of retrofit. How can I make a network more transparent in the first step? And after transparency comes data utilization, of course. What can I do with all of it to simply get more efficiency out of it?

I also found it really fascinating to think about, in the run-up, just how many of these chambers there are. There are district heating chambers, so in major cities there are a thousand chambers in every metropolis. Across Germany there are something like 4,000 district heating networks and, accordingly, hundreds, thousands of these chambers that then have to be inspected by people. Can you describe a bit how such an inspection works? So what actually happens there?

Philipp

Of course there are the district heating chambers, but in principle you just have to walk across the street with your eyes open a bit – be it this evening or tomorrow morning. Basically the street consists almost entirely of manhole covers, if you look closely. So a chamber is built like this: we have the classic manhole cover and then there's often a small ladder going down. Sometimes it goes up to six metres underground, and down there runs, first of all, a –

any pipe, so a gas line, a district heating line, a water line, whatever. Down there today I often have an analogue pressure gauge installed. So really a mechanical measuring device. In the best case from WIKA, or very probably from WIKA. And of course it still works after 40, 50 years. But first of all I have a relatively high effort. Before I even drive out there, I first have to start planning the whole thing.

Which chambers or measuring points have to be monitored today? Is the measuring point under a busy road? Can I do it alone? Often it's two employees who drive out to the measuring point. One secures the entrance area of the manhole cover up top, so nobody falls in, so that if the colleague down in the chamber gets injured, he can help him, and so on. It's a relatively high effort. Only whether I can really capture a snapshot of my district heating network, of my water network, because I look at it and right now maybe everything is fine. Then I climb up out of the chamber, close the cover, drive on, and then five minutes later something happens, and today I simply notice that very late. Or only when a complaint comes in somewhere, or the water is gushing out of the street and it's maybe already too late.

And what kind of consequences can occur there? I mean, one is very extreme, that the water essentially breaks out completely, but there are other variants too. Especially with district heating, insulation is a very important topic. So which types of damage, which damage cases do you come across?

Philipp

Exactly, so in principle the most frequently occurring damage is of course, first of all, a leak. We all know that from the water sector too. When the excavator is standing there, it's still relatively uncritical. But as water increasingly becomes an ever more important resource in the future, we have to deal with that too. Sure, on the topic of gas lines, you just have to look at the news. That often doesn't end very smoothly when something becomes leaky. And in the example of the district heating line –

well, the phenomenon of a leak occurring in the district heating line, that's the worst case first of all. We have water up to 100 degrees warm in there, or on top of that even hotter steam. So basically I really have a pot of soup in the chamber, where there's boiling water in some cases. And if, for example, the employee from the utility goes down into a district heating network, that's of course an –

extreme risk of injury. Yes, that's regarding leaks, but it can also simply be that, due to the surrounding soil or generally the proximity to a river, whatever, heavy rainfall events fill the chamber up so much that my measurement technology might be under water and I have to pump it out again. So those are, first of all, two scenarios. And at WIKA we also have a small niche where we talk about steel jacket pipes. That's a bit the topic of insulation.

That means, so the listener can picture better what a steel jacket pipe is: it's basically a pipe within a pipe. Between the two pipes there's a vacuum. So one-to-one like a thermos flask at home works, just in the form of a pipe; it's often used for difficult, more complex geometries. Or when I have to cross a bridge and pass along a river with the district heating line. That means –

there's basically a vacuum in there, and the vacuum simply disappears over time. Or rather, air penetrates from the outside, if you want to be precise about it. And accordingly, the insulation effect deteriorates for that section, for example. And that means it radiates an awful lot of heat into the ground. So if you now look at which moles you've got in there, on the outside –

coming into warmer regions, they're maybe happy about it. They then basically get inclusive underfloor and ceiling heating thrown in. But the network operator isn't happy about it, or the utility, because in the end far more energy has to be pumped in to get back to the correct supply temperature again.

Then let's look at it very concretely with an example: how does it actually work that then no inspection trips, or reduced inspection trips, are necessary? We already have sensors installed, some from WIKA, mostly, you said, but also from others, and now we have a range of sensors and actually want to bring them together centrally in a control room and maybe set some limit values there. Can you describe a typical route for me, from the sensor all the way to the central control room, how does that work, or what are the variants there along the way?

Philipp

In the classic case, today we have analogue measurement technology installed. We often don't have any connection via a cable for the topic of, I want to feed the whole thing somehow into a control room via a classic bus or analogue data transmission. Very difficult. And then this IoT approach comes into play a bit. That's where I see this topic of wireless transmission.

Battery-powered devices come into use, so basically I want a very simple installation. I don't want to lay down power, I don't want to lay down a cable. That's why we rely on battery-powered devices with different wireless technologies. There I'd say, a lot in the area of utilities, network operators, or general industry. Increasingly, for example, LoRaWAN or mioty come into play.

Then there are of course also mobile-network-based technologies, NB-IoT, LTE-M, and so on. And in the end I've now got a wireless technology combined with a sensor plus a battery, and I basically already have everything I need to go from maybe one measured value per year, or per half-year, to maybe one measured value per hour or one measured value per day. And now, first of all, we have the sensor.

Afterwards the data of course has to be transmitted. If I have a mobile technology, I use the existing mobile network. As a network operator, as a utility, I can also build my own private network. That simply has an advantage, it's very cost-effective specifically for large-scale scaling. I can manage the data relatively well, I have quite a lot of options to design it exactly as I want. And ultimately, when the data is then forwarded to the control centre. There it's of course important again that we rely on standardized interfaces, like a REST API, MQTT, OPC UA, and so on, so that at the very top layer we can really say we can integrate the data quickly and therefore don't create an extra project, but rather it should work plug and play with an IIoT approach.

Let's take a closer look at a few of these components along this route. The sensors would certainly be very exciting too, and you at WIKA could surely tell us a lot about them. But let me probe the battery a bit more, because it's like this: now you say nobody has to drive out there, and suddenly you install a battery, and then intuitively you'd say, now you have to drive out there constantly to change the batteries. Can you tell us again how do I know when the battery is empty, and what are the maintenance and replacement cycles there?

Philipp

In principle, the devices normally always report a battery status. So basically I have a voltage and then ultimately see whether my battery is running low. Speaking very generally. But you can also compare it a bit, maybe simply with a wall clock that you used to wind up manually. Back then I really had to pull the string every day to keep my clock alive. A wall clock has a small battery in it and lasts for years.

And in the end, again as an analogy, that's basically how it is with all the IoT technologies, wireless technologies that we use, because they are essentially low-power protocols. That means we need very, very little energy. I maybe can't play streaming data, so no Netflix, with a pressure sensor, but that maybe doesn't need to be the case here. And with that I can already achieve battery lifetimes of up to ten years in the field, which then pushes the battery replacement far back down the priority list.

That‘s already quite impressive, ten years. Okay, so we've got the battery ticked off and now let's move on to the wireless standards. Mobile, I think, everyone can already picture a bit. It's relatively similar to how you work day to day. But let's take a closer look at LoRaWAN. That's, as you said, something where you can build your own network. What does that mean? And do you maybe also have an example, a customer or something who once built such a network, also with – what can go wrong there and what can work? Because LoRaWAN keeps getting discussed in the podcast from different areas, but rarely on the scale of an entire municipality. Where do you see the possibilities to scale something like that? How do you build something like that?

Philipp

Let's maybe start with the topic of setup. In the end I actually need nothing except – if I have a professional network provider – basically a network server, hosted relatively simply via the cloud in most cases, and I need a gateway. Then I take the gateway, mount it, put plainly, simply somewhere at a good spot, power in. In the simplest case there's also a SIM card in it for the internet connection, or I simply plug in an internet cable, and then the thing is connected to the internet, and that was basically the physical setup for a LoRaWAN network. So I actually only have to install a gateway, and the gateway then automatically communicates with the network server, and that's exactly the central point and basically the most important thing, that you rely on a really professional solution here, on a professional partner, because for one or two devices it's the case that I can maybe still build something myself relatively well. But in the end, as a network operator, for example, I don't want to deal with the topic of LoRaWAN networks, but with my district heating network or water network. And that's why it's all the more important that you rely on a stable partner, like LORIOT for example, or other network providers. And then I've basically already created everything for one sensor all the way up to several tens of thousands of sensors in the field, because the infrastructure makes that relatively easy with a plug-and-play solution.

I think you can picture it well: a gateway is basically like the spider in the web, sending out its threads to the respective little sensors that are installed everywhere in the field. They then all send to this gateway, which then centrally and in bundled form forwards the data to the server, also via the internet, via mobile. Okay.

And the difficulties in scaling are also manifold. What I've picked up on are all the updates that then keep being necessary, that you install, the different kinds of devices and sensors that you then connect. What growing pains do you see there? Often it's like this: you first start tinkering a bit, a bit like smart home, and say, well, at home I managed to connect my weather stations and then my roller shutters or something. Where do you see the difficulties there, in the fact that you simply can't transfer that to a city?

Philipp

Yes, that came about when someone had the idea and said, yeah, we can do a bit. Historically it was often looked after by the IT department at many utilities. Very classically, we've seen a few customers who then said, yeah, student project, and so on. Then it grew. And then maybe even their own software was somehow cobbled together. And we also have a concrete case where the customer basically said, yeah, here, utility, we now have our own platform.

You in the network department also have to use the platform, but they overreached with it, because it's simply something you can't manage with two people, and accordingly they now basically have the problem with scaling, because the internal communication doesn't work, because the capacities aren't sufficient. And that's why it's actually all the more sensible to say, yes, you host the whole thing in a cloud. That means it's essentially updated daily. Here in the area of IoT, it's not only about pure data transmission that I want, but also about the topic of security. And basically everyone uses cloud services in their company today. The ERP system no longer runs on the local machine, and so on. So everything is secure, but only because I'm essentially updating constantly. And that's something, as I said, where I say, if I now operate it myself I only want to take care of my network and not worry about my software being updated somehow by programmers and about the whole thing being held together somehow with sticky tape here and sticky tape there; instead I simply want it to just work.

Especially the topic of security and cloud. Back in my time at Siemens – so that's already a good few years ago too – where we always had this cloud discussion. Many, especially in the factories, of course wanted to and still want to stay local, on the edge, and the like. Because cloud was always associated with a bit of uncertainty. How do you perceive it, has this discussion shifted, maybe generally in the IoT area on the one hand, but then maybe also the distinction between – I mean, the data from a chamber is definitely not as critical and relevant as data straight out of a factory. How do you view this discussion of cloud and local and security?

Philipp

Well, I can definitely understand it too, if I simply want to have the data with me in the company on the server, so host it there. There's also the option – the network server, it's a piece of software that can run either in a cloud, but can of course also run on a company server. So that doesn't hinder scaling for now, and there it's of course always important to respond to the customer's needs. Nevertheless – I have the feeling that, especially in Germany, the whole thing is viewed very critically. And, where I as a 30-year-old look on a bit sceptically, because I would say again, other countries are leaving us behind, because they simply do it. They are much faster. On the topic of digitalization. I think we all know that Germany is no model example. And when we simply stand in our own way and hold unnecessary discussions about it – especially people who actually haven't dealt with the topic yet simply slow down digitalization too. And yes, put simply: if we want others to always be faster, then we have to keep up the scepticism. Maybe a more critical statement, but I understand it all and it all has its purpose. And of course there are also applications where it makes sense. But I'm now talking more about the topic of when I'm simply permanently sceptical and actually don't even know how the technologies work, then in the end it's of course a decision everyone has to make for themselves.

I agree with you there, definitely, because my observation is also that it tends to come from ignorance or, when you don't differentiate, when you say in an undifferentiated way, cloud is out of the question for me. But I find the example with the chambers so nice, because there it's obvious that it's not critical knowledge or anything that's somehow flowing away. So there it's actually no question at all that you try to make things as simple as possible for yourself, to simply make operating this network easier.

If the data were somehow visualized completely openly and transparently on the pavement, nobody would come to harm either. Starting there and then thinking, step by step, at what point does it become critical, at what point is it really business-critical and relevant. I think few people really put their mind to which data is fine and which isn't.

Philipp

Yes, and then you simply also have everyday office life, you store some production data, medication compositions on a cloud server, and you don't even think about it, but then, as you say, it becomes an issue over a pressure value that is nevertheless encrypted. It's not as if I snap my fingers and can get in there just because it's in a cloud, but we use it every day, we make phone calls over it every day, the phone is listening to us permanently, and I think there –

a pressure value that you also can't just decrypt so easily is, I think, the smallest problem we have today when it comes to security.

So much for security. You shouldn't let it hold you up. Engage with it, sure, but don't let it hold you up. That's always, I think, an opinion. Absolutely. But now once more on an IoT topic, so especially for network operators and utilities as well. Where else could they use this? District heating was a great example. You spoke about water and the like. Once you build a LoRaWAN like this, for example, you can expand it in all sorts of directions. So which use cases around it do you see then?

Philipp

Well, sure, pressure measuring points, where it's mostly about branch points. And through that I can record long-term data. When is the drop in water pressure highest, and so on, with historical data. Simply to operate the network more efficiently again. Then of course we have distribution stations. There you have, on the one hand, the option that you raise the whole thing again with a pump, the pressure, so that I'm somewhere in my target range. But I can also maybe lower the pressure again with the pressure control valve. And that's, for example, such a pressure control valve, that's also a mechanical component, there's a spring inside that more or less regulates the pressure. And that can of course also lead to wear again. Then you have the wrong pressure in the network. At some point the pressure control valve can start to oscillate, and at some point I then basically have a complete oscillation across an entire network, because that transfers at some point to the next pressure regulator or pressure control valve. But also water monitoring of rivers, so water levels, groundwater measurements, so really classic topics. Yesterday, at the fire brigade drill, we had a discussion again about how the water is actually monitored here in our town. And out in the field there's basically a small water house somewhere.

Once a week the municipal employee drives up there, and there it basically came to light again, right here with us, oh, the thing is empty all of a sudden. Where you simply only noticed it after two weeks. And those are relatively simple things where I have a relatively big impact. And the whole thing can also be transferred, broadly, to the gas network again. There we're of course in the explosion-hazard area, but more or less such a network often works relatively similarly here. They're pipelines and there's a liquid in there, a gas. I have to regulate it up and down, I have consumers, leaks. Accordingly, it can often be seen analogously from one area to the next.

What, from your point of view, can simply be transferred, and what is perhaps more site-dependent? I can imagine, sometimes these district heating chambers are very deep. That means it's probably difficult to transmit out of there somehow. Other topics are more standardized. Tell me, when you look at different customers, your home village for example compared to a big city, where are the differences, and what can simply be transferred, and what is perhaps then always specific and a bit individual for each customer?

Philipp

A very important point is really also the signal quality, or basically the range that I can achieve with such a network. And that's of course very critical when I'm six metres underground, because there I can screw in the best IoT sensor, LoRaWAN sensor. It won't come up to the surface anymore. In practice it then basically does me no good. And that's why it's important, for example,that you also have an alternative, maybe a detachable antenna, so that I simply have my measurement technology down in the chamber, then I go up with a cable and install the antenna or the radio unit up there. Generally it can be transferred that really everywhere – whether it's in a rural area, which is maybe less critical in terms of road closures, but where I have longer distances I have to drive – in the city I basically have shorter distances, but more complicated access options, and of course also a much higher density. And in the end, the benefit is the same whether in the city or in the countryside. People of course often talk about smart city projects, but in Germany a great many people still live in the countryside at the moment. And yes, that's basically always a bigger challenge, to really keep these old networks in operation. And the less effort I have with it, the better it is in the end for me as an operator.

Can you say something about the costs? If a village community now decides, yes, we want something like that too, is that even realistic? Can only cities afford a monitoring system like that? So who is it suitable for, and what does something like that cost?

Philipp

It's suitable, I'd say, for most. In terms of cost, we have an advantage on our side. We are an industrial company, and we produce, for example, batch sizes of one for the pharmaceutical industry – that would be a single pressure gauge – all the way up to thousands of pressure sensors that get built into a tractor somewhere or into a machine-building plant. And that's why we can really implement things very efficiently. So you get down to less than 100 euros for what such a measuring point costs. Of course, with rising quantity it naturally always gets cheaper, as it does. And the nice thing is, because we also rely on such central solutions, like a network server that then simply also works based on the devices I have, or the data that runs through it, I can of course also arrange the whole thing cost-effectively. There I think the customer doesn't have to pay 2,000 euros a month, but can simply do it by device, so basically by number of devices.

And if I now simply compare it: a measuring point somewhere in the city, I visit it three times a year, for example, or four times a year, I always need two people to go there, that's at least half an hour of time that goes into it. In total that's then two hours a year, times two people. If you extrapolate that, a sensor pays off relatively quickly, and if I now say I'm driving out to the village as well, then people first drive to us from the depot, 20 minutes. And yes, I think it's more sensible to say I put the resources more towards maintenance work, so really actively keeping the network in good condition, instead of fetching some piece of information for myself. So one you can do this way, and for the other, the human is simply irreplaceable.

And that, so far, is basically why it fits for everyone, and why it will, let's say, pay off in 90 percent of cases too.

Wouldn't it make sense to set overarching network guidelines for how such things should be done, and with whom? A kind of framework. Is there something in that direction, that there are established standards, or is it really still a bit of the Wild West? Does every single utility, every network operator, whether water, gas, or whatever, have to figure out for themselves how they now do this with IoT and with the monitoring?

Philipp

Fortunately it's not that bad. In principle, the negative example, or this isolated solution, is fortunately more the exception, and those are often projects that really already got going maybe ten years ago, when it was all still in its infancy. But there are now also a great many platform providers, like at our company too. In the end, basically everything is already in place. Yes, it's of course also a discussion which technologies are used for what. Especially towards LoRaWAN, it's now also often used in IoT for the topic of meter reading, where it's also not yet 100 percent regulated. How will it be in the future? Is that actually even allowed? But by now it's, let's say, too big to fail. And that is, let's say, also often the biggest pain point, that we first have this topic with meter reading, and then in the second step – that's exactly what backs WIKA up – how can I now really optimize the network as well, when I actually already have all the information and all the parameters that come with it.

Great. So what can you take away now? If someone out there is listening to us, among the listeners, who are from these network operators, these utilities, or who are maybe some factory, campus, or the like, and who want to start moving towards IoT. What would you give them? What shouldn't they get wrong at the start, because it's maybe done wrong more often? So that they really get through more efficiently and reach a good result as quickly as possible.

Philipp

It's always like the German saying, cobbler, stick to your last. That basically says it all, and in this case it means a professional partner. For example WIKA, but also other companies that basically stand by your side in an advisory capacity, where I can say, I have this problem, I need a solution. Then there are enough companies that can simply implement it really well. And that's why it's important simply not to rely on a on a central solution in the first step, but really on something scalable. And then you can simply focus on the day-to-day business, on the maintenance and upkeep of the network, and simply outsource the whole thing, saying, you take care of it and I have my peace, I simply get my data, and then the experts can further utilize the data. And I think it doesn't have to be complicated. You simply just need a reliable partner. Then it works.

Very good. Partners can also be found at IoT Use Case on the homepage. And in the podcast we'll still be talking about many different ones of these elements. LoRaWAN, mioty, and the like. So do subscribe to the podcast if you simply want to stay up to date on how the whole thing develops. You can surely find and contact Philipp via LinkedIn if something is needed there, the WIKA homepage or similar. From my side, many thanks, Philipp. Many thanks, dear listeners.

I wish you a nice day and see you next time.

Philipp

Many thanks, Peter, I had a lot of fun again. See you next time. Take care. Ciao.