Protokollwahl für Digital Twins und IoT
Muss es immer MQTT sein?
Die Senkung der Betriebskosten ist ein Trend bei IIoT-Installationen, was auch als Zeichen einer reifen Branche zu verstehen ist. Dabei stellen Betreiber schon bei der Architektur-Planung sicher, keine unnötigen Kostentreiber einzurichten. Das bedeutet auch, Lösungen auch mal ohne das beliebte MQTT-Protokoll durchzudenken.
Digital Twinning als Konzept ist noch recht neu, doch es gibt bereits allgemeine Richtlinien für die Entwicklung dieser Lösungen. Die Befolgung der Richtlinien ist sicher, aber können Unternehmen damit immer ihre beste Leistung erzielen? Nach Erfahrung der Autoren werden in Digital Twin- und Industrial IoT-Projekten die Kosten- und Leistungsoptimierungen in den ersten Phasen des Architekturdesigns nicht als primäres Ziel angesehen. Manchmal machen die Gemeinkosten bis zu 50 Prozent der monatlichen Abrechnung aus. Wenn ein Unternehmen eine neue Plattform für die Erfassung, Bereitstellung und Speicherung von Gerätedaten und die Entwicklung von Algorithmen für das maschinelle Lernen aufbauen muss, stellt sich immer die Frage nach einer Wahl des Technologie-Stacks. Es gibt viele Anbieter von Cloud-Lösungen, die Ihnen alle notwendigen Tools zur Verfügung stellen. Sie sind flexibel und universell einsetzbar. Aber wie können Anwender die Lösungen einfach halten und die Kosten für die Bereitstellung senken? Die neunte Ausgabe von Rockwell Automations „State of Smart Manufacturing“ Report liefert Einblicke in Trends und Herausforderungen für Hersteller. Dazu wurden über 1.500 Fertigungsunternehmen befragt, knapp 100 der befragten Unternehmen kommen aus Deutschland. ‣ weiterlesen
KI in Fertigungsbranche vorn
Einfach bleiben und Kosten senken
Angenommen, Firmen wollen ein Internet-der-Dinge-Projekt aufbauen und haben keine Erfahrung. Was würden sie tun? Nachdem sie Vor- und Nachteile gründlich abgewogen haben, 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. Die Richtlinien wurden wahrscheinlich auf universelle und gut anwendbare Weise erstellt. In den meisten Anwender auf das MQTT-Protokoll treffen. AWS IoT, Azure IoT und Google Cloud IoT basieren 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. Schauen wir uns jetzt einige Beispiele an. In einem Projekt im Bereich der Schwerindustrie mussten Daten von Sensoren auf dem Feld geliefert werden. Sie sollten in ihrer Digital Twin-Lösung verwendet werden, um einige Metriken und Werte möglicher zukünftiger Bedingungen vorherzusagen. Die Lösung wurde auf AWS aufgebaut, in der Abbildung links ist die ursprünglich angebotene Architektur dargestellt. Diese Architektur ist die wohl am weitesten verbreitete und passt zu den meisten IoT-Projekten. Nehmen wir z.B. ein anderes Projekt aus der Vergangenheit, bei dem Thermostate und HLK-Systeme verbunden wurden. 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 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 arbeiten. Allerdings erfordern solche Lösungen ein fortschrittliches Firmware-Upgrade-System für alle Geräte, um Änderungen an der Logik der Geräte vorzunehmen. Hoffentlich kann AWS GreenGrass das leisten. Um das Beispiel weiter zu vereinfachen, kann die Vorstellung eines Projekts dienen, bei dem MQTT-fähige Glühbirnen mit MQTT-fähigen Wandschaltern gesteuert werden sollten, gemäß der Anforderungen nur lokal. Dazu wird nur ein MQTT-Broker benötigt. Nutzer können 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 perfekt.
Keine Regel ohne Ausnahme
Zurück zum anfangs beschriebenen Industrieprojekt mit der AWS-Architektur. Es bestand die Notwendigkeit, Daten für den digitalen Zwilling zu sammeln, der einige Berechnungen durchführte. War MQTT eine optimale Wahl? Sensoren erzeugen nur Daten. Es besteht keine Notwendigkeit, irgendetwas an die Sensoren und zwischen den Sensoren zu senden. Werden alle Funktionen von MQTT benötigt? Wollen Anwender Gebühren für AWS IoT- und AWS Lambda-Services zahlen und die MQTT-Broker verwenden? Einfacher wird es, wenn Daten direkt an einen Data Lake gehen. Da bereits AWS GreenGrass verwendet wurde, gibt es auf der Gateway-Seite Anmeldeinformationen für AWS und die boto3-Bibliothek. Warum schließen nicht MQTT und Lambdas ausklammern, um Kosten zu sparen? Wir können dem Data Lake einfach die Berechtigung ‘Nur Einfügen’ erteilen und die Daten von der Gateway-Seite aus einfügen. Grafik 2 bildet die Archtiektur ab. Der Thin[gk]athon, veranstaltet vom Smart Systems Hub, vereint kollaborative Intelligenz und Industrie-Expertise, um in einem dreitägigen Hackathon innovative Lösungsansätze für komplexe Fragestellungen zu generieren. ‣ weiterlesen
Innovationstreiber Thin[gk]athon: Kollaborative Intelligenz trifft auf Industrie-Expertise
Kostenpflege per Architektur
Betreiber dieser Infrastruktur zahlen nur noch die Kosten für den Data Lake und brauchen zudem die MQTT-Broker nicht mehr zu pflegen. Bei einer beispielhaften Summe von 10.000 Geräten lässt sich der Nutzen wie folgt quantifizieren: Jedes Gerät sendet einmal pro Minute eine Nachricht. Im Falle von AWS IoT müssen wir für die Verbindungskosten aufkommen: 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 unserem Fall 288 US-Dollar betrugen. Insgesamt haben wir bei 10.000 Geräten 750 US-Dollar pro Monat gespart, ohne weitere DevOps-Optimierungen. Bei den meisten Digital Twin oder IIoT-Projekten werden nur Daten gesammelt. Hier reichen in der Regel einfachere Protokolle wie den direkten Zugriff auf den Data Lake oder sogar HTTPS-Anfragen, um Daten auszuliefern. 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.
