DataArt

Muss es immer MQTT sein?

27. Oktober 2022, 9:15 Uhr | Nikolay Khabarov
IoT_MQTT.jpg
© AdobeStock / putilov_denis

Wenn ein Unternehmen eine Plattform für die Erfassung, Bereitstellung und Speicherung von Gerätedaten und die Entwicklung von Algorithmen für das maschinelle Lernen aufbaut, stellt sich immer die Frage nach einer klugen Wahl der Architektur. Einige Projekt-Beispiele.

Es gibt viele Anbieter von Cloud-Lösungen, die Anwendern alle notwendigen Tools zur Verfügung stellen – flexibel und universell einsetzbar. Aber wie kann der Anwender die Lösungen einfach halten und die Kosten für die Bereitstellung senken? Ist es immer kosteneffizient Standardrichtlinien zu befolgen? Lässt sich eventuell Geld sparen und sogar Projekte einfacher gestalten, indem die Architektur von der Norm abweicht?

Angenommen, es ist ein Internet-der -Dinge-Projekt aufzubauen und es existiert noch keine Erfahrung dafür im Hause. Was wäre zu tun? Nach dem gründlichen Abwägen aller Vor- und Nachteile, scheint eine bestehende IoT-Plattform eine gute Lösung zu sein. Dazu gibt es etliche Richtlinien, die von Experten herausgegeben wurden.

Bild-1-IoT-Architekturen.jpg
Bild 1. Eine der gängigsten IoT-Architekturen, mit der Verwendung des MQTT-Protokolls.
© DataArt

MQTT – der Favorit

Es liegt auf der Hand, dass die Richtlinien auf die universellste und am besten anwendbare Weise erstellt werden. In den meisten von ihnen ist das MQTT-Protokoll anzutreffen. AWS IoT, Azure IoT und Google Cloud IoT basieren auf MQTT-Nachrichten. Ein beliebter Open-Source Message Broker, Eclipse Mosquitto, verwendet ebenfalls MQTT für den Nachrichtenaustausch.

Ein Beispiel: In einem von DataArt realisierten Projekt im Bereich der Schwerindustrie mussten Daten von Sensoren aus dem Feld geliefert werden. Sie sollten in einer Digital-Twin-Lösung verwendet werden, um Metriken und Werte möglicher zukünftiger Bedingungen vorherzusagen. Die Lösung wurde auf AWS aufgebaut. Bild 1 zeigt die ursprünglich angebotene Architektur.

Oft lassen sich solche Architekturen allerdings vereinfachen. Das lässt sich aus einem anderen Projekt ersehen, bei dem Thermostate und HLK-Systeme mit im Spiel waren. Hier ist es 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 eine MQTT-Nachricht direkt von dem HLK-Gerät abgeholt werden, das 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, also 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.

Bild-2-Data-Lake.jpg
Bild 2. Eine lokale Steuerung von Glühbirnen mittels MQTT-Broker.
© DataArt

Um das Beispiel noch weiter zu vereinfachen, ist ein Projekt vorstellbar, bei dem es gilt, MQTT-fähige Glühbirnen mit MQTT-fähigen Wandschaltern zu steuern (Bild 2) . Und gemäß den Anforderungen reicht es, diese lokal zu steuern. Alles, was es braucht, ist ein MQTT-Broker. Es lassen sich so Abonnements zwischen Glühbirnen und Schaltern erstellen, um die Logik zu beschreiben, mit der die Glühbirnen von den Schaltern gesteuert werden.

Aber nun zurück zu dem anfangs beschriebenen Industrieprojekt mit der AWS-Architektur: Es bestand die Notwendigkeit, Daten für den digitalen Zwilling zu sammeln, der einige Berechnungen durchführt. War MQTT eine optimale Wahl?

Sensoren erzeugen nur Daten. Es besteht keine Notwendigkeit, irgendetwas an die Sensoren und zwischen den Sensoren zu senden. Braucht es wirklich alle Funktionen von MQTT? Ist es wirklich nötig, Gebühren für AWS IoT- und AWS Lambda-Services zu zahlen und die MQTT-Broker zu verwenden?

Bild-3-Data-Lake.jpg
Bild 3. Es fallen nur noch die Kosten für den Data Lake an. Die MQTT-Broker müssen nicht nicht gepflegt werden. Das ist eine doppelte Win-Situation.
© DataArt

AWS-Kosten sparen

Es lässt sich alles ein bisschen einfacher gestalten, indem die Daten direkt an einen Data Lake gesendet werden. Da bereits

AWS GreenGrass Verwendung findet, gibt es auf der Gateway-Seite Anmeldeinformationen für AWS und die boto3-Bibliothek. Warum also nicht MQTT und Lambdas von diesem Projekt ausschließen, um AWS-Kosten zu sparen? Es lässt sich doch dem Data Lake die Berechtigung „Nur Einfügen“ erteilen und die Daten einfach von der Gateway-Seite aus einfügen. Die Architektur zeigt Bild 3. 

Die Berechnungen für 10.000 Geräte sehen nun folgendermaßen aus: Jedes Gerät sendet einmal pro Minute eine Nachricht. Im Falle von AWS IoT müssen die Verbindungskosten beglichen werden: 432.000.000 Verbindungsminuten entsprechen 34,38 Dollar pro Monat. Dazu kommt die Gebühr für die Nachrichten: 432.000.000 Nachrichten pro Monat sind 432 Dollar. Und die Zahlungen für AWS Lambda-Aufrufe, die in dem beschriebenen Fall 288 Dollar betragen. Insgesamt lassen sich so bei 10.000 Geräten 750 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.

Khabarov_Nikolay_DataArt.jpg
Nikolay Khabarov ist leitender Architekt, IIoT und Industrie 4.0 bei DataArt
© DataArt

Raum für Optimierung

Bei den meisten Digital-Twin-/IIoT-Projekten müssen nur Daten gesammelt werden. Das erlaubt, 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 zur Optimierung.

Die Senkung der Betriebskosten ist ein Trend bei modernen IIoT-Innovationen. Dies zeigt 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. Es gilt, sich zu vergegenwärtigen, was 20 bis 30 % OpEx-Unterschied für das eigene Unternehmen bedeuten würden – und diese 20 bis 30 % Einsparung sind lediglich der Durchschnittswert für die Gemeinkosten, die DataArt bei den jüngsten Optimierungsprojekten erlebt hat. Also nein, es geht nicht immer um MQTT.


Das könnte Sie auch interessieren

Verwandte Artikel

Edge & Cloud Computing - Applications