MQTT-Broker (Mosquitto) für industrielle IoT-Anwendungen

Ein MQTT-Broker (Mosquitto) ist in vielen industriellen IoT-Anwendungen das zentrale Bindeglied zwischen Sensoren, Maschinen, Edge-Gateways und IT-Systemen. Während Feldbusse und klassische Automatisierungsprotokolle oft streng hierarchisch organisiert sind, ermöglicht MQTT eine flexible Publish/Subscribe-Kommunikation: Geräte senden Messwerte als „Topics“, andere Systeme abonnieren genau die Informationen, die sie benötigen. Das reduziert Kopplung, vereinfacht Integrationen und skaliert in verteilten Umgebungen häufig besser als direkte Punkt-zu-Punkt-Verbindungen. In der Industrie zählt jedoch nicht nur „es funktioniert“, sondern vor allem: determinierbares Verhalten, belastbare Sicherheit, nachvollziehbares Logging, Update-Strategien und ein Betriebskonzept für 24/7. Mosquitto als schlanker, weit verbreiteter Open-Source-Broker aus dem Eclipse-Ökosystem ist dafür eine häufige Wahl – sowohl für Pilotprojekte als auch für produktive Anlagen, wenn man die Konfiguration professionell umsetzt. Dieser Artikel erläutert, wie Mosquitto in industriellen IoT-Szenarien eingesetzt wird, welche Architekturentscheidungen wichtig sind (QoS, Sessions, Retained Messages, Bridging), wie Sie Sicherheit (TLS, Authentifizierung, ACL) sauber aufsetzen und worauf es beim Betrieb unter Last und bei hoher Verfügbarkeit ankommt.

MQTT in der Industrie: Warum Publish/Subscribe so gut passt

MQTT wurde für ressourcenarme Geräte und unzuverlässige Netze entwickelt, was es für verteilte IoT-Umgebungen attraktiv macht. In industriellen Szenarien kommen weitere Anforderungen hinzu: viele Endpunkte, unterschiedliche Lebenszyklen von Geräten, wechselnde Datenabnehmer (SCADA, MES, Historian, Cloud, Data Lake) und klare Trennung von OT- und IT-Netzen. Publish/Subscribe ist hier ein Vorteil, weil Publisher nicht wissen müssen, wer die Daten nutzt. Der Broker übernimmt Verteilung, Sessions und – je nach QoS – Zustellgarantien.

• Lose Kopplung: Maschinen und IT-Systeme können unabhängig weiterentwickelt werden
• Skalierung: neue Subscriber lassen sich hinzufügen, ohne Publisher umzubauen
• Netzwerkfreundlich: kleine Header, langlebige TCP-Verbindungen, optional Keep-Alive
• Robustheit: Offline-Phasen lassen sich über Sessions und QoS abfedern

Mosquitto als Broker: Stärken und typische Einsatzbilder

Mosquitto ist bewusst schlank, schnell installiert und sehr gut dokumentiert. In industriellen Umgebungen wird Mosquitto häufig als lokaler Broker am Edge eingesetzt (z. B. im Schaltschrank, auf einem Industrie-PC oder einem Raspberry Pi) und entweder direkt von Anwendungen genutzt oder zu einem zentralen Broker/Cluster weitergeleitet. Gerade diese „Edge-first“-Architektur kann Bandbreite sparen und sorgt dafür, dass lokale Prozesse auch dann weiterlaufen, wenn die Verbindung zur IT oder Cloud gestört ist.

• Edge-Broker: sammelt Maschinendaten lokal, verteilt sie an HMI/SCADA, leitet selektiv weiter
• Zentraler Broker: aggregiert Daten aus mehreren Standorten oder Linien
• DMZ-Broker: entkoppelt OT und IT (z. B. über Bridging oder streng definierte Firewall-Regeln)
• Test-/Integrationsbroker: für Inbetriebnahme, Simulationen, Integrationstests

Grundkonzepte: Topics, Wildcards und Namenskonventionen

Die Topic-Struktur entscheidet darüber, ob Ihr System langfristig wartbar bleibt. Industrielle Projekte profitieren von konsistenten Namenskonventionen, klaren Hierarchien und einer Trennung nach Standort, Linie, Maschine, Signalgruppe und Messpunkt. Wildcards helfen, Daten selektiv zu abonnieren, sollten aber nicht als Ersatz für eine saubere Topic-Taxonomie dienen.

