Earlier flood detection with radar and NB-IoT

Today on the IoT Use Case Podcast: flood early warning systems. A topic where minutes and the ability to make decisions matter. Our guest is Felix Brühl from Endress+Hauser, a company known in industry for decades for measurement technology, automation, and digital solutions — here in an exciting context outside traditional process industries. We talk about how to recognize good solutions: at the sensor level and in the overall system. Enjoy the episode.

Today’s topic is flood early warning, a very exciting application of widely distributed and decentralized sensor technology. Not only since the terrible disaster in the Ahr Valley do we know that this is a highly critical use case. While traditional gauging stations may measure the current situation, newer systems can also generate forecasts of what can be expected in the near term and how the situation is developing. To discuss this, I’m joined today by Felix Brühl. Felix works in Business Development at Endress+Hauser, in the Innovation and Digitalization unit. This is where solution packages are developed that consist of multiple components — from the idea all the way to market readiness.
Felix, let’s get specific right away: Which measured values can we actually collect in order to make forecasts? What helps us do that?

Felix

The main focus of the sensor technology is definitely on water level, in other words the current actual values of water levels in rivers and streams: how high is the water body? For an early warning system, soil moisture is also a key factor, meaning how saturated the soil is. In the end, those are the two core parameters we measure. In addition, rain gauges are occasionally used to record the actual local rainfall amounts and also contribute to early warning. But at the core, it always comes down to water level and soil moisture.

Can you describe the sensor? How is a water level like this recorded? Where is it located, what does it look like?

Felix

We try to measure at the points where flooding originates. You need to know that these are usually very remote places — very small streams — where no power supply is available. That is why the basic requirement for such a sensor is that it must function autonomously. That means: communication module inside the sensor and its own power supply. We have a fully autonomous sensor with a battery and an LTE modem, or alternatively a 2G and NB-IoT modem, so that we can transmit the data regardless of location. The entire system has to operate quite autonomously.

The battery is obviously also a critical point. How long does such a battery last, and what does that depend on? I imagine wireless communication and similar factors play a role.

Felix

That is a question I get from most customers. I can’t answer it in general terms because battery life is influenced by several factors. We have a transmission interval that adapts depending on the water level event. We measure every minute — the measuring itself consumes almost no energy. Transmission is the part that consumes the most energy. If, in a non-flood situation, we transmit bundled measured values twice a day, then the battery can realistically last five to ten years. But if we are in a situation where threshold values are exceeded, the sensor adapts based on thresholds and increases the transmission frequency. Then we transmit smaller data packets as often as every five minutes. That is significantly more energy-intensive. In addition, ambient temperature and signal strength are important factors. We have a fallback scenario: first LTE, then 2G, and if that does not work either, Telekom NB-IoT. In such a case, the sensor may spend a long time searching for a network, which also affects battery life. If you know that in advance, you can classify it and, for example, go directly to NB-IoT first. So battery life depends on signal strength, ambient temperature, and the measurement and, above all, transmission intervals. Realistically, the sensor can run on its battery for around three to ten years.

That is a strong service life. There are probably also differences in the sensor itself: What exactly does it measure, and how does it measure it? Is it installed in the stream, or do you use a different method?

Felix

We measure with 80 GHz radar. The sensor is mounted some distance above the water body — in some cases up to 15 meters. At very small inlets, third-order watercourses, we sometimes do not even have a permanently flowing water body at all. In those cases, the distances between the water surface and the sensor are very small. Of course, we measure the water level, but we also have additional measured values that are relevant, for example ambient temperature. And another important point is this: these areas are sometimes accessible to passers-by and local residents, so there is a risk of vandalism. With radar, the measurement cone has to point downward from the sensor toward the water surface. If something happens to the sensor, that can change the measurement cone. For example, we had installations in a cow pasture with a stream running through it. In some cases, cows ran into the sensor and the measurement cone would then be tilted. During a flood event, that would give us false measured values if we did not monitor the angle of inclination. That is why we also include parameters such as tilt angle. If a threshold is exceeded, for example by 3 to 4 percent, we issue a warning that something is wrong with the sensor. Other measured values include battery levels, so that we can warn when things become critical, and health statuses. As Endress+Hauser, we also helped define the NAMUR standard and provide corresponding recommendations for action, meaning cause and remedy information: what is wrong with the sensor and what needs to be done to resolve fault messages. A classic case is vegetation growth on the sensor: in that case, you receive the information that the echo has been lost.

