IoT Streaming: Sensordaten in Echtzeit verarbeiten

IoT Streaming ist der kontinuierliche Fluss von Telemetriedaten aus Sensoren, Maschinen, Fahrzeugen und vernetzten Produkten in Systeme, die diese Daten in dem Moment verarbeiten, in dem sie eintreffen. Statt darauf zu warten, dass Geräte Dateien in Batches hochladen, filtert und aggregiert eine Pipeline für IoT Streaming jeden Messwert innerhalb von Sekunden und reagiert darauf. Dieser Leitfaden behandelt Geräte- und Sensordaten, nicht Live-Video von IoT-Kameras.

Was ist IoT Streaming?

Die meisten frühen IoT-Projekte erfassten Daten in Batches. Geräte pufferten Messwerte und luden sie stündlich oder jede Nacht hoch, und Analysten sahen sich die Ergebnisse am nächsten Tag an. Für das Reporting funktioniert das, aber es versagt, wenn ein Kompressor überhitzt, sich ein Kühllastwagen erwärmt oder ein Smart Meter plötzlich einen Ausschlag zeigt. IoT Streaming behandelt jeden Messwert als Event und leitet ihn durch eine Pipeline, die reagieren kann, solange die Situation noch andauert.

Was IoT-Daten besonders macht

IoT-Daten sind schwerer zu verarbeiten als die meisten Event Streams. Eine einzelne Geräteflotte kann Millionen kleiner Nachrichten pro Minute erzeugen, jede mit wenigen Bytes Telemetrie. Geräte verlieren die Verbindung und senden dann die gepufferten Messwerte mehrerer Stunden auf einmal, sodass Events verspätet und in falscher Reihenfolge eintreffen. Auch die Payload-Formate verändern sich mit der Zeit, weil in einer Flotte selten nur eine Firmware-Version läuft und ältere Geräte noch lange ältere Schemas senden, nachdem neue ausgeliefert wurden.

Diese Eigenschaften prägen jede weitere Design-Entscheidung. Eine Pipeline, die sie ignoriert, liefert Dashboards, die so lange korrekt aussehen, bis der erste Netzwerkausfall oder das erste Firmware-Rollout kommt.

So funktioniert IoT Streaming

Eine typische Architektur für IoT Streaming hat vier Stufen, und jede löst einen anderen Teil des Problems. Die Grundlagen der Verarbeitungsstufe erklärt unser Leitfaden zu Stream Processing.

Geräte und Gateways

Sensoren und Geräte veröffentlichen Messwerte direkt oder über ein lokales Gateway. MQTT ist in dieser Stufe das gängigste Protokoll, weil es schlank ist, auf ressourcenbeschränkter Hardware läuft und unzuverlässige Netzwerke toleriert. Version 5.0 von MQTT ist seit dem 7. März 2019 ein OASIS-Standard. In industriellen Umgebungen übersetzen Gateways Maschinendaten oft aus OPC UA oder älteren Feldbusprotokollen, bevor sie sie veröffentlichen.

Vom MQTT Broker zu Apache Kafka

Ein MQTT Broker verwaltet die Geräteverbindungen, deren Zahl in die Millionen gehen kann. Er ist nicht dafür gebaut, lange Historien zu speichern oder viele nachgelagerte Consumer unabhängig voneinander zu versorgen. Deshalb verbinden die meisten Architekturen ihn mit Apache Kafka, entweder über einen Kafka Connect MQTT Source Connector oder über eine Broker-seitige Kafka-Integration. Kafka speichert jeden Messwert dauerhaft, ermöglicht neuen Anwendungen ein Replay der Historie und entkoppelt die Gerätekonnektivität von den Systemen, die die Daten nutzen.

Stream Processing

Eine Stream Processing Engine liest aus Kafka und übernimmt die Arbeit, die aus rohen Telemetriedaten nutzbare Signale macht. Apache Flink ist für IoT eine häufige Wahl, weil es Event Time, State und verspätete Daten nativ verarbeitet. Kafka Streams passt, wenn die Verarbeitungslogik in einem Microservice liegt, und mit Flink SQL können Datenteams dieselbe Logik als kontinuierliche Abfragen schreiben.

Speicherung und Bereitstellung

Verarbeitete Daten landen dort, wo Menschen und Anwendungen sie nutzen können. Zeitreihendatenbanken versorgen operative Dashboards und liefern die jüngste Historie, Lakehouse-Tabellen halten den langfristigen Datenbestand für Analysen und Modelltraining vor und Alerting-Tools benachrichtigen das Betriebspersonal oder lösen automatisierte Aktionen aus. Unser Leitfaden zu Streaming Analytics zeigt, wie Teams aus diesen Ergebnissen Entscheidungen ableiten.

So verarbeiten Sie Streaming-Daten von IoT-Geräten

In der Verarbeitungsstufe entscheidet sich, ob IoT-Pipelines funktionieren oder scheitern. Fünf Muster tauchen in fast jedem Projekt auf.

Payloads normalisieren und anreichern

Die erste Aufgabe besteht darin, den Payload jedes Geräts unabhängig von seiner Firmware-Version in ein einheitliches, kanonisches Format zu überführen. Eine Schema Registry und versionierte Schemas machen das beherrschbar. Anschliessend reichert die Pipeline jeden Messwert mit Gerätemetadaten wie Standort, Asset-Typ oder Kunde an. Dazu verknüpft sie den Stream per Join mit einer Referenztabelle, die selbst laufend aus der Geräte-Registry aktualisiert wird.

Fensteraggregation und Downsampling

Nur wenige Consumer benötigen jeden einzelnen Rohmesswert. Tumbling oder Hopping Windows verdichten sekündliche Telemetrie zu minütlichen Durchschnitts-, Minimal- und Maximalwerten pro Gerät. Das senkt die Speicherkosten und macht Dashboards schneller. Die Rohdaten können trotzdem für Audits und Modelltraining in einen günstigen Langzeitspeicher fliessen.

Event Time, Watermarks und verspätete Sensordaten

Wenn sich ein Gerät nach einem Ausfall wieder verbindet, beschreiben seine Messwerte die Vergangenheit, nicht den Moment ihres Eintreffens. Die Verarbeitung nach Event Time, also nach dem Zeitstempel, den das Gerät erfasst hat, hält Aggregate korrekt. Flink nutzt Watermarks, um zu verfolgen, wie weit die Event Time fortgeschritten ist. So weiss ein Operator, wann ein Fenster geschlossen werden kann, auch wenn Datensätze in falscher Reihenfolge eingetroffen sind. Teams legen eine zulässige Verspätung (Allowed Lateness) fest und leiten alles, was noch später kommt, zur Korrektur in einen Side Output.

Gerätezustand und Digital Twins

Viele Fragen hängen von der Historie eines einzelnen Geräts ab, etwa ob eine Temperatur 10 Minuten in Folge gestiegen ist oder ob eine Tür länger als üblich offen steht. Keyed State im Stream Processor hält das aktuelle Bild jedes Geräts fest. Zusammengenommen bilden diese Zustände pro Gerät einen Digital Twin der Flotte in Echtzeit, den Anwendungen abfragen können.

Anomalieerkennung und Alerting

Das letzte Muster vergleicht Live-Messwerte mit Schwellenwerten, Regeln oder Modellvorhersagen und löst Alerts aus, wenn sie voneinander abweichen. Einfache Regeln erkennen offensichtliche Ausfälle, während die Mustererkennung über mehrere Events hinweg schleichende Probleme aufdeckt, etwa ein Lager, das jeden Tag etwas stärker vibriert. Alerts sollten genug Kontext mitliefern, etwa Gerät, Standort und die letzten Messwerte, damit das Betriebspersonal handeln kann, ohne ein weiteres System öffnen zu müssen.

Edge- oder Cloud-Verarbeitung

Nicht jede Berechnung gehört in die Cloud. Die Entscheidung hängt von Latenz und Bandbreite ab und davon, was passiert, wenn die Verbindung abbricht.

Die meisten Produktivsysteme kombinieren beides. Die Edge filtert, führt Downsampling durch und übernimmt zeitkritische Steuerungsaufgaben. Die Cloud kümmert sich um Anreicherung, flottenweite Korrelation und Historie.

MQTT vs. Kafka für IoT

MQTT und Kafka werden oft miteinander verglichen, erfüllen aber unterschiedliche Aufgaben und arbeiten meist zusammen.

Anwendungsfälle für IoT Streaming

In Flottenmanagement und Logistik streamen Fahrzeuge Standort, Motordaten und Ladungstemperatur. Die Pipeline meldet Verzögerungen, Routenabweichungen oder Unterbrechungen der Kühlkette, solange die Fahrerinnen und Fahrer noch reagieren können. In der Energie- und Versorgungswirtschaft streamen Smart Meter und Netzsensoren Verbrauchs- und Spannungswerte, die in Lastprognosen und die Erkennung von Ausfällen einfliessen.

Smart Buildings streamen Belegungs-, Luftqualitäts- und Anlagendaten, um Heizung und Kühlung anzupassen und Wartungen zu planen. Hersteller vernetzter Produkte wie Haushaltsgeräte, Heizsysteme und Medizingeräte nutzen dieselbe Pipeline, um installierte Geräte zu überwachen, Service-Einsätze zu planen und zu verstehen, wie Kunden ihre Produkte nutzen. Anwendungsfälle aus der Produktion beschreibt unser Leitfaden zu Data Streaming in der Fertigung.

Abgekündigte IoT-Plattformen, die Sie einplanen sollten

Mehrere gemanagte IoT-Services, die ältere Architekturleitfäden empfehlen, sind bereits eingestellt oder werden eingestellt. Google Cloud IoT Core wurde am 16. August 2023 eingestellt. AWS IoT Analytics nahm ab dem 24. Juli 2024 keine Neukunden mehr an und erreichte am 15. Dezember 2025 das Ende des Supports. Microsoft hat angekündigt, Azure IoT Central am 20. September 2029 einzustellen, und verweist Kunden auf Azure IoT Hub, Device Provisioning Service und Azure Device Registry sowie für Analysen auf Microsoft Fabric.

Diese Abkündigungen sprechen deutlich dafür, den Streaming-Kern portabel zu halten. Wenn die Gerätekonnektivität über Standard-MQTT läuft und das Event-Backbone auf Kafka basiert, betrifft ein Wechsel des Cloud-Service nur eine Ebene statt der gesamten Pipeline.

Herausforderungen beim IoT Streaming

Projekte für IoT Streaming stossen meist an denselben Stellen auf Probleme:

• Geräteidentität und Sicherheit, einschliesslich der Zertifikatsrotation über grosse Flotten hinweg
• Schemaänderungen über Firmware-Versionen hinweg, die bei nachgelagerten Consumern zu Fehlern führen
• Datenfluten, wenn sich nach einem Ausfall Tausende Geräte gleichzeitig wieder verbinden
• Aufbewahrungskosten für rohe Telemetriedaten, die nach der ersten Woche niemand mehr liest
• End-to-End-Observability, damit Teams ein stummes Gerät von einer defekten Pipeline unterscheiden können

Jedes dieser Probleme lässt sich in der Konzeptionsphase leichter lösen als dann, wenn die Flotte bereits gewachsen ist.

Häufige Fragen

Ist IoT Streaming dasselbe wie IoT Video Streaming?

Nein. IoT Streaming bezieht sich in der Regel auf Telemetrie: kleine, häufige Messwerte wie Temperatur, Standort oder Vibration. IoT Video Streaming überträgt kontinuierlich Kamerabilder und setzt auf andere Protokolle und eine andere Infrastruktur. Manche Pipelines kombinieren beides, etwa indem sie Events aus der Videoanalyse zusammen mit Sensordaten streamen.

Wie lassen sich verspätete oder ungeordnete Sensordaten verarbeiten?

Verarbeiten Sie die Daten nach Event Time, also nach dem Zeitstempel, den das Gerät erfasst hat, und nicht nach der Ankunftszeit. Ein Stream Processor wie Apache Flink nutzt Watermarks, um zu entscheiden, wann ein Zeitfenster vollständig ist, und eine Allowed-Lateness-Einstellung hält Fenster für Nachzügler offen. Messwerte, die noch später eintreffen, können in einen separaten Stream fliessen, der gespeicherte Ergebnisse korrigiert.

Welche Stream Processing Engine eignet sich am besten für IoT-Daten?

Für die meisten IoT-Workloads ist Apache Flink eine gute Standardwahl, weil es Event Time, grossen Keyed State und verspätete Daten zuverlässig verarbeitet. Kafka Streams eignet sich für kleinere Pipelines, die in Microservices eingebettet sind, und gemanagte Flink-Services nehmen Ihnen den Betrieb der Cluster ab. Die richtige Wahl hängt von der Grösse des State, den Kompetenzen im Team und davon ab, wo der Rest Ihrer Plattform läuft.

IoT Streaming funktioniert, wenn jede Ebene ihre eigene Aufgabe erfüllt

Zuverlässiges IoT Streaming entsteht durch eine klare Arbeitsteilung. MQTT verbindet Geräte über unzuverlässige Netzwerke, Kafka speichert und verteilt jeden Messwert und ein Stream Processor wendet Event Time, State und Anreicherung an, bevor die Ergebnisse Dashboards, Alerts und den Langzeitspeicher erreichen. Wer von Anfang an für verspätete Daten, Schemaänderungen und Reconnect-Stürme plant, hält die Pipeline korrekt, während die Flotte wächst.

Mimacom konzipiert, entwickelt und betreibt Pipelines für IoT Streaming auf IBM Confluent und liefert produktive Streaming-Lösungen in Fertigung, Transport und Handel. Wir sind seit 2017 Confluent Partner und seit 2021 offizieller Confluent Training Partner. Seit der Übernahme von Confluent durch IBM arbeiten wir als IBM Partner mit IBM Confluent. Für einen deutschen Heizungshersteller haben wir eine IoT-Datenplattform auf eine cloud-native Kafka-Umgebung in Azure migriert. Unsere Confluent Beratungsleistungen umfassen Architektur, Implementierung und Betrieb, und unser Whitepaper „Das Data-Streaming-Fundament für KI“ erklärt, wie dasselbe Fundament Analytics und KI unterstützt.