IoT Use Case Podcast

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/)

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/)

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/)
Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten

www.iotusecase.com
#LoRaWAN #Dampfnetz #Digitalisierung
In Episode #216 des IoT Use Case Podcasts spricht Dr. Peter Schopf mit Murat Mutlu, IoT-Portfolio Manager bei Currenta Conneqtive, und Dominik Neugebauer, Leitung Technik Rohrnetze bei Currenta. Thema ist die Digitalisierung eines 180 Kilometer langen Dampfnetzes im CHEMPARK – mit LoRaWAN statt Kabel, für mehr Transparenz im Netz und weniger Energieverluste.
Zusammenfassung
Der CHEMPARK betreibt rund 1.000 Kilometer Rohrleitungen, davon ca. 180 Kilometer Dampfnetz. Das Netz wurde historisch für andere Lastprofile ausgelegt – Bedarfe und Abnahmepunkte haben sich seitdem stark verändert. Klassische Temperaturmessung ist im Feld ohne aufwändige Verkabelung kaum wirtschaftlich darstellbar. Kondensatableiter – Bauteile, die flüssiges Kondensat aus dem Dampfsystem ableiten – wurden bislang manuell geprüft; Defekte blieben dadurch monatelang unbemerkt.
Currenta Conneqtive hat ein LoRaWAN-Netz aufgebaut, das mit wenigen Outdoor-Antennen den gesamten CHEMPARK abdeckt. Batteriebetriebene Sensoren erfassen Temperaturen an Knotenpunkten und überwachen den Status der Kondensatableiter per Condition Monitoring. Ziel ist es, Reaktionszeiten bei defekten Ableitern von Monaten auf Stunden zu reduzieren – und die Netzauslegung auf Basis besserer Daten schrittweise zu optimieren.
Parallel entsteht ein KI-gestütztes dynamisches Simulationsmodell, das den Netzzustand auch zwischen Messpunkten abbildet. Da externe Dienstleister die nötige Kombination aus ML-Kompetenz und thermodynamischem Prozesswissen nicht lieferten, wird das Modell intern entwickelt. Der CHEMPARK dient dabei als Stresstest – was hier zuverlässig läuft, soll als standardisiertes SaaS-Produkt für externe Industriekunden angeboten werden.
Das nimmst du mit
LoRaWAN deckt weitläufige Industriestandorte mit wenigen Antennen kostengünstig ab – ohne aufwändige Verkabelungsinfrastruktur.
Condition Monitoring der Kondensatableiter reduziert Reaktionszeiten bei Defekten von Monaten auf Stunden.
Live-Sensordaten aus dem Feld verbessern Netzwerksimulationen und ermöglichen fundiertere Investitionsentscheidungen im Dampfnetzbetrieb.
KI-gestützte Simulation im Prozessumfeld erfordert ML-Kompetenz und thermodynamisches Domänenwissen gleichermaßen – wer beides nicht vereint, scheitert am Modell.
Ein LoRaWAN-Netz als geteilte Infrastruktur lässt sich für mehrere Use Cases gleichzeitig nutzen und schrittweise mit neuen Anwendungsfällen erweitern.
-----
Relevante Folgenlinks:
Peter (https://www.linkedin.com/in/peter-schopf/)
Murat (https://www.linkedin.com/in/murat-mutlu-solution-portfolio-manager/)
Dominik (https://www.linkedin.com/in/dominik-neugebauer-8a47b6298/
Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten

www.iotusecase.com
#UnifiedNamespace #VibeCoding #GenerativeAI 
Alexander Krüger, CEO und Managing Director von United Manufacturing Hub (UMH), ist zu Gast bei Dr. Peter Schopf im IoT Use Case Podcast. Im Mittelpunkt steht eine These, die gerade in vielen Werken an Relevanz gewinnt: Was passiert, wenn generative KI nicht nur Texte schreibt, sondern gleich die Produktionsanwendungen dahinter baut – und welche Datengrundlage dafür zwingend nötig ist?
Zusammenfassung
UMH positioniert sich als Open-Source-Plattform für industrielles Datenmanagement. Die Grundidee: Wer Vibe-Coding – also das KI-gestützte Generieren von Frontend-Applikationen – im Shopfloor nutzen will, braucht dafür eine saubere, strukturierte Datengrundlage. Diese stellt UMH über einen Unified Namespace bereit: eine eventbasierte Architektur, die Maschinendaten aus unterschiedlichsten Quellen normalisiert und über REST-APIs sowie Echtzeit-Streams verfügbar macht. Krüger erklärt, warum KI dieselbe Datensemantik braucht wie ein menschlicher Produktionsleiter – ohne klaren Kontext halluziniert sie genauso.
Besonders konkret wird es beim Thema MES. Traditionelle Implementierungen kosten Hunderttausende Euro, erfordern Systemintegratoren und sind kaum änderbar. Mit einem sauberen Daten-Backend und Vibe-Coding lassen sich solche Anwendungen nach Angaben von Krüger heute intern in wenigen Wochen und für einen Bruchteil der früheren Kosten bauen. Eine Forrester-Studie mit UMH-Kunden zeigt: 5 % Energieeinsparung, 14 % weniger ungeplante Stillstände, ROI von über 400 %.
Das nimmst du mit
Vibe-Coding im Shopfloor funktioniert nur auf einer sauberen Datengrundlage – der Unified Namespace liefert die nötige Semantik und Struktur.
KI braucht denselben Kontext wie ein Mensch: Ohne strukturierte Daten halluziniert sie genauso zuverlässig wie mit unklaren Arbeitsanweisungen.
Infrastructure as Code macht das Anbinden von Maschinen drastisch schneller – aus Tagen werden Minuten, wenn die AI mit Konfigurationsdateien statt UI-Klicks arbeitet.
Build vs. Buy verschiebt sich fundamental: MES-Anwendungen lassen sich heute intern für einen Bruchteil der früheren Kosten selbst bauen.
UMH ist vollständig Open Source – einfach herunterladen, eigene Use Cases validieren, loslegen.
-----
Relevante Folgenlinks:
Peter (https://www.linkedin.com/in/peter-schopf/)
Alexander (https://www.linkedin.com/in/alexander-krueger/)
Jetzt IoT Use Case auf LinkedIn folgen

1x monatlich IoT Use Case Update erhalten