OPC UA vs. MQTT — Semantik oder schlanker Transport?

OPC UA: gut geeignet für

• ✓Wenn Maschinen verschiedener Hersteller zusammenarbeiten sollen, weil OPC UA eine herstellerunabhängige, gemeinsame Sprache ist.
• ✓Wenn Daten sich selbst erklären müssen, weil jeder Wert Name, Einheit und Datentyp direkt bei sich trägt.
• ✓Wenn Sicherheit Pflicht ist, weil Verschlüsselung, Signierung und Zertifikate fest eingebaut sind.
• ✓Wenn du komplexe Anlagen sauber abbilden willst, weil sich ganze Anlagen als übersichtlicher Baum aus Bauteilen, Messwerten und aufrufbaren Funktionen abbilden lassen.
• ✓Wenn du plattformunabhängig bleiben willst, weil OPC UA auf Windows, Linux und auf kleinen, fest in Geräte eingebauten Steuer-Computern läuft.

OPC UA: weniger geeignet für

• ✗Für kleinste, batteriebetriebene Sensoren mit sehr wenig Rechenleistung, hier ist ein leichtgewichtiges Protokoll wie MQTT oder CoAP (schlanke Protokolle für stromsparende Geräte) oft passender.
• ✗Für sehr einfache Abfragen einzelner Zahlenwerte ohne Bedeutungsbedarf, wo das schlanke Modbus TCP (ein sehr einfacher, alter Standard für nackte Zahlenwerte) genügt und weniger Aufwand macht.
• ✗Für harte Echtzeit im Mikrosekunden-Takt zwischen Steuerung und Antrieb, dort sind Feldbus-Systeme wie EtherCAT oder PROFINET (blitzschnelle Direktverbindungen in der Steuerungsebene) zuständig.
• ✗Für die Verteilung an sehr viele Empfänger gleichzeitig ist das klassische Frage-Antwort-Muster von OPC UA schwach; hier braucht es entweder MQTT (das über einen Broker, eine Verteilstation, Nachrichten an viele weiterreicht) oder die neuere PubSub-Betriebsart von OPC UA selbst, die mit wachsender Empfängerzahl besser zurechtkommt.

MQTT: gut geeignet für

• ✓Viele Geräte, kleine Nachrichten: Ein Broker verteilt mühelos Messwerte von Tausenden Sensoren gleichzeitig.
• ✓Schmale Bandbreite: Der Verwaltungsanteil pro Nachricht (Overhead) ist extrem klein, eine komplette Datennachricht kommt mit wenigen Bytes plus Topic-Name aus, ein Bruchteil eines HTTP-Requests.
• ✓Instabile Verbindungen: Quittungsmechanismen (QoS) und die Abschiedsnachricht Last Will fangen Verbindungsabbrüche sauber ab.
• ✓Entkopplung: Sender und Empfänger kennen sich nicht, dadurch lassen sich neue Abonnenten jederzeit ergänzen, ohne die Sender anzufassen.
• ✓Firewall-freundlich: Der Client (so heisst jedes angeschlossene Gerät oder Programm) baut die Verbindung immer selbst nach aussen zum Broker auf. Auf der Geräteseite muss keine Tür in der Firewall (ein sogenannter Port) von aussen geöffnet werden; erreichbar sein muss nur der Broker.

MQTT: weniger geeignet für

• ✗Harte Echtzeit im Maschinentakt: Wenn jede Millisekunde zählt, etwa bei der Steuerung von Maschinenachsen, sind spezialisierte Maschinen-Netzwerke die richtige Wahl (Fachbegriffe: Feldbusse oder Industrial Ethernet, etwa PROFINET und EtherCAT).
• ✗Grosse Dateien: MQTT ist für kurze Meldungen gebaut, für Firmware-Updates, Bilder oder Videos eignet sich ein Dateitransfer über HTTP oder ein spezialisiertes Protokoll besser.
• ✗Klassisches Frage-Antwort-Muster: Wer gezielt eine Antwort auf eine Anfrage braucht, etwa eine App, die auf Knopfdruck Daten abruft, fährt mit HTTP, der gewohnten Web-Technik, meist einfacher.
• ✗Direktverbindungen ohne Infrastruktur: MQTT braucht immer einen Broker, für eine simple Punkt-zu-Punkt-Verbindung zwischen zwei Geräten ist das zu viel des Guten.