Edge-to-Cloud Telemtry: Datenübertragung mit MQTT und Azure IoT

Die Digitalisierung industrieller Anlagen & Maschinen verlangt nach zuverlässigen Wegen, um Daten aus vielen verschiedenen Quellen in zentrale Cloud-Plattformen zu übertragen. Insbesondere in verteilten Systemen mit Edge Devices und Sensoren entsteht die Herausforderung, heterogene Datenquellen effizient und sicher zu konsolidieren. Ein möglicher Ansatz dafür ist der Einsatz von MQTT in Kombination mit einem IoT-Gateway zur Anbindung an Microsoft Azure. Dieser Beitrag behandelt eine technisch erprobte Architektur zur Übertragung industrieller Sensordaten über MQTT in die Azure Cloud, stellt relevante Komponenten vor und beleuchtet Herausforderungen und Lösungsansätze bei der Implementierung.
Datenquellen im industriellen Umfeld: Edge Devices & Sensoren
In modernen Produktionsumgebungen werden häufig Computer & IoT-Geräte an Maschinen eingesetzt, die als Edge Devices fungieren. Diese sind direkt mit einer Sensorik und Steuerungen verbunden und konsolidieren die Daten am Ort ihrer Erhebung. Hierbei können erste Vorverarbeitungsschritte durchgeführt werden, etwa die Mittelung oder Filterung von Messwerten. Die Daten werden über gängige industrielle Protokolle wie Modbus oder MQTT nach außen bereitgestellt. OPC UA oder andere Feldbusse sind ebenfalls möglich, jedoch ist MQTT aufgrund seiner Einfachheit und Flexibilität besonders verbreitet und wurde deswegen als Messaging-Protokoll für diese Architektur gewählt.
Die Edge Devices senden ihre Daten per Ethernet an ein zentrales Gateway – in vielen Fällen ein industrielles Embedded-Gerät wie ein robustes Linux-basiertes Wireless Embedded Computer Gateway. Dieses Gerät ist eine IoT-Gateway-Plattform, die speziell für anspruchsvolle Edge-Computing-Anwendungen in industriellen und mobilen Umgebungen entwickelt wurde. Sie fungiert als Schnittstelle zwischen der Maschinen-/Device-Ebene und der Cloud.
Da die Daten in unserem Modell bereits vorverarbeitet vorliegen, wird keine direkte Sensorintegration auf dem Gateway benötigt. Das vereinfacht die Architektur und ermöglicht eine klar definierte Trennung zwischen Edge- und Cloud-Ebene.
MQTT als Messaging-Backbone
MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges, offenes Publish-Subscribe-Protokoll, das speziell für den Einsatz in ressourcenbeschränkten Umgebungen und bei instabilen Netzwerkverbindungen entwickelt wurde. Es eignet sich besonders für IoT- und Industrieanwendungen, da es einen minimalen Overhead aufweist und zuverlässig kleine Datenpakete übertragen kann. Die Datenquelle, der sogenannte Publisher, senden ihre Daten an einen zentralen Broker, der die Nachrichten gezielt an abonnierende Clients (Subscriber) verteilt. Durch die Verwendung von Topic-Hierarchien und Wildcards lassen sich Datenströme flexibel abonnieren und strukturieren.
Diese Architektur ermöglicht eine entkoppelte Kommunikation und hohe Skalierbarkeit. Dank seiner Einfachheit, Flexibilität und breiten Unterstützung durch industrielle Gateways und Cloud-Dienste hat sich MQTT als De-facto-Standard für die Übertragung von Sensordaten etabliert – insbesondere in modernen Edge-to-Cloud-Szenarien.

