Suchen

Crate.io

Die vier Mythen des Datenmanagements im Internet der Dinge

| Autor/ Redakteur: Christian Lutz* / Julia Engelke

Intelligente Systeme im Internet of Things haben einen großen Appetit auf Daten – das ist eine allgemein bekannte Tatsache. Dennoch kursieren erstaunlich viele Mythen rund um das Datenmanagement im IoT. Wir räumen mit vier der Gängigsten auf.

Firmen zum Thema

Der Autor: Christian Lutz ist CEO & Co-Founder von Crate.io.
Der Autor: Christian Lutz ist CEO & Co-Founder von Crate.io.
( Bild: Crate.io )
  • Daten-Integration und -Analyse notwendig, um das Verhalten von „Dingen“ zu überwachen
  • IoT schafft neue Anforderungen an die Datenhaltung und -analyse

Pipelines von Sensordaten – oft Millionen von Messwerten pro Minute und Dutzende von Nachrichtenformaten– müssen in Echtzeit integriert und analysiert werden, um das Verhalten von „Dingen“ zu überwachen, vorherzusagen oder zu kontrollieren. Nur so können Unternehmen Korrekturen etwa bei Störungen in der Fertigung vornehmen, um Produktionsausfälle oder Ausschuss zu vermeiden.

Mythos #1: „Das ist kein neues Datenproblem“

Tatsächlich ist es ein gewaltiger Unterschied, ob eine Maschine im Stand-alone-Betrieb oder innerhalb einer vernetzten IoT-Lösung mit Remote-Überwachung arbeitet. Der Workload eines beispielhaften Herstellers von Kunststoffflaschen kann im Umfeld von Industrie 4.0 etwa so aussehen:

  • Unterschiedlichste Datenpunkte pro Flasche werden kontinuierlich abgegriffen und dabei über 900 verschiedene Sensor-Formate wie Flaschengewichte, fotografische Dimensionsmessungen, Werkzeugtemperaturen, Maschinenzustand oder Ähnliches an die Cloud, als zentrale Intelligenz, weitergeleitet.
  • Mittels Echtzeit-Dashboards werden zentrale Fertigungs- oder Maschinenexperten im „Mission Control Center“ über den aktuellen Status der Fertigungslinie informiert. Dabei stehen ihnen Funktionen wie Zeitreihenanalysen, Textsuche oder maschinelles Lernen zur Verfügung.
  • Beim Auftreten von Unregelmäßigkeiten oder Messwertüberschreitungen werden automatische als auch händische Alarme erzeugt und der verantwortliche Experte entscheidet über zu treffende Maßnahmen wie etwa das Einschalten der Remote-Hilfe zur Behebung oder die Benachrichtigung des Maschinenbedieners oder die Entsendung eines Produktspezialisten.

Ein häufiger Fehler liegt darin zu versuchen, die IoT-Infrastruktur auf Basis des bestehenden SQL-Datenbankstandards (z. B. Microsoft SQL Server, Oracle, et al.) zu implementieren. Dieser ist meist nicht in der Lage, die gestiegenen Anforderungen aufgrund der zu verarbeitenden Datenmengen zu erfüllen.

Im gegebenen Beispiel brauchte der SQL-Server zwischen zwei und vier Minuten, um die Daten zu analysieren und die Dashboards in der „Mission Control“ zu aktualisieren. Ziel des neuen Systems war es jedoch, Ineffizienzen in der Produktionslinie (z. B. steigende Fehlerraten) zu erkennen und innerhalb von fünf Minuten zu beseitigen. Die lange Abfragezeit war also inakzeptabel, denn die Daten müssen mit einer Verzögerung im Bereich von Millisekunden verfügbar sein – also praktisch in Echtzeit.

Darüber hinaus erstellte das Unternehmen 900 verschiedene Tabellen in SQL-Server – also eine pro Sensornachrichtenstrukturtyp. Das war zeitaufwendig, langsam und inflexibel. Es verzögerte den Entwicklungsplan um Wochen und trug zu der langsamen Abfrageleistung und schwierigen Skalierung bei.

Traditionelle SQL-Datenbanken sind zwar einfach zu bedienen, aber nicht für die Abfrage von Maschinendatenströmen in Echtzeit konzipiert, es sei denn, sie werden auf sehr teurer Hardware bereitgestellt, aber selbst da stößt man auf Limits.

Mythos #2: „IoT erfordert eine NoSQL-Datenbank“

Oft gehen Datenbank-Experten bei hohen Datenmengen und unstrukturierten Daten (JSON) – wie in Industrie-4.0-Umgebungen – davon aus, dass hier zwangsläufig ein NoSQL-Anwendungsfall vorliegt. NoSQL-Datenbanken wie Cassandra, Elasticsearch oder MongoDB können tatsächlich Maschinendaten-Anwendungsfälle verarbeiten; sie sind bekannt für ihre Skalierbarkeit und die Fähigkeit, mit komplexen und weitreichenden Datenstrukturen umzugehen.

Die Realität ist, dass NoSQL-Datenbanken in der Praxis schwieriger zu verwenden und zu integrieren sein können als SQL-basierte Lösungen. Es ist einfach so, dass solche Use Cases fast immer auch die Speicherung von relationalen Daten erfordern wie z. B. Topologien, Firmware-Infos, ERP- oder Artikeldaten. Das bedeutet, dass zwei Systeme parallel gefahren und synchronisiert werden müssen.

Die NoSQL-Datenbanken haben jeweils eigene Sprachen (CassandraQL, Mongo, Elastic …), und so führt jede NoSQL-Auswahl zu einer Art Lock-in, da proprietäre Sprachen und möglicherweise eigene Speicherformate die Arbeit mit den Daten erschweren – verglichen mit einer vollständig transparenten und offenen ANSI-SQL-Schnittstelle. Darüber hinaus werden erfahrene Entwickler für diese Sprachen benötigt. Aber vor allem entsteht der doppelte Aufwand für zwei DB-Systeme (Cloud-Kosten) und die Synchronisation (Entwicklungskosten und Cloud-Kosten).

Tatsächlich liegt eine Alternative darin, reine NoSQL-Datenbanken durch neuere und modernere SQL-basierte Lösungen wie die CrateDB zu ersetzen, die die Vertrautheit von ANSI SQL mit der Skalierbarkeit und Flexibilität von NoSQL kombinieren. Es besteht demnach keine Notwendigkeit, auf SQL zu verzichten, um die Anforderungen an Echtzeit-IoT zu erfüllen.

Mythos #3: „IoT ist ein Zeitreihen-Datenproblem“

In letzter Zeit sind spezialisierte Zeitreihendatenbanken (Timeseries) wie InfluxDB (auch eine NoSQL-DB) oder auch Azure Time Series Insights in Mode gekommen. Sie zeichnen sich dadurch aus, dass sie Daten schnell erfassen und über integrierte Tools verfügen, um Daten im Zeitverlauf grafisch darstellen, insbesondere intensive Datenströme, wie sie beispielsweise in intelligenten industriellen Systemen vorliegen. Ein häufig zu beobachtender Fehler ist die Auswahl einer Zeitreihen-Datenbank als IoT-Datenplattform.

Die Realität zeigt, dass Zeitreihen-Datenbanken oft in ihrer Funktionalität und Skalierbarkeit eingeschränkt sind. Sie zeigen zwar auf, wie sich Daten im Laufe der Zeit ändern, gefordert ist aber die Unterstützung eine Vielzahl von Analysen und Datenmodelländerungen, die es ermöglichen zu verstehen, worin die Ursachen für Auffälligkeiten bestehen.

Erforderlich ist das interaktive Arbeiten mit Daten – und zwar gleichzeitig, um Dutzende, Hunderte oder Tausende Nutzern oder Millionen von interaktiven Machine Learning Queries damit zu realisieren. All das muss möglich sein, während gleichzeitig in den Cluster geschrieben wird und massive Lesevorgänge ausgeführt werden.

Aber auch die Arbeit mit dynamischen Schemas zur Laufzeit ist hier wichtig. Beispielsweise müssen zu den nackten Sensordaten auch ERP-Daten, Qualitätsdaten oder Logistikdaten hinzugefügt werden, um anzuzeigen, ob Produktionsanomalien beispielsweise mit bestimmten Aufträgen verbunden sind oder auf Rohstoffe einzelner Lieferanten zurückzuführen sind. Das sollte einfach zu bewerkstelligen sein, indem zusätzliche Spalten zur Datenbank oder einer Tabelle zur Laufzeit hinzugefügt werden; in der Tat erfordern Datenmodelländerungen aber oft, dass Anwender ihre Zeitreihendatenbanken vollständig neu erstellen müssen (Replay der Daten). Das geht zu Lasten der Agilität und verursacht in der Regel hohe Kosten.

Das Konzept, hier eine, manchmal sogar zwei, Zeitreihen-Datenbanken zu verwenden, plus eine separate (typischerweise) relationale Datenbank für Nicht-Zeitreihen-Daten, führt kaum zum langfristigen Erfolg. Die Realität ist vielmehr, dass es sich hierbei zwar um eine schnell zu implementierende Lösung handelt, es aber mit zunehmendem Wachstum der Datenbasis teuer und schwierig wird, Daten in mehreren Datenbanken zu duplizieren und sie synchron zu halten.