• Hierarchie: z. B. werk/linie/maschine/sensor/temperatur
• Trennung: telemetrie/ (Messwerte), event/ (Ereignisse), cmd/ (Kommandos), status/ (Zustände)
• Versionierung: bei Payload-Änderungen eine neue Topic-Variante oder ein Schema-Tag nutzen
• ACL-freundlich: Topics so gestalten, dass Zugriffsrechte sauber abbildbar sind

QoS, Sessions und Zustellgarantien in industriellen Datenflüssen

MQTT bietet Quality of Service (QoS) mit drei Stufen. In der Industrie ist es entscheidend, QoS bewusst auszuwählen: höhere Zustellgarantien erhöhen Overhead, Latenz und Brokerlast. Gleichzeitig können sie für kritische Ereignisse unverzichtbar sein. Ergänzend spielen Sessions (Clean Session/Clean Start) und Persistenz eine Rolle, damit Nachrichten nicht verloren gehen, wenn Clients kurzzeitig offline sind.

QoS 0, 1 und 2 praxisnah einordnen

• QoS 0 (at most once): schnell, minimaler Overhead, ideal für hochfrequente Telemetrie, bei der einzelne Aussetzer tolerierbar sind
• QoS 1 (at least once): zuverlässiger, aber Duplikate möglich; gut für Ereignisse und Zustände, wenn die Anwendung Duplikate idempotent verarbeiten kann
• QoS 2 (exactly once): höchste Garantie, aber am teuersten; eher für seltene, wirklich kritische Nachrichten geeignet

Retained Messages und Last Will sinnvoll nutzen

Retained Messages sind praktisch, um den „letzten bekannten Zustand“ direkt beim Abonnieren zu erhalten (z. B. Betriebsmodus, aktuelle Zählerstände, Online-Status). Last Will and Testament (LWT) hilft, Ausfälle zu erkennen: Ein Client definiert beim Verbinden eine „Abschieds-Nachricht“, die der Broker veröffentlicht, wenn die Verbindung unerwartet abbricht. Das ist in der Industrie sehr nützlich, um Anlagenzustände, Gateways oder Datenquellen zuverlässig zu überwachen.

Sicherheit: TLS, Authentifizierung und ACLs professionell umsetzen

Ein MQTT-Broker in industriellen Netzen darf nicht „offen im Netz“ stehen. Selbst in abgeschotteten OT-Umgebungen sind interne Angriffe, Fehlkonfigurationen und versehentliche Exposition realistische Risiken. Mosquitto unterstützt TLS-Verschlüsselung, Benutzer-/Passwort-Authentifizierung sowie Zugriffskontrollen über ACLs. Für produktive Setups ist eine klare Policy wichtig: Wer darf was publizieren oder abonnieren? Welche Clients bekommen Zugriff auf Kommandokanäle? Welche Topics sind read-only?

• TLS aktivieren: verschlüsselte Kommunikation, Schutz vor Mitschnitt und Manipulation
• Client-Zertifikate: optional für starke Geräteidentität (mTLS), besonders in industriellen Umgebungen empfehlenswert
• Benutzer/Passwort: sinnvoll, wenn Zertifikate nicht überall möglich sind
• ACLs: Rechte pro Benutzer/Client, Topic-Granularität
• Netzsegmentierung: Broker in VLAN/DMZ, Zugriff nur von definierten Subnetzen

Port- und Listener-Strategie: Klar trennen statt mischen

In vielen Installationen ist es sinnvoll, getrennte Listener zu nutzen, etwa einen internen Listener für OT-Clients und einen weiteren für IT/Analytics, jeweils mit eigenen TLS-/Auth-Regeln. So lassen sich Sicherheitsanforderungen pro Zone sauber trennen. Achten Sie darauf, unsichere Defaults (z. B. unverschlüsseltes 1883 ohne Auth) bewusst zu vermeiden und nur dort zu erlauben, wo es organisatorisch und technisch begründet ist.

Payload-Design: JSON ist bequem, aber nicht immer optimal

