Anzeige
Anzeige
Beitrag drucken

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.

 (Bild: DataArt Germany)

(Bild: DataArt Germany)

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 Unter­nehmen 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?

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 Nachrichten­austausch. 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.

IoT-Architektur ohne unnötige Datenbroker (Bild: DataArt Germany)

IoT-Architektur ohne unnötige Datenbroker (Bild: DataArt Germany)

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.

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.


Das könnte Sie auch interessieren:

Wer Produktion und Logistik in einer Echtzeit-Visualisierung abbildet, kann niedrigschwellig in die digitale Transformation einsteigen und viel Papier aus dem Shopfloor bannen. Ergänzt um zentrale MES-Funktionen lassen sich solche Visualisierungssysteme zur Operational Excellence-Plattform ausprägen, die bei fortlaufenden Prozessoptimierungen unterstützt.‣ weiterlesen

Industrielle Trends wie IIoT und Digitalisierung setzen immense Datenströme voraus. Doch im Gegensatz zur IT-Security für Büros müssen Fabrikbetreiber auf wesentlich mehr Stolpersteine achten, damit ihre Anlagen nicht schon einfachen Angriffen zum Opfer fallen.‣ weiterlesen

Ab und zu fehlte ein Schlüssel im Kloster der Franziskanerinnen der ewigen Anbetung von Schwäbisch Gmünd. Beim letzten Mal gab das den Impuls, anstatt neue mechanische Zylinder in die rund 220 Türen des Komplexes einzubauen, die alte Technik durch das Bluesmart-System von Winkhaus zu ersetzen.‣ weiterlesen

Mit 100,5 Punkten hält sich das IAB-Arbeitsmarktbarometer im November stabil und liegt weiter im leicht über der neutralen Marke. Auf europäischer Ebene sank der Frühindikator allerdings erneut.‣ weiterlesen

In einer neuen Expertise des Forschungsbeirats Industrie 4.0 untersuchen das FIR an der RWTH Aachen und das Industrie 4.0 Maturity Center den Status-quo und die aktuellen Herausforderungen der deutschen Industrie bei der Nutzung und wirtschaftlichen Verwertung von industriellen Daten und geben Handlungsempfehlungen für Unternehmen, Verbände, Politik und Wissenschaft.‣ weiterlesen

Im Forschungsprojekt FabOS soll eine KI-Bin-Picking-Anwendung entstehen, die ein verbessertes Erkennen, Greifen und definiertes Ablegen von Blechteilen in der Produktion ermöglicht.‣ weiterlesen

Die Digitalisierung des Qualitätsmanagements stellt Unternehmen vor Herausforderungen. Daher haben das Fraunhofer IPT und die FH Südwestfalen im Forschungsvorhaben 'Qbility - Quality 4.0 Capability Determination Model' ein datengetriebenes Reifegradmodell entwickelt, das die Anforderungen eines digitalisierten Qualitätsmanagements bei KMU adressiert.‣ weiterlesen