Im industriellen IoT, insbesondere im Kontext des Unified Namespace, ist die Auswahl des richtigen Nachrichtenprotokolls von entscheidender Bedeutung. Dabei sind MQTT und NATS zwei prominente Optionen. Beide Protokolle gehören zu den wichtigsten Messaging-Technologien für moderne OT/IT-Architekturen, verfolgen jedoch unterschiedliche technische Ansätze. Während MQTT seit Jahren als zuverlässiger Standard für die Geräte- und Shopfloor-Kommunikation etabliert ist, positioniert sich NATS als hochperformante, Cloud-native Alternative für skalierbare Edge-, Factory- und Enterprise-UNS-Strukturen. Dieser Artikel vergleicht NATS vs MQTT im industriellen Einsatz und zeigt, welches Protokoll sich für welchen UNS-Anwendungsfall am besten eignet.
Messaging Technologien im Unified Namespace (UNS)
Ein Unified Namespace (UNS) ist eine datenzentrisches Architekturkonzept, welches den durchgängigen Datenaustausch zwischen OT-Geräten und IT-Anwendungen ermöglicht. Alle relevanten Fertigungsdaten werden hierbei in einem gemeinsamen Namespace mit einheitlicher Struktur und Namenskonvention verfügbar gemacht. Dies vereinfacht den standort- und systemübergreifenden Zugriff erheblich. Als Nachrichtenprotokoll kommen in der Produktion dafür typischerweise MQTT- oder NATS-basierte Systeme zum Einsatz. Beide Protokolle verfolgen einen ähnlichen Grundansatz, unterscheiden sich jedoch in wichtigen technischen Details.
Grundlagen von NATS (Neural Autonomic Transport System)
NATS ist ein offenes, leichtgewichtiges und äußerst performantes Messaging-System für verteilte Anwendungen. Ursprünglich von Derek Collison entwickelt, wird es heute als CNCF-Projekt weiterentwickelt. NATS zeichnet sich durch einen minimalistischen Kern aus: Der Broker läuft als einzelne, ca. 15 MB kleine Binärdatei ohne externe Abhängigkeiten. Dieses schlanke Design vereinfacht Deployment und Wartung erheblich. Trotz seiner Simplizität unterstützt NATS mehrere Kommunikationsmuster – neben Publish/Subscribe auch Request/Reply und Point-to-Point – und ist daher vielseitig einsetzbar. Aufgrund seiner hohen Geschwindigkeit und Skalierbarkeit wird NATS bisweilen als aufstrebende Messaging Technologie für das IIoT bezeichnet und bereits von vielen Unternehmen (z.B. Volvo, Schaeffler) produktiv genutzt. Standardmäßig liefert der NATS-Core Nachrichten mit “at most once” Semantik aus (maximal einmal, ohne Zustellgarantie), was ultrageringe Latenzen ermöglicht. Für Anwendungsfälle, die eine garantierte Zustellung oder Persistenz erfordern, bietet das erweiterte NATS JetStream Modul zusätzliche Funktionen (z.B. Speicherung von Nachrichten, Acknowledgements und Replay). Weitere Informationen finden Sie hier.
Grundlagen von MQTT (Message Queuing Telemetry Transport)
MQTT ist ein leichtgewichtiges Messaging-Protokoll, das speziell für instabile Netzwerke mit geringer Bandbreite und hoher Latenz entwickelt wurde. Heute ist MQTT ein offener OASIS-Standard und seit 2016 auch ISO-Standard (ISO/IEC 20922). MQTT hat sich aufgrund seiner Zuverlässigkeit und Einfachheit schnell zum De-facto-Standard im IoT und besonders im industriellen IoT entwickelt. In modernen Fabriken bildet MQTT oft das Rückgrat für den Austausch von Echtzeitdaten aus OT- und IT-Systemen. Typische MQTT-Broker unterstützen Funktionen wie Quality of Service (QoS)-Stufen für garantierte Zustellung und Retained Messages (vom Broker gespeicherte letzte Nachrichten je Topic), um auch bei temporär offline befindlichen Clients den Datenzustand vorzuhalten. Diese Mechanismen sorgen für eine zuverlässige Kommunikation zwischen Geräten und dem Broker, selbst unter schwierigen Netzwerkbedingungen. Weitere Informationen finden Sie hier.
1. NATS vs MQTT: Einsatzgebiete und Architektur
MQTT: Wurde für ressourcenbeschränkte Umgebungen entworfen und ist daher ideal im OT-Bereich: remote Sensoren, eingebettete Geräte oder Maschinensteuerungen mit limitierter Bandbreite profitieren von MQTTs geringem Protokoll-Overhead. In klassischen IoT-Anwendungen – etwa verteilte Sensor-Netzwerke oder Smart Devices – sorgt MQTT durch seine Einfachheit für zuverlässige Übertragung auch bei instabilen Verbindungen. Ein UNS auf MQTT-Basis spielt seine Stärken vor allem dann aus, wenn viele Endgeräte in der Produktion direkt angebunden werden sollen und Netzwerkunzuverlässigkeit ein Thema ist.
NATS: Ist konzipiert für moderne, datenintensive Anwendungen, die höchste Leistung erfordern. NATS glänzt als universelles Messaging-System in Edge oder Cloud-nativen Architekturen, Microservices-Umgebungen und überall dort, wo sehr große Nachrichtenmengen in Echtzeit bewegt werden. In einem UNS-Kontext eignet sich NATS insbesondere für Hybrid-Szenarien, die eine Brücke zwischen der Fabrikhalle und Cloud-Services schlagen: Die geringe Latenz und hohe Durchsatzrate von NATS kommen z.B. bei Echtzeitanalysen oder der Anbindung von Big-Data-Infrastruktur zum Tragen.
2. Messaging-Muster
MQTT: Setzt vollständig auf das Publish/Subscribe-Muster. Daten werden in hierarchischen Topics veröffentlicht, und abonnierte Clients erhalten die entsprechenden Nachrichten. Diese Entkopplung über einen Broker ist äußerst effektiv für IoT-Szenarien, in denen viele verteilte Geräte (Sensoren, Maschinen, Apps) mit minimaler Abstimmung asynchron kommunizieren. Mit MQTT 5 wurde das Protokoll um optionale Header-Felder wie Response Topic und Correlation Data erweitert. Damit lässt sich ein Request/Response-Muster auf Nachrichtenebene prinzipiell umsetzen. Dieses eignet sich unter anderem für Konfiguration oder Diagnoseabfragen, bleibt jedoch explizit asynchron und erfordert eine saubere Modellierung auf Topic- und Payload-Ebene.
NATS: Unterstützt ebenfalls Publish/Subscribe, bietet darüber hinaus aber Request/Reply als natives Kommunikationsmuster mit synchroner Semantik sowie klassischen Point-to-Point-Versand. Dadurch eignet sich NATS besonders für Service-zu-Service-Kommunikation, Orchestrierung und Microservices. In einem UNS kann NATS ergänzend eingesetzt werden, wenn neben der Datendistribution auch direkte, synchron wirkende Service-Interaktionen erforderlich sind.
| Aspekt | MQTT (auch 5) | NATS |
|---|---|---|
| Request/Response | Modelliert | Nativ |
| Broker kennt Zusammenhang | ❌ | ✅ |
| Korrelation | Payload (manuell implementiert) | System |
| Timeout | Anwendung (manuell implementiert) | System |
| Fehlerfälle | Anwendung (manuell implementiert) | System |
| Mehrere Antworten möglich | ⚠️ | ❌ |
3. NATS vs MQTT: Leistung und Skalierbarkeit
MQTT: MQTT ist sehr skalierbar in Bezug auf die Anzahl der angeschlossenen Clients: Moderne Broker unterstützen tausende bis Millionen gleichzeitiger Verbindungen und verteilen insbesondere viele kleine Nachrichten sehr effizient bei niedriger Latenz. ABER: Die horizontale Skalierung bzw. das Clustering ist nicht Teil des MQTT-Standards, sondern wird von den Herstellern (HiveMQ, EMQX, VerneMQ, Mosquitto-Cluster usw.) proprietär und jeweils unterschiedlich als Zusatzfunktion implementiert. Damit ist ein MQTT-Cluster kein verteilter Broker, sondern eine Gruppe koordinierter Einzelinstanzen – und häufig ein kostenpflichtiges Enterprise-Feature. Ein MQTT-Cluster besteht daher immer aus synchronisierten Einzelbrokern und kann, je nach Produkt, eine oder mehrere der folgenden Funktionen umfassen:
- Replikation von Sessions
- Replikation von Subscriptions
- Synchronisierung von Retained Messages
- Load Balancing über mehrere Broker
- State-Sharing
NATS: NATS wurde für extremen Durchsatz und minimale Latenzen entworfen. Benchmarks zeigen Millionen von Nachrichten pro Sekunde bei Mikro- bis niedrigen Millisekunden-Latenzen. Der große Vorteil ist dabei: Während MQTT beim Clustering auf proprietäre Erweiterungen angewiesen ist, ist horizontale Skalierung bei NATS nativ im Open-Source-Core implementiert. Ein NATS Cluster verhält sich wie ein einziger verteilter Broker, und ein NATS Supercluster verbindet mehrere Cluster zu einem globalen, föderierten Namespace. Dadurch skaliert NATS architektonisch deutlich sauberer und eignet sich ideal für Factory- und Enterprise-UNS-Strukturen.
NATS bietet zwei native Cluster Mechanismen
- NATS Cluster – ein einziger verteilter Broker: Ein NATS Cluster besteht aus mehreren Servern, die sich wie ein einziger logischer Broker verhalten. Ein NATS-Cluster ist ein echter verteilter Broker – nicht mehrere Einzelinstanzen. Dazu gehören:
- gemeinsamer globaler Namespace
- Shared State / Meta-Cluster
- clusterweite Kenntnis ALLER Subscriptions
- automatisches Routing
- Load Balancing auf Nachrichtenniveau
- optional: gemeinsamer JetStream für Persistenz
- NATS Supercluster – globales intelligentes Datennetzwerk: Ein NATS Supercluster verbindet mehrere NATS-Cluster über Standorte, Netzwerke oder Cloud-Grenzen hinweg. Dabei entsteht keine zusätzliche Server-Schicht: Der Supercluster besteht ausschließlich aus den vorhandenen NATS-Clustern, die über Gateways logisch zu einem globalen System verbunden werden. Es gibt also keine separate Supercluster-Komponente, die betrieben werden muss. In dieser Verbundstruktur agiert NATS wie ein globaler, selbstoptimierender UNS-Datenbus. Er bietet:
- föderierte Domains für mehrere Werke/Regionen
- globalen Namespace
- Gateway-Routing über WAN/Cloud
- hocheffizientes Subject-Routing („only send when needed“)
- Multi-Region-, Multi-Cloud- und Multi-Factory-Federation
Zusammenfassung Skalierbarkeit
| Aspekt | NATS Cluster / Supercluster | MQTT Clustering |
|---|---|---|
| Standardisiert? | Ja – Clustering & Superclustering sind Teil des offenen NATS-Kerns | Nein – vollständig herstellerabhängig (HiveMQ, EMQX, VerneMQ, Mosquitto-Cluster) |
| Architektur | Ein verteilter Broker (Cluster) + föderiertes Multi-Cluster-Netzwerk (Supercluster) | Mehrere logisch getrennte Broker, die über proprietäre Mechanismen synchronisiert werden |
| Routing | Intelligentes Subject-Routing („only send when needed“), Subscription Awareness | Topic-Routing je nach Broker; häufig Broadcast- oder Hash-basierte Verteilung |
| State Handling | Vollverteilt durch Meta-Cluster & JetStream (optional persistent und repliziert) | Brokerabhängig: Session-, Retain- und Subscription-Replikation nicht einheitlich unterstützt |
| Load Balancing | Nativ integriert: dynamisches, subscription-aware Lastmanagement auf Message- und Connection-Ebene; keine externen Komponenten notwendig | Kein Standard: Load Balancing über externe Load Balancer, Hashing, Sticky Sessions oder Herstellermechanismen; kein Message-Level-Balancing |
| Skalierung | Native horizontale Skalierung, Multi-Werk, Multi-Region, Multi-Cloud | Horizontal skalierbar, aber komplex und proprietär; oft Enterprise-Feature |
| Globaler Namespace | Ja – vollständig integriert durch Supercluster-Föderation | Nein – nur über manuelle Bridges oder Hersteller-Replikation |
| WAN / Multi-Site | Nativ optimiert (Gateways, Federation, WAN-Routing) | Nicht im Standard definiert; Multi-Site meist eingeschränkt oder unzuverlässig |
| Multi-Tenancy | Native Accounts, Berechtigungen und Subject-Isolation | Nur in wenigen Enterprise-Brokern vorhanden; nicht standardisiert |
| Federation | Voll integriert: Cluster ↔ Supercluster Federation über Gateways | Nicht nativ; nur über Bridges oder Broker-spezifische Replikation |
4. High Availability (HA) im Vergleich
MQTT: Der MQTT-Standard definiert weder Clustering noch Mechanismen für Failover oder State-Replikation. Hochverfügbarkeit ist daher vollständig brokerabhängig und unterscheidet sich je nach Hersteller deutlich. Dies führt in der Praxis zu sehr unterschiedlichen Failover-Eigenschaften zwischen den MQTT-Implementierungen:
- Active/Active-Cluster: Moderne Broker bieten load-balancete Cluster an, in denen mehrere Instanzen parallel betrieben werden. Dabei wird jedoch kein echter verteilter Broker gebildet, sondern ein Verbund synchronisierter Einzelinstanzen.
- Active/Passive-Failover: Viele MQTT-Installationen setzen auf klassische Redundanzmechanismen der Infrastruktur, z. B. virtuelle Maschinen mit Heartbeat, Kubernetes Deployments oder Pacemaker/Corosync. Fällt der aktive Broker aus, übernimmt ein passiver Node – jedoch ohne garantierte Session- oder State-Kontinuität.
- Session- und Subscription-Replikation: Einige Broker replizieren Client-Sessions, Retained Messages oder Subscriptions zwischen Cluster-Knoten. Umfang und Konsistenz der Replikation sind jedoch herstellerabhängig.
- Externe Komponenten notwendig: Für echtes Failover wird meist ein externer Load Balancer (DNS Round Robin, HAProxy, NGINX, Cloud Load Balancer) eingesetzt.
NATS: NATS verfolgt ein völlig anderes Architekturmodell. Hochverfügbarkeit ist kein Add-on, sondern integraler Bestandteil des Systems. Bereits der NATS-Core unterstützt Mechanismen, die einen kontinuierlichen Betrieb auch bei Ausfällen einzelner Knoten sicherstellen – auch ohne externe Komponenten:
- Echter verteilter Broker: Ein NATS-Cluster ist eine logische Einheit. Fällt ein Node aus, übernehmen die verbleibenden Nodes sofort – ohne dass Clients ihre Subscriptions verlieren oder sich neu verbinden müssen.
- Meta-Cluster für State-Konsistenz: Der Control Plane State (Accounts, Berechtigungen, Cluster-Metadaten) wird über ein internes Meta-Cluster repliziert. Dadurch bleibt die Systemkonfiguration konsistent, selbst wenn einzelne Knoten ausfallen.
- Subscription-Aware Routing: Da alle Cluster-Nodes den vollständigen Subscription-Graphen kennen, können Nachrichten jederzeit automatisch über alternative Wege zugestellt werden.
- JetStream sorgt für Datenverfügbarkeit: Wird Persistenz benötigt, repliziert JetStream Nachrichtenströme über mehrere Nodes (RAFT-basiert). Damit bleiben gespeicherte Events auch bei Ausfällen jederzeit verfügbar.
5. NATS vs MQTT: Sicherheit
MQTT: Setzt primär auf klassische, einfach handhabbare Security-Mechanismen: TLS-Verschlüsselung, Benutzername/Passwort und häufig ACLs pro Topic. Viele Broker bieten zudem Unterstützung für x.509-Zertifikate. Insgesamt ist die Sicherheitskonfiguration eher standardisiert und schnell einsatzbereit.
NATS: Unterstützt ebenfalls TLS, geht aber deutlich weiter: Es bietet mehrere parallele Authentifizierungsmodelle (u. a. Tokens, Nkeys, JWTs) und mit dem integrierten Accounts- und Operator-Modell eine viel granularere, hierarchische Sicherheitsarchitektur. Damit ermöglicht NATS komplexe Mandantenstrukturen und feinste Berechtigungskontrolle. Dies eignet sich besonders für große, verteilte oder stark regulierte Architekturen.
6. Nachrichtenzustellung und Zuverlässigkeit
MQTT: MQTT stellt verschiedene Quality of Service Stufen bereit (QoS 0, 1 und 2), um je nach Anwendungsfall eine garantierte Zustellung von Nachrichten sicherzustellen. Bei QoS 1 (“at least once”) garantiert der Broker die Ankunft jeder Nachricht mindestens einmal, bei QoS 2 (“exactly once”) sogar genau einmal. Dies ist wichtig für kritische Daten, die keinesfalls verloren gehen oder dupliziert ankommen dürfen. Außerdem bietet MQTT eingebaute Retained Messages. Dabei speichert der Broker pro Topic die letzte Nachricht und stellt neuen Abonnenten so immer den aktuellen Wert beim Verbindungsaufbau bereit. Damit fungiert MQTT gewissermaßen als Key-Value-Store des aktuellen Anlagenzustands („Current State“).
NATS: NATS ist im Kern auf Fire-and-Forget getrimmt. Ohne Erweiterungen werden Nachrichten ohne Persistenz und ohne Zustell-Quittierung übertragen. Das minimiert zwar Latenz und Overhead, bedeutet aber: Sollte ein Subscriber offline sein, geht die Nachricht verloren (keine automatische Wiederholung). In reinen OT-Umgebungen mit MQTT kann dies problematisch sein – je nach Anwendungsfall erwartet man, dass Broker Nachrichten puffern. NATS bietet jedoch mit JetStream eine Option, Zustellgarantien nachzurüsten: JetStream ermöglicht Persistenz, Acknowledgements und At-Least-Once-Delivery durch dauerhaftes Speichern von Nachrichtenstreams. Zusätzlich erweitert JetStream NATS um einen Key-Value-Store, der – anders als MQTT – neben einem echten Current State auch TTL (Time To Live) und Versioning unterstützt. Dadurch können Werte automatisch nach Ablauf einer definierten Zeit gelöscht oder in ihren historischen Versionen abgerufen werden. Allerdings erkauft man sich diese Zuverlässigkeit mit höherem Ressourcenbedarf und Systemkomplexität: JetStream benötigt Disk/SSD oder entsprechenden RAM und ist auf kleinen Edge-Geräten eher nicht einsetzbar.
Zusammenfassung Nachrichteneigenschaften
| Nachrichteneigenschaft | MQTT | NATS (Core + JetStream) |
|---|---|---|
| Current State | ✔ Retained Messages | ✔ Key-Value Store (echter State, inkl. TTL & Versioning) |
| Historie | ❌ | ✔ Streams (vollständige Event-Historie) |
| Replay | ❌ | ✔ Wiederholung alter Events möglich |
| Persistenz | begrenzt (1 Retain-Wert) | ✔ Streams + Key-Value Store |
| TTL / Versioning | ❌ | ✔ unterstützt durch KV Store |
| Offline Clients erhalten Wert | ✔ Retain | ✔ Persistenz + Replay |
| Exactly-Once Delivery | ✔ QoS 2 | ❌ nur „effectively once“, consumer-abhängig |
| At-Least-Once Delivery | ✔ QoS 1 | ✔ JetStream (Acks + Persistenz) |
| At-Most-Once Delivery | ✔ QoS 0 | ✔ Core (Standardverhalten) |
| Speicherbedarf für State | niedrig (1 Wert pro Topic) | höher (Streams & KV benötigen Disk/RAM) |
| Handling Offline Clients | sehr gut (Retain + Session Store) | gut mit JetStream, ❌ Core ohne Persistenz |
| Latenz | niedrig (ms-Bereich) | sehr niedrig (µs–ms); JetStream etwas höher |
| Ressourceneinsatz | sehr gering (OT-Gerät freundlich) | Core gering, JetStream mittel (Edge freundlich) |
7. NATS vs MQTT: Datenstrukturierung im Namespace
MQTT: MQTT nutzt strukturierte Topics wie Fabrik1/Halle3/Linie2/MaschineX/Temperatur, die sich gut dazu eignen, Anlagen- oder Datenmodelle logisch abzubilden. Wildcards ermöglichen es, ganze Teilbereiche des Namensraums abzurufen (z. B. alle Temperaturen in Halle 3). Durch die weite Verbreitung in der Industrie haben sich für MQTT-Topic-Strukturen faktische Best Practices etabliert, was in vielen Projekten die Vereinheitlichung des Namensraums erleichtert und die Umsetzung eines gemeinsamen „Datenbaums“ im Unified Namespace unterstützt.
NATS: NATS verwendet Subjects, die funktional ähnlich zu MQTT-Topics sind, z. B. Fabrik1.Halle3.Linie2.MaschineX.Temperatur. Auch hier lassen sich Daten über Wildcards selektiv abonnieren. Da das Subject-Modell frei gestaltbar ist, können Unternehmen dieselben hierarchischen Strukturen nutzen, die sie aus MQTT kennen – lediglich mit einem anderen Trenner. In der Praxis bedeutet das: Ein konsistenter UNS-Namensraum lässt sich in NATS genauso abbilden wie in MQTT, er muss jedoch – wie bei MQTT auch – über interne Naming-Konventionen definiert, dokumentiert und eingehalten werden.
Globaler Namespace über mehrere Standorte
Ein wichtiger Unterschied zwischen MQTT und NATS zeigt sich bei einem UNS über mehrere Standorte. MQTT bietet im Standard keinen Multi-Site-Namespace. Jeder MQTT-Broker und jedes MQTT-Cluster bleiben eine lokale Einheit, die ihren Namespace nur innerhalb dieses Standorts verwalten. Hersteller lösen das deshalb mit eigenen, oft sehr unterschiedlichen Bridge- oder Replikationsmechanismen. NATS hingegen ermöglicht mit dem Supercluster-Modell eine native und vollständig integrierte Föderation über mehrere Werke hinweg.
Konkretes Beispiel: Werk A (Deutschland) Werk B (USA) und Enterprise Broker C. Beide Werke betreiben eigene lokale UNS-Strukturen.
- MQTT: Alle drei Broker betreiben jeweils eigene, voneinander unabhängige Topic-Namespaces.
- Broker A: FactoryA/Line1/Press/Temperature
- Broker B: FactoryB/Line3/Cutter/Speed
- Broker C (Enterprise-Broker): Enterprise/FactoryA/Line1/Press/Temperature; Enterprise/FactoryB/Line3/Cutter/Speed
- NATS: Es entsteht kein separater Enterprise-Broker wie im MQTT-Beispiel. Werk A und Werk B bilden im NATS-Supercluster einen einzigen globalen Namespace.
- Broker A: FactoryA.Line1.Press.Temperature
- Broker B: FactoryB.Line3.Cutter.Speed
Wie ein globaler Namespace mit MQTT entsteht
Um einen gemeinsamen Namespace aufzubauen, müssen MQTT-Broker A, B und C über proprietäre Bridges miteinander verbunden werden (abhängig vom Broker-Hersteller). Jeder Broker verwaltet weiterhin seinen eigenen lokalen Namespace. Der Enterprise-Broker C erhält lediglich replizierte Topics aus A und B und bildet daraus einen separaten „Enterprise-Namespace“. Typische Konfigurationen sehen dann so aus:
- Bridge A → C
- Bridge B → C
- optional zusätzlich: Bridge C → A sowie C → B (z. B. für Befehle oder Rückmeldungen)
Damit die Replikation zuverlässig funktioniert, müssen die Bridges zusätzlich:
- Retained Messages sauber abgleichen
- QoS-Level korrekt übertragen
- Loop-Prevention manuell absichern
- ACLs, Authentifizierung und Zertifikate pro Bridge definieren
- Topic-Auswahl und Mappings explizit konfigurieren
Wichtig: Broker C hält keinen echten globalen Namespace, sondern lediglich eine replizierte Kopie ausgewählter Daten aus A und B. A und B bleiben weiterhin separate MQTT-Cluster, mit eigenen Retains, eigenen Sessions und eigenen Subscriptions. Damit entsteht kein konsistenter, übergreifender Namespace – nur drei unabhängige Broker, die über Bridges Daten austauschen.
Wie ein globaler Namespace mit NATS entsteht
Mehrere Standorte – zum Beispiel Werk A und Werk B – betreiben jeweils ihr eigenes lokales NATS-Cluster. Diese werden dann über ein gemeinsames Supercluster zu einem einzigen globalen Messaging-System zusammengeschlossen. Die lokalen Cluster bleiben autark und können unabhängig skalieren, sind aber über sogenannte Gateways föderiert. Dadurch teilen sich die Standorte automatisch:
- Routing-Informationen
- Subscriber-Aware („only send when needed“)
- Subjects
- Optional: Persistente State-Replikation (JetStream)
Wichtig: Es entsteht kein separater Enterprise-Broker wie im MQTT-Beispiel. Werk A und Werk B bilden im NATS-Supercluster einen einzigen globalen Namespace. Die Subjects FactoryA.Line1.Press.Temperature und FactoryB.Line3.Cutter.Speed sind darin automatisch gemeinsam verfügbar. Ein Subscriber in Werk A kann ohne zusätzliche Konfiguration FactoryB.> abonnieren – und erhält alle Daten aus Werk B. Umgekehrt gilt dasselbe. Auch übergeordnete Systeme können einfach > abonnieren und erhalten alle Daten aus beiden Standorten. Bridges, Topic-Mappings oder manuelle Replikation entfallen vollständig. Hierduch ensteht der globale Namespace nativ, bleibt konsistent und skaliert ohne zusätzlichen Aufwand mit jedem weiteren Standort.
NATS vs MQTT: Globaler Namespace über mehrere Standorte
| Aspekt | MQTT | NATS |
|---|---|---|
| Multi-Site-Namespace im Standard | ❌ nicht vorhanden | ✔ nativ (Supercluster) |
| Mechanismus | Proprietäre Bridges (Hersteller-spezifisch) | Gateways + Routing im Open-Source-Core |
| Konfiguration | Manuell: pro Topic/Prefix | Automatisch |
| Konflikte | Loops, Duplikate, Retain-Konflikte | Automatische Loop-Prevention, Subscription-aware |
| Skalierung auf viele Werke | exponentiell wachsende Komplexität | linear, beliebig viele Standorte |
| WAN-/Cloud-Federation | Nur mit Enterprise-Erweiterungen, eingeschränkt | Vollständig integriert, Multi-Region optimiert |
| Globaler Namespace | Durch Synchronisation erzeugt, nie „echt“ | Ein einziger föderierter Namespace |
Fazit
Mit MQTT können Sie zwei Standorte verbinden, aber nie ein echtes globales Messaging-System bauen – nur manuelle Synchronisationen. NATS ist dafür konstruiert: ein Supercluster ergibt automatisch und ohne Zusatzkonfiguration einen globalen Namespace über beliebig viele Standorte.
8. Standardisierung und Ökosystem
MQTT: Als offizieller ISO-Standard und dank einfacher Integrationsmöglichkeiten hat MQTT eine breite Akzeptanz in der Industrie. Es existiert ein umfangreiches Ökosystem an Bibliotheken, Tools und Best Practices. Führende Automatisierungsanbieter (Siemens, Rockwell, Beckhoff u.a.) sowie zahlreiche IoT-Plattformen unterstützen MQTT bereits nativ. Für Anwender bedeutet dies, dass die meisten OT-Geräte, SCADA-Systeme oder MES sich vergleichsweise einfach an einen MQTT-basierten Unified Namespace anbinden lassen. Die Community und Ressourcen rund um MQTT sind groß.
NATS: NATS ist bislang kein formaler Industriestandard, sondern „nur“ ein CNCF-gepflegtes Open-Source-Projekt. Im traditionellen OT-Umfeld ist NATS daher noch weniger verbreitet. Nur wenige Geräte oder Softwarepakete bieten von Haus aus einen NATS-Connector. Daher ist oft eine zusätzliche Gateway Schicht wie i-flow Edge notwendig, um bestehende Maschinen an NATS anzubinden. Dies kann zwar die Einstiegshürde erhöhen, alerdings genießt NATS in der Cloud-nativen Community stark wachsendes Interesse. Die Community ist Stand heute zwar kleiner als die von MQTT, aber sehr engagiert und treibt kontinuierlich neue Clients und Features voran.
NATS vs MQTT: Zusammenfassung
Die folgende Tabelle zeigt die zentralen Gemeinsamkeiten von MQTT und NATS, die beide Protokolle grundsätzlich für einen Unified Namespace geeignet machen.
| Bereich | MQTT | NATS |
|---|---|---|
| Architekturprinzip | Broker-basiertes Messaging | Broker-/Cluster-basiertes Messaging |
| Publish/Subscribe | Unterstützt | Unterstützt |
| Wildcard-Subscriptions | Unterstützt (+ und #) | Unterstützt (* und >) |
| Strukturierbarer Namespace | Hierarchische Topics („/“) | Flache Subjects („.“), frei hierarchisierbar |
| Verwendung im UNS | Geeignet für zentrale Datenräume und Events | Geeignet für zentrale Datenräume und Events |
| TLS-Verschlüsselung | Unterstützt | Unterstützt |
| Benutzer/Passwort-Auth | Unterstützt | Unterstützt |
| Hohe Skalierbarkeit | Viele Geräte (Edge/OT) | Sehr hohe Nachrichtenrate (Cloud/Edge) |
| Open Source Ökosystem | Viele Broker & Clients verfügbar | CNCF-gepflegtes Projekt, Clients verfügbar |
Die folgende Tabelle fasst die wichtigsten Unterschiede von NATS vs MQTT zusammen, insbesondere mit Blick auf Architektur, Leistungsfähigkeit und Einsatz im UNS.
| Kategorie | MQTT | NATS |
|---|---|---|
| Primäres Einsatzgebiet | OT, Sensorik, ressourcenarme Geräte | Edge-fähig, Cloud-native, High-Performance-Pipelines |
| Messaging-Muster | Publish/Subscribe, Request/Reply (manuell in v5) | Pub/Sub, Request/Reply, Queue-Groups |
| Zustellgarantie | QoS 0/1/2 für garantierte Zustellung | Fire-and-Forget im Core; JetStream für Persistenz & Acks |
| Aktueller Wert (State) | Retained Messages nativ | Kein Retain im Core; JetStream oder App-Logik nötig |
| Security-Features | TLS, Benutzer/Passwort, ACLs, x.509 (abhängig vom Broker) | TLS, Benutzer/Passwort, Tokens, Nkeys, JWTs, Accounts/Operator-Modell |
| Skalierungsfokus | Viele Geräte, moderater Datendurchsatz | Extrem hoher Durchsatz, sehr geringe Latenz |
| Cluster- / Verbundbetrieb | Herstellerspezifische, proprietäre Mechanismen | Im Open-Source Core integrierte Cluster- und Föderationsfunktionalität |
| Echtzeitfähigkeit | Gute Latenz | Sehr geringe Latenz, geeignet für Echtzeit-Pipelines |
| Standardisierung / Verbreitung | ISO-Standard, sehr weite OT-Verbreitung | Kein Industriestandard, weniger OT-native Integrationen |
| Ökosystem | Breit in OT/IIoT (SCADA, MES, PLCs) | Breit in Cloud/Microservices, kleiner im OT |
| UNS-Integration | Ideal für Edge-Geräte & stabile OT-Anbindung | Ideal für High-Performance Edge-to-Cloud Pipelines |
Kombination im Unified Namespace (UNS)
Ein optimales Architekturkonzept – besonders in Unified Namespace (UNS) Architekturen – nutzt die Stärken beider Technologien. MQTT als Edge UNS, während NATS das skalierbare Backbone für den farbik- und unternehmensweiten UNS bildet. Damit lassen sich OT-Daten nahtlos und performant durch alle Ebenen eines Unternehmens transportieren.
MQTT als Edge UNS
MQTT fungiert in dieser Architektur als Edge UNS, also als semantisch strukturierte Datenebene direkt auf dem Shopfloor. Hierbei integriert der MQTT Broker:
- Sensoren
- SPS/Maschinen
- SCADA
- Edge-Devices
- lokale Gateways.
MQTT ist für diese Ebene ideal geeignet, da es: leichtgewichtig ist, geringe Latenzen hat, QoS + Retains und Topic-Hierarchien für stabile OT-Kommunikation bietet und von einigen OT-Systemen (z.B. Sensoren) nativ unterstützt wird. Im Edge UNS werden alle relevanten OT-Daten in einem sauber strukturierten MQTT-Topic-Namespace bereitgestellt. Dies ist die „Single Source of Truth“ für den Shopfloor und die Grundlage für den weiteren Datenfluss in Richtung IT.
NATS als Fabrik UNS
Oberhalb des Edge UNS übernimmt NATS die Rolle des Factory UNS. Hier dient NATS als extrem performante, clusterfähige und horizontal skalierbare Event- und Datenbus-Ebene innerhalb des Werksnetzwerks. Bridges synchronisieren MQTT-Daten aus Edge UNS Topic Namespaces in NATS-Subjects. Dabei werden relevante MQTT-Topics werden abonniert, semantisch transformiert und in Factory-UNS-NATS-Subjects publiziert. Die Daten stehen im Factory UNS sofort für:
- Microservices
- MES
- Quality Appliaktionen
- Produktionsoptimierung
- KI-Modelle
- Event-getriebene Verarbeitung zur Verfügung.
Im Factory UNS lassen sich NATS-Cluster einsetzen, die lokale Redundanz sicherstellen und horizontale Skalierung ermöglichen.
NATS als Enterprise UNS
Eine Ebene höher dient NATS als Enterprise UNS – dem unternehmensweit skalierten Daten-Backbone. Hier werden die Daten aus allen Werken harmonisiert, verteilt oder global analysiert. Ein Enterprise UNS ermöglicht:
- übergreifende Produktionsoptimierung
- globales Asset-Tracking
- zentrale KI-/ML-Modelle
- unternehmensweite Audit- und Compliance-Strukturen
- Integration in Enterprise IT (z.B. ERP)
- Cloud-Plattformen (AWS, Azure, GCP)
- Föderation über NATS-Supercluster über Länder/Standorte hinweg
Die horizontale Skalierbarkeit von NATS erlaubt es, mehrere Werke und Cloud-Regionen in einem einzigen Namespace zu verknüpfen – ohne die Last im Shopfloor zu erhöhen.
Fazit
Sowohl MQTT als auch NATS haben ihre einzigartigen Stärken, und die Wahl zwischen ihnen hängt letztlich vom spezifischen Anwendungsfall ab. Beim Vergleich NATS vs MQTT zeigt sich: MQTT spielt seine Vorteile aus, wenn eine breite Palette an IoT-Geräten mit begrenzten Ressourcen und wechselhaften Verbindungen eingebunden werden soll – hier bieten der etablierte Standard und die gewährleistete Zuverlässigkeit (QoS, Retains) eine sichere Bank. NATS hingegen überzeugt durch überlegene Performance und Skalierbarkeit in datenintensiven, modernen Anwendungen. In vielen Fällen kann eine Kombination beider Ansätze sinnvoll sein: Beispielsweise MQTT für die Kommunikation auf Geräteebene und NATS für hochfrequente Mikrodienste-Interaktionen in der übergeordneten IT-Schicht. Entscheidend ist, die Anforderungen Ihrer Anwendung genau zu prüfen – insbesondere in Bezug auf Datenvolumen, Echtzeitbedarf, vorhandene Infrastrukturen und Integrationsaufwand. Auf dieser Basis lässt sich das Protokoll (oder die Mischung von Protokollen) auswählen, das den größten Mehrwert für Ihren Unified Namespace bietet.
