IoT Use Case Podcast

#222 | Cyber Resilience Act for OEMs: From Compliance Evidence to a Lifecycle Service | Cumulocity

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/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

• Transcript

#221 | 23 Folgen zusammengefasst: Was wirklich funktioniert hat und was nicht

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

#220 | Datenfundament für die KI-getriebene Produktion im Mittelstand

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/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

• Transcript

#219 | Make or Buy im IIoT: Use Cases skalieren mit einer LoRaWAN-Plattform | akenza.io

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/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

• Transcript

#218 | Verwaltungsschale in der Modellfabrik: Produktionslinien flexibel rekonfigurieren | XITASO

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/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

• Transcript

#217 | Netze nachrüsten in Stadtwerken: Zustand per Funk statt Kontrollfahrten | WIKA

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

#216 | 180 km Dampfnetz kabellos überwachen: Condition Monitoring mit LoRaWAN | Currenta

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

#215 | Vibe-Coding im Shopfloor: MES-Anwendungen selbst bauen ohne Systemintegrator | UMH

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

#214 | Ohne Kabel, ohne SPS-Eingriff, ohne IT-Projekt: dezentrale Assets einfach anbinden | autosen

www.iotusecase.com #LteM #Sensorik #RemoteMonitoring In der 214. Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Dennis Jansen, Product Manager IIoT bei autosen. Im Fokus steht die Frage, wie Betreiber dezentrale Assets ins IIoT bringen – ohne Steuerungseingriff, ohne IT-Projekt, ohne Kabel. Zusammenfassung autosens Antwort ist das minion: ein modulares Sensorsystem mit integriertem Mobilfunk-Gateway und Batterie, das ohne bestehende Infrastruktur auskommt. Der Ansatz dahinter ist bewusst radikal einfach – Steuerungen werden nicht angefasst, stattdessen werden neuralgische Punkte im Feld überwacht. Vom Auspacken bis zu den ersten Daten in der Cloud: maximal 30 Minuten. Dennis Jansen erklärt, warum autosen dabei auf LTE-M und NB-IoT setzt, statt auf 5G – Energieeffizienz schlägt Bandbreite, wenn eine Batterie zwei Jahre halten soll. Und er macht deutlich, für wen das System gedacht ist: nicht für den Endanwender selbst, sondern für Systemhersteller, die ihren Kunden eigenständige IoT-Services anbieten wollen – etwa bei Industrieventilatoren, Füllstandsüberwachung oder Zugangskontrolle. Das nimmst du mit – Plug & Play im IIoT ist möglich, wenn man Steuerungen weglässt und eigenständige Devices für neuralgische Punkte einsetzt – LTE-M und NB-IoT schlagen 5G für batteriebetriebene Sensoren, weil Energieeffizienz vor Bandbreite kommt – Das minion-System richtet sich an Systemhersteller als Enabler – nicht direkt an Endkunden ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Dennis (https://www.linkedin.com/in/dennis-jansen-82246799/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

Sommerpause 2026

Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#213 | Direct Air Capture: Der Weg vom Pilot zur autonomen Industrieanlage | ifm & Greenlyte

www.iotusecase.com #DirectAirCapture #DAC #IIoT In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Peter mit Niklas Friederichsen, Co-Gründer und CTO/CPO bei Greenlyte, und Christoph Schneider, Vice President Produktmanagement bei ifm. Im Fokus steht die Frage, wie Direct-Air-Capture-Anlagen den Sprung vom Laborprototyp zur autonomen, industrietauglichen Anlage schaffen – und welche Rolle dabei dynamische Prozessführung, IO-Link-Sensorik und der Remote-Zugriff über moneo spielen. Folge 208 auf einen Blick (und Klick): (11:04) Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus Podcast Zusammenfassung Greenlyte überführt eine im Labor validierte Direct-Air-Capture-Technologie in real betreibbare und skalierbare Anlagen: von einer 50 t CO₂/Jahr Pilotanlage in Duisburg hin zu einer 1.500 t/Jahr First-of-a-Kind-Anlage in Marl. Die zentrale Herausforderung liegt dabei weniger in der Grundidee als in der industriellen Umsetzung: schwankende Verfügbarkeit erneuerbarer Energien, variable Umgebungsbedingungen wie Temperatur und Luftfeuchte sowie die Kombination aus klassischer Prozesstechnik (Absorption) und Elektrochemie (Desorption) erfordern eine hochdynamische und robuste Prozessführung. Hinzu kommen praktische Themen wie zuverlässige Sensorik unter realen Bedingungen – etwa bei Schaumbildung oder sich verändernden Medien. Technisch setzt Greenlyte früh auf durchgängige Digitalisierung: Sensoren werden über IO-Link angebunden, Parametrierung und Datenzugriff erfolgen remote über ifm moneo. Zentrale Datenhaltung, Wiederverwendung von Parametersätzen sowie strukturierte FAT/SAT-Tests ermöglichen eine schnelle Iteration und Skalierung. Ergänzt wird dies durch ein revisionsgeführtes Anlagen-Engineering, bei dem Änderungen häufig über Konfiguration statt über Code-Rollouts umgesetzt werden. Der Use Case zeigt, wie standardisierte Feldanbindung, Remote-Service und datenbasierte Optimierung helfen, Prototypen schneller zu stabilisieren, Inbetriebnahmen zu beschleunigen und die Grundlage für skalierbare Anlagenflotten sowie effiziente Wartungsstrategien zu schaffen. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Niklas (https://www.linkedin.com/in/dr-niklas-friederichsen-8290849b/) Christoph (https://www.linkedin.com/in/christoph-schneider-18872627/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#212 | Statt Laptop am Schaltschrank: Device- & App-Management in der OT | Portainer.io & WAGO

