IoT-Architektur intelligent bauen – so gelingt es Ihnen
Das Internet of Things (IoT) revolutioniert die Kommunikation und den Datenaustausch zwischen Geräten, Sensoren, Aktoren und Co. Dabei werden die Daten meist über einen Gateway versendet.
Die Anzahl vernetzter IoT-Geräte in der Industrie 4.0 oder auch im privaten Umfeld wächst stetig und beträgt inzwischen über 20 Milliarden Geräte.
Gerade im industriellen Umfeld ist – wie beim Bau eines Hauses, eines Industrieparks oder einer Stadt – die richtige Architektur nötig. Ohne strukturiertes Planen bleibt am Ende nur eine riesige IoT-Architektur-Flickenteppich mit zahlreichen Baustellen übrig.
Beim Internet der Dinge besteht die Architektur aus verschiedenen Komponenten. Damit Sie von Anfang an Ihre IoT-Architektur richtig umsetzen, zeigen wir Ihnen in diesem Artikel, welchen Hürden und Fallstricken Sie beim Planen und Umsetzen begegnen und wie Sie diese gekonnt meistern und beseitigen.
In der Grafik sehen Sie, wie Daten verschiedener Geräte, wie zum Beispiel einer Drohne, auf Rechner (beispielsweise Edge Computer) übertragen werden. Die Daten auf diesem Rechner können dort bereits im Vorfeld berechnet und gefiltert werden. Es werden nur die benötigten Daten von den Rechnern in die Cloud übertragen. Die gesamte Datenlast liegt nicht mehr in der Cloud alleine, sondern verteilt sich auf die einzelnen lokalen Rechner, was zu einer besseren Skalierbarkeit führt.
Direkt auf den Edge-Geräten können Sie Edge Analytics betreiben, um Alarme zu generieren (Schwellwertüberprüfung), Statistiken über die verbundenen Geräte zu führen oder Anomalien mittels Machine Learning zu erkennen.
Welche 5 Dinge muss ich beim Planen einer IoT-Architektur beachten?
Die 5 größten Hürden beim Aufbau von IoT-Architekturen sind:
- Skalierbarkeit und Microservices
- Schnittstellen für heterogene Sensorlandschaft
- Data Analytics Features
- Vendor Lock-In Effekt und Erweiterbarkeit
- Viele Deployment Optionen
Problem 1 bei der Planung einer IoT-Architektur: Skalierbarkeit und Microservices
Im Rahmen eines Proof of Concepts ist eine bestimmte Anzahl an Sensoren angebunden. In der Regel verwendet das Unternehmen einen monolithischen Ansatz, bei dem alle Lösungen auf einem einzelnen Server installiert sind. Der Server ist unter anderem dafür zuständig, Daten zu speichern, Dashboards anzuzeigen. 3 Probleme entstehen bei diesem Architektur-Ansatz:
- Je mehr Nutzer und Sensoren allerdings hinzukommen, desto langsamer wird das System; es kommt zu massiven Performance-Einbrüchen.
- Mit wachsender Datenmenge kann die IoT-Plattform schnell an Ihre Grenzen stoßen und Datenverlust die Folge sein.
- Mit steigender Datenmenge verzögert sich die Verarbeitung von Datenmengen (hohe Latenzzeiten). Ein Echtzeit-Monitoring ist undenkbar.
Beim monolithischen Ansatz besteht nur die Möglichkeit einer vertikalen Skalierung. Sie können den Server zwar beispielsweise mit Arbeitsspeicher erweitern, die Robustheit fehlt jedoch und die Fehleranfälligkeit bleibt hoch. Bei einem Ausfall des einzelnen Servers steht Ihnen kein Backup bzw. keine Kopie zur Verfügung.
Lösung: Skalierbarkeit durch Microservices
Bei dieser Lösung übernimmt jeder einzelne Microdienst einzelne Aufgaben innerhalb der IoT-Plattform. So kümmert sich beispielsweise ein Dienst um die Alarme und ein anderer um die Eingangsdaten.
Außerdem können Sie einen kompletten Cluster-Verbund an Servern einsetzen, um die Last zu verteilen. Es arbeiten zwei Server parallel zusammen, sodass Sie auch horizontal skalieren und um weitere Knoten erweitern können.
Per Autoscaling haben Sie den Vorteil, bei hoher Nutzlast temporär weitere Knoten im Cluster zu starten, um „Peaks“ abzufedern.
Die vorgestellten Lösungen setzen in der Regel auf Kubernetes oder Openshift, um Dockercontainer zu orchestrieren.
Praxistipp: Führen Sie Lasttests durch, um Ihre IoT-Architektur zu prüfen und zu skalieren.
Problem 2 bei der Planung einer IoT-Architektur: Schnittstellen für heterogene Sensorlandschaften
Ein weiteres Problem bei der Planung der Architektur des IoT ist es, wenn Sie sich nur auf einige wenige Protokolle und Schnittstellen verlassen. Möchten Sie später neue Sensortypen einbinden, die andere Protokolle oder Schnittstellen verwenden, sind für deren Einbindung spezielle Einzellösungen bzw. Eigenentwicklungen nötig. Das erhöht den Wartungsaufwand teilweise erheblich.
Lösung: Flexible IoT-Plattform von Anfang an
Praxistipp: Wählen Sie von Beginn an eine flexible IoT-Plattform, die bereits von Haus aus verschiedene Schnittstellen zur Verfügung stellt und auch durch Customizing erweitert werden kann. Einheitliche Datenformate wie die Sparkplug-Spezifikation erleichtern Ihnen ebenfalls die Integration neuer Sensoren.
Problem 3 bei der Planung einer IoT-Architektur: Data Analytics Features
Das nächste Problem beim Aufsetzen eines IoT-Systems ist, wenn Sie die Data Analytics Funktionen vernachlässigen. Fehlende Data Analytics Features führen dazu, dass Sie keine tiefergehenden Erkenntnisse aus Ihren Daten extrahieren können.
Je nach Anwendungsfall kann es passieren, dass mehr Wert auf operative Dashboards als auf analytische Dashboards gelegt wird. Bei operativen Dashboards wird die Vergangenheit betrachtet; aber auch Echtzeit-Monitoring, beispielsweise durch Alerting, findet statt. Das Zielpublikum ist technischer Natur, wie Werkleiter, Maschinenführer und Instandhaltung. Im Gegensatz dazu dienen analytische Dashboards zum Überprüfen von Root-Cause-Analysen, Forecasts/Predictions und Periodenvergleichen. Das Zielpublikum kommt aus dem betriebswirtschaftlichen Bereich, wie zum Beispiel Management, Datenanalysten, Finance und Controlling. Häufig wird das betriebswirtschaftliche Zielpublikum von vielen Firmen vernachlässigt.
Lösung: Tools, Schnittstellen und Datenquellen
Achten Sie bei der Einführung der IoT-Architektur auf folgende Aspekte:
- Welche Schnittstellen haben Sie für Ihre Sensoren und Aktoren?
- Wie können Sie mehrere Datenquellen miteinander verknüpfen?
Wenn bisher nur der Fokus auf der operativen Sicht liegt, müssen Sie mehrere Tools miteinander kombinieren:
- Für operative Dashboards: ThingsBoard
- Für analytische Dashboards: Apache Superset
- Für Machine Learning Plattformen: H20.ai, MLFlow
Problem 4 bei der Planung einer IoT-Architektur: Kein Vendor Lock-In Effekt und Erweiterbarkeit
Ein weiteres Problem kommt auf, wenn Sie Ihre IoT-Landschaft von nur einem Anbieter abhängig machen. Ein geschlossene Systemlandschaft zwingt Sie dazu, andere Produkte des gleichen Herstellers zu kaufen und zu benutzen. Sie haben keine Möglichkeit, Produkte anderer Dritthersteller einzusetzen.
Wenig Flexibilität und starke Abhängigkeit haben Sie bei:
- Lizenzen (Kosten, Modelle)
- Wirtschaftlichen Problemen des Herstellers
- Dateneigentum -> Gehören die Daten immer noch Ihnen selbst?
Auslaufenden Support des Herstellers -> Kein Einblick in den Quellcode bei Closed-Source
Lösung: Best-of-Breed Ansatz
Um nicht von einem einzigen Hersteller abhängig zu sein, lohnt sich der Best-of-Breed Ansatz:
- Modularer Aufbau der Architekturen aus beliebten Technologien -> Immer die Software für den jeweiligen Einsatzzweck
- Keine Abhängigkeit von einzelnen Anbietern -> leichter austauschbar
- Open-Source-Lösungen verwenden -> mehr Transparenz und durch Customizing leichter erweiterbar
Weitere Tools finden Sie in der folgenden Tabelle:
|
Funktion
|
Open-Source Tools
|
Beschreibung
|
|---|---|---|
|
MQTT
|
HiveMQ
|
MQTT Cluster Support, Tools für Monitoring und Lasttests, mehrere MQTT Versionen unterstützt
|
|
Event Streaming Plattform
|
Confluent Cloud, Apache Kafka
|
Zentraler Datenhub, Streamprocessing Support, Hoher Durchsatz und Skalierbarkeit
|
|
IoT Plattform / Operative Dashboards
|
ThingsBoard, Thinger.io
|
Herzstück der IoT-Architektur, Geräteverwaltung und Speicherung von Zeitreihendaten, Echt-Zeit Visualisierung
|
|
Analytische Dashboards / Self-Service BI
|
Apache Superset, Redash, Metabase
|
Leicht zu bedienen, einfache Erstellung von Visualisierungen
|
|
Machine Learning Plattform
|
Python ML Bibliotheken, H20.ai
|
Machine Learning Modelle entwickeln
|
|
MLOps
|
MLFlow, Kubeflow
|
Verwaltung von Machine Learning Modellen und Deployment
|
|
Monitoring
|
Prometheus, Grafana
|
Monitoring der Komponenten der IoT Architektur
|
|
API Gateway
|
Kong
|
Datenbereitstellung via REST API, Vielzahl an Plugins
|
Problem 5 bei der Planung einer IoT-Architektur: spärliche Deployment-Optionen
Haben Sie sich auf eine Lösung festgelegt, die nur wenige Deployment-Optionen bieten, wie beispielsweise entweder On-Premise oder Cloud, bringt das einige Nachteile mit sich:
- Wenig flexibel bei Änderungen in der IoT-Architektur
- Möglicherweise kein Internetzugriff erlaubt – wegen Datenschutz und Datensicherheit
- Bei Edge Computing wird teilweise für beides, On-Premise und Cloud, Deployment-Optionen benötigt
Bei Cloud-Deployment sollten Sie zudem auf folgende Punkte achten:
- Welches Land wird unterstützt? Sind Sie nur auf ein bestimmtes Land beschränkt (Datenschutz)?
- Wird nur ein Cloud Provider unterstützt?
- Gehören die Daten wirklich Ihnen?
Lösung: mehre Deployment-Optionen zur Auswahl
Wählen Sie gleich von Beginn an Architekturkomponenten aus, die bereits von Hause aus mehrere Deployment-Optionen bieten:
- Self-Managed -> Es sollte sowohl On-Premise als auch Cloud möglich sein
- On-Premise (auf eigener Hardware)
- Cloud (AWS, Azure, GCP)
- Optional: Software-as-a-Service (SaaS) -> Sinnvoll für:
- Testen
- Proof-of-Concepts (PoC)
IoT Use Cases aus der Praxis – Möglichkeiten und Herausforderungen
Die folgenden drei Use Cases beschreiben, wie IoT-Plattformen beim Verarbeiten von Sensoren- und Gerätedaten Kunden aus verschiedenen Branchen geholfen haben und welche Herausforderungen und Anforderungen es bei den verschiedenen Projekten gab.
IoT-Plattform Use Case: Besser Schutz vor Umweltgefahren
Ein Kunde überwacht mit Spezialsensoren die Umwelt, um besser vor Umweltgefahren schützen zu können. Eine Cloud-Schnittstelle hilft dem Kunden, die Daten von den Spezialsensoren sowohl zeit- als auch sensorbasiert abzufragen. Mehrere offene Technologien helfen dem Kunden, die Daten der Umweltsensoren performant und skalierbar zu verarbeiten und zu analysieren.
Diesen Herausforderungen und Anforderungen zum Aufbau einer IoT-Plattform stand der Kunde gegenüber:
- Daten waren ausschließlich via proprietärer Cloud-API verfügbar
- Dynamische Berechnungen von physikalischen Formeln sollten möglich sein
- Bei Bedarf sollen historische Daten nachgeliefert werden
- Die IoT-Plattform sollte über eine intuitive Oberfläche für einfaches Verwalten von Devices uns Assets ermöglichen
- Die Plattform sollte mehrsprachig sein
Für die IoT-Plattform wurde ThingsBoard eingesetzt, welches folgende Vorteile bietet:
- Mit vorgefertigten Dashboard-Formularen ist es möglich, Devices und Assets einfach zu erstellen und zu bearbeiten (ThingsBoard Custom Actions)
- Physikalische Formeln werden schnell berechnet
- ThingsBoard ermöglicht das zyklische Abfragen von Daten aus der Cloud-API über frei definierbare Zeitintervalle
- Alarmtypen werden in Echtzeit-Dashboards analysiert und klassifiziert
Über einen QR-Code wird ein Sensor einfach und bequem automatisch angelegt
IoT-Plattform Use Case: Hochfrequentierte Daten aus der Produktion sammeln
Ein Unternehmen mit Druckmaschinen liest Sensordaten vom herstellerspezifischen OPC-Server event-baisert über das Tool „OPC Router“ aus, verarbeitet diese vor und überträgt diese zu einer Data Streaming Plattform. Dort erfolgt bei Bedarf ein Stream Processing, um bspw. die Rohdaten zu aggregieren. Im letzten Schritt werden die Daten von den Sensoren aus Kafka konsumiert, um Visualisierungen und Analysen von Maschinenparametern durchzuführen.
Mit der bisherigen Lösung war der Kunde nicht zufrieden. Daten wurden lediglich in einer Postgres-Datenbank gespeichert, was sich als zu unflexibel herausstellte und für Latenzen sorgte.
Folgende Herausforderungen und Anforderungen waren gegeben:
- Eine hohe Datenfrequenz ist via OPC-UA erforderlich
- Es herrscht eine hohe Maschinendiversität (unterschiedliche SPS Hersteller)
- Viele Anlagen müssen angebunden werden
- Der kritische Infrastrukturbereich muss gesichert werden (geschlossenes System)
- Daten müssen für 3rd Party Tooling bereitgestellt werden (KI und Analyse)
Es wurden verschiedene Lösungen eingesetzt, welche folgende Vorteile haben:
- Effizienter Datenzugriff auf OPC-Bausteine mit dem Tool OPC Router
- Event-gesteuerte Datenübertragungen sind mit dem Tool OPC Router möglich (z.B. nur bei Wertänderung, Fehler)
- Unterstützung vom OPC Router der offiziellen Schnittstelle zwischen OPC Router & Kafka
- Skalierbares Stream Processing mit Kafka Streams und ksqlDB u.a. für Aggregation und Filter
Leicht zu konfigurierendes Monitoring und Alerting mit ThingsBoard
IoT-Plattform Use Case: Flotten in der Logistik smart warten und optimieren
Ein Logistikdienstleister nutzt eine IoT-Plattform, um verschiedene Fahrzeuge aus seiner kompletten Flotte, welche in einzelne Flotten gruppiert ist, überwachen, um Empfehlungen für Wartungszyklen zu erhalten. Die Wartungszyklen werden nutzungsbasiert berechnet. Fahrzeuge, die wenig oder überhaupt nicht bewegt wurden, müssen daher nur selten zur Wartung in die Werkstatt.
Der Logistikdienstleister stand vor folgenden Herausforderungen und Anforderungen:
- Fahrzeugtelemetrien wie Position, Geschwindigkeit sollen erfasst werden
- Die Fahrzeugbewegungen sollen in einer Karte im Dashboard angezeigt werden
- Beim Verlassen bestimmter Regionen soll über Geofencing Alarme ausgelöst werden
- Über das Dashboard soll die Flotte zentral verwaltet werden
- Auf Basis der Nutzung sollen Erinnerungen für Wartungszyklen eingerichtet werden
Als Lösung wurde ThingsBoard eingesetzt, welches folgende Vorteile für diesen Use Case bietet:
- Widgets in ThingsBoard, um Geodaten und Fahrzeugbewegungen zu visualisieren
- Einfaches Customizing der Geokarten möglich (dynamische Marker, Ampelfarben und Tooltips)
- Dank smarter Regelketten werden Wartungsempfehlungen ermittelt
- Bei einer Wartung wird per Mail und auch über eine Integration an ein Ticketsystem an diese erinnert
FAQs: Häufig gestellte Fragen zum Aufbau einer IoT-Architektur
- Für Python gibt es eine Low-Cost Library
- Eclipse Mosquitto
- JMeter
- Unsere Empfehlung: Gatling. Gatling gibt es auch als Open Source-Version. Mit Gatling können beispielsweise MQTT-Nachrichten simuliert werden.
Es gibt eine Menge von Protokollen für verschiedene Sensoren. ThingsBoard unterstützt eine Vielzahl von Protokollen. Falls ein neues Protokoll von ThingsBoard noch nicht unterstützt werden sollte, kann das problemlos über das Customizing von ThingsBoard entsprechend angelegt werden.
ThingsBoard stellt entsprechende Skripte zur bereit, um das Entsprechende aufzusetzen. Es gibt die Möglichkeit, die Daten damit entsprechend zu migrieren. Ggf. müssen die Skripte noch entsprechend an die eigenen Bedürfnisse angepasst werden.