With cows and vegetation growth, the areas where your sensors are installed are definitely challenging. So that was the radar and water level sensor. You also mentioned that soil moisture is another topic. What does that kind of sensor look like, and what are the requirements there?

Felix

Before we talk about the soil moisture sensor, let me briefly explain the general idea: with water levels, we always measure the current actual values in the water bodies. But during a flood event, a water level does not always rise steadily — at some point it becomes exponential. That happens when the soil surfaces — agricultural land that can normally absorb water — can no longer take in water because the soils are saturated. Then the water becomes runoff-effective: it flows across fields and slopes into the inlets, and the water levels rise exponentially. That is why, in order to set up an early warning system properly and issue early warnings, we also incorporate soil moisture. We measure the saturation in the first soil layer: how much water content is present in the ground and how much water the soil can still absorb. Two measured values are central here: soil temperature and saturation in percent. Soil temperature is important because we have two extreme events: in frost conditions, the ground cannot absorb water. And in cases of extreme dryness — in 2023, for example, we had a situation where it did not rain for four months — the soils become extremely dry. Then, when a heavy rain event occurs, the soils are also unable to absorb the water effectively, and it becomes runoff-effective. We measure the soil moisture, transmit the data in a fully autonomous system with a gateway that also powers the sensor via battery, into our cloud platform, and on that basis set up an early warning system together with our partner.

There are probably different suppliers and versions available. Can you say something about the variants? What are the advantages and disadvantages? What are the decision criteria for sensor technology — both for water level measurement and soil moisture?

Felix

The clear focus is on reliability and service life of the sensor technology. We want a water level sensor that can transmit at higher density during an event. The soil moisture sensor must also work in winter at minus 20 degrees and still continue to operate in spring. It must send a fault message early enough before information stops coming altogether. I need valid measured values and reliable status information about sensors and gateways: are they still transmitting? Is there a fault? The focus should always be on the quality of the sensor technology and the measured values because we are operating in a highly critical area. Soil moisture is also measured in other applications, for example in agriculture or in municipal contexts for urban irrigation. There, when making a purchasing decision, it is often less relevant if a sensor costing 80 to 100 euros breaks over the winter or is stolen, because the installations are accessible. In flood applications, however, we are dealing with very remote locations, especially for soil moisture. That is why the focus here is clearly on quality and service life of the sensor.

That makes sense. The sensor, as you described it, proactively decides itself when it transmits. So the intelligence lies at the sensor level, whereas in other settings it tends to lie at the system level and the sensor is queried. Is that fair to say? Is that fair to say?

Felix

The sensor we use for water level originally had a different use case and was explicitly further developed for flood applications. Originally, these were applications such as bulk material silos or IBC containers, where you measure surfaces without time-critical requirements. In those applications, things operate cyclically, and changes to the transmission or measurement interval are written from the cloud to the sensor during the next transmission — maybe not until twelve hours later. In flood situations, that does not work. Our approach is to have a denser measurement chain during an event. The sensor measures every minute, and as soon as the first threshold is exceeded, instead of transmitting every twelve hours it transmits every 60 minutes. If the second threshold is exceeded, it detects that immediately and transmits at a higher interval, all the way down to every five minutes. The advantage is that the intelligence for adapting the transmission interval lies in the sensor and is event-based. Normally, the transmission and sending interval is written to the sensor from above, but usually only with the next transmission.

A flood early warning system is relatively complex when, in addition to water levels, you also generate forecasts. Are there also simpler systems? Are there stages leading up to such a complex early warning system?

Felix

