Same-same but different: Datenanalysen in IoT-Projekten

Bei MaibornWolff arbeiten wir kontinuierlich in IoT-Projekten für Kunden aus vielen verschiedenen Branchen. Alle diese Projekte haben gemeinsam, dass man Erkenntnisse auf Grundlage der Daten gewinnen möchte, die von IoT-Geräten und Sensoren erzeugt werden. Damit sind im Grunde alle IoT-Projekte auch Datenanalyse-Projekte. Bei Datenanalysen ist es wichtig, dass man die Umgebung und die Daten, mit denen man arbeitet, versteht. In diesem Artikel beschreibe ich Aspekte von IoT-Projekten und IoT-Daten, um dieses Verständnis zu verbessern. Aus der Distanz betrachtet gibt es zwei Hauptaspekte, die IoT-Projekte von anderen Datenanalyseprojekten unterscheiden: (1) die Geräte und (2) die Daten. In den folgenden Abschnitten gehe ich auf Einzelheiten zu beiden Aspekten ein.

Die Geräte

Viele gleichzeitig angeschlossene Geräte

In den meisten IoT-Projekten gibt es eine große Anzahl von Geräten, die gleichzeitig an eine zentrale Kommunikationsinfrastruktur angeschlossen sind, typischerweise ein MQTT Message Broker Cluster. Der genaue Aufbau unterscheidet sich etwas zwischen IoT-Projekten im Industrie-Kontext und Projekten, bei denen die Endbenutzergeräte wie Autos oder Haushaltsgeräte direkt an das Backend angeschlossen sind.

Bei vielen industriellen IoT-Projekten sind es vielleicht nur ein paar hundert oder tausend Geräte oder Sensoren, die an ein Gateway oder eine Edge-Computing-Lösung angeschlossen sind. Dafür senden diese Geräte oder Sensoren Aktualisierungen mit einer hohen Frequenz, etwa alle paar Millisekunden (natürlich auch teilweise mit niedrigereren Frequenzen).

In Projekten mit Endbenutzergeräten gibt es normalerweise viel mehr Geräte mit stehenden TCP-Verbindungen, die Anzahl kann in die Millionen gehen. Diese Geräte senden allerdings weniger häufig Daten, in Sonderfällen maximal jede Sekunde oder alle paar Sekunden.

Bidirektionale Kommunikation

In IoT-Projekten muss man teilweise auch die im Rahmen der bidirektionalen Kommunikation von Backend-Diensten gesendeten Daten persistieren, um diese mit den von den Geräten gesendeten Daten zu Geschäftsobjekten zusammenfassen zu können, etwa zu einer Autofahrt oder dem Waschgang einer Waschmaschine. Dadurch werden weitergehende Analysen möglich. Sie müssen daher unter Umständen auch Daten persistieren, die nur über den Message Broker laufen und möglicherweise nicht in den Datenbanken der einzelnen Services gespeichert sind. Zudem ist es wichtig, das sie die originalen Rohnachrichten der Geräte persistieren und nicht nur die von anderen Services vorverarbeiteten Daten, da in den vorverarbeiteten Daten möglicherweise nicht mehr alle Informationen enthalten sind.

Unzuverlässige Netzwerke

In vielen IoT-Projekten werden Daten über relativ unzuverlässige Netzwerke wie Mobilfunknetze gesendet. Das bedeutet: Wir müssen damit rechnen, dass gesendete Daten verloren gehen können, mehrfach gesendet werden, verspätet ankommen (möglicherweise erst nach Tagen oder Monaten) oder sogar beschädigt werden.

Vielfalt in der Kombination von Hardware- und Software-Versionen

Besonders bei IoT-Projekten mit Endbenutzergeräten haben wir es oft mit einer großen Anzahl und Kombination verschiedener Hardware- und Softwareversionen zu tun. Selbst wenn wir Glück haben und alle Geräte kontinuierlich zu Software-Remote-Updates gezwungen werden können, gehen immer noch neue Geräte online, auf denen möglicherweise ab Werk ältere Softwareversionen vorinstalliert sind. Es kann auch sein, dass Geräte aus dem Service kommen, die noch ältere Software-Stände haben. Leider kann man nicht immer sicherstellen, dass sich alle Geräte selbst updaten. Beispielsweise kann die Software in Autos nicht aktualisiert werden, während jemand sie fährt oder wenn sie in Parkhäusern ohne Internetanschluss geparkt sind. Außerdem: Da der Endbenutzer diese Geräte besitzt, ist es normalerweise dem Besitzer/der Besitzerin überlassen, ob er oder sie Updates installieren möchte.

Das Hauptproblem bei den vielen möglichen Hardware- und Software-Versionen ist, dass diese in der Regel verschiedene Fehler und Eigenheiten haben, mit denen wir umgehen müssen. Die Komplexität steigt dabei durch die Anzahl der Kombinationsmöglichkeiten. Dies gilt nicht nur für die Versionen, die noch im Einsatz sind, sondern auch für alle historischen Kombinationen, die jemals im Feld waren. Diese müssen wir ebenfalls abdecken für den Fall, dass alte Daten neu verarbeitet werden müssen.