Die Architektur im Detail
Die Übertragung von Maschinendaten in die Cloud erfolgt typischerweise nicht direkt vom Sensor oder Edge Device aus, sondern über eine mehrstufige Datenpipeline. Diese ist so aufgebaut, dass sie Modularität, Fehlertoleranz und klare Zuständigkeiten berücksichtigt.
Die Architektur gliedert sich in drei Layer - Edge, Gateway und Cloud. Im folgenden werden die wichtigsten Bausteine der Edge und Gateway Layer beschrieben, die den Weg in die Cloud ebnen:
1. Modbus-MQTT Konvertierung (Edge Layer)
Viele Edge-Geräte nutzen Modbus anstelle von MQTT als Kommunikationsweg. Um die gesamte Datenübertragung auf MQTT zuschneiden zu können, muss jede Modbus-Quelle auf ein MQTT-Topic abgestimmt werden. Die Konvertierung umfasst folgende Schritte:
- Verbindung zu Modbus-Servern
- Auslesen von Registern gemäß Konfiguration
- Umwandlung der 16-Bit-Rohdaten – abhängig von Byte-Reihenfolge, Skalierung und Interpretation – in allgemeine Datentypen wie int64, float, bool, string oder auch JSON
- Veröffentlichung der konvertierten Werte auf MQTT-Topics
- Da Modbus selbst nur 16-Bit-Register kennt und weder eine feste Byte-Reihenfolge (Big/Little Endian) noch standardisierte Datenformate vorgibt, entstehen vielfältige, zum Teil proprietäre Konfigurationen. Der Konverter bringt diese heterogenen Modbus-Datenquellen in ein einheitliches, strukturiertes MQTT-Interface – und legt so den Grundstein für eine konsistente Weiterverarbeitung in der Cloud.
2. MQTT Broker (Gateway)
Die angebundenen MQTT-Nachrichten werden am Gateway zentralisiert und vom MQTT-Broker in Empfang genommen. Dieser auf Eclipse Mosquitto basierende Service ist der zentrale Bestandteil der Architektur. Durch die Entkopplung über das Publish/Subscribe-Modell lassen sich neue Datenquellen oder Abnehmer problemlos integrieren, ohne die bestehende Architektur zu ändern. Das industrielle IoT-Gateway bietet dabei ausreichend Performance, um auch mehrere parallele Datenströme zu verarbeiten. Neben der Verarbeitung der MQTT-Nachrichten übernimmt der Broker ebenfalls Aufgaben wie Authentifizierung über Benutzername/Passwort oder Unterstützung für verschlüsselte Verbindungen (TLS).
Edge Devices publizieren ihre Daten periodisch oder eventbasiert an vordefinierte Topics. Die Intervalle und Daten können dabei sehr heterogen sein. Beispielsweise werden GPS-Daten hochfrequent gesendet, wohingegen Sensordaten mit träger Dynamik wie beispielsweise die Ladung einer Batterie nur alle 60 Sekunden übermittelt werden. Darüber hinaus werden auch zeitunabhängige Signale bei flankenabhängigen Zustandsereignissen verarbeitet.
3. MQTT-Azure-Connector (Gateway)
Um die Brücke zwischen MQTT-Ökosystem und Cloud schlagen zu können, wurde ein zusätzlicher Service eingeführt – der MQTT-Azure-Connector. Er abonniert relevante Topics auf dem MQTT-Broker und sendet die eingehenden Nachrichten mithilfe des Azure IoT Hub SDK an die Cloud. Dieses SDK übernimmt die Authentifizierung und Verwaltung des Gateways als „IoT Device“ in Azure und erlaubt sowohl das Senden von Telemetriedaten als auch das Empfangen von Konfigurationen über den sogenannten Digital Twin.
Für anspruchsvollere Szenarien kann statt des SDKs auch Azure IoT Edge direkt auf dem Gateway betrieben werden. Dabei handelt es sich um eine Container-Laufzeitumgebung, die speziell für IoT-Geräte entwickelt wurde. Gerade bei limitierten Speicherverhältnissen – wie auf manchen Embedded-Gateways – bietet dieser Ansatz entscheidende Vorteile:
- Modulbasierte Architektur: Docker-Container können orchestriert und versioniert über JSON-Configs verteilt werden
- Lokale Intelligenz: KI-Modelle lassen sich direkt an der Edge ausführen
- Nachrichten-Pufferung: temporäre Zwischenspeicherung bei Netzwerkausfällen
- Monitoring und Verwaltung: Metriken zu Speicher, CPU-Auslastung und Netzwerk verfügbar
- Container-Lifecycle-Management: mit integriertem Garbage Collector zur Ressourcenoptimierung