MQTT definiert nur Transport und Topics, nicht das Datenformat. In industriellen Szenarien sollten Sie das Payload-Design bewusst wählen. JSON ist gut lesbar und für Prototypen ideal, hat aber Overhead. Für hohe Datenraten oder strenge Bandbreitenlimits sind binäre Formate (z. B. CBOR, Protocol Buffers) oft effizienter. Noch wichtiger: Einheitliche Schemata, klare Einheiten und Zeitstempel.

• Konsistenz: gleiches Feldlayout für gleiche Signaltypen
• Einheiten: z. B. °C, %rF, bar, kW – nie implizit lassen
• Zeit: UTC-Zeitstempel für korrekte Historisierung und Korrelation
• Idempotenz: bei QoS 1 Duplikate erwarten und verarbeiten können

Performance und Kapazitätsplanung: Was der Broker leisten muss

In der Praxis scheitern MQTT-Projekte selten an der Grundfunktion, sondern an falsch eingeschätzter Last: zu viele Clients, zu häufige Publishes, große Payloads, zu aggressive Retain-Nutzung oder ungebremste Wildcard-Subscriptions. Für eine grobe Kapazitätsabschätzung hilft eine einfache Bandbreitenrechnung:

$B=N·f·s$

Hier ist $N$ die Anzahl der Publisher, $f$ die Veröffentlichungsfrequenz (Nachrichten pro Sekunde) und $s$ die durchschnittliche Nachrichtengröße (Bytes). Beispiel: 200 Sensoren senden jede Sekunde 250 Bytes Telemetrie:

$B=200·1·250=50000\mathrm{Bytes/s}$

Das sind ca. 50 kB/s nur für den Uplink – ohne TCP/TLS-Overhead und ohne Berücksichtigung der Subscriber. Wenn 5 Systeme dieselben Daten abonnieren, vervielfacht sich der ausgehende Traffic am Broker entsprechend. Für industrielle Umgebungen ist daher wichtig: Frequenzen drosseln, Payloads optimieren, Topics sinnvoll aggregieren und Lasttests vor dem Rollout durchführen.

Bridging und Multi-Site-Architekturen: OT und IT sauber entkoppeln

Mosquitto unterstützt Bridging, also das Weiterleiten von Topics zwischen Brokern. Das ist in industriellen Architekturen extrem nützlich: Ein Edge-Broker sammelt lokale Daten, und nur relevante Topics werden in ein zentrales System gespiegelt. So bleibt der Standort autonom und die zentrale Plattform erhält trotzdem konsolidierte Daten. Bridging ermöglicht außerdem eine DMZ-Strategie, bei der der OT-Broker nicht direkt mit der IT kommuniziert, sondern über einen kontrollierten Zwischenbroker.

• Edge → Zentrale: selektive Weiterleitung, Bandbreite und Sicherheit besser kontrollierbar
• Store-and-forward: je nach Konfiguration können Offline-Phasen abgefedert werden
• Topic-Filtering: nur benötigte Topics über die Grenze senden
• Richtlinien: Kommandos (cmd/) besonders streng kontrollieren

Hohe Verfügbarkeit: Was Mosquitto kann – und wo Architekturentscheidungen zählen

„High Availability“ bedeutet in der Industrie oft: geplante Wartung ohne Datenverlust, definierte Wiederanlaufzeiten und ein kontrolliertes Fehlerverhalten. Mosquitto ist sehr robust, ist aber kein „Cluster-Broker“ im Sinne eines verteilten Zustands über mehrere Knoten, wie es manche Enterprise-Broker bieten. Trotzdem lassen sich hochverfügbare Designs aufbauen, etwa über aktive/passive Redundanz, DNS-/VIP-Konzepte, redundante Edge-Broker pro Linie oder über vorgeschaltete Load-Balancer – abhängig davon, wie Ihre Clients Failover unterstützen.

• Redundante Broker: zwei Broker pro Standort, Clients mit Failover-Logik
• Persistenzkonzept: saubere Storage-Strategie (SSD, Dateisystem, Backup)
• Wartungsfenster: Rolling Updates, kontrollierte Neustarts, Monitoring
• Offline-Toleranz: Session-/Queue-Strategie bei Clients und Broker

Betrieb und Wartung: Logging, Monitoring und Auditing

