In fast jedem IIoT-Projekt taucht die gleiche Frage auf: OPC UA oder MQTT? Manchmal steckt dahinter echter Entscheidungsbedarf. Oft steckt dahinter die Hoffnung, dass eine klare Antwort existiert — "nimm X, dann bist du fertig."
Die ehrliche Antwort ist: Es kommt darauf an. Aber "es kommt darauf an" ist nur dann hilfreich, wenn man weiss, worauf es ankommt. Genau das versuche ich hier zu erklären — aus der Perspektive von jemandem, der beide Protokolle regelmässig in realen Fertigungsumgebungen einsetzt.
Was OPC UA ist — und was nicht
OPC UA (Open Platform Communications Unified Architecture) ist ein industrieller Kommunikationsstandard, der 2008 von der OPC Foundation veröffentlicht wurde. Das Entscheidende: OPC UA ist nicht nur ein Transportprotokoll. Es definiert auch ein semantisches Datenmodell.
Was bedeutet das konkret? Wenn eine Siemens S7-SPS via OPC UA einen Datenpunkt "Spindeldrehzahl" exportiert, dann weiss ein OPC-UA-Client nicht nur, dass der Wert 3.200 ist. Er weiss auch, was dieser Wert bedeutet, welche Einheit er hat, welche Grenzwerte gelten und wann er zuletzt geändert wurde.
Das ist der grosse Vorteil von OPC UA: Daten tragen ihre eigene Bedeutung mit sich. Das macht die Integration deutlich robuster, weil weniger implizites Wissen zwischen Sender und Empfänger vereinbart werden muss.
Was MQTT ist — und warum es so populär wurde
MQTT (Message Queuing Telemetry Transport) wurde 1999 von IBM für Anwendungen in Umgebungen mit schlechter Netzwerkverbindung entwickelt — ursprünglich für Ölpipelines in der Wüste. Leichtgewichtig, robust, niedrige Latenz, minimaler Overhead (der Header braucht nur 2 Bytes).
MQTT ist ein reines Pub/Sub-Protokoll: Geräte (Publisher) senden Nachrichten an Topics. Ein Broker (z.B. Mosquitto oder HiveMQ) verteilt sie an alle Subscriber. Das funktioniert hervorragend — aber MQTT selbst definiert nicht, was in diesen Nachrichten steht. Das müssen Sender und Empfänger vorab vereinbaren.
Wenn eine Maschine via MQTT einen Wert "3200" sendet, weiss der Empfänger davon erst mal nichts — ausser was im Topic-Namen steckt. Ob das Umdrehungen pro Minute, Watt oder Gramm sind, liegt komplett in der Implementierung.
Der direkte Vergleich
| Aspekt | OPC UA | MQTT |
|---|---|---|
| Ursprung | Industriestandard (OPC Foundation, 2008) | IoT-Protokoll (IBM, 1999) |
| Architektur | Client-Server & Pub/Sub (ab v1.04) | Pub/Sub (Broker-basiert) |
| Datenmodell | Typisiert, semantisch (Addressspace) | Payload-agnostisch (binär, JSON, etc.) |
| Semantik | Eingebaut — Daten haben Bedeutung | Keine — Bedeutung muss vereinbart werden |
| Sicherheit | TLS + Zertifikate nativ | TLS optional, Implementierung variiert |
| Overhead | Höher (XML/Binary, Handshake) | Sehr gering (Header: 2 Bytes) |
| Latenz | Niedrig bis mittel | Sehr niedrig |
| Eignung | Maschinenanbindung, OT-Integration | Sensor→Cloud, Edge→Backend |
Wann ich OPC UA empfehle
OPC UA ist die richtige Wahl, wenn die Verbindung zur Maschinensteuerung im Vordergrund steht — also wenn Sie Daten direkt aus einer SPS, einem CNC-Controller oder einem SCADA-System lesen wollen.
- Maschinenanbindung: Siemens, Beckhoff, B&R, Bosch Rexroth — diese SPS unterstützen OPC UA nativ. Die Integration ist sauber, typisiert und gut dokumentiert.
- Interoperabilität: Wenn verschiedene Maschinen von verschiedenen Herstellern integriert werden sollen, gibt es mit OPC UA einen gemeinsamen Standard. Mit MQTT müssen Sie für jede Maschine eine eigene Topic-Struktur definieren.
- IT/OT-Integration: OPC UA hat einen klaren Sicherheitsrahmen (Zertifikate, Authentifizierung, verschlüsselte Sessions). Das ist in regulierten Umgebungen und überall dort relevant, wo IT- und OT-Netze verbunden werden.
- Semantische Anforderungen: Wenn Datenpunkte in verschiedenen Systemen konsistent interpretiert werden sollen — z.B. in Historian, SCADA und Analytics gleichzeitig — ist das typisierte Datenmodell von OPC UA ein erheblicher Vorteil.
Wann ich MQTT empfehle
MQTT ist die richtige Wahl für alles, was zwischen Edge-Device und Backend passiert — besonders wenn viele Datenpunkte mit hoher Frequenz übertragen werden müssen und die Netzwerkverbindung unzuverlässig sein kann.
- Sensor-Anbindung: Raspberry Pi, Arduino, ESP32 — diese Geräte haben selten OPC UA implementiert. MQTT läuft auf allen davon, mit minimalen Ressourcen.
- Offline-Fähigkeit: MQTT-Broker können Nachrichten puffern (QoS Level 1 und 2), bis der Subscriber wieder erreichbar ist. Das ist in Produktionsumgebungen mit instabilem Netz wertvoll.
- Hoher Durchsatz: Wenn 500 Datenpunkte pro Sekunde übertragen werden sollen, ist MQTT durch seinen minimalen Overhead deutlich effizienter als OPC UA.
- Cloud-Anbindung: AWS IoT Core, Azure IoT Hub, Google Cloud IoT — alle grossen Cloud-Plattformen sprechen MQTT nativ. OPC UA braucht dort immer einen Adapter.
Die häufigste Antwort in der Praxis: Beide
In fast allen Projekten, die wir umsetzen, kommen beide Protokolle zum Einsatz — an unterschiedlichen Stellen der Architektur. Das sieht typisch so aus:
SPS (Siemens S7) ──OPC UA──▶ Edge-Gateway
Edge-Gateway ──MQTT──▶ Broker (Mosquitto/HiveMQ)
Broker ──MQTT──▶ InfluxDB / Grafana / Backend
OPC UA liest die Maschinensteuerung aus — typisiert, semantisch korrekt, mit Zertifikatsauthentifizierung. Das Edge-Gateway (typisch ein industrieller PC oder Raspberry Pi) normalisiert die Daten und überträgt sie per MQTT weiter — leichtgewichtig, offline-fähig, cloud-kompatibel.
Das ist kein Kompromiss. Es ist die Architektur, die die Stärken beider Protokolle an der richtigen Stelle nutzt.
Praktische Entscheidungshilfe
Maschine hat OPC UA nativ?
→ OPC UA direkt nutzen.
Maschine hat proprietäre Schnittstelle (FOCAS, SHDR, Siemens S5)?
→ Adapter auf Edge-Gateway, Ausgabe per MQTT.
Sensor ohne Netzwerkprotokoll (analog, digital I/O)?
→ Edge-Gateway mit Sensor-Hardware, Ausgabe per MQTT.
Daten sollen in Cloud-Plattform (Azure, AWS)?
→ MQTT zum Broker, dann weiter.
Mehrere Maschinen verschiedener Hersteller sollen vereinheitlicht werden?
→ OPC UA als Zielprotokoll, Adapter wo nötig.
Sehr hohe Datenrate (>100 Punkte/s)?
→ MQTT bevorzugen.
Regulierte Umgebung, Audit-Anforderungen?
→ OPC UA wegen Sicherheits- und Authentifizierungsrahmen.
Was MQTT Sparkplug B ändert
Ein kurzer Hinweis für alle, die tiefer einsteigen wollen: MQTT Sparkplug B ist eine Spezifikation, die auf MQTT aufbaut und ein standardisiertes Datenmodell und Topic-Struktur für Industrieanwendungen definiert. Es versucht, den semantischen Vorteil von OPC UA auf MQTT zu übertragen.
In der Praxis sehen wir Sparkplug B vor allem bei Greenfield-Projekten mit einheitlicher Infrastruktur. Für gemischte Umgebungen mit Legacy-Maschinen bleibt OPC UA die robustere Wahl auf der Maschinenebene.
Fazit
OPC UA und MQTT sind keine Konkurrenten — sie lösen unterschiedliche Probleme an unterschiedlichen Stellen einer IIoT-Architektur. Die Frage "OPC UA oder MQTT?" ist oft die falsche Frage. Die richtige Frage ist: "Was soll wo übertragen werden, unter welchen Bedingungen, mit welchen Anforderungen an Sicherheit und Semantik?"
Wenn Sie diese Fragen für Ihre konkrete Situation durchsprechen wollen — welche Maschinen Sie haben, welche Protokolle sie sprechen und wie eine pragmatische Architektur aussehen würde: Melden Sie sich.