Technische Herausforderungen und Lösungen
Die Umsetzung einer solchen Datenübertragung ist technisch anspruchsvoll. Bei der Umsetzung gibt es einige Hürden zu überwinden:
1. High-Level-Datentypen in Modbus abbilden
Modbus überträgt nur einfache 16-Bit-Registerwerte, was die Abbildung komplexerer Datentypen wie GPS-Koordinaten, Strings oder Statusbits erschwert. Diese müssen auf mehrere Register verteilt und korrekt interpretiert werden – inklusive Byte-Reihenfolge, Skalierungsfaktoren und Bitmasken. Eine konfigurierbare Parser-Logik ist notwendig, um die Daten korrekt auszulesen und im MQTT-Format weiterzugeben.
2. Speicheroptimierung auf Embedded-Geräten
Das genutzte Gateway verfügt über begrenzten Speicher, wobei der Systembereich strikt vom Nutzdatenbereich getrennt ist. Um Stabilität zu gewährleisten, müssen Docker-Container gezielt im Datenspeicher abgelegt und mit schlanken Images (z. B. Alpine) betrieben werden. Auch Logging und temporäre Datenhaltung sollten ressourcenschonend konfiguriert sein.
3. Testing ohne reale Geräte
Da die eingesetzten Edge Devices nicht durchgängig verfügbar waren, wurde ein lokales Testsetup mit simulierten Daten in Docker genutzt. Die Simulation verschiedener Datenquellen kann sehr aufwendig sein. Dennoch ermöglichte dies eine realitätsnahe Entwicklung und frühzeitiges Debugging der gesamten MQTT-Strecke. Erst nach erfolgreichem Labortest wurde die Lösung in der echten Umgebung beim Kunden eingesetzt und erfolgreich verprobt.
4. Gateway-Auswahl und Plattformentscheidung
Bei der Auswahl des Gateways fiel die Entscheidung zugunsten einer offenen, Linux-basierten Plattform, da diese deutlich mehr Flexibilität und Rechenleistung bietet. Eigene Services wie MQTT-Broker oder Azure-Connector lassen sich frei deployen, was für individuelle Anforderungen unerlässlich war.
Alternativ wurden auch Gateways mit vorkonfigurierten Funktionen, integrierter Benutzeroberfläche und VPN-Funktionalität in Betracht gezogen. Diese Systeme punkten mit schneller Einsatzbereitschaft, sind jedoch deutlich eingeschränkter, wenn es um die Ausführung eigener Anwendungen oder den Betrieb von Containern geht. Zudem sind sie meist weniger robust und für mobile oder industrielle Szenarien nur eingeschränkt geeignet.
Trotz des höheren Konfigurationsaufwands bot die gewählte Plattform die nötige Offenheit und Zukunftssicherheit, um eine modulare, anpassbare Lösung zu realisieren.

Typische Anwendungsfälle
Typische Anwendungsfelder für die dargestellte Architektur finden sich vor allem in der industriellen Fertigung, in der Logistik und in Infrastrukturanlagen. Ein zentrales Einsatzszenario ist die Zustandsüberwachung von Maschinen und Anlagen (Condition Monitoring). Dabei werden kontinuierlich physikalische Größen wie Temperatur, Druck, Vibration oder Stromaufnahme erfasst, lokal auf dem Edge Device vorverarbeitet und anschließend per MQTT in die Cloud übertragen. Auf diese Weise lassen sich Zustandsveränderungen frühzeitig erkennen und fundierte Entscheidungen treffen.
Darauf aufbauend ermöglicht die Architektur auch Predictive Maintenance, also die vorausschauende Wartung. Historische Messdaten, kombiniert mit Echtzeitinformationen, dienen als Grundlage für Modelle, die den optimalen Wartungszeitpunkt prognostizieren. So lassen sich Ausfälle vermeiden, Wartungsintervalle optimieren und Serviceeinsätze gezielter planen.
Ein weiteres Einsatzgebiet ist die Qualitätsüberwachung in der Fertigung. Hier werden Prozessdaten wie Taktzeiten, Drehzahlen oder Temperaturen erfasst und analysiert, um Rückschlüsse auf die Produktqualität zu ziehen. Abweichungen vom Normbereich lassen sich in Echtzeit erkennen, was eine unmittelbare Reaktion im Produktionsprozess erlaubt und langfristig zur Optimierung beiträgt.
Ausblick
Die Kombination aus MQTT, robustem Edge-Gateway und Microsoft Azure bietet eine leistungsfähige, skalierbare und zukunftssichere Architektur für die Übertragung industrieller Sensordaten in die Cloud. Die Erfahrungen aus der Praxis zeigen: Eine saubere Trennung zwischen Edge-, Gateway- und Cloud-Ebene sowie der Einsatz offener Standards wie MQTT ermöglichen nicht nur technische Stabilität, sondern auch langfristige Erweiterbarkeit. Gleichzeitig erfordert die Umsetzung ein tiefes Verständnis der zugrunde liegenden Protokolle, Embedded-Systeme und Cloud-Dienste – insbesondere bei der Datenmodellierung, Ressourcenoptimierung und Sicherheit.
In Zukunft werden solche Architekturen weiter an Bedeutung gewinnen: Mit zunehmender Verbreitung von KI-Modellen an der Edge, wachsender Datenmenge und steigenden Anforderungen an Echtzeitfähigkeit und Ausfallsicherheit, wird die nahtlose Integration zwischen OT- und IT-Welt zum entscheidenden Erfolgsfaktor für smarte Industrieanwendungen. Wer frühzeitig in skalierbare, standardbasierte IoT-Infrastrukturen investiert, legt den Grundstein für datengetriebene Geschäftsmodelle. Wir begleiten sind von der Anforderungsaufnahme, über die Implementierung bis zum weiteren Betrieb und Support, nehmen Sie bei Fragen gerne Kontakt zu uns auf.
Teilen Sie diesen Artikel