www.iotusecase.com #IIoT #EdgeComputing #Container In dieser Live-Episode von der Hannover Messe spricht Gastgeber Peter Schopf mit Tobias Mühlnikel von Portainer.io und Jürgen Pfeifer von WAGO. Im Mittelpunkt steht die Frage, wie Containerisierung im OT- und Shopfloor-Umfeld ein skalierbares Device- und Applikationsmanagement ermöglicht – von der Auswahl geeigneter Images über Edge-Deployment bis hin zu CI/CD, Rollbacks, Edge-KI und Datenhoheit. Podcast Zusammenfassung Live von der Hannover Messe diskutieren Portainer.io und WAGO, wie containerbasiertes Applikations- und Device-Management den Betrieb und das Skalieren von Edge-Lösungen im Shopfloor praxistauglich macht. Im Zentrum steht der Transfer bewährter IT-Prinzipien in die OT – ohne dass OT-Teams zu IT-Spezialisten werden müssen. Dabei treffen moderne Ansätze auf typische Herausforderungen: heterogene Hardware (32/64-Bit-Architekturen), fehlende Transparenz über Softwarestände („goldener USB-Stick“), aufwendige 1:1-Updates direkt am Schaltschrank sowie der organisatorische IT/OT-Gap mit klar definierten Update-Fenstern. Die technische Grundlage bilden standardisierte Docker-Images (z. B. Node-RED), die über eine Control Plane verteilt und per CI/CD automatisiert ausgerollt werden. Rollbacks ermöglichen es, jederzeit auf stabile Versionen zurückzugehen. Auch KI-Anwendungen lassen sich nahtlos integrieren: Edge-Hardware kann gezielt mit KI-Beschleunigern erweitert werden, um etwa Anomalie-Erkennung oder spezialisierte, kleinere LLMs (Tiny-LLMs) direkt vor Ort auszuführen – ohne den containerbasierten Stack zu verlassen. Für Entscheider ergibt sich ein klarer Mehrwert: schnellere und planbare Deployments über verteilte Standorte, reduzierte Reise- und Integrationskosten, höhere Modularität durch zusätzliche Container sowie mehr Unabhängigkeit von einzelnen Anbietern. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Tobias (https://www.linkedin.com/in/tobias-mue/?locale=de) Jürgen (https://www.linkedin.com/in/juergen-pfeifer/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#211 | Sensoren netzwerkfähig machen: Shopfloor-Daten direkt in die IT | Perinet