Mythos #4: „Wir können keine KI starten, bis wir unsere Daten bereinigt haben“

In manchen Projekten gehen Entwickler davon aus, dass ihnen die Datenbasis oder die Datenhygiene fehlen, die sie benötigen, um KI-Algorithmen in smarten Systemen zu etablieren. Es besteht die Befürchtung, dass unzureichende Daten zu einer schlechten KI-gesteuerten Automatisierung führen würden.

In der Praxis setzen die meisten Unternehmen eine Lösung wie CrateDB ein, um mit KI-Technologien und maschinellem Lernen die menschliche Entscheidungsfindung zu optimieren, nicht um sie zu ersetzen. Die Befürchtung, dass unzulängliche Daten automatisch dazu führen, dass ganze Fabriken Amok laufen, ist unbegründet. Eine praktische Herangehensweise ist es, die Daten im Prozess automatisch zu bereinigen, indem die Analyseergebnisse überwacht werden und so schrittweise ein sauberer Datenbestand entsteht.

Dabei ist es wichtig, die kompletten Rohdaten zu erfassen und zu speichern, und nicht nur die aggregierten Wert wie Minimum, Maximum oder Durchschnitt. Nur mit den Rohdaten lassen sich KI-Modelle trainieren. Durch Systeme, die preiswerte Cloud-Instanzen nutzen und einfach über günstige SSDs zu skalieren sind, können solche Use-Cases auch finanziert werden. Der Versuch, zuerst alle historischen Daten als Voraussetzung für ein Projekt vollständig zu bereinigen, verzögert die Entwicklung und Implementierung von intelligenten IoT-Systemen und bietet oft zu wenige Daten oder Tiefe.

Es ist in der Regel besser, einfach loszulegen und Rohdaten zu sammeln und auf dem Weg die Use Cases zu entwickeln. Denn die Rohdaten aus den Sensoren der Maschinen und Fabriken sind der eigentliche Schatz, den es zu heben gilt, bevor er wie Sand durch die Finger rinnt, und der zukünftig entscheidende Wettbewerbsvorteil von Data Driven Manufacturing nicht oder zu spät aktivieren werden kann.

Fazit

Tatsächlich schafft IoT in der Praxis gänzlich neue Anforderungen an die Datenhaltung und -analyse. Diese Erfahrung machen Unternehmen, die sich mit entsprechenden Projekten beschäftigen, und auch Analysten wie Gartner Research weisen etwa darauf hin, dass IoT gänzlich neue Herausforderungen in Bezug auf Datenvolumen, Daten- und Abfragekomplexität sowie die Integration stellt. Schnelle Erfassung und Analyse von Maschinendaten sind die Voraussetzung, die datengesteuerte Automatisierung der Schlüssel zum Erfolg eines zukunftssicheren IoT-Projektes. Das beginnt bei der Auswahl einer Datenbank, die performant genug ist, den Workload zu verarbeiten und die Flexibilität bietet, umfassenden Datenmanagement-Lösungen zu entwickeln.

Lesen Sie auch

Weitere Artikel zur Führung von Medizintechnik-Unternehmen finden Sie in unserem Themenkanal Management.

Dieser Artikel ist zuerst erschienen auf unserem Schwesterportal www.industry-of-things.de.

Buchtipp „Industrial IT Security“Das Fachbuch „Industrial IT Security" erläutert nicht nur potenzielle Sicherheitsrisiken für Steuerungstechnik und Standard-Informationstechnologien in Industrieunternehmen, sondern zeigt auch passende Lösungswege zum Schutz der IT-Systeme auf. „Industrial IT Security“ kann hier versandkostenfrei oder als eBook bestellt werden.

* Christian Lutz ist Gründer und CEO von Crate.io.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 46046177)

Pixabay; Photo by Taton Moïse on Unsplash; gemeinfrei; ©Patrick P. Palej - stock.adobe.com; VDMA; EOS; ; Crate.io; Messe Düsseldorf; Devicemed; Axel Schmidt/ Siemens Healthineers AG; © ARNET·FOTO·GRAFIK, Christoph Arnet / Messe Luzern AG; Gemü; Solvay; Covestro; Deutsche Messe; Schneider Messtechnik; Transfluid; ©hati - stock.adobe.com; Aesculap; Die Storyfactory / Devicemed; Andreas Jürgens, 2W; BV-Med; Erbe Elektromedizin; Hochschule Stralsund; NUS National University of Singapore; Fergal Coulter / ETH Zürich; Sanofi