Inhalt
Was ist der Unterschied in einem Satz?
OPC UA ist ein Informationsmodell mit Transport, MQTT ein Transport ohne Informationsmodell. OPC UA beschreibt, was ein Wert bedeutet — Typ, Einheit, Zugehörigkeit, Zugriffsrechte. MQTT bringt ihn nur von A nach B und überlässt die Bedeutung Ihrer Konvention. Alles Weitere folgt aus diesem einen Unterschied.
Wie unterscheiden sich die beiden im Detail?
| Kriterium | OPC UA | MQTT |
|---|---|---|
| Informationsmodell | Im Standard enthalten: typisierte Knoten, Referenzen, Einheiten, Companion Specifications je Branche | Keins. Bedeutung entsteht aus Topic-Struktur und Payload-Konvention, die Sie selbst festlegen und durchsetzen |
| Discovery | Eingebaut. Der Adressraum ist zur Laufzeit durchsuchbar; ein Client findet Knoten ohne Vorwissen | Nicht vorhanden. Topics müssen bekannt sein oder über eine Konvention erschlossen werden |
| Kommunikationsmuster | Client/Server (Request, Subscribe) und seit 1.04 zusätzlich PubSub | Publish/Subscribe über einen Broker, mit QoS 0/1/2 |
| Latenz | Session-basiert; typisch niedrige zweistellige Millisekunden im LAN. Der Verbindungsaufbau ist teuer, die laufende Session günstig | Sehr gering im Steady State. QoS 2 kostet zwei zusätzliche Roundtrips, QoS 0 keinen |
| Payload-Größe | Binärkodierung kompakt, JSON-Kodierung deutlich größer. Der Adressraum-Overhead fällt beim Verbindungsaufbau an, nicht je Wert | Header ab 2 Byte. Die tatsächliche Größe bestimmt allein Ihr Payload-Format |
| Security-Modell | Im Standard: X.509-Zertifikate je Anwendung, Signierung und Verschlüsselung auf Nachrichtenebene, Benutzerrechte im Adressraum | TLS auf Transportebene. Authentifizierung und Rechte hängen am Broker und sind zwischen Implementierungen unterschiedlich |
| Firewall-Verhalten | Server steht im Werk, Verbindungen kommen eingehend an. Über Werksgrenzen hinweg braucht es eine Freigabe oder einen Reverse-Tunnel | Ausgehende Broker-Verbindung. Kommt durch NAT und restriktive Firewalls, ohne eingehende Ports zu öffnen |
| Broker-Abhängigkeit | Keine im Client/Server-Modus. PubSub kann optional über einen Broker laufen | Zwingend. Der Broker ist Single Point of Failure und muss betrieben, skaliert und abgesichert werden |
| Eignung an der Edge | Ressourcenbedarf real: Stack, Zertifikatsspeicher, Adressraum. Für Kleinstgeräte meist zu viel | Läuft auf Mikrocontrollern. Der Client ist in wenigen Kilobyte implementierbar |
| Werkzeugunterstützung | Ausgereift auf Steuerungsseite: nahezu jede moderne SPS bringt einen Server mit. Auf Auswertungsseite schmaler | Ausgereift auf Auswertungsseite: Broker, Bridges, Stream-Anbindungen überall. Auf Steuerungsseite oft nachgerüstet |
Wann trägt OPC UA?
Wenn die Semantik mitreisen soll. Sobald Maschinen verschiedener Hersteller dasselbe Konzept — Werkzeug, Auftrag, Zustand, Störung — vergleichbar liefern müssen, spart ein standardisiertes Informationsmodell genau die Abbildungsarbeit, die sonst in jedem Integrationsprojekt neu anfällt.
Das eigentliche Argument sind dabei nicht die Protokollmechanismen, sondern die Companion Specifications: branchenweit abgestimmte Modelle, die festlegen, wie eine Spritzgießmaschine oder ein Roboter ihre Daten benennen. Wo eine solche Spezifikation existiert und die Hersteller sie umsetzen, ist die Integration einmalig statt je Gerät.
Der zweite Fall ist Discovery. Wenn Sie zur Laufzeit wissen müssen, was eine Anlage überhaupt anbietet — weil sich der Bestand ändert oder weil Sie nicht für jede Maschine ein Datenblatt pflegen wollen —, ist ein durchsuchbarer Adressraum der Unterschied zwischen Betrieb und Betreuung.
Wann trägt MQTT?
Wenn Menge, Frequenz und Netzgrenzen dominieren. Eine ausgehende Broker-Verbindung kommt durch Firewalls, die eingehende OPC-UA-Verbindungen nicht durchlassen — und genau das ist der Regelfall, sobald Daten das Werk verlassen sollen.
Der zweite Fall ist Gerätevielfalt bei knappen Ressourcen. Ein MQTT-Client passt auf einen Mikrocontroller; ein OPC-UA-Server tut das in der Regel nicht. Wer hunderte kleiner Sensorknoten anbindet, hat praktisch keine Wahl.
Der dritte Fall ist Entkopplung. Der Broker trennt Erfassung von Auswertung: Fällt die Auswertung aus, laufen die Messwerte weiter und werden später verarbeitet. Bei einer direkten Client/Server-Verbindung fehlen sie.
Wie sieht die Kombination in der Praxis aus?
Die verbreitetste Architektur ist nicht entweder/oder, sondern OPC UA an der Maschine, MQTT über die Standortgrenze. Ein Edge-Knoten spricht OPC UA gegen die Steuerung, normalisiert die Werte und publiziert sie über MQTT weiter.
Damit bleibt die Semantik dort, wo sie entsteht — nah an der Anlage, wo sie überprüfbar ist —, und der Transport nach außen ist schlank und firewallfreundlich. In unseren IIoT-Projekten liegt genau an dieser Stelle die Grenze zwischen den Verarbeitungsstufen: Geräteanbindung in einer eigenen Stufe, Ingest über MQTT, Weiterverarbeitung über Kafka. Eine neue Geräteklasse berührt dann nur die erste Stufe.
Was kostet MQTT an Governance, das OPC UA mitbringt?
Diese Rechnung wird regelmäßig übersehen. Was OPC UA im Standard mitliefert, müssen Sie bei MQTT selbst herstellen und über Jahre durchhalten:
- Topic-Struktur. Wer legt fest, wie ein Topic aufgebaut ist? Ohne verbindliche Konvention entsteht innerhalb eines Jahres ein Wildwuchs, den niemand mehr abfragen kann.
- Payload-Schema. JSON ohne Schema ist ein Versprechen, kein Vertrag. Spätestens wenn ein Hersteller ein Feld umbenennt, merkt man den Unterschied — im besten Fall im Test, im schlechteren im Betrieb.
- Einheiten und Skalierung. Ist der Wert in Watt oder Kilowatt? OPC UA schreibt es an den Knoten. Bei MQTT steht es in der Dokumentation, die niemand liest.
- Zugriffsrechte. Broker-seitige Topic-ACLs sind implementierungsabhängig und müssen gepflegt werden.
Nichts davon ist ein Argument gegen MQTT. Es ist ein Argument dafür, diese Punkte vor dem ersten produktiven Topic zu entscheiden statt danach.
Wie verhalten sich beide an der Firewall?
OPC UA im Client/Server-Modus verlangt, dass der Client den Server erreicht. Über Werksgrenzen hinweg heißt das: eingehende Freigabe, VPN oder Reverse-Tunnel — organisatorisch aufwendig und in vielen Betrieben schlicht nicht genehmigungsfähig.
MQTT dreht die Richtung um. Das Gerät baut die Verbindung nach außen auf und hält sie offen; die Firewall sieht eine gewöhnliche ausgehende TLS-Verbindung. Das ist der Grund, warum MQTT die Standortgrenze in der Praxis fast immer gewinnt, unabhängig davon, was an der Maschine läuft.
Was ist mit Sparkplug B?
Sparkplug B ist der Versuch, MQTT das nachzurüsten, was ihm fehlt: eine verbindliche Topic-Struktur, ein definiertes Payload-Format und ein Zustandsmodell mit Geburts- und Todesnachrichten, damit ein Konsument weiß, ob ein Gerät gerade schweigt oder ausgefallen ist.
Das löst einen Teil des Governance-Problems und ist eine ernsthafte Option, wenn die Alternative selbstgebaute Konventionen wären. Es ersetzt aber kein branchenweit abgestimmtes Informationsmodell: Sparkplug normiert die Form, nicht die Bedeutung. Ob „Temp_1" die Vorlauftemperatur ist, steht dort so wenig wie in nacktem MQTT.
Und wenn die Steuerung keins von beidem spricht?
Dieser Fall ist häufiger, als Herstellerpräsentationen vermuten lassen — besonders bei Anlagen, die zehn oder zwanzig Jahre laufen sollen. Dann bleibt die proprietäre Schnittstelle, für die es Dokumentation im günstigen Fall als PDF gibt.
Wir haben für solche Steuerungen mehrfach eigene Transportimplementierungen gebaut und sie hinter derselben Geräteanbindungsstufe versteckt, hinter der auch OPC UA und Modbus liegen. Nach oben sieht die Plattform keinen Unterschied. Das ist unspektakulär, aber es ist der Grund, warum die Auswertung nicht jedes Mal angefasst werden muss, wenn ein Gerät hinzukommt.
Wie wir entscheiden
Drei Fragen, die sich ohne Projekt beantworten lassen:
- Muss die Bedeutung mitreisen, oder reicht der Wert? Wenn mehrere Hersteller dasselbe Konzept vergleichbar liefern müssen: OPC UA, und zwar wegen der Companion Specification, nicht wegen des Protokolls.
- Wo verläuft die Netzgrenze? Sobald Daten das Werk verlassen: MQTT nach außen, unabhängig davon, was innen läuft.
- Wer pflegt die Konvention in drei Jahren? Gibt es darauf keine Antwort, ist der Governance-Aufwand von MQTT unterschätzt — dann ist entweder OPC UA die ehrlichere Wahl oder Sparkplug B das Minimum.
Wenn Sie an dieser Entscheidung stehen: Wir schauen uns die konkrete Anlagenlandschaft an und sagen Ihnen, welche der drei Fragen bei Ihnen den Ausschlag gibt. Details unter Industrial IoT & Automatisierung.