www.iotusecase.com #Shopfloor #IndustrialIoT #SinglePairEthernet In dieser Live-Folge direkt von der Hannover Messe spricht Gastgeber Dr. Peter Schopf mit Karsten Walther, Geschäftsführer von Perinet, und Georg Bassenge, Chief Sales Officer bei Perinet. Im Fokus steht die Frage, wie sich Shopfloor-Daten durchgängig und effizient bis in MES- und IT-Systeme übertragen lassen. Dabei geht es unter anderem um ereignisbasierte Kommunikation, netzwerkfähige Sensoren, den Einsatz von Single Pair Ethernet sowie Retrofit-Ansätze im Brownfield. Podcast Zusammenfassung Viele IIoT-Projekte scheitern nicht an KI oder Analytics, sondern am Zugang zu Shopfloor-Daten. Gerade in heterogenen Bestandsanlagen gelangen Daten oft nur mit hohem Engineering-Aufwand in IT-Systeme. Ursachen sind unter anderem mehrstufige OT-Architekturen, zyklische Feldbus-Kommunikation sowie unstrukturierte Rohdaten ohne ausreichende Semantik. Schon kleine Änderungen an Sensoren, etwa bei Messbereichen, können dazu führen, dass Daten ohne Kontext schwer interpretierbar sind und aufwendig normalisiert werden müssen. Perinet adressiert dieses Problem, indem Sensoren und Aktoren direkt netzwerkfähig werden. Relevante Informationen werden ereignisbasiert und parallel zur bestehenden SPS-Kommunikation per IP in die IT übertragen. Technologische Grundlage ist unter anderem Single Pair Ethernet, das Ethernet bis ins Feldgerät bringt und Retrofit in bestehenden Anlagen ermöglicht – ohne zusätzliche Infrastruktur wie neue Schaltschränke. Das Ergebnis ist ein schlanker Datenpfad mit geringerem Integrationsaufwand, reduzierter Datenlast und deutlich höherer Datenqualität. Dadurch werden Anwendungen wie KI, OEE oder Condition Monitoring erst effizient umsetzbar – inklusive Security-Anforderungen im Kontext des EU Cyber Resilience Act. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Georg (https://www.linkedin.com/in/bassenge/) Karsten (https://www.linkedin.com/in/karsten-walther-395822365/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#210 | Produktdigitalisierung für OEMs: komplexe Feldprodukte modular entwickeln | ML!PA

www.iotusecase.com #OEM #EdgeComputing #FunctionalSafety In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Tobias Maier, CEO der ML!PA Consulting GmbH, und Mirko Spitalny, Teamlead Hardware Development bei ML!PA, über die Digitalisierung von Maschinen und Fahrzeugen im Feld. Im Fokus steht, wie OEMs robuste, energieautarke und sicherheitskritische IoT-Systeme für ihre Produkte umsetzen – von Energy Harvesting und Funk in Metallumgebungen bis zu Lifecycle-Management, Datensouveränität und langfristigem Betrieb. Folge 210 auf einen Blick (und Klick): (07:52) Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus Podcast Zusammenfassung OEMs wollen Maschinen und Fahrzeuge im Feld digitalisieren und dabei Funktionen zuverlässig betreiben, obwohl die Geräte oft nur selten physisch erreichbar sind. Im Podcast berichten Tobias Maier und Mirko Spitalny am Beispiel des „digitalen Güterzugs“ mit Knorr-Bremse, wie aus ersten Prototypen robuste IoT-Produkte werden. Im Zentrum stehen drei wiederkehrende Herausforderungen: eine fehlende bzw. nicht planbare Energieversorgung, zuverlässige Datenübertragung in anspruchsvollen Umgebungen mit viel Metall sowie die Ruggedization des Produkts für den Feldeinsatz. Um das zu lösen, wird ein energieautarkes Edge-System mit Solarzellen und Batterien aufgebaut. Für den sicherheitskritischen digitalen Bremstest kommt eine Waggon-zu-Waggon-Funkvernetzung im Sub-Gigahertz-Bereich zum Einsatz, während LTE ergänzend und nur zeitweise für Funktionen wie Firmware-Upgrades oder Positionsübermittlung genutzt wird. Basis dafür ist ein modularer IoT-Baukasten mit wiederverwendbaren Hardware- und Softwaremodulen, etwa für Energy Harvesting, Batteriesysteme, BLE zur Inbetriebnahme, Funkkommunikation und Device-Management. Für IT/OT-Entscheider zeigt die Folge, wie sich Entwicklungsaufwand reduzieren, Iterationen beschleunigen und digitale Produkte über lange Lebenszyklen souverän betreiben lassen. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Mirko (https://www.linkedin.com/in/mirko-spitalny-9428a7367/) Tobias (https://www.linkedin.com/in/mlpatobiasmaier/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

Trailer

Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#209 | Hochwasser früher erkennen mit Radar und NB-IoT | Endress+Hauser

www.iotusecase.com #Frühwarnsystem #IoT #Sensorik 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. Podcast 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. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Felix (https://www.linkedin.com/in/felix-brühl-698178237/) Success Story: Frühalarmierung bei Hochwasser (https://www.de.endress.com/en/endress-hauser-group/Case-studies-application-notes/bad-münstereifel-dynamischer-pegel) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#208 | IO-Link in der Fertigung: Condition Monitoring und digitale Dienste | in.hub & nass magnet

