IoT Use Case Podcast

#ITOTIntegration #OPCUA #MQTT

In episode #225 of the IoT Use Case Podcast, Ing. Madeleine Mickeleit talks to Pyry Grönholm, CEO of Prosys OPC. Using a plant in Finland with more than 100 machines as an example, they discuss how to get data out of a machine park built up over the years – and when OPC UA or MQTT is the right choice.

Summary

The plant is part of an international manufacturing group, with machines from many vendors and generations. The trigger was an MES project due in about two years. Prosys first replaced the outdated OEE system and built status dashboards. Machines were connected wherever possible: via OPC UA servers, Siemens, Beckhoff and EtherNet/IP connectors, Modbus through existing gateways, or an additional PLC next to the old one. The team initially expected 30 to 50% of the machines – according to Pyry, it was significantly more.

The data is harmonized in open OPC UA information models for status, OEE and MES, identical across all machines. The customer owns the model, not the software vendor. A newly connected machine is live in under an hour.

Then the question many in the community ask: OPC UA or MQTT – which wins for industrial data? Pyry has a clear answer, explains it with an everyday analogy and links it to a project detail: The original plan is not what was implemented in the end.

Key takeaways

• One information model per machine type is enough; after that, each new machine is just a template plus mapping.
• Gateways a legacy system already wired to unconnected PLCs can still be used via Modbus.
• If automation engineers model each variable's unit, value range and meaning, data engineers and AI understand the data.
• In large corporations, find out early how IT provisioning and permissions work – or lose a lot of time waiting.

-----
Relevante Folgenlinks:
Madeleine (https://www.linkedin.com/in/madeleine-mickeleit/)
Pyry (https://www.linkedin.com/in/pyrygronholm/)

Join the user group (https://www.iotusecase.com/en/user-group)

#AIoT #KIAgenten #Datenharmonisierung

Ing. Madeleine Mickeleit spricht im IoT Use Case Podcast mit Dr. Jürgen Krämer, CPO und Geschäftsführer bei Cumulocity, über AIoT – die Verschmelzung von klassischem Machine Learning, generativer und agentischer KI mit Industrial IoT. Im Fokus steht der Weg von der reinen Vernetzung von Maschinen hin zu teilautonomen Abläufen.

Zusammenfassung

Die sicher angeschlossene Flotte ist für Krämer Voraussetzung, nicht Leistung: Ohne sie lohnt kein KI-Projekt. Er trennt zwei KI-Arten – klassisches Machine Learning für hochfrequente Maschinendaten, weil ein LLM dort die Token-Kosten sprengen würde, und agentische KI, die auf ein erkanntes Anomalie-Event hin eine Root-Cause-Analyse startet. Beides steht und fällt mit dem Kontext: Ohne Asset-Beziehungen, Einheiten und Produktdokumentation bleibt eine Fehlermeldung wie 4711 an einer Pumpe für den Agenten bedeutungslos.

Konkret wird das bei der Datenharmonisierung. In einem Werk heißt der Temperatursensor Hugo, im nächsten Willi. Ein Expert Agent liest den eingehenden Datenstrom mit und schlägt die Transformation ins Cumulocity-Format vor, getestet unter anderem mit OPC UA, Modbus, LoRaWAN, Protobuf, CBOR und Sparkplug. Bei Enercon automatisiert eine regelbasierte Remote-Aktion rund 40 Prozent der Turbinen-Restarts; KI ist dabei nach Krämers eigener Aussage nicht im Spiel.

Autonome Eingriffe bleiben Zukunft: Prototypen ja, Produktivbetrieb nein. Kunden bringen ihr eigenes LLM mit, Cumulocity trainiert keine Modelle auf Kundendaten – Begründung ist der Schutz des Domänenwissens der Betreiber. Und Krämer warnt vor Vibe Coding in geschäftskritischen Prozessen: KI-gestützte Entwicklung gehört auf die Applikationsebene, nicht in das System of Record, auf dem Governance und Auditierung aufsetzen.

Das nimmst du mit

• Ohne sicher angeschlossene Flotte lohnt kein KI-Projekt – schlechte Daten erzeugen schlechte Ergebnisse.
• Hochfrequente Maschinendaten gehören an klassisches Machine Learning, nicht an ein LLM, sonst explodieren die Token-Kosten.
• Der Semantic Layer ist branchenspezifisch und damit der Punkt, an dem Domänenpartner gebraucht werden.
• Wer Datenhoheit will, muss klären, ob der Anbieter Modelle auf den eigenen Betriebsdaten trainiert.

-----
Relevante Folgenlinks:
Madeleine (https://www.linkedin.com/in/madeleine-mickeleit/)
Jürgen (https://www.linkedin.com/in/juergenkraemer/)
Cumulocity (https://www.cumulocity.com/)
Folge zu Cyber Resilience Act (https://www.iotusecase.com/de/podcast/cyber-resilience-act-oems)
Vision-AI-Beispiel (Doku) (https://community.cumulocity.com/t/14554)

Top-5-AIoT-Use-Cases:
1. Datenharmonisierung per Expert Agent
2. Dashboards per Agent
3. Software-Rollout per Agent (in Entwicklung)
4. IT/OT-Security per Expert Agent (Idee)
5. Daten mit Kontext für externe Agenten via MCP (im Ausbau)

Anwenderkreis beitreten (https://www.iotusecase.com/de/anwenderkreis)

In dieser Folge des IoT Use Case Podcasts meldet sich Gastgeberin Ing. Madeleine Mickeleit ohne Gast zu Wort: eine kurze Ankündigung an alle Hörerinnen und Hörer, verbunden mit einem Dank und zwei Neuigkeiten zum Podcast.

Der IoT Use Case Podcast läuft seit Ende 2019. In dieser Zeit sind zahlreiche Projekte und Use Cases aus der Praxis vorgestellt worden, und um den Podcast ist ein Netzwerk gewachsen, mit dem das Team heute arbeitet. Genau dafür sagt Madeleine Mickeleit in dieser Folge Danke – an Stammhörer wie an alle, die gerade zum ersten Mal reinhören.

Gleichzeitig gibt es zwei Änderungen. Das Team arbeitet an einem neuen Format, unter anderem zum Thema KI, das in der Praxis von Anwendern umgesetzt wird. Deswegen erscheint der Podcast künftig alle zwei Wochen statt wöchentlich; die Formate werden sich abwechseln. Wann das neue Format live geht, wird im Podcast berichtet. 

Der Aufruf am Ende richtet sich an Anwender: Wer selbst ein Projekt umgesetzt hat und darüber erzählen möchte, kann sich proaktiv bei Madeleine Mickeleit und dem Team melden.

Das nimmst du mit

• Der IoT Use Case Podcast erscheint ab jetzt alle zwei Wochen statt wöchentlich. 
• Grund ist ein neues Format, an dem das Team parallel arbeitet – unter anderem zum Thema KI in der Umsetzung bei Anwendern. 
• Die Formate werden sich künftig abwechseln; der Start des neuen Formats wird im Podcast angekündigt. 
• Anwender mit eigenen umgesetzten Projekten können sich proaktiv bei Madeleine Mickeleit und dem Team melden.
  
  -----
  Relevante Folgenlinks:
  Madeleine (https://www.linkedin.com/in/madeleine-mickeleit/)
  
  Zum IoT Use Case Anwenderkreis

Wie kommen Sensordaten aus der Maschine, ohne dass jemand die Steuerung anfasst? Darüber spricht Gastgeberin Ing. Madeleine Mickeleit im IoT Use Case Podcast mit Christoph Rose, Produktmanager Cloud & Software bei Turck, und Christoph Schmermund, Produktmanager für die Turck Automation Suite. Im Mittelpunkt steht TAS Edge – der Weg von der IO-Link-Sensorik über MQTT in MES-, ERP-, SCADA- oder Cloud-Systeme.

Zusammenfassung

Klassisch läuft die Anbindung über die Steuerung: Wer einen zusätzlichen Datenpunkt braucht, muss das Steuerungsprogramm anfassen, testen und freigeben lassen – teilweise mit Anlagenstillstand. Schmermund beschreibt das als den Aufwand, den Kunden am häufigsten unterschätzen.

TAS Edge greift die Daten stattdessen direkt an den IO-Link-Mastern ab. Es läuft parallel zum Steuerungsprogramm und sammelt Daten auch dann, wenn gar keine Steuerung vorhanden ist. Konfiguriert wird per UI im Webbrowser, die Datenpunkte werden über Checkboxen ausgewählt und per MQTT weitergeleitet. Rose schildert den Unterschied aus eigener Erfahrung: über eine Woche für die Anbindung über CODESYS, zwei Stunden mit TAS Edge auf der Messe.

Ergänzend geht es um TAS Desktop als kostenloses Gerätemanagement – Konfiguration, Firmware-Updates und Reports, die sich bei Factory Acceptance Tests mitgeben lassen. Als wichtigstes Learning nennen beide Gäste die Einfachheit: Die größte Hürde war nicht die Technik, sondern den eigenen Vertrieb zu überzeugen.

Das nimmst du mit

• Der unterschätzte Aufwand liegt nicht in der Ersteinrichtung, sondern in jedem zusätzlichen Datenpunkt, der Test, Freigabe und oft Stillstand nach sich zieht.
• TAS Edge läuft parallel zum Steuerungsprogramm und braucht keine Steuerung, um Daten zu sammeln und per MQTT weiterzuleiten.
• Für die Konfiguration ist kein MQTT-Wissen nötig – ausgewählt wird per Checkbox, für die gesicherte Übertragung wird ein Zertifikat geladen.
• TAS Desktop dokumentiert die Sensorkonfiguration geräteübergreifend und macht vertauschte Anschlüsse vor der Inbetriebnahme sichtbar.
• Auf der unteren Ebene ist die Lösung herstelleroffen: Angebunden werden IO-Link-Geräte unabhängig vom Hersteller, sofern sie über einen Turck-Master laufen.

-----
Relevante Folgenlinks:
Madeleine (https://www.linkedin.com/in/madeleine-mickeleit/)
Christoph R. (https://www.linkedin.com/in/christoph-ronald-rose/)
Christoph S. (https://www.linkedin.com/in/christoph-schmermund-76ba14337/)
IO-Link-Master (https://www.turck.at/de/productgroup/Snap%20Signal/IO-Link%20Master)
TAS Edge (https://www.turck.com/de/de/spotlight/special/tas-edge-ot-daten-erfassen-filtern-und-gezielt-bereitstellen)

Anwenderkreis beitreten (https://www.iotusecase.com/de/anwenderkreis)

www.iotusecase.com

#CyberResilienceAct #CRA #NIS2

How does a legal reporting duty turn into a service you can charge for? That is the question behind “Cyber Resilience Act for OEMs: From Compliance Evidence to a Lifecycle Service” on the IoT Use Case Podcast. Host Ing. Madeleine Mickeleit talks to Miguel Morales, Vice President Strategic Cloud Alliances at Cumulocity, about what the CRA asks of connected-product manufacturers and where it meets NIS2.

Podcast Summary

The CRA comes with two dates: from September 2026, manufacturers have 24 hours to report actively exploited vulnerabilities and severe incidents; from December 2027, full conformity applies. Morales draws the line between the two regulations – the CRA governs manufacturers and their products, NIS2 the operators, with personal liability attached.

That intersection is where his argument sits. CRA obligations stop at disclosing vulnerabilities and making patches available, and the patches must be free. Operators, though, have to prove their own compliance across equipment from many vendors. A manufacturer who hands them that evidence automatically is selling a lifecycle service, not just hardware.

A published cybersecurity paper from Danfoss serves as the reference point. Beyond that, the conversation stays technical: SBOM generation, continuous firmware scanning, PKI certificates and update rollouts across globally distributed fleets. Morales calls the manual effort behind this the governance tax, and closes with ten actions for manufacturers.

What you take away

• The first deadline is September 2026, not December 2027: 24-hour reporting for actively exploited vulnerabilities starts then.
• CRA and NIS2 interlock – the manufacturer’s obligation is the basis of the operator’s own proof.
• The patch must be free under the regulation; what can be priced is the rollout orchestration and the auditable evidence.
• Compliance shifts from an annual reporting exercise to a status calculated continuously from device state data.
• First of Morales’ ten actions: move CRA ownership out of legal and into the product P&Ls.

-----
Relevante Folgenlinks:

Madeleine (https://www.linkedin.com/in/madeleine-mickeleit-mrs-iot/)
Miguel (https://www.linkedin.com/in/moralesamiguel/)
CRA and NIS2 compliance (https://www.cumulocity.com/resource-library/cumulocity-eu-regulation-white-paper/)
Cumulocity and EY Law (https://www.cumulocity.com/resource-library/building-cyber-resilience-for-the-eu-market/)

Join the user group (iotusecase.com/en/user-group)

Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten

www.iotusecase.com
#IoTUseCase #Mittelstand

In Episode #221 des IoT Use Case Podcasts blickt Gastgeberin Ing. Madeleine Mickeleit gemeinsam mit Dr. Peter Schopf zurück, der die vergangenen 23 Folgen als Co-Host moderiert hat. Die Sonderfolge bündelt die Use Cases, Business Cases und Architekturfragen dieser Episoden – von Dampfnetzmonitoring im CHEMPARK über kommunale Hochwasser-Früherkennung bis zu privatem 5G im Stahlwerk. 

Zusammenfassung

Statt einzelner Anwenderfolgen hören die beiden in Originalzitate hinein und ordnen sie ein – unter anderem von Currenta Conneqtive, Endress+Hauser, SPALECK, ORGATEX, der Johannes Giesser Messerfabrik und Salzgitter Flachstahl.

Konkret wird es beim Business Case. Am Beispiel einer überwachten Wärmekammer bei DENIOS rechnet Mickeleit vor, was ein Chargenverlust kostet: rund 20.000 Euro für einen 1000-Liter-IBC, dazu etwa 2.000 Euro Reinigung plus eine Schicht Stillstand. Schopf ordnet ein, warum solche Beträge in der Prozessindustrie schneller entstehen als in der diskreten Fertigung – und warum belastbare Zahlen in Podcast-Gesprächen die Ausnahme bleiben: Endkunden geben sie nicht heraus, vieles läuft unter NDA.

Der zweite rote Faden ist die Frage, woran Digitalisierung im Mittelstand scheitert. An der Technik nicht mehr, so Schopf – für fast jede Fragestellung gebe es bereits einen Use Case und einen Anbieter.
-----
Relevante Folgenlinks:
Madeleine (https://www.linkedin.com/in/madeleine-mickeleit/)

Peter (https://www.linkedin.com/in/peter-schopf/)

Folgen der Episode:

#216 Dampfnetz CHEMPARK: https://iotusecase.com/podcast/condition-monitoring-lorawan-dampfnetz

#209 Hochwasser: https://iotusecase.com/podcast/hochwasser-frueher-erkennen-mit-radar-und-nb-iot

#206 SPALECK Service: https://iotusecase.com/podcast/condition-monitoring-proaktiver-service-maschinenbau

#202 ORGATEX Doku: https://iotusecase.com/podcast/digitale-intralogistik-iot-visuelles-management

#205 OPC UA ins ERP: https://iotusecase.com/podcast/iot-low-code-am-shopfloor-edge-opc-ua-erp

#215 UMH Unified Namespace: https://iotusecase.com/podcast/vibe-coding-shopfloor-mes-ohne-systemintegrator

#207 WAGO ECLASS/AAS: https://iotusecase.com/podcast/digitaler-produktpass-eclass-aas-interoperable-produktdaten

#201 Privates 5G: https://iotusecase.com/podcast/privates-5g-campusnetz-autonome-transportsysteme-stahlindustrie

#220 Datenfundament: https://iotusecase.com/podcast/datenfundament-ki-produktion-mittelstand

Anwenderkreis: https://iotusecase.com/de/anwenderkreis

www.iotusecase.com
#ProductCarbonFootprint #Datensouveränität

In der 220. Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit:

• Henrik Schunk, Geschäftsführer der Next Level Mittelstand GmbH und Vorsitzender des Verwaltungsrats bei SCHUNK
• Peter Sorowka, Mitgründer und Co-CEO von Cybus
• Daniel Traub, Head of Manufacturing & Automotive Industry bei STACKIT, Schwarz Digits Cloud GmbH & Co. KG.

Im Fokus steht die Frage, wie der industrielle Mittelstand ein belastbares Datenfundament für KI-getriebene Produktion aufbaut – souverän und ohne Eigenbau.

Zusammenfassung

Ausgangspunkt ist ein nüchterner Befund: Die meisten Betriebe in der diskreten Fertigung wissen nicht live, welche Maschine läuft und welche steht. Störgründe landen handschriftlich auf Papierkarten. Sorowka argumentiert, dass Technologie seit zehn Jahren nicht das Problem ist, sondern der Business-Durchstich – datenbasierte Entscheidungsprozesse, Transparenz über Performance und ein verbreitetes Not-invented-here-Denken. Mit generativer KI verschiebt sich der Engpass auf die IT/OT-Integration.

Traub ordnet ein, warum Datensouveränität dabei zum Wettbewerbsthema wird: Bei vielen Hidden Champions ist Produktionsknow-how das differenzierende Merkmal. Neben dem Speicherort geht es um den Rechtsraum des Vertrags und um Unabhängigkeit vom einzelnen KI-Modell.

Konkret wird es an zwei Stellen: Schunk beschreibt ein PCF-Kochrezept aus einer Working Group, mit dem ein Mittelständler den von einem Automotive OEM geforderten Wert in zwei Stunden ausweisen konnte. Sorowka legt mit der autonomen Fabrik ein Zielbild vor, gestaffelt in Autonomie-Level 0 bis 4 analog zum autonomen Fahren.

Das nimmst du mit

• Wer nicht live weiß, welche Maschine steht, kennt seinen Bottleneck nicht – und kann den ROI eines Datenprojekts vorab kaum planen.
• Generative KI liefert Analyseideen und Prototypen in Stunden; der verbleibende Engpass ist die Anbindung an die reale Fertigung.
• Datensouveränität ist laut Traub ein Wettbewerbs- und kein Compliance-Thema, weil Produktionsknow-how das differenzierende Merkmal ist.
• Ein Zielbild mit Autonomie-Leveln macht Investitionen begründbar, auch wenn der ROI eines einzelnen Use Case fehlt.

-----
Relevante Folgenlinks:

Peter (https://www.linkedin.com/in/peter-schopf/)
Daniel (https://www.linkedin.com/in/daniel-traub-1678b4139/)
Henrik (https://www.linkedin.com/in/henrik-schunk-3a0a9098/)
Peter S (https://www.linkedin.com/in/psorowka/)

Anwenderkreis beitreten (https://www.iotusecase.com/de/anwenderkreis)

Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten

www.iotusecase.com
#LoRaWAN #PredictiveMaintenance #IIoT #MakeOrBuy

In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Murat Mutlu, IoT Portfolio Manager bei Currenta Conneqtive, und Christian Olt, IoT Industrial Solutions Director bei akenza. Im Mittelpunkt steht die Frage, wann aus einzelnen Sensorprojekten eine skalierbare IoT-Infrastruktur wird – und die Make-or-Buy-Entscheidung zwischen selbst gebautem IoT-Stack und einer bestehenden Plattform.

Zusammenfassung

Ausgangspunkt ist das LoRaWAN-Netz im CHEMPARK, mit dem Currenta Conneqtive zunächst das Dampfnetz und später Pumpen im Flusswasserwerk überwacht. Statt einen eigenen IoT-Stack aufzubauen – mit Entwicklungsabteilung, Anforderungskatalog und ein bis zwei Jahren Vorlauf – setzt Conneqtive auf die akenza-Plattform und kann sich so auf Sensoren und Use Cases konzentrieren. Ein zentraler Punkt ist die Device Type Library mit über 400 vordekodierten Geräten: Das Dekodieren neuer Sensoren, sonst ein wiederkehrender Schmerzpunkt, fällt per Klick weg.

Murat Mutlu und Christian Olt gehen den Weg vom TWTG-Vibrationssensor über Actility als LoRaWAN-Network-Server bis zur Auswertung in akenza durch – inklusive FFT-Analysen, Grenzwerten und Alarmierung. Deutlich wird: Mit Grenzwerten lässt sich ein Großteil der Fälle abdecken, komplexe Schwingungsbilder und KI-Modelle brauchen dagegen weiter einen Experten. Der eigentliche Hebel liegt darin, eine einmal aufgebaute Infrastruktur als Shared Medium für viele weitere Anwendungsfälle zu nutzen – von der Einzelraumregelung bis zur Schmierungsoptimierung.

Das nimmst du mit

• Wer IoT skalieren will, baut nicht einzelne Use Cases, sondern eine Infrastruktur, auf der viele Anwendungsfälle aufsetzen.
• Eine vordekodierte Device-Bibliothek nimmt den größten Aufwand beim Anbinden neuer Sensoren – das Dekodieren – aus dem Projekt.
• Grenzwerte lösen einen Großteil der Predictive-Maintenance-Fälle; für komplexe Schwingungsbilder braucht es weiterhin Expertenwissen.
• Als Infrastructure- und Software-as-a-Service finanzieren Einsparungen, etwa bei Heizkosten, die Infrastruktur mit.
• Das größte Lehrgeld fiel nicht in der Software an, sondern im Feld – durch zu komplexe, zu stark ingenieurgetriebene Lösungen statt pragmatischer Standards.

-----
Relevante Folgenlinks:

Peter (https://www.linkedin.com/in/peter-schopf/)
Christian (https://www.linkedin.com/in/christian-olt-a75244199/)
Murat (https://www.linkedin.com/in/murat-mutlu-solution-portfolio-manager/)

Anwenderkreis beitreten (https://www.iotusecase.com/de/anwenderkreis)

Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten

www.iotusecase.com
#Verwaltungsschale #IIoT

In dieser Episode des IoT Use Case Podcasts spricht Co-Host Dr. Peter Schopf mit Michael Knoblich, Product Owner bei XITASO, und Hans Michael Krause, Director Ecosystem ctrlX World bei Bosch Rexroth. Im Mittelpunkt steht die Frage, wie aus der Verwaltungsschale – der Asset Administration Shell – in der Modellfabrik von Bosch Rexroth in Ulm konkrete Produktionsflexibilität wird.

Zusammenfassung

Ausgangspunkt ist ein bekanntes Problem: Neue Maschinen lassen sich nur mühsam in bestehende Linien integrieren, weil Linien-SPS starr programmiert sind und Daten in Subsystemen mit unterschiedlicher Semantik brechen. Die Verwaltungsschale dient als standardisierte Datenschnittstelle – im Werk und über Unternehmensgrenzen hinweg.

In der Modellfabrik bekommt jede Maschine und jedes Modul eine Verwaltungsschale. Über eine Asset Orchestration Platform modelliert Bosch Rexroth die Linie per Businesslogik statt fester SPS-Programmierung und rekonfiguriert flexibel zwischen AGVs und Maschinen. XITASO unterstützt bei der standardisierten Erstellung; ein frühes Beispiel ist das digitale Typenschild bei WITTENSTEIN. Die Verwaltungsschale bleibt dabei eine Technologie neben OPC UA und MQTT – entscheidend ist die Wahl je Use Case.

Die größte Hürde ist die Erstellung der Verwaltungsschale selbst. Krause rät, klein an der vermuteten Bottleneck-Maschine anzufangen und erst Datentransparenz zu schaffen, bevor die Linie orchestriert wird. Knoblich lenkt den Blick auf OT/IT und ein gemeinsames Zielbild: Am Ende seien es die Menschen, die man mitnehmen muss.

Das nimmst du mit

• Als größte Einstiegshürde erscheint die Erstellung der Verwaltungsschale selbst – für Brownfield-Maschinen bietet XITASO dafür einen SPS-Funktionsbaustein.
• Auf Basis der Verwaltungsschale lässt sich eine Linie über eine Asset Orchestration Platform per Businesslogik modellieren, statt sie starr in die Linien-SPS zu programmieren.
• Die Verwaltungsschale ist eine Technologie von mehreren; für Bewegungskommandos eignet sich MQTT, für Sensorsignale OPC UA.
• Wer OEE verbessern will, beginnt an der vermuteten Bottleneck-Maschine: erst Verluste transparent machen, dann orchestrieren.
  

-----
Relevante Folgenlinks:

Peter (https://www.linkedin.com/in/peter-schopf/)
Hans Michael (https://www.linkedin.com/in/hansmichaelkrause/)
Michael (https://www.linkedin.com/in/michael-knoblich/)

Anwenderkreis beitreten (https://www.iotusecase.com/de/anwenderkreis)

Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten

www.iotusecase.com
#LoRaWAN #Stadtwerke #Fernwärme

In Folge #217 des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Philipp Lausberger, IIoT Application Specialist bei WIKA, über IoT-Applikationen bei Stadtwerken und Netzbetreibern. Im Mittelpunkt steht die Frage, wie aus einem Messwert im Feld eine bessere Entscheidung im Netzbetrieb wird – und wie sich Kontrollfahrten zu schwer zugänglichen Fernwärme-, Wasser- und Gasnetzen reduzieren lassen.

Zusammenfassung

Viele Stadtwerke betreiben jahrzehntealte Bestandsnetze, deren Zustand bisher nur über manuelle Inspektionen erfasst wird: Zwei Mitarbeiter fahren zu einem Schacht, steigen bis zu sechs Meter tief hinab und lesen ein analoges Manometer ab. Das liefert nur eine Momentaufnahme – Leckagen, überflutete Schächte oder nachlassende Isolation an Stahlmantelrohren bleiben zwischen den Kontrollfahrten unentdeckt.

Lausberger beschreibt die Strecke vom Sensor bis in die Leitwarte: batteriebetriebene Messtechnik mit Funkübertragung über LoRaWAN, mioty oder Mobilfunk wie NB-IoT und LTE-M, angebunden über standardisierte Schnittstellen wie REST-API, MQTT und OPC UA. Zentrale Abwägung ist die Skalierbarkeit: Selbstgebaute Insellösungen stoßen schnell an ihre Grenzen, weshalb er cloudbasierte Netzwerkserver und einen verlässlichen Partner einem eigenen Plattformbetrieb vorzieht.

Wie die Daten den Netzbetrieb verbessern, zeigt er an einem Druckregelventil, das nach wochenlanger Suche als Ursache eines „springenden Netzes" identifiziert wurde, sowie an Langzeitdaten zu Druckspitzen für die Netzplanung. Bei Kosten unter 100 Euro pro Messstelle hält er den Ansatz auch für kleinere Kommunen für tragfähig.

Das nimmst du mit

• Der Zustand vieler Fernwärme-, Wasser- und Gasnetze wird bislang nur per manueller Schachtkontrolle erfasst; IoT liefert kontinuierliche Daten statt Momentaufnahmen.
• Batteriebetriebene Funksensoren (LoRaWAN, mioty, NB-IoT, LTE-M) erreichen Laufzeiten von bis zu zehn Jahren und lassen sich ohne Strom- oder Kabelinstallation nachrüsten.
• Selbstgebaute Insellösungen skalieren schlecht; ein cloudbasierter Netzwerkserver und ein verlässlicher Partner sind laut Lausberger der tragfähigere Weg.
• Sechs Meter tiefe Schächte erfordern Alternativen wie absetzbare Antennen, weil das Funksignal sonst nicht an die Oberfläche gelangt.

-----
Relevante Folgenlinks:

Peter (https://www.linkedin.com/in/peter-schopf/)
Philipp (https://www.linkedin.com/in/philipp-lausberger-5a16291a5/)

Anwenderkreis beitreten (https://www.iotusecase.com/de/anwenderkreis)

Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten