Modbus, MQTT, OPC-UA: Welches Industrieprotokoll soll man 2026 wählen?

· 14 Minuten Lesezeit
14 min read
Eziwan-Team
Eziwan-Team
IoT-Infrastruktur

Die Frage „Welches Protokoll soll ich für mein industrielles IoT-Projekt verwenden?“ taucht bei Projekten zur Modernisierung von Fabriken immer wieder auf. Modbus, MQTT und OPC-UA sind die drei am häufigsten genannten Protokolle – doch sie sind keine gleichwertigen Alternativen. Sie arbeiten auf unterschiedlichen Ebenen, erfüllen unterschiedliche Anforderungen und ergänzen sich oft eher, als dass sie miteinander konkurrieren.

Dieser Artikel erläutert die grundlegenden Unterschiede, Stärken und Grenzen dieser Protokolle und bietet Ihnen eine Entscheidungshilfe, um das für Ihren Anwendungsfall geeignete Protokoll auszuwählen.

Zunächst einmal: Protokolle unterschiedlicher Art​

Bevor man einen Vergleich anstellt, muss man verstehen, dass Modbus, MQTT und OPC-UA nicht auf derselben Ebene arbeiten:

Modbus ist ein Protokoll zum Auslesen von Daten: Es ermöglicht es, ein Gerät abzufragen, um dessen Register (Messwerte, Zustände) auszulesen. Es handelt sich um ein Feldprotokoll im Master-Slave-Prinzip, das für die Datenerfassung an industriellen Anlagen konzipiert ist.

MQTT ist ein Nachrichtenübermittlungsprotokoll: Es ermöglicht das Veröffentlichen und Abonnieren von Datenströmen über einen zentralen Broker. Es handelt sich um ein Protokoll zur Übertragung von Nachrichten, nicht um eine direkte Datenerfassung auf einem Gerät.

OPC-UA ist eine Dienstarchitektur: Sie vereint Datenerfassung, Zugriff auf das Datenmodell, Sicherheit, Alarme und Historien in einem einzigen, einheitlichen Industriestandard. Es ist die umfassendste – und komplexeste – Lösung.

In der Praxis: Die meisten modernen industriellen IoT-Architekturen nutzen alle drei Protokolle. Modbus zum Auslesen der Feldgeräte, MQTT zum Transport der Daten in die Cloud und OPC-UA für die Interoperabilität zwischen komplexen Systemen.

Modbus RTU und Modbus TCP​

Was ist Modbus?​

Modbus wurde 1979 von Modicon (heute Schneider Electric) entwickelt. Es ist das älteste noch aktiv genutzte Industrieprotokoll – und in der französischen Industrie mit Abstand das am weitesten verbreitete.

Modbus RTU wird über eine serielle RS-485-Verbindung (oder RS-232) betrieben. Es handelt sich um ein asynchrones Master/Slave-Protokoll mit einer linearen Bus-Topologie (Multidrop). An einem einzigen RS-485-Bus können bis zu 247 Slaves angeschlossen werden.

Modbus TCP ist Modbus, der in TCP/IP-Pakete gekapselt ist. Es läuft über Ethernet, Port 502. Es behält das Master-Slave-Modell bei, ermöglicht jedoch beliebige Netzwerktopologien (Stern, Baum). Es gibt keine strenge Begrenzung der Anzahl der Slaves auf Netzwerkebene.

Was lässt sich über Modbus auslesen?​

Modbus stellt 4 Datentypen bereit:

  • Coils (0x): digitale Lese-/Schreib-Ausgänge (Boolesche Werte)
  • Discrete Inputs (1x): digitale Lese-Ausgänge (Boolesche Werte)
  • Input Registers (3x): 16-Bit-Register (nur Lesezugriff) (Sensorwerte)
  • Holding Registers (4x): 16-Bit-Register (Lese-/Schreibzugriff) (Sollwerte, Parameter)

Um einen Temperaturmesswert von einem Sensor auszulesen: Der Master sendet eine Anfrage „Register 3x01 bis 3x02 auslesen“, woraufhin der Slave mit den beiden Registern antwortet, die den Wert enthalten (in der Regel ein 32-Bit-Float-Wert, verteilt auf zwei benachbarte Register).

Vorteile von Modbus​

Absolute Universalität: Wenn Sie ein Industriegerät mit einem RS-485-Anschluss oder einem Ethernet-Anschluss haben und nicht wissen, welches Protokoll es verwendet, probieren Sie zunächst Modbus aus. Die Wahrscheinlichkeit ist sehr hoch, dass es Modbus unterstützt.

Einfachheit: Das Protokoll ist einfach – nummerierte Register, Standard-Lese-/Schreibfunktionen. Jeder Entwickler kann innerhalb weniger Stunden einen Modbus-Client implementieren.

Ausfallsicherheit: Keine Abhängigkeit von einem Broker oder einem zentralen Server. Der Master fragt jeden Slave direkt ab. Ein Ausfall des Masters hat keine Auswirkungen auf die Kommunikation zwischen den Slaves untereinander.

Ausgereiftheit: 45 Jahre industrielle Nutzung. Modbus-Bibliotheken gibt es für alle Programmiersprachen (Python, C, Java, JavaScript ...).

Einschränkungen von Modbus​

Reine Pull-Architektur: Der Master muss jeden Slave proaktiv abfragen. Die Geräte senden nicht von sich aus Daten. Bei einem Bus mit 50 Slaves, die jede Sekunde abgefragt werden, kann die tatsächliche Abfragefrequenz pro Slave auf 20 Sekunden sinken.

Keine integrierte Sicherheit: Modbus RTU und Modbus TCP verfügen über keinerlei Authentifizierungs- oder Verschlüsselungsmechanismen. Jedes Gerät im Netzwerk kann die Register eines ungeschützten Modbus-Geräts lesen oder beschreiben. Sicherheitsmaßnahmen müssen auf Netzwerkebene getroffen werden (VPN, Segmentierung).

Keine automatische Erkennung: Es gibt keinen Mechanismus zur Erkennung von Modbus-Geräten auf einem Bus. Sie müssen die Slave-Adresse und die Registeradressen jedes einzelnen Geräts kennen.

Keine semantische Benennung: Das Register 40001 gibt keinen Hinweis auf seinen Inhalt – man muss die Herstellerdokumentation zu Rate ziehen, um zu erfahren, dass es sich um die „Wassereintrittstemperatur“ handelt. Keine Selbstbeschreibung.

Wann sollte Modbus verwendet werden?​

  • Auslesen von Daten aus Feldgeräten (Energiezähler, Drucksensoren, Frequenzumrichter, SPSen)
  • Bestehende Feldnetzwerke mit vorhandener RS-485-Verkabelung
  • Projekte mit heterogenen Geräten verschiedener Hersteller (Modbus ist am universellsten)
  • Begrenzte Budgets oder Teams ohne Fachkenntnisse

MQTT (Message Queuing Telemetry Transport)​

Was ist MQTT?​

MQTT wurde 1999 von IBM für die Telemetrie über Satellitenverbindungen mit geringer Übertragungsrate entwickelt. Es wurde 2014 (MQTT 3.1.1) und 2019 (MQTT 5.0) von OASIS standardisiert.

MQTT ist ein Publish/Subscribe-Protokoll: Publisher senden Nachrichten an Topics, Subscriber empfangen die Nachrichten zu den Topics, die sie abonniert haben. Ein zentraler MQTT-Broker leitet die Nachrichten zwischen Publishern und Subscribern weiter.

MQTT-Architektur​

Der Broker ist das Herzstück der MQTT-Architektur. Die Clients (Publisher und Subscriber) stellen eine Verbindung zum Broker her – sie kommunizieren niemals direkt miteinander.

Vorteile von MQTT​

Push-Architektur: Die Publisher senden Daten, sobald sie etwas mitzuteilen haben. Kein Polling – der Abonnent erhält die Daten sofort nach der Veröffentlichung. Typische Latenz: 10–50 ms von Ende zu Ende.

Leichtgewichtig: Das Protokoll wurde für Geräte mit begrenzten Ressourcen (Mikrocontroller, 2G-Modems) entwickelt. Eine MQTT-Nachricht kann in 2 Bytes untergebracht werden (minimaler Header). Sehr bandbreitenschonend.

Konfigurierbares QoS: Drei Stufen der Dienstgüte: QoS 0 (höchstens einmal), QoS 1 (mindestens einmal), QoS 2 (genau einmal). Bei kritischen Anwendungen gewährleistet QoS 2, dass die Daten genau einmal zugestellt werden.

Cloud-Interoperabilität: Alle großen Cloud-Anbieter (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) stellen einen nativen MQTT-Broker bereit. MQTT ist das De-facto-Protokoll für IoT-Cloud-Architekturen.

Natives TLS: MQTT unterstützt TLS 1.3 nativ. Die Sicherheit ist in das Protokoll integriert und keine nachträgliche Ergänzung.

Einschränkungen von MQTT​

Kann Geräte nicht direkt auslesen: Ein Modbus-RTU-Gerät unterstützt MQTT nicht von Haus aus. Es wird ein Gateway benötigt, das die Modbus-Daten ausliest und als MQTT-Nachrichten veröffentlicht. Aus diesem Grund werden Modbus und MQTT in industriellen IoT-Architekturen häufig gemeinsam eingesetzt.

Abhängigkeit vom Broker: Fällt der MQTT-Broker aus, bricht die gesamte Messaging-Architektur zusammen. Die Ausfallsicherheit des Brokers ist daher von entscheidender Bedeutung. Verwaltete Broker (AWS IoT, HiveMQ Cloud) sind zwar sehr zuverlässig, führen jedoch zu einer Abhängigkeit von einem externen Dienst.

Kein standardisiertes Datenmodell: MQTT legt weder das Format der Nachrichten noch die Struktur der Topics fest. Jede Implementierung ist frei gestaltbar – was die Interoperabilität beeinträchtigt. Zwei MQTT-Systeme verschiedener Anbieter kommunizieren nicht unbedingt ohne Anpassungen miteinander.

Keine native Anfrage-Antwort-Struktur: MQTT ist auf unidirektionale Ereignisse ausgerichtet. Um ein Anfrage-Antwort-Muster zu implementieren (z. B. eine Abfrage eines Parameters bei einem Gerät), muss MQTT 5.0 mit korrelierten Antwort-Topics verwendet werden – dies ist möglich, jedoch komplexer.