Industrielle IoT-Systeme müssen nachvollziehbar sein. Das betrifft nicht nur Maschinenzustände, sondern auch Kommunikation: Wer hat wann publiziert? Warum fehlen Daten? Welche Clients sind verbunden? Mosquitto bietet Logging-Möglichkeiten, und in professionellen Setups sollten Sie Logs zentral sammeln (z. B. über Syslog/Log-Forwarding) und Metriken überwachen (Verbindungen, Nachrichtenraten, Speicher, CPU, Netzwerk).

• Verbindungsmonitoring: Online/Offline über LWT, Heartbeats, Session-Zustände
• Broker-Logs: Auth-Fehler, Verbindungsabbrüche, ungewöhnliche Clients
• Metriken: Nachrichtenraten, Retained-Anzahl, Persistenz-Queue, Ressourcenverbrauch
• Audit-Trails: besonders wichtig bei Kommandokanälen und sicherheitsrelevanten Aktionen

Industrial Hardening: Typische Schutzmaßnahmen, die in der Praxis helfen

Ein Broker in industriellen Netzen wird schnell zur kritischen Infrastruktur, weil viele Systeme davon abhängen. Entsprechend sollten Sie nicht nur den Broker selbst absichern, sondern auch die Umgebung.

• Minimale Angriffsfläche: unnötige Dienste deaktivieren, nur benötigte Ports öffnen
• Least Privilege: ACLs restriktiv, getrennte Benutzer für Publisher/Subscriber/Administratoren
• Zertifikatsmanagement: Laufzeiten, Rotation, klare Verantwortlichkeiten
• Konfigurationsmanagement: Versionierung (Git), definierte Rollout-Prozesse
• Backup/Restore: Persistenzdaten und Konfiguration regelmäßig sichern und Rücksicherung testen
• Segmentierung: OT/IT trennen, DMZ für Übergänge, klare Routing-Regeln

Deployment-Optionen: Bare Metal, Docker und Edge-Geräte wie Raspberry Pi

Mosquitto läuft auf typischen Linux-Systemen sehr effizient und lässt sich sowohl klassisch als Dienst (systemd) als auch containerisiert betreiben. In industriellen Umgebungen ist die Entscheidung meist nicht ideologisch, sondern betrieblich: Container vereinfachen Updates und Rollbacks, klassische Installationen sind manchmal leichter zu auditieren und zu integrieren (z. B. in bestehende Patchprozesse). Auf Edge-Geräten wie dem Raspberry Pi ist Mosquitto häufig eine gute Wahl, wenn Stromversorgung, Storage (SSD statt microSD) und Netzwerk stabil sind.

• systemd-Service: klarer Autostart, Restart-Policy, Integration in OS-Logging
• Docker: reproduzierbare Deployments, einfache Versionierung, aber sauberes Volume-/TLS-Handling nötig
• Edge-Betrieb: lokal puffern, selektiv weiterleiten, Ausfälle der WAN-Verbindung tolerieren

Interoperabilität: Clients, Libraries und industrielle Integrationen

MQTT lebt vom Ökosystem. Für industrielle Anwendungen ist relevant, dass es stabile Client-Bibliotheken (z. B. Eclipse Paho) und Integrationen in gängige Plattformen gibt (Node-RED, SCADA-Konnektoren, Historian-Anbindungen, Cloud-IoT-Services). Achten Sie darauf, dass Ihre Client-Implementierungen die gewählten Features (QoS, Persistenz, MQTT v5 Eigenschaften) zuverlässig unterstützen.

• Client-Libraries: stabile SDKs erleichtern robuste Reconnect- und Offline-Logik
• Protokollversion: MQTT 3.1.1 ist sehr verbreitet; MQTT 5 bietet zusätzliche Features (z. B. Reason Codes, User Properties)
• Schema-Strategie: klare Datenmodelle vermeiden spätere Integrationskosten

Weiterführende Informationsquellen (Outbound-Links)

• MQTT Grundlagen und Überblick (mqtt.org)
• Eclipse Mosquitto Dokumentation (Konfiguration, Sicherheit, Betrieb)
• Mosquitto-Konfigurationsreferenz (mosquitto.conf manpage)
• MQTT 3.1.1 Spezifikation (OASIS)
• MQTT 5.0 Spezifikation (OASIS)
• Eclipse Paho MQTT Client Libraries (Interoperabilität und SDKs)
• Eclipse Mosquitto Projektseite (Hintergrund und Ökosystem)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.