MQTT ist ein einfaches Publish-Subscribe-Modell-Protokoll für die Gerätekommunikation. Es ist bei IoT-Projekten sehr beliebt, zudem unterstützen es alle großen Cloud-Dienste. Aber braucht es das immer? (Bild: lexiconimages – Adobe Stock)
Wenn ein Unternehmen eine neue IoT-Plattform für das Erfassen, Bereitstellen und Speichern von Gerätedaten und das Entwickeln von Algorithmen für das maschinelle Lernen aufbauen muss, stellt sich immer die Frage nach einer klugen Wahl des Technologie-Stacks. Ein Problem: Es gibt viele Anbieter von Cloud-Lösungen, die alle notwendigen Tools zur Verfügung stellen. Sie sind dazu noch flexibel und universell einsetzbar. Aber wie können Anwender die Lösungen einfach halten und die Kosten für die Bereitstellung senken?
Sollten bei IoT-Projekten Standardrichtlinien befolgt werden?
DataArt hat Kunden bei einer Reihe von Digital Twin- und Industrial-IoT-Projekten unterstützt. Den Erfahrungen des Unternehmens nach, zählen Kosten- und Leistungsoptimierungen in den ersten Phasen des Architekturdesigns jedoch oft nicht zu den primären Zielen (Sondern? - Das Hauptziel während der anfänglichen Entwicklung besteht darin, die Dinge zum Laufen zu bringen, die Idee hinter dem Projekt zu validieren und ein minimal lebensfähiges Produkt zu bauen.) Dabei machen die Gemeinkosten bis zu 50% der monatlichen Abrechnung aus. Die Frage lautet: Ist es immer kosteneffizient ist, Standardrichtlinien zu befolgen? Oder lässt sich sogar Geld sparen und Projekte einfacher gestalten, indem die Architektur schlicht gehalten wird?
Angenommen, eine Unternehmen will ein Internet-der-Dinge-Projekt aufbauen – hat aber keine Erfahrung. Was wäre zu tun? Nachdem alle Vor- und Nachteile gründlich abgewogen wurden, scheint eine bestehende IoT-Plattform eine gute Lösung zu sein. Und zum Glück gibt es eine ganze Reihe von Richtlinien, die von Experten herausgegeben wurden. Hier eine Auswahl:
Warum sich MQTT für IoT-Projekte eignet
Es liegt auf der Hand, dass Experten diese Richtlinien auf die universellste und am besten anwendbare Weise erstellen. In den meisten von ihnen ist das MQTT-Protokoll enthalten. AWS IoT, Azure IoT und Google Cloud IoT basieren beispielsweise alle auf MQTT-Nachrichten. Ein beliebter Open-Source Message Broker, Eclipse Mosquitto, verwendet ebenfalls MQTT für den Nachrichtenaustausch. Und es ist in den meisten Fällen ein hervorragendes Protokoll, wie diese Beispiele zeigen: In einem IoT-Projekt im Bereich der Schwerindustrie sollten Daten von Sensoren in Digital-Twin-Lösung zum Einsatz kommen, um einige Metriken und Werte möglicher zukünftiger Bedingungen vorherzusagen. Die Lösung wurde auf AWS aufgebaut und so sah die ursprünglich angedachte Architektur aus:
Wie sieht eine typische Architektur für ein IoT-Projekt aus?
Diese Architektur ist die am weitesten verbreitete, denn sie passt zu den meisten IoT-Projekten. Bei einem anderen Beispiel von DataArt wurden Daten von Thermostaten an HLK-Systeme ebenfalls per MQTT ausgetauscht. Es war praktisch, Befehle über denselben Kanal zu senden und zu empfangen und sogar einige Logik auf der Seite des MQTT-Brokers zu automatisieren. Wenn der Thermostat seinen Zustand ändert, kann das HLK-Gerät direkt eine MQTT-Nachricht abholen, wenn es das entsprechende MQTT-Thema abonniert hat. Da diese Geräte mit einem lokalen Gateway verbunden sind, das auch als MQTT-Broker fungiert, kann das gesamte System ohne Verbindung zur Cloud, d.h. vollständig lokal, weiterarbeiten. Allerdings erfordern solche Lösungen ein fortschrittliches Firmware-Upgrade-System für alle Geräte, um Änderungen an der Logik der Geräte vorzunehmen.
Um das Beispiel weiter zu vereinfachen, wäre ein Projekt denkbar, bei dem MQTT-fähige Glühbirnen mit MQTT-fähigen Wandschaltern gesteuert werden müssen. Und gemäß den Anforderungen müsste das nur lokal geschehen. Alles, was es braucht, ist ein MQTT-Broker. So lassen sich Abonnements zwischen Glühbirnen und Schaltern erstellen, um die Logik zu beschreiben, mit der die Glühbirnen von den Schaltern gesteuert werden. Alles ist ganz einfach und MQTT ist hier ideal.
Direkter Weg in den Data Lake spart MQTT und damit Kosten
Zurück zu dem anfangs beschriebenen Industrieprojekt mit der AWS-Architektur: Dabei mussten Daten für den digitalen Zwilling zu sammeln. War MQTT hier wirklich die optimale Wahl? Sensoren erzeugen nur Daten – es besteht also keine Notwendigkeit, irgendetwas an die Sensoren und zwischen den Sensoren zu senden. Braucht es also wirklich alle Funktionen von MQTT? Damit würden zudem Gebühren für AWS IoT- und AWS Lambda-Services anfallen und ein MQTT-Broker wäre ebenfalls notwendig.
Das geht alles einfach, indem die Daten direkt an den Data Lake gesendet werden. Aber wie? Da bereits AWS GreenGrass zum Einsatz kommt, gibt es auf der Gateway-Seite Anmeldeinformationen für AWS und die boto3-Bibliothek, eine Python-Bibliothek von AWS. Sie ermöglicht den Zugriff auf alle AWS-Dienste. Sie wurde verwendet, um eine MQTT-Konnektivität herzustellen, und kann auch für eine direkte Verbindung mit dem Data Lake verwendet werden.
Warum also nicht MQTT und Lambdas von diesem Projekt ausschließen, um AWS-Kosten zu sparen? Dazu benötigt der Data Lake lediglich die Berechtigung "Nur Einfügen" und die Daten kommen von der Gateway-Seite aus. Jetzt sieht die Architektur so aus:
Jetzt entstehen nur noch die Kosten für den Data Lake und die MQTT-Broker müssen nicht mehr gepflegt werden – also eine doppelte Win-Situation.
Um das Abstrakte zu nehmen, folgen hier ein paar Zeilen für ein Beispiel mit 10.000 Geräten: Jedes Gerät sendet einmal pro Minute eine Nachricht. Im Falle von AWS IoT berechnen sich die Verbindungskosten so: 432.000.000 Verbindungsminuten entsprechen 34,38 US-Dollar pro Monat. Dazu kommt die Gebühr für die Nachrichten: 432.000.000 Nachrichten pro Monat sind 432 Dollar. Und natürlich die Zahlungen für AWS Lambda-Aufrufe, die in diesem Fall weitere 288 US-Dollar betragen würden. Insgesamt lassen sich so bei 10k Geräten 750 US-Dollar pro Monat sparen. Und das sogar ohne weitere DevOps-Optimierungen – einfach dadurch, dass in der Entwurfsphase der Lösung die richtige Entscheidung getroffen wurde.
Sollte also bei jedem IoT-Projekt MQTT verwendet werden?
Bei den meisten Digital Twin / IIoT-Projekten werden lediglich Daten gesammelt. Das ermöglicht es, einfachere Protokolle wie den direkten Zugriff auf den Data Lake oder sogar HTTPS-Anfragen zu verwenden, um solche Daten zu liefern. Die Wahl hängt jedoch immer von den Anforderungen ab. Es gibt keine allgemeingültigen Lösungen und es gibt immer Raum für Optimierungen.
Die Senkung der Betriebskosten ist ein Trend bei modernen IIoT-Innovationen. Das bedeutet vor allem, dass die Branche dieses Stadium der Reife erreicht hat. Die Einführung von Innovationen erfordert eine detaillierte Planung, gründliche ROI-Berechnungen und ein tiefes Verständnis für jeden Aspekt einer sich entwickelnden Lösung. Stellen Sie sich nur vor, was 20-30% Betriebskosten-Unterschied für Ihr Unternehmen bedeuten würden. Das ist die durchschnittliche Zahl für die Gemeinkosten, die DataArt bei den jüngsten Optimierungsprojekten gesehen hat. Also nein, es geht nicht immer um MQTT. Und ja, wahrscheinlich müssen auch Sie über Ihre Kostenreduzierung nachdenken.
