Hochwasser früher erkennen mit Radar und NB-IoT

    In dieser Episode des IoT Use Case Podcasts spricht Peter mit Felix Brühl aus dem Business Development für Innovation und Digitalisierung bei Endress+Hauser. Im Fokus steht die Frage, wie autarke Pegelstand- und Bodenfeuchtesensorik an entlegenen Messpunkten eingesetzt wird, um Hochwasser früher zu erkennen und Frühwarnsysteme technisch sauber aufzubauen.

    Zusammenfassung

    Kommunen brauchen bei Starkregen und Hochwasser belastbare Echtzeitdaten, um kritische Entwicklungen früher zu erkennen und schneller reagieren zu können. Genau darum geht es in dieser Podcastfolge mit Felix Brühl von Endress+Hauser.

    Im Mittelpunkt stehen autarke Pegel- und Bodenfeuchtesensoren, die auch an entlegenen Messpunkten ohne Stromversorgung zuverlässig arbeiten müssen. Die Folge zeigt, welche Anforderungen dabei in der Praxis zählen: lange Batterielebensdauer, stabile Datenübertragung trotz schwankender Netzabdeckung sowie valide Messwerte auch bei Frost, Bewuchs, Vandalismus oder Lageveränderungen.

    Besprochen wird außerdem, wie Pegelsensoren mit ereignisbasierten Übertragungsintervallen arbeiten und warum Bodenfeuchte und Bodentemperatur wichtige Zusatzinformationen für die Frühwarnung liefern. Ergänzend spielen Diagnosedaten wie Batteriezustand, Neigungswinkel und Sensorstatus eine wichtige Rolle, um die Messqualität dauerhaft abzusichern.

    Darüber hinaus geht es um die Integration der Daten in bestehende Systemlandschaften – etwa über API, Webhooks oder OPC UA – und um die Frage, worauf Kommunen und Betreiber kritischer Infrastrukturen bei Auswahl, Betrieb und Skalierung solcher Lösungen achten sollten.

    Transkript

    Heute im IoT Use Case Podcast: Hochwasser-Frühwarnsysteme. Ein Thema, bei dem Minuten und Entscheidungsfähigkeit zählen. Zu Gast ist Felix Brühl von Endress+Hauser, in der Industrie seit Jahrzehnten bekannt für Messtechnik, Automatisierung und digitale Lösungen – und hier in einem spannenden Kontext außerhalb der klassischen Prozessindustrie. Wir sprechen darüber, woran man gute Lösungen erkennt: auf Sensorebene und im Gesamtsystem. Viel Spaß dabei.

    Heute geht es um Hochwasserfrühwarnung, eine sehr spannende Variante von weit verteilter und dezentraler Sensorik. Nicht erst seit dem schrecklichen Vorfall im Ahrtal wissen wir, dass das eine sehr kritische Anwendung ist. Während klassische Pegelstationen vielleicht messen, wie die Lage aktuell ist, können neue Systeme auch Vorhersagen treffen, womit man zeitnah rechnen muss und wie sich das entwickelt. Um das zu besprechen, habe ich heute Felix Brühl bei mir. Felix ist im Business Development bei Endress+Hauser, in der Einheit Innovation und Digitalisierung. Dort werden Lösungspakete entwickelt, die aus mehreren Komponenten bestehen – von der Idee bis zur Marktreife.
    Felix, lass uns gleich konkret werden: Welche Messwerte können wir überhaupt erheben, um Vorhersagen zu treffen? Was hilft uns dabei?

    Felix

    Der Hauptschwerpunkt der Sensorik liegt auf jeden Fall beim Pegelstand, also den aktuellen Istwerten der Gewässerstände: Wie hoch ist das Gewässer? Für ein Frühwarnsystem ist vor allem auch die Bodenfeuchte ein wesentlicher Faktor, also wie gesättigt die Böden sind. Das sind im Endeffekt zwei Kernpunkte, die wir messen. Zusätzlich sind gelegentlich auch Niederschlagsschreiber im Einsatz, die die tatsächlichen Niederschlagsmengen vor Ort aufnehmen und ebenfalls zur Frühwarnung dienen. Der Kern des Ganzen ist aber immer Wasserstand und Bodenfeuchte.

    Kannst du den Sensor beschreiben? Wie wird so ein Pegelstand erfasst? Wo befindet er sich, wie sieht er aus?

    Felix

    Wir versuchen, an den Entstehungsorten von Hochwassern zu messen. Dazu muss man wissen, dass das meistens sehr entlegene Orte sind – kleinste Bachläufe –, wo keine Spannungsversorgung vorhanden ist. Die Grundanforderung an so einen Sensor ist deshalb, dass er autark funktionieren muss. Das heißt: Kommunikationsmodul im Sensor und eigene Spannungsversorgung. Wir haben einen komplett autarken Sensor mit Batterie und einem LTE-Modem beziehungsweise 2G- und NB-IoT-Modem, damit wir die Daten unabhängig vom Ort übertragen können. Das ganze System muss relativ autark funktionieren.

    Batterie ist ja auch ein kritischer Punkt. Wie lange hält so eine Batterie, und wovon hängt das ab? Ich kann mir vorstellen, dass Funk und ähnliche Themen eine Rolle spielen.

    Felix

    Das ist eine Frage, die ich von den meisten Kunden gestellt bekomme. Pauschal kann ich das nicht beantworten, weil verschiedene Einflussfaktoren auf die Batterielebensdauer wirken. Wir haben ein Übertragungsintervall, der sich je nach Ereignis des Wasserstands anpasst. Wir messen jede Minute – das Messen verbraucht so gut wie keine Energie. Das Übertragen ist der Punkt, der am meisten Energie verbraucht. Wenn wir im Nicht-Hochwasserfall zweimal am Tag gebündelte Messwerte übertragen, kann die Batterie realitätsnah fünf bis zehn Jahre halten. Wenn wir aber in einem Bereich sind, in dem es Grenzwertüberschreitungen gibt, passt sich der Sensor über Schwellwerte an und erhöht die Übertragungsfrequenz. Dann übertragen wir bis zu alle fünf Minuten kleinere Datenpakete. Das ist deutlich energieintensiver. Zusätzlich sind Umgebungstemperatur und Empfangsstärke wichtige Faktoren. Wir haben ein Fallback-Szenario: zuerst LTE, dann 2G, und wenn das auch nicht geht, NB-IoT von Telekom. In so einem Fall würde der Sensor unter Umständen lange nach einem Netz suchen, was ebenfalls auf die Batterielebensdauer geht. Wenn man das vorab weiß, kann man das klassifizieren und beispielsweise direkt zuerst über NB-IoT gehen. Die Batterielebensdauer hängt also von Signalstärke, Umgebungstemperatur und den Mess- und vor allem Übertragungsintervallen ab. Realistisch kann der Sensor mit der Batterie etwa drei bis zehn Jahre laufen.

    Das ist eine starke Lebensdauer. Da gibt es wahrscheinlich auch Unterschiede beim Sensor selbst: Was misst der denn, und wie misst er das? Hängt der im Bachlauf oder nutzt ihr eine andere Methodik?

    Felix

    Wir messen mit 80-Gigahertz-Radar. Der Sensor hängt in einem gewissen Abstand über dem Gewässer – teilweise bis zu 15 Meter. Bei sehr kleinen Zulaufstellen, Gewässern dritter Ordnung, haben wir teilweise überhaupt kein dauerhaftes Fließgewässer. Dann sind die Abstände zwischen Wasseroberfläche und Sensor sehr klein. Wir messen natürlich den Wasserstand, haben aber auch zusätzliche Messwerte, die relevant sind: zum Beispiel Umgebungstemperatur. Außerdem muss man wissen: Diese Bereiche sind teilweise zugänglich für Passanten und Bürger, daher gibt es ein Vandalismusrisiko. Beim Radar muss der Messkegel vom Sensor zur Wasseroberfläche nach unten zeigen. Wenn am Sensor etwas passiert, kann das den Messkegel verändern. Wir hatten zum Beispiel Installationen in einem Kuhgehege, in dem ein Bachlauf durchläuft. Da ist es vorgekommen, dass Kühe gegen den Sensor gelaufen sind und der Messkegel schräg abstrahlen würde. Bei einem Hochwasserereignis würden wir dann falsche Messwerte bekommen, wenn wir den Neigungswinkel nicht überwachen. Deshalb beziehen wir Messwerte wie Lagewinkel ein. Ab einer Grenzwertüberschreitung, zum Beispiel bei 3 bis 4 Prozent, geben wir eine Warnung aus, dass am Sensor etwas nicht stimmt. Weitere Messwerte sind Batteriestände, damit wir warnen können, wenn es kritisch wird, und Gesundheitszustände. Als Endress+Hauser haben wir auch den NAMUR-Standard mitdefiniert und übertragen entsprechende Handlungsempfehlungen, also Cause- und Remedy-Informationen: was am Sensor ist und was zu tun ist, um Fehlermeldungen zu beheben. Ein klassischer Fall ist Bewuchs am Sensor: Dann bekommt man die Information, dass das Echo verloren ging.

    Mit Kühen und Bewuchs durchaus herausfordernd, die Gegenden, in denen eure Sensoren aufgebaut sind. Das war jetzt der Radar- und der Pegelmesssensor. Du hattest auch gesagt: Bodenfeuchte ist ein Thema. Wie sieht so ein Sensor aus, und was ist dort die Anforderung?

    Felix

    Bevor wir über den Bodenfeuchtesensor sprechen, kurz zur Grundthematik: Mit den Wasserständen messen wir immer die aktuellen Istwerte an den Gewässern. Ein Gewässerstand steigt im Hochwasserfall aber nicht immer konstant, sondern irgendwann exponentiell. Das ist dann der Fall, wenn die Bodenflächen – Ackerlandschaften, die normalerweise Wasser aufnehmen können – kein Wasser mehr aufnehmen können, weil die Böden gesättigt sind. Dann wird das Wasser abflusswirksam: Es fließt über Felder und Hänge in die Zulaufstellen, und die Pegel steigen exponentiell. Um ein Frühwarnsystem sinnvoll aufzusetzen und frühzeitig zu warnen, beziehen wir deshalb die Bodenfeuchte mit ein. Wir messen in der ersten Erdschicht die Sättigung des Bodens: wie viel Wasseranteil im Erdreich vorhanden ist und wie viel Wasser der Boden noch aufnehmen kann. Zwei Messwerte sind dabei zentral: Bodentemperatur und Sättigung in Prozent. Bodentemperatur ist wichtig, weil wir zwei Extremereignisse haben: Im Frostbereich kann der Boden kein Wasser aufnehmen. Und bei sehr starker Trockenheit – wir hatten 2023 das Ereignis, dass es vier Monate nicht geregnet hat – sind die Böden extrem trocken. Wenn dann ein Starkregenereignis kommt, können die Böden das Wasser ebenfalls schlecht aufnehmen, und es wird abflusswirksam. Wir messen die Bodenfeuchte, übertragen die Daten in einem komplett autarken System mit einem Gateway, das den Sensor auch per Batterie versorgt, in unsere Cloud-Plattform, um darauf mit unserem Partner ein Frühwarnsystem aufzusetzen.

    Da gibt es wahrscheinlich unterschiedliche Anbieter und Ausführungen. Kannst du zu Varianten etwas erzählen? Was sind Vor- und Nachteile? Was sind Entscheidungskriterien für Sensorik – sowohl Pegelmessung als auch Bodenfeuchte?

    Felix

    Ganz klar im Fokus stehen Zuverlässigkeit und Lebensdauer der Sensorik. Wir wollen, dass ein Wasserstandsensor im Ereignisfall verdichtet übertragen kann. Der Bodenfeuchtesensor muss auch im Winter bei minus 20 Grad funktionieren und im Frühjahr weiterhin arbeiten. Er muss frühzeitig eine Fehlermeldung senden, bevor gar keine Informationen mehr kommen. Ich brauche valide Messwerte und zuverlässige Statusinformationen über Sensoren und Gateways: Übertragen sie noch? Gibt es eine Störung? Der Fokus sollte immer auf der Qualität der Sensorik und der Messwerte liegen, weil wir in einem sehr kritischen Bereich sind. Bodenfeuchte wird auch in anderen Anwendungsfällen gemessen, etwa in der Landwirtschaft oder im kommunalen Bereich bei Stadtbewässerung. Dort ist es bei der Kaufentscheidung oft weniger relevant, wenn ein Sensor für 80 bis 100 Euro über den Winter kaputtgeht oder geklaut wird, weil die Installationen zugänglich sind. Im Hochwasserfall sind wir hingegen an sehr entlegenen Orten, gerade bei Bodenfeuchte. Deshalb stehen Qualität und Lebensdauer des Sensors hier ganz klar im Fokus.

    Das macht Sinn. Der Sensor, wie du ihn beschrieben hast, stellt proaktiv selbst ein, wann er funkt. Die Intelligenz liegt also auf Sensorebene, während sie in anderen Settings eher auf Systemebene liegt und der Sensor abgefragt wird. Kann man das so sagen?

    Felix

    Der Sensor, den wir für Wasserstand einsetzen, hatte ursprünglich einen anderen Anwendungsfall und wurde explizit für Hochwasser weiterentwickelt. Ursprünglich waren das Anwendungen wie Baustoffsilos oder IBC-Kanister, wo man Oberflächen misst, ohne zeitkritische Anforderungen. Dort arbeitet man zyklisch, und Änderungen am Übertragungs- oder Messintervall schreibt man bei der nächsten Übertragung – vielleicht erst in zwölf Stunden – von der Cloud auf den Sensor. Im Hochwasserfall geht das nicht. Wir setzen darauf, dass wir im Ereignisfall eine verdichtete Messkette haben. Der Sensor misst jede Minute, und sobald der erste Grenzwert überschritten wird, überträgt er statt alle zwölf Stunden alle 60 Minuten. Wird der zweite Grenzwert überschritten, registriert er das sofort und überträgt in einem höheren Intervall, bis hin zu alle fünf Minuten. Der Vorteil ist: Die Intelligenz zur Anpassung des Übertragungsintervalls liegt im Sensor, eventbasiert. Üblicherweise wird der Übertragungs- und Sendeintervall von oben auf den Sensor geschrieben, aber meist erst mit der nächsten Übertragung.

    Ein Hochwasser-Frühwarnsystem ist relativ komplex, wenn man neben den Pegelständen auch Vorhersagen trifft. Gibt es auch einfachere Systeme? Gibt es Stufen hin zu so einem komplexen Frühwarnsystem?

    Felix

    Ja. Im ersten Schritt haben wir immer die klassische Wasserstandsüberwachung. Dazu kommt zum Beispiel das Thema Rechen: große Rechensysteme, die bei Hochwasser Treibgut – Blätter, Baumstämme und andere Einflüsse – aus dem Gewässer filtern sollen. In Gemeinden und Landkreisen sind das kritische Stellen: Wenn es zu einer Verklausung kommt, also wenn sich der Rechen zusetzt, steigt der Wasserstand. Ich war zum Beispiel auf einer Bürgermeistersitzung in Süddeutschland: Dort sind immer zwei, drei Haushalte betroffen, sobald sich der Rechen zusetzt und Wasser in Kellerräume läuft. Das ist eine sehr kleine Zulaufstelle, teilweise ohne dauerhaftes Fließgewässer. Bei Starkregen kommen Baumstämme und Blätter, setzen sich vor den Rechen, und dann werden diese Haushalte überflutet. Da saßen betroffene Bürger dabei und haben sich berechtigterweise beschwert, dass es keine Maßnahmen zur frühzeitigen Alarmierung gibt. In kleinen Kommunen haben wir deshalb Differenzmessungen umgesetzt: Wir messen den Füllstand vor dem Rechen und hinter dem Rechen. Wenn eine Differenz entsteht, deutet das auf eine Verklausung hin, und die Feuerwehr kann frühzeitig Gegenmaßnahmen einleiten. Dort ist man sogar so weit gegangen, ein Boxwall-System bereitzustellen, um eine unmittelbar bevorstehende Überflutung umzuleiten. Ein zweiter Anwendungsfall ist die Großstadt, wo wir knapp 52 Rechen haben. Logistisch ist es im Ereignisfall unmöglich, dass vier Personen alle Rechen nach Priorität rechtzeitig anfahren und reinigen. Deshalb haben wir Kamerasysteme installiert: Wenn ein Rechen sich zusetzt, werden Live-Bilder in unsere Cloud-Plattform Netilion übertragen, sodass man priorisieren kann, welche Rechen zuerst angefahren und gereinigt werden. Es gibt weitere Fälle, in denen wir mit unseren Sensorkomponenten kleinere Frühwarnsysteme implementiert haben. Der große Anwendungsfall geht aber Richtung Wasserstandsüberwachung als Basis und dann – mit Bodenfeuchte und Algorithmus – ein Frühwarnsystem.

    Wir bleiben beim Hochwasser: Das Ahrtal war eine Katastrophe, rund 20 Milliarden Schaden. Habt ihr eine Referenz, an der wir so ein System durchsprechen können?

    Felix

    Wir haben inzwischen, als einer der wenigen Sensorikhersteller, ein Frühwarnsystem in gleich zwei Kommunen im Ahrtal platziert, die aktuell laufen. Über eine Kommune kann ich sprechen: die Stadt Bad Münstereifel. Dazu haben wir eine Case Study, einen Erfahrungsbericht, was für ein Frühwarnsystem wir mit unserem Partner Okeanos aufgesetzt haben. Wir liefern die Messwerte zur Ist-Situation der Pegelstände, und Okeanos setzt das Frühwarnsystem auf. Wir messen an den Entstehungsstellen solcher Gewässer. Wenn man sich die Case Study ansieht, erkennt man, dass das sehr entlegene Orte sind. Wir messen dort früh, um vor die erste Welle zu kommen und frühzeitig zu erkennen, dass es zu einem Ereignis kommen kann.

    Wo gibt es diese Case Study zu sehen?

    Felix

    Auf unserer Homepage. Wenn man nach „Netilion dynamische Pegel“ googelt, kommt man auf unsere Seite. Dort findet man den Erfahrungsbericht zur Stadt Bad Münstereifel.

    Das verlinken wir in den Show Notes. In dem Fall werden Sensordaten an Okeanos übertragen: Wem gehören denn die Daten? Endress+Hauser, Okeanos oder der Kommune? Wer ist Datenbesitzer, und wo laufen die zusammen?

    Felix

    Das ist unterschiedlich und hängt vom Anwendungsfall ab. Teilweise ist Okeanos der direkte Auftraggeber und besitzt die Datenhoheit. Oder Landkreise, Kommunen und Städte erwerben das Sensorprodukt direkt bei uns; dann liegt die Datenhoheit dort, und die Daten können mit Okeanos geteilt werden, um ein Hochwasserfrühwarnsystem aufzusetzen.

    Dann sind die Schnittstellen maßgeblich in die Cloud hinein – wahrscheinlich bei Okeanos. Habt ihr eine eigene Cloud, oder wo ist die Übergabe?

    Felix

    Wir haben unsere hauseigene Endress+Hauser Netilion Cloud, in die weltweit bereits Millionen Sensoren integriert sind und über die wir Asset Management betreiben. Die Sensoren senden ihre Daten in unsere Cloud und werden dort gemanagt, also auch Grenzwerteinstellungen. Von dort stellen wir die Daten entweder Okeanos bereit oder der Kommune, dem Landkreis, der Stadt – je nachdem, wer Endkunde ist –, um Daten einzusehen oder im Fall von Okeanos die Daten für ein Frühwarnsystem zu verarbeiten. In vielen Fällen haben wir über unsere Cloud bei Grenzwertüberschreitungen – zum Beispiel beim Gewässerstand – eine direkte Integration in Feuerwehr-Meldungleitsysteme. Dafür werden Schnittstellen wie Webhooks, API oder OPC UA genutzt, um Daten direkt in Meldungleitsysteme, SCADA-Systeme oder cloudbasierte Frühwarnsysteme zu integrieren. Dafür ist eine standardisierte Schnittstelle entscheidend.

    Dann würdet ihr das auch als Komplettpaket inklusive eurer IoT-Plattform anbieten, wenn eine Kommune das möchte. Was kostet so ein System? Ist das vergleichbar oder sehr unterschiedlich? Welche Komponenten werden wie bepreist?

    Felix

    Das ist abhängig von der Anzahl der Sensoren und vom Aufwand dahinter. Wir hatten Projekte mit kompletter Montage von 30 bis 50 Sensoren, das kann in den sechsstelligen Bereich gehen. Generell sind wir mit den Paketen aber sehr schlank unterwegs. Wenn wir von kleinen Kommunen sprechen, sind wir meist bei fünf bis zehn Wasserstandsensoren. Da liegen wir im üblichen Fall unter der Ausschreibungsgrenze, teilweise unter 10.000 Euro inklusive Inbetriebnahme. Je nach Anwendungsfall muss man schauen, wie weit das sinnvoll ist. Wir haben auch Modelle, bei denen man schrittweise ausrollt und pro Jahr weitere Sensorik ergänzt.

    Wie lange so etwas haltbar ist, ist total relevant. Eine Kommune müsste eigentlich die Lebenszykluskosten kalkulieren, was nicht einfach ist und viele vermutlich nicht machen. Wenn du das aus Sicht einer Kommune betrachtest: Was ist der Business Case? Wie sollte man so ein Projekt bewerten?

    Felix

    Im Endeffekt ist es ein Thema, dass man sich als Gemeinde oder Landkreis Gedanken macht, wie solche Sensoren über eine Lebensdauer von 15 bis 20 Jahren bewertet werden. Man muss dazu sagen: Mit dem autarken Sensor haben wir im Vergleich zu kabelgebundenen Sensoren gewisse zusätzliche Aufwände, die man aber in Relation sehen muss. Der Wasserstandsensor ist deutlich günstiger als eine hydrostatische Drucksonde inklusive Einbau und sämtlichen zusätzlichen Aufwänden. Laufende Kosten sind Mobilfunk und gelegentlicher Batterieaustausch. Wir haben den Batterieaustausch aber so gestaltet, dass er sehr einfach ist: In zwei bis drei Minuten kann man die Batterie tauschen, den Sensor wieder verschließen, und er bleibt wasserdicht. Das kann als Dienstleistung durch uns erfolgen oder auch vom Kunden selbst. Wir geben klare Empfehlungen, welche Ersatzbatterien geeignet sind, und liefern diese auch in Paketen. Das Ganze wird über die Cloud so gemanagt, dass der typische Anwendungsfall ist: Der lokale Bauhof bekommt eine Meldung, wenn etwas am Sensor ist, zum Beispiel wenn die Batterielebensdauer gegen null geht. Oder es gibt eine Warnung mit Vorlauf, sodass innerhalb der nächsten zwei bis drei Monate ein Austausch geplant werden kann.

    Du bist im Business Development. Das ist also kein Produkt, das seit 10 oder 20 Jahren im Markt ist, sondern noch relativ neu und aus anderen Bereichen weiterentwickelt. Was habt ihr in diesen Projekten gelernt? Worauf muss man achten, wenn man ein Hochwasser-Frühwarnsystem oder generell Hochwasserüberwachung einführt?

    Felix

    Jedes Produkt und jede Lösung hat eine Lernkurve. Wir haben am Anfang gedacht, eine reine E-Mail-Benachrichtigung bei Grenzwertüberschreitungen oder für ein Frühwarnsystem würde ausreichen. Mit Okeanos sind wir aber relativ schnell zu dem Punkt gekommen, dass es bei rasant steigenden Pegeln darauf hinausläuft, über offene Schnittstellen eine Integration in ein Leitsystem zu ermöglichen. Das war ein großes Learning. Ein weiteres Learning betrifft den kommunalen Bereich: Es gibt meist eine Instanz, die Grenzwertinformationen benötigt, und eine andere Instanz, die für die Gesundheit der Sensoren zuständig ist. Bauhof oder Ordnungsamt sind typische Empfänger von Meldungen, wenn am Sensor etwas nicht stimmt. Wir haben gelernt, dass wir eine Nutzerverwaltung brauchen, sodass je nach Ereignis – Grenzwertüberschreitung oder Gesundheitszustand des Sensors – unterschiedliche Zielgruppen die Informationen bekommen. Spannend war auch die Zusammenarbeit mit Okeanos, die ein gesamtes Frühwarnsystem mit Zusatzdaten aufbauen. Wir haben gelernt, dass für ein Frühwarnsystem auch Daten vom Deutschen Wetterdienst essenziell sind, um die Prognosen genauer zu machen. Wichtig ist, dass alle Daten über die Plattform gebündelt laufen, um eine konsistente Informationsquelle für die Frühwarnung zu haben.

    Wenn eine Kommune loslegen will: Wir hatten schon mal Probleme mit Hochwasser, wir wollen jetzt starten – was sind die allerersten Schritte?

    Felix

    Der erste Schritt sind Pegelstände. Das ist die Grundvoraussetzung: an den entlegensten Orten anfangen, Wasserstände zu messen, und das über einen Zeitraum entlang des Flussverlaufs zu monitoren – insbesondere, wenn es mehrere Zulaufstellen gibt. Der zweite Schritt ist dann ein gesamtes Frühwarnsystem mit Bodenfeuchte und Wetterdaten, zum Beispiel über unseren Partner Okeanos. Wir können im Beratungsfeld unterstützen, auch bei der Projektauslegung: Macht es Sinn, ein komplettes Frühwarnsystem aufzusetzen, oder bleibt man zunächst beim Standardpaket der Wasserstandsmessung? Grundlage ist auf jeden Fall die Wasserstandsmessung und darauf aufbauend – je nach Sinnhaftigkeit – ein Hochwasser-Frühwarnsystem.

    Felix, vielen Dank. Ich glaube, ich habe gut verstanden, wie sich so ein System zusammensetzt. Das war sicher auch für die Zuhörerinnen und Zuhörer spannend: vom Sensor mit den zwei Sensortypen – Pegelstand und Bodenfeuchte – über das System, die Schnittstellen und Übergaben bis hin zur Kommune, die Lebenszykluskosten betrachten sollte. Auch wenn so ein System zunächst teurer wirkt: Wenn man sieht, welche Schäden entstehen können, wenn man das nicht rechtzeitig adressiert, ist der Beitrag zu mehr Sicherheit enorm. Vielen Dank. Hast du noch etwas zu ergänzen, was ich nicht explizit gefragt habe, was aber relevant ist – zum System, Umfeld oder zu Referenzprojekten?

    Felix

    Danke für die abschließenden Worte. Einen Punkt möchte ich revidieren: Ich glaube nicht, dass wir hier ein sehr teures Produkt haben oder dass die Kosten eines Frühwarnsystems besonders hoch sind. Sobald es um Ausschreibungen geht, werden häufig auch günstige Sensorikprodukte in Betracht gezogen. Deshalb ist mein Appell: Gerade bei Ausschreibungen sollte der Fokus auf Lebensdauer und Qualität der Messungen liegen. Und ich glaube, dass wir für den Leistungsumfang und die Qualität preislich sehr gut dabei sind.

    Hervorragend. Das passt gut zu unserem Thema heute. Vielen Dank, Felix, dass du heute da warst. Vielen Dank, liebe Zuhörerinnen und Zuhörer, dass ihr so lange mit uns dabei wart. Bis zum nächsten Mal.

    IoT Use Case

    Wir verwenden Cookies

    Wir nutzen Cookies und ähnliche Technologien, um unsere Website zu verbessern und dir relevante Inhalte anzuzeigen. Du kannst selbst entscheiden, welche Kategorien du zulässt. Weitere Informationen findest du in unserer Datenschutzerklärung. Datenschutzerklärung