Wann sollte man MQTT verwenden?​

  • Datenübertragung vom Feld in die Cloud (Modbus → Gateway → MQTT → Cloud)
  • Ereignisgesteuerte Architekturen, bei denen sich die Daten unregelmäßig ändern
  • Embedded-IoT-Implementierungen auf Mikrocontrollern oder Geräten mit begrenzten Ressourcen
  • Integration mit nativen Cloud-Brokern (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

Was ist OPC-UA?​

OPC-UA (IEC 62541) wurde ab 2006 von der OPC Foundation als Nachfolger von OPC Classic (basierend auf Windows COM/DCOM) entwickelt. Es handelt sich um den anspruchsvollsten Industriestandard: Er vereint Datenerfassung, semantisches Modell, Sicherheit, Historien, Alarme und den Zugriff auf Methoden in einem einzigen Protokoll.

OPC-UA ist heute das bevorzugte Protokoll der Steuerungshersteller für Industrie-4.0-Architekturen: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation – alle unterstützen OPC-UA seit 5 bis 10 Jahren nativ.

Stärken von OPC-UA​

Semantisches Datenmodell: Im Gegensatz zu Modbus (anonyme, nummerierte Register) stellt OPC-UA eine Baumstruktur aus benannten und typisierten Objekten bereit. Der Knoten „ns=2;i=1001“ kann beispielsweise „Maschine1/Hauptmotor/Lagertemperatur“ heißen und über Metadaten (Einheit, Bereich, Beschreibung) verfügen. Die Selbstbeschreibung ist nativ integriert.

Integrierte Sicherheit: Authentifizierung, Autorisierung, Verschlüsselung, Nachrichtenintegrität – all das ist im Protokoll enthalten. OPC-UA unterstützt mehrere Sicherheitsprofile (None, Sign, SignAndEncrypt) mit modernen Algorithmen (AES-256, RSA-2048+).

Publish/Subscribe über OPC-UA PubSub (2017): OPC-UA kann nun nicht mehr nur im Anfrage-Antwort-Modus (Pull), sondern auch im asynchronen Veröffentlichungsmodus (Push) betrieben werden. Es kann Daten an MQTT-Broker veröffentlichen, wodurch sich OPC-UA und MQTT ergänzen, anstatt miteinander zu konkurrieren.

Zugriff auf Methoden: Mit OPC-UA lassen sich Methoden an Geräten aufrufen – es werden nicht nur Werte ausgelesen. Eine Ventilbetätigung, ein Motorstartbefehl – alles wird als OPC-UA-Objekt modelliert.

Semantik und Interoperabilität: Die OPC-UA-„Companion Specifications“ definieren branchenstandardisierte Modelle: OPC-UA für die Kunststoffindustrie, für die Robotik, für PackML (Verpackung), für den Bergbau … Eine SCADA-Software, die OPC-UA for PackML unterstützt, kann ohne spezielle Konfiguration eine Verbindung zu jeder konformen Verpackungslinie herstellen.

Einschränkungen von OPC-UA​

Komplexität: OPC-UA ist das Protokoll, dessen Implementierung und Konfiguration am komplexesten ist. Die Spezifikationen umfassen mehr als 1000 Seiten. Für Teams ohne Vorkenntnisse in OPC-UA ist die Lernkurve beträchtlich.

Erforderliche Ressourcen: Ein vollwertiger OPC-UA-Server benötigt mehr Ressourcen als ein Modbus-Slave. Ältere SPSen oder Mikrocontroller mit begrenzten Ressourcen können keinen vollständigen OPC-UA-Stack hosten (es gibt jedoch vereinfachte „Nano“-Profile).

Nicht flächendeckend im Feld: Ältere Geräte (vor 2010–2015) unterstützen OPC-UA nicht. In einer heterogenen Industrieumgebung werden Sie bei den vorhandenen Feldgeräten weitaus häufiger auf Modbus als auf OPC-UA stoßen.

Netzwerk-Overhead: OPC-UA-Nachrichten sind umfangreicher als Modbus-Nachrichten (je nach Übertragungsart als XML oder Binärdaten). Bei 4G-Verbindungen mit geringer Übertragungsrate kann dies eine Rolle spielen.

Wann sollte OPC-UA verwendet werden?​

  • Aktuelle Siemens S7-1200/1500-Steuerungen mit TIA Portal (natives OPC-UA)
  • Industrie-4.0-Architekturen mit SCADA/MES/ERP-Interoperabilität
  • Projekte, die ein hohes Maß an Sicherheit und Rückverfolgbarkeit bei den Zugriffen erfordern
  • herstellerübergreifende Umgebungen mit Bedarf an semantischer Interoperabilität

Entscheidungshilfe: Welcher Anzug passt zu Ihrem Projekt?​

Typische einfache industrielle IoT-Architektur​

Anwendungsbereich: Prozessüberwachung, Warnmeldungen, Verlaufsdaten. 80 % der französischen IoT-Projekte im industriellen Bereich entsprechen diesem Schema.

Architektur mit Cloud-Integrationsbus​

Anwendungsbereich: Projekte mit mehreren Datenverbrauchern (SCADA + ERP + BI). MQTT als Integrationsbus.

Industrie 4.0-Architektur mit OPC-UA​

Einsatzbereich: Fabriken mit modernen Steuerungen, Industrie-4.0-Projekte, MES-Integration.

Entscheidungsmatrix​

AnforderungModbus RTUModbus TCPMQTTOPC-UA
RS-485-Feldsensoren auslesen✓✓———
SPSen im Netzwerk auslesen✓✓✓—✓
Daten an die Cloud senden——✓✓✓
SCADA/MES-Interoperabilität✗✗Teilweise✓✓
Integrierte Sicherheit✗✗TLS✓✓
Ältere Geräte✓✓✓—✗
Neuere Steuerungen (>2015)✓✓—✓✓
Cloud-native Architekturen✗✗✓✓✓
KMU ohne Protokoll-Know-how✓✓✓✓✓✗

Wie Eziwan die drei Protokolle verwaltet​

Das Eziwan-Gateway ist unabhängig von den Feldprotokollen:

  • Modbus RTU: nativer RS-485-Anschluss, Master-Modus, bis zu 247 Slaves pro Bus, konfigurierbares Polling von 1 s bis 15 min
  • Modbus TCP: Modbus-TCP-Client, gleichzeitige Verbindungen zu mehreren Modbus-Servern
  • MQTT: MQTT-Publisher (Veröffentlichung der erfassten Daten), Subscriber für Befehle möglich
  • OPC-UA: OPC-UA-Client (Auslesen von Knoten, Abonnieren von Wertänderungen) – auf Anfrage für OPC-UA-Implementierungen verfügbar

In der Cloud werden die Daten intern standardisiert und über folgende Schnittstellen bereitgestellt:

  • REST-API (JSON) für Cloud-Anwendungen
  • Webhooks für Echtzeit-Ereignisse
  • MQTT (ausgehend) für Bus-Integrationen

Sie können Modbus RTU an den Feldgeräten mit MQTT in Ihre AWS-/Azure-Cloud kombinieren, ohne irgendetwas ändern zu müssen – das Gateway übernimmt die Konvertierung.

Fazit​

Im Jahr 2026 lautet die Antwort auf die Frage „Modbus oder MQTT oder OPC-UA?“ in der Regel „alle drei zusammen“:

  • Modbus zum Auslesen Ihrer Feldgeräte (das ist die Sprache, die sie sprechen)
  • MQTT, um die Daten in Ihre Cloud zu übertragen und an mehrere Anwendungen weiterzuleiten
  • OPC-UA, wenn Sie neuere Steuerungen von Siemens, Rockwell oder Beckhoff einsetzen und SCADA/MES-Interoperabilität benötigen

Es handelt sich nicht um einen Wettbewerb – es ist eine mehrschichtige Architektur. Die Frage lautet nicht „Welches Protokoll?“, sondern „Welches Protokoll auf welcher Schicht für welches Gerät?“.

FAQ – Modbus, MQTT und OPC-UA​

Kann man Modbus und MQTT gleichzeitig auf demselben Gateway nutzen?

Ja, und das ist die gängigste Architektur im IIoT. Das Gateway sammelt die Daten der Steuerungen über Modbus TCP oder RTU (Feldebene) und überträgt sie per MQTT in die Cloud (Transportschicht). Modbus endet am Gateway – es wird niemals im Internet exponiert. MQTT übernimmt den Transport in die Cloud, mit TLS 1.3 und Authentifizierung.

Kann OPC-UA Modbus bei bestehenden Steuerungen (S7-1200, M340) ersetzen?

Bei den Siemens S7-1200 ist der OPC-UA-Server erst ab Firmware-Version V4.4 verfügbar und muss im TIA Portal explizit konfiguriert werden. Bei den S7-1500 ist er ab Firmware-Version V2.0 nativ integriert. Bei den Schneider M340-Steuerungen ist OPC-UA nicht nativ integriert – hierfür wäre ein zusätzliches Modul erforderlich. In der Praxis bleibt Modbus TCP für bestehende Anlagen die universelle Lösung; OPC-UA ist vor allem für neue Projekte mit aktuellen Steuerungen relevant.

MQTT mit QoS 0 vs. QoS 1 vs. QoS 2 – was ist die richtige Wahl für die industrielle Überwachung?

Für die Überwachung von Prozessdaten (Temperaturen, Drücke) bietet QoS 1 („At Least Once“) das richtige Gleichgewicht: Die Zustellung ist auch nach einer erneuten Verbindung gewährleistet, wobei es zu einigen Duplikaten kommen kann (was für Überwachungsdaten akzeptabel ist). QoS 2 (Exactly Once) ist aufgrund des Hin- und Rücklaufs der Bestätigung aufwändiger und für Messwerte selten erforderlich. QoS 0 (At Most Once) eignet sich für sehr häufig anfallende Daten (> 1/s), bei denen ein gelegentlicher Verlust akzeptabel ist.

Reicht ein öffentlicher MQTT-Broker (HiveMQ, EMQX Cloud) für Industrieunternehmen aus?

Für Pilotprojekte oder nicht sensible Anwendungen, ja. Für eine Produktion mit Vertraulichkeitsanforderungen (Prozessdaten, Identitäten der Anlagen) ist jedoch ein privater, in Frankreich gehosteter Broker vorzuziehen. MQTT-Daten, die über öffentliche US-Broker übertragen werden, unterliegen potenziell dem CLOUD Act – dies ist je nach Sensibilität der Daten und der Branche zu prüfen.

Hat OPC-UA im Vergleich zu Modbus Auswirkungen auf die Leistung der SPS?

OPC-UA beansprucht deutlich mehr CPU-Leistung und Arbeitsspeicher als Modbus TCP. Auf einer S7-1500-CPU 1511 mit einem aktiven OPC-UA-Server und 50 Client-Verbindungen kann sich die Zykluszeit um 5 bis 15 % erhöhen. Auf einer S7-1200 sind die Ressourcen begrenzter – testen Sie daher systematisch die Auswirkungen mit dem vollständigen Produktionsprogramm, bevor Sie OPC-UA im Produktivbetrieb einsetzen.

Weiterführende Informationen​

Weitere Ressourcen​