Yes. The first step is always classic water level monitoring. Then there is, for example, the topic of trash racks: large rack systems that are intended to filter floating debris — leaves, tree trunks, and other material — out of the water during flood events. In municipalities and districts, these are critical points: if a blockage occurs, meaning the rack becomes clogged, the water level rises. For example, I was at a mayoral meeting in southern Germany: there, two or three households are affected every time the rack gets clogged and water runs into basements. This is at a very small inlet, in some cases without a permanently flowing watercourse. During heavy rain, tree trunks and leaves collect in front of the rack, and then those households are flooded. There were affected residents sitting there who quite rightly complained that there were no measures for early alarm notification. In small municipalities, we therefore implemented differential measurements: we measure the fill level in front of the rack and behind it. If a difference occurs, it indicates a blockage, and the fire brigade can initiate countermeasures at an early stage. In fact, they even went so far as to provide a boxwall system to divert imminent flooding. A second use case is the large city, where we have close to 52 trash racks. Logistically, in an event situation, it is impossible for four people to reach and clean all the racks in time according to priority. That is why we installed camera systems: when a rack becomes clogged, live images are transmitted to our Netilion cloud platform so that it is possible to prioritize which racks should be approached and cleaned first. There are other cases in which we have implemented smaller early warning systems using our sensor components. But the major use case is moving toward water level monitoring as the basis and then — together with soil moisture and an algorithm — a full early warning system.

Let’s stay with flooding: the Ahr Valley disaster was catastrophic, with around 20 billion in damages. Do you have a reference project where we can walk through such a system?

Felix

In the meantime, as one of the few sensor manufacturers, we have implemented an early warning system in two municipalities in the Ahr Valley that are currently up and running. I can talk about one municipality: the town of Bad Münstereifel. We have a case study on that, an experience report on the type of early warning system we set up together with our partner Okeanos. We provide the measured values for the current situation of the water levels, and Okeanos builds the early warning system on top of that. We measure at the origin points of such water bodies. If you look at the case study, you can see that these are very remote locations. We measure there early, so that we are ahead of the first wave and can detect at an early stage that an event may occur.

Where can people find this case study?

Felix

On our homepage. If you google “Netilion dynamische Pegel,” you will find our page. There you can find the experience report on the town of Bad Münstereifel.

We’ll link that in the show notes. In that case, the sensor data is transferred to Okeanos: who actually owns the data? Endress+Hauser, Okeanos, or the municipality? Who owns the data, and where does it all come together?

Felix

That varies and depends on the use case. In some cases, Okeanos is the direct client and holds data sovereignty. Or districts, municipalities, and towns purchase the sensor product directly from us; in that case, the data sovereignty lies with them, and the data can then be shared with Okeanos in order to build a flood early warning system.

So the interfaces mainly go into the cloud — probably at Okeanos. Do you have your own cloud, or where does the handover happen?

Felix

We have our own Endress+Hauser Netilion Cloud, into which millions of sensors worldwide are already integrated and through which we manage asset management. The sensors send their data to our cloud and are managed there, including threshold settings. From there, we either provide the data to Okeanos or to the municipality, district, or town — depending on who the end customer is — so they can view the data, or, in the case of Okeanos, process the data for an early warning system. In many cases, via our cloud, when threshold values are exceeded — for example in water level — we have direct integration into fire brigade incident control systems. For this, interfaces such as webhooks, APIs, or OPC UA are used to integrate data directly into incident control systems, SCADA systems, or cloud-based early warning systems. A standardized interface is crucial for this.

So you would also offer this as a complete package including your IoT platform if a municipality wanted that. What does such a system cost? Is it comparable, or does it vary a lot? How are the components priced?

Felix

That depends on the number of sensors and the amount of effort involved. We have had projects with complete installation of 30 to 50 sensors, and that can reach the six-figure range. In general, though, our packages are kept very lean. When we talk about small municipalities, we are usually talking about five to ten water level sensors. In typical cases, that keeps us below the public tender threshold, in some cases below 10,000 euros including commissioning. Depending on the use case, you have to look at how far that makes sense. We also have models where you roll things out step by step and add more sensor technology each year.

How long something like this lasts is extremely relevant. A municipality would really need to calculate the life cycle costs, which is not easy and probably something many do not do. If you look at it from a municipality’s perspective: what is the business case? How should such a project be evaluated? A municipality would really need to calculate the life cycle costs, which is not easy and probably something many do not do. If you look at it from a municipality’s perspective: what is the business case? How should such a project be evaluated?

Felix

In the end, it is really about municipalities or districts thinking about how to evaluate such sensors over a service life of 15 to 20 years. One thing that has to be said is this: with the autonomous sensor, compared to wired sensors, we do have certain additional efforts, but these need to be seen in relation. The water level sensor is significantly cheaper than a hydrostatic pressure probe including installation and all the additional effort involved. Ongoing costs are mobile communication and occasional battery replacement. But we have designed battery replacement to be very simple: in two to three minutes, you can change the battery, close the sensor again, and it remains watertight. This can be provided as a service by us or done by the customer themselves. We provide clear recommendations on which replacement batteries are suitable, and we also supply them in packages. The whole thing is managed via the cloud in such a way that the typical use case is this: the local municipal depot receives a notification if something is wrong with the sensor, for example if battery life is approaching zero. Or there is a warning in advance so that a replacement can be scheduled within the next two to three months.

You work in Business Development. So this is not a product that has been on the market for 10 or 20 years, but something still relatively new that has been developed further from other areas. What have you learned in these projects? What do you need to pay attention to when introducing a flood early warning system, or flood monitoring in general? What do you need to pay attention to when introducing a flood early warning system, or flood monitoring in general?

Felix

Every product and every solution has a learning curve. At the beginning, we thought that pure email notification in the event of threshold exceedances or for an early warning system would be sufficient. But together with Okeanos, we came to the point relatively quickly that when water levels rise rapidly, the real requirement is to enable integration into a control system via open interfaces. That was a major learning. Another learning concerns the municipal environment: there is usually one instance that needs threshold information and another instance that is responsible for the health of the sensors. The municipal depot or public order office are typical recipients of notifications when something is wrong with the sensor. We learned that we need user management so that, depending on the event — threshold exceedance or health status of the sensor — different target groups receive the relevant information. Another exciting aspect was the collaboration with Okeanos, which builds a complete early warning system with additional data. We learned that data from the German Weather Service is also essential for an early warning system in order to make the forecasts more accurate. What matters is that all data is bundled via the platform in order to have one consistent source of information for early warning.

If a municipality wants to get started: we have already had problems with flooding, and now we want to begin — what are the very first steps?

Felix

The first step is water levels. That is the basic requirement: start measuring water levels at the most remote locations and monitor them over a period of time along the course of the river — especially if there are multiple inlet points. The second step is then a complete early warning system with soil moisture and weather data, for example through our partner Okeanos. We can support in the consulting phase, including project design: does it make sense to implement a complete early warning system, or do you initially stay with the standard package of water level measurement? In any case, the basis is water level measurement and, building on that — depending on what makes sense — a flood early warning system.

Felix, thank you very much. I think I now have a good understanding of how such a system is structured. I am sure that was also exciting for our listeners: from the sensor with the two sensor types — water level and soil moisture — through the system, the interfaces and handovers, all the way to the municipality, which should take life cycle costs into account. Even if such a system may seem more expensive at first: when you see the kind of damage that can occur if you do not address this in time, the contribution to greater safety is enormous. Thank you very much. Is there anything else you would like to add that I did not explicitly ask about but that is still relevant — about the system, the environment, or reference projects?

Felix

Thank you for those closing words. One point I would like to revise: I do not believe that we are dealing with a very expensive product here or that the costs of an early warning system are particularly high. As soon as public tenders are involved, lower-cost sensor products are often considered as well. That is why my appeal is this: especially in tenders, the focus should be on service life and measurement quality. And I believe that, for the scope of performance and the quality, we are very well positioned in terms of price.

Excellent. That fits very well with today’s topic. Thank you, Felix, for being with us today. And thank you, dear listeners, for staying with us for so long. Until next time. Thank you, Felix, for being with us today. And thank you, dear listeners, for staying with us for so long. Until next time.