Die Daten

Kontinuierlicher Datenfluss

Sensoren und Geräte erzeugen einen kontinuierlichen Datenfluss. Die Daten bestehen normalerweise aus bestimmten Ereignissen (z.B. Start des Motors) oder zeitbasierten Aktualisierungen, die mit einer bestimmten Frequenz gesendet werden (z.B. Temperatur, die von einem Sensor gemessen wird). Für diese Art von Daten ist typischerweise eine Event-Verarbeitung mit Streaming-Technologien sinnvoll, so dass man auf Ereignisse reagieren und möglicherweise Machine-Learning-basierte Vorhersagen durchführen kann. Solange dabei nur Einzelnachrichten betrachtet werden, lässt sich diese Art Echtzeitverarbeitung auch mit “normalen” Services umsetzen, solange kein verteilter State gehalten werden muss.

Kleine Datenpakete, aber davon viele

Die oben beschriebenen Events und zeitbasierten Nachrichten sind in der Regel klein: oft kleiner als oder um 1kb (vorausgesetzt, sie sind in einem binären Format wie Google Protocol Buffers kodiert). Von diesen Nachrichten gibt es typischerweise aber eine große Menge. Die folgende Abbildung gibt eine ungefähre Vorstellung der Datenmenge, mit der wir es zu tun haben.

Teile im Datenpuzzle zusammenfügen

Die einzelnen Nachrichten, die von den IoT-Geräten gesendet werden, sind für sich allein oft nicht nützlich. Wie oben bereits erwähnt, werden sie für viele Analysen zu einer Art Geschäftsobjekt aggregiert, auf dem Analysen sinnvoll sind. Bei Fahrzeugen führt man zum Beispiel häufig Analysen für ganze Fahrten durch, die erst aus Ereignissen und zeitbasierten Meldungen, die während einer Fahrt auftreten, erzeugt werden müssen. Durch die oben erwähnten Fehlerquellen wegen der unzuverlässigen Netzwerke ist das ein wenig so, als müsste man ein Puzzle zusammensetzen, bei dem man noch nicht einmal weiß, wie das Zielbild aussehen wird.

Datenqualität ist noch schlechter als üblich

Die Erfahrung zeigt, dass die Qualität der Daten in IoT-Projekten oft sogar noch schlechter ist als das, was man von regulären Unternehmensdatenanalyseprojekten gewohnt ist. Ein Grund dafür sind die erwähnten Puzzle-Teile, die durch den Transport über unzuverlässige Netzwerke durcheinander geraten (MQTT garantiert die Nachrichtenreihenfolge, aber “davor und dahinter” kann viel passieren), verspätet eintreffen, beschädigt werden oder sogar verloren gehen. Ein anderer Grund: Die Daten aus den IoT-Geräten sind im Gegensatz zu vielen anderen Unternehmensdaten kein inhärenter Bestandteil irgendeiner Art von Geschäftstransaktion, die in irgendeiner Datenbank nach ACID-Prinzipien gespeichert weden. Diese Geschäftsobjekte oder Transaktionen müssen erst aus einzelnen Nachrichten erstellen werden, die nicht für diesen Zweck erstellt wurden. Die Qualität der Entwicklungsarbeit bei dieser Aggregation beeinflusst also die Datenqualität ganz direkt.

Edge Computing erforderlich

In den meisten Fällen produzieren die Sensoren in einem IoT-Projekt VIELE Daten. Dies gilt nicht nur für Projekte in Produktionskontexten, sondern zum Beispiel auch bei vernetzten Autos oder bei Haushaltsgeräten. Um eine Vorstellung über die Menge der Daten zu bekommen: Für Autos mit autonomen Fahrsensoren wird oft angegeben, dass ein einzelnes Fahrzeug bis zu 10 bis 20 TB Sensordaten pro Tag produziert. Natürlich wird die konkrete Menge pro Auto und Hersteller variieren, entscheidende ist hier aber die Größenordnung. Aufgrund der Datenmenge, die erzeugt wird, kann nicht einfach alles ins Backend übertragen werden – ganz egal, ob dieses in der Cloud oder On-Premise gehostet wird. Stattdessen gibt es meist eine gewisse gerätenahe Vorverarbeitung der Daten. In industriellen IoT-Anwenungen steht Ihnen vielleicht ein vollständiger Edge-Computing-Cluster zur Verfügung, während es in anderen IoT-Projekten eine Art Gateway geben kann, das die Vorverarbeitung übernehmen kann, etwa die Headunit in einem Auto.

Was kommt als nächstes?

In einem Folgebeitrag werde ich darüber sprechen, welche Entscheidungen auf der Grundlage der oben beschriebenen Merkmale getroffen werden können.

Dieser Artikel wurde veröffentlicht unter Medium.com. Folgen Sie Marc auf Twitter für weitere Einblicke.

---

Über den Autor