www.iotusecase.com #IOLink #ConditionMonitoring #PredictiveMaintenance In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Oliver Salo, Senior Partner bei in.hub, und Zoltán Ziegler, Vertriebsleiter bei nass magnet. Im Fokus: Wie IO-Link-Daten über Master und Edge in eine belastbare Datenpipeline für Condition Monitoring, Predictive Maintenance und KI-basierte Anomalieerkennung überführt werden. Folge 208 auf einen Blick (und Klick): (05:32) Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus (08:24) Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien (23:54) Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen Podcast Zusammenfassung In vielen Anlagen sind IO-Link-fähige Sensoren und Aktoren zwar verbaut, genutzt werden aber oft nur Schalt- und Analogausgänge; Diagnose- und Zustandsdaten bleiben unerschlossen. In Projekten scheitert die Wertschöpfung weniger an der Technik als an unklaren Zielen (z. B. Alarmierung, Reports, OEE, Energie) und daran, früh die richtigen Stakeholder aus OT und IT an einen Tisch zu bekommen. nass magnet adressiert das Feldniveau mit einem IO-Link-fähigen Smart Connector (Stecker) für Magnetspulen und Ventile sowie einem Ethernet-Master, der Messdaten IoT-tauglich weiterreicht. in.hub integriert den Master in SIINEOS: Geräte und IO-Link-Devices lassen sich ohne Programmierung konfigurieren, Daten werden normiert, im Edge gespeichert und über Services wie Dashboards, Alarmierung sowie Cloud- und SQL-Anbindungen bereitgestellt. IODD-Interpretation und strukturierte Übergabe (z. B. via OPC UA/MQTT) unterstützen die Semantik in Richtung IT-Welt. So entstehen schnellere Retrofit-Projekte, geringere Steuerungslast und eine skalierbare Datenbasis für Condition Monitoring sowie OEE- und Energieanalysen. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Oliver (https://www.linkedin.com/in/oliver-salo-007808197/) Zoltán (https://www.linkedin.com/in/zolt%C3%A1n-ziegler-142938a2/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#207 | Digitaler Produktpass: Produktdaten mit ECLASS und AAS bereitstellen | Neoception & WAGO

www.iotusecase.com #DigitalProductPassport #DPP #AssetAdministrationShell In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Thorsten Kroke (ECLASS e.V.), Adrian Grüner (Neoception) und Simone Brinkmann-Thewes (WAGO) darüber, wie ECLASS-Semantik und die Asset Administration Shell (AAS) Produktdaten so standardisieren, dass sie für den Digital Product Passport (DPP) und für interoperablen Datenaustausch wiederverwendbar werden. Folge 207 auf einen Blick (und Klick): (09:26) Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus (29:46) Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen Podcast Zusammenfassung Viele Industrieunternehmen müssen Produktdaten für Einkauf, Engineering und Service über mehrere Systeme (ERP/PLM/PIM) hinweg bereitstellen – künftig zusätzlich im Kontext des Digitalen Produktpasses (Digital Product Passport, DPP) der EU. Im Podcast wird gezeigt, wie fehlende Semantik und uneinheitliche Begriffe (z. B. „Höhe“ vs. „Tiefe“ je nach CAD/CAE-Kontext) zu Interpretationsaufwand, Fehlern und manueller Nacharbeit führen. Als Ansatz dienen standardisierte Datencontainer und eindeutige Merkmalsdefinitionen: Die Asset Administration Shell (AAS) strukturiert den Austausch, ECLASS liefert die Semantik für Klassifikation und Merkmale. WAGO nutzt gemeinsam mit Neoception ein Mapping von Quellsystemdaten auf ECLASS (Advanced), um Informationen konsistent bereitzustellen und perspektivisch in verschiedene Senken (u. a. CAD-Portale, Website, DPP) auszuleiten. Für IT/OT-Entscheider entsteht so ein skalierbarer Weg, Integrationskosten zu senken, Datensouveränität zu behalten und regulatorische Anforderungen mit wiederverwendbaren Datenbausteinen zu erfüllen. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Thorsten (https://www.linkedin.com/in/thorsten-kroke-650500196/) Adrian (https://www.linkedin.com/in/adrian-grüner-46418a99/) Simone (https://www.linkedin.com/in/simone-brinkmann-tewes-82731a172/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#206 | Von Condition Monitoring zum proaktiven Service im Maschinenbau | IXON & aiXbrain & SPALECK

www.iotusecase.com #PredictiveMaintenance #ConditionMonitoring #Maschinenbau In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Lukas Schattenberg, Vertriebsleiter bei IXON, Alexander Engels, CEO von aiXbrain, und Jörg Halladin, Entwicklungsleiter bei SPALECK. Im Fokus: Wie Maschinenbauer mit IoT-Plattform, Edge-Anbindung und integrierter KI ein skalierbares Condition-Monitoring- und Predictive-Maintenance-Serviceangebot für Betreiber umsetzen. Folge 206 auf einen Blick (und Klick): (08:46) Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus (15:22) Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen (24:26) Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen Podcast Zusammenfassung SPALECK, ein Maschinenbauer für Schwingförderer und Schwingsiebe in Recycling-, Chemie- und Lebensmittelanlagen, baut Condition Monitoring in seine langlebigen Maschinen ein, um Stillstände in verketteten Prozesslinien zu vermeiden. Die Herausforderung lag weniger in der Datenerfassung als in der Reaktionsfähigkeit im Betrieb: lokale Ampelanzeigen wurden übersehen, und starre Grenzwerte reichen bei wechselnden Produkten und Betriebsweisen nicht für verlässliche Vorwarnungen. Um aus Maschinendaten rechtzeitig Serviceentscheidungen abzuleiten, wurden Maschinen über IXON per Edge-Router schnell angebunden und Daten in der Cloud verfügbar gemacht. aiXbrain ergänzte als integrierte App (Dataray) ML-Modelle für Predictive Maintenance – inklusive Labeling in der Plattform, Modellvergleich (False Positives/Negatives) und automatisiertem Nachtrainieren. Die Lösung bleibt bewusst offen über Schnittstellen wie OPC UA, PROFINET und API, sodass Betreiber Daten in eigene Werk-Dashboards integrieren können. Nutzen für IT/OT-Entscheider: schneller Rollout, sichere Remote-Zugriffe, skalierbare Datenpipeline, frühere Fehlererkennung (mehrere Tage Vorlauf) und servicefähige Prozesse mit klaren Alarmen statt zusätzlichem Tool-Overhead. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Alexander (https://www.linkedin.com/in/alexander-engels-phd/) Jörg (https://www.linkedin.com/in/halladin-joerg-334156115/) Lukas (https://www.linkedin.com/in/lukasschattenberg/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten

#205 | IoT-Low-Code auf dem Shopfloor: Maschinendaten per OPC UA ins ERP | Peakboard & Giesser

www.iotusecase.com #IIoT #Shopfloor #LowCode In dieser Episode des IoT Use Case Podcasts spricht Gastgeber Dr. Peter Schopf mit Thilo Brosinsky, Entwicklungsleiter bei der Peakboard GmbH, und Björn Mutschler, Produktionsleiter bei der Johannes Giesser Messerfabrik GmbH. Thema: Wie eine dezentrale IoT-Low-Code-Plattform Shopfloor-Apps von der Maschinenintegration bis zum Energie- und Produktionsmanagement schrittweise skaliert. Folge 205 auf einen Blick (und Klick): (05:59) Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus Podcast Zusammenfassung GIESSER Messer startete mit einer einfachen Shopfloor-Visualisierung, um Produktionskennzahlen erstmals tagesaktuell und direkt an der Maschine sichtbar zu machen. Die zentrale Herausforderung: geringe Akzeptanz, heterogene Datenquellen (ERP, Maschinen, Energie), fehlende Standards bei Maschinenschnittstellen und die Notwendigkeit, produktionskritische Anzeigen ausfallsicher zu betreiben – ohne Großprojekt oder Cloud-Zwang. Umgesetzt wurde dies mit einer dezentralen IoT-/Low-Code-Architektur: Anwendungen werden im Peakboard Designer per Drag-and-drop (bei Bedarf mit Scripting) erstellt, Daten über OPC UA, Modbus, SQL/ERP angebunden und auf lokale Peakboard Boxen verteilt; der Peakboard Hub dient optional zur zentralen Verwaltung, ohne dass bei Ausfall der Zentrale die Shopfloor-Logik stoppt. Eingesetzt werden u. a. MDE/BDE, Downtime-Tracking, papierarme Auftragssteuerung (ziehende Fertigung) sowie Energiemonitoring bis hin zu Lastmanagement. Für IT/OT-Entscheider zeigt der Use Case: iteratives Skalieren mit geringem Startaufwand, schnelle Integration bestehender OT/IT-Systeme, höhere Transparenz und robuste Betriebsfähigkeit im Werk. ----- Relevante Folgenlinks: Peter (https://www.linkedin.com/in/peter-schopf/) Thilo (https://www.linkedin.com/in/thilo-brosinsky-39870766/) Jetzt IoT Use Case auf LinkedIn folgen 1x monatlich IoT Use Case Update erhalten