von DerSchneider<\/p>\n\n\n\n
Wer heute \u00fcber Industrie 4.0, IIoT (Industrial Internet of Things) oder die Vernetzung von Produktion spricht, st\u00f6\u00dft unweigerlich auf zwei Protokolle: OPC UA (Open Platform Communications Unified Architecture) und MQTT (Message Queuing Telemetry Transport). In Foren und Fachartikeln wird oft ein \u201eKampf der Standards\u201c beschworen \u2013 als m\u00fcsste sich am Ende eines durchsetzen. Diese Sichtweise ist nicht nur irref\u00fchrend, sie ist auch sch\u00e4dlich f\u00fcr die Architektur moderner Automatisierungssysteme.<\/p>\n\n\n\n
Die Wahrheit ist: OPC UA und MQTT wurden f\u00fcr unterschiedliche Anwendungsf\u00e4lle, unterschiedliche Netzwerktopologien und unterschiedliche Qualit\u00e4tsanforderungen entwickelt. Sie konkurrieren kaum, sie erg\u00e4nzen sich. Wer beide versteht und richtig einsetzt, baut robustere, sicherere und zukunftsf\u00e4higere Systeme als derjenige, der sich auf eine Seite schl\u00e4gt.<\/p>\n\n\n\n
Dieser Artikel analysiert die Architekturen, St\u00e4rken und Schw\u00e4chen beider Protokolle aus systemischer Perspektive \u2013 und zeigt an konkreten Integrationsszenarien, wie sie als Zweckgemeinschaft zusammenarbeiten.<\/p>\n\n\n\n
OPC UA entstand aus dem klassischen OPC (OLE for Process Control) der sp\u00e4ten 1990er, das auf Microsofts COM\/DCOM-Technologie basierte \u2013 plattformabh\u00e4ngig, schwer konfigurierbar und eine Sicherheitskatastrophe. Die Unified Architecture (UA) wurde ab 2006 als plattformunabh\u00e4ngiger Nachfolger entwickelt (heute standardisiert in IEC 62541).<\/p>\n\n\n\n
Die Philosophie von OPC UA ist Information Modeling<\/strong>: Nicht nur Rohdaten zu \u00fcbertragen, sondern deren Bedeutung, Kontext und Beziehungen zu anderen Daten. Ein OPC UA\u2011Server stellt einen Adressraum<\/strong> zur Verf\u00fcgung, der Objekte, Variablen, Methoden und Ereignisse in einer baumartigen Struktur organisiert. Jedes Objekt kann mit Metadaten versehen werden \u2013 Einheit, Genauigkeit, Werksgrenzen, Historisierungsverhalten, Sicherheitsanforderungen.<\/p>\n\n\n\n Das macht OPC UA extrem m\u00e4chtig, aber auch komplex. Ein vollst\u00e4ndiger OPC UA\u2011Stack ben\u00f6tigt je nach Konfiguration 1\u20135 MB RAM und eine leistungsf\u00e4hige CPU. F\u00fcr kleine Sensoren ist das oft zu viel.<\/p>\n\n\n\n OPC UA ist klassisch ein Client\/Server\u2011Protokoll<\/strong>. Ein Client (z.\u202fB. eine SPS, ein SCADA\u2011System oder eine Cloud\u2011Plattform) verbindet sich mit einem Server (z.\u202fB. einem Sensor oder einer Maschine) und liest oder schreibt Werte, ruft Methoden auf oder abonniert Daten\u00e4nderungen (Monitored Items). Die Kommunikation l\u00e4uft typischerweise \u00fcber TCP\/IP (Port 4840) oder \u00fcber HTTPS (Port 443) mit SOAP\/XML.<\/p>\n\n\n\n Seit Version 1.04 (2017) gibt es OPC UA Pub\/Sub<\/strong> als Erweiterung. Hierbei senden Publisher (Server) Nachrichten an einen MQTT\u2011Broker, einen AMQP\u2011Broker oder direkt \u00fcber UDP\u2011Multicast, ohne dass ein Client vorher eine Verbindung aufbauen muss. Das ist der wichtige Br\u00fcckenschlag zu MQTT.<\/p>\n\n\n\n MQTT wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Arcom) entwickelt \u2013 f\u00fcr die \u00dcberwachung von \u00d6lpipelines \u00fcber Satellitenverbindungen mit geringer Bandbreite und hoher Latenz. Die Philosophie: Publish\/Subscribe<\/strong> mit einem zentralen Broker<\/strong>. Sensoren (Publisher) senden Nachrichten an den Broker, der sie an alle interessierten Clients (Subscriber) verteilt. Die Nachrichten sind thematisch organisiert (Topics), z.\u202fB. MQTT ist extrem leichtgewichtig. Ein minimaler MQTT\u2011Client kommt mit weniger als 10 KB RAM aus, der gesamte Protokoll\u2011Overhead betr\u00e4gt nur 2 Bytes pro Nachricht (plus Topic\u2011L\u00e4nge). Das ist ideal f\u00fcr batteriebetriebene Sensoren mit geringer Rechenleistung.<\/p>\n\n\n\n MQTT kennt keine direkte Kommunikation zwischen Clients. Alle Nachrichten gehen \u00fcber den Broker. Das hat Vorteile:<\/p>\n\n\n\n Die Quality of Service (QoS) Stufen sind:<\/p>\n\n\n\n MQTT bietet keine eingebaute Verschl\u00fcsselung, kann aber \u00fcber TLS (MQTTS) auf Port 8883 betrieben werden. Authentifizierung erfolgt \u00fcber Benutzername\/Passwort oder Client\u2011Zertifikate.<\/p>\n\n\n\n Die hitzigsten Debatten entz\u00fcnden sich an scheinbaren Widerspr\u00fcchen:<\/p>\n\n\n\n \u201eOPC UA ist zu schwer f\u00fcr die Feldebene\u201c<\/strong> \u2013 Ja, aber es gibt das OPC UA Pub\/Sub \u00fcber UDP f\u00fcr einfache Ger\u00e4te und das Nano\u2011Profil. Und niemand zwingt einen Drucksensor, einen vollst\u00e4ndigen OPC UA\u2011Server zu implementieren. Er kann weiterhin MQTT sprechen, und ein Gateway \u00fcbersetzt.<\/p>\n\n\n\n \u201eMQTT kann keine komplexen Maschinendaten abbilden\u201c<\/strong> \u2013 Das ist richtig, aber wozu auch? Ein Vibrationssensor sendet einen FFT\u2011Vektor als Byte\u2011Array. Die Information, dass es sich um einen FFT\u2011Vektor handelt, muss irgendwo abgelegt sein \u2013 entweder im Topic (z.\u202fB. \u201eOPC UA ist sicherer\u201c<\/strong> \u2013 Grunds\u00e4tzlich ja, weil Sicherheit integriert ist. Aber MQTT mit TLS und Zertifikaten ist genauso sicher. Das Problem ist, dass viele Anwender die Sicherheitsfeatures von MQTT nicht aktivieren, weil sie zu aufwendig sind.<\/p>\n\n\n\n \u201eMQTT ist schneller\u201c<\/strong> \u2013 Bei kleinen Nachrichten und vielen Clients ja, weil der Verbindungsaufbau minimal ist. Bei gro\u00dfen Datenbl\u00f6cken (z.\u202fB. Hunderte Variablen auf einmal) ist OPC UA oft effizienter, weil es Bin\u00e4rkodierung (UA\u2011Binary) und Datenkomprimierung unterst\u00fctzt.<\/p>\n\n\n\n Die Praxis zeigt, dass eine reine MQTT\u2011 oder reine OPC\u2011UA\u2011L\u00f6sung selten optimal ist. Stattdessen haben sich drei etablierte Integrationsmuster herausgebildet:<\/p>\n\n\n\n Beschreibung:<\/strong> Hunderte einfache Sensoren (Temperatur, F\u00fcllstand, Vibration) senden ihre Daten per MQTT an einen lokalen Broker. Eine Edge\u2011Gateway\u2011Software (z.\u202fB. Node\u2011RED, Siemens Industrial Edge, Bosch IoT Gateway) subscribt zu diesen Topics, aggregiert die Daten, reichert sie mit Metadaten an (aus einer lokalen Konfigurationsdatenbank) und stellt sie als OPC UA\u2011Server zur Verf\u00fcgung. Das SCADA\u2011System der Leitebene verbindet sich dann mit diesem OPC UA\u2011Server, um die Daten abzuholen und zu archivieren.<\/p>\n\n\n\n Vorteile:<\/strong> Die Sensoren bleiben einfach und billig. Die Leitebene bekommt ein sauberes, informationsreiches OPC UA\u2011Modell. Das Gateway kann auch Protokoll\u00fcbersetzung, Datenvalidierung und vorverarbeitende Analyse (z.\u202fB. FFT) durchf\u00fchren.<\/p>\n\n\n\n Typische Produkte:<\/strong> MQTT\u2011Broker (Mosquitto, EMQX), OPC UA\u2011Server\u2011SDK (Softing, Unified Automation), Gateway\u2011Software (Node\u2011RED mit OPC UA\u2011 und MQTT\u2011Nodes).<\/p>\n\n\n\n Beschreibung:<\/strong> Seit OPC UA Pub\/Sub (Teil 14 der Spezifikation) ist es m\u00f6glich, OPC UA\u2011Nachrichten \u00fcber MQTT zu transportieren. Ein OPC UA\u2011Publisher kodiert seine Daten als UA\u2011Binary oder JSON und sendet sie an einen MQTT\u2011Broker. Ein OPC UA\u2011Subscriber empf\u00e4ngt sie von dort. Der Empf\u00e4nger sieht die Nachricht als vollwertige OPC UA\u2011Daten mit allen Metadaten.<\/p>\n\n\n\n Vorteile:<\/strong> Die reiche Informationsmodellierung von OPC UA bleibt erhalten, w\u00e4hrend die Transportebene die Vorteile von MQTT nutzt: Entkopplung, Skalierbarkeit, einfache Firewall\u2011Passage.<\/p>\n\n\n\n Einschr\u00e4nkung:<\/strong> Nicht alle OPC UA\u2011Server unterst\u00fctzen Pub\/Sub bereits. Die Implementierung ist komplexer als klassisches Client\/Server.<\/p>\n\n\n\n Beschreibung:<\/strong> Ein zentrales System (z.\u202fB. eine Cloud\u2011Plattform wie AWS IoT Core oder Microsoft Azure IoT Hub) empf\u00e4ngt MQTT\u2011Nachrichten von tausenden Sensoren. Diese Plattform speichert die Daten in einer Zeitreihendatenbank. Ein separates OPC UA\u2011Server\u2011Modul (z.\u202fB. als Teil der Plattform) liest die Daten aus der Datenbank und stellt sie \u00fcber OPC UA zur Verf\u00fcgung \u2013 f\u00fcr SCADA\u2011Systeme, die kein MQTT sprechen.<\/p>\n\n\n\n Vorteile:<\/strong> Alte SCADA\u2011Systeme, die nur OPC UA (oder klassisches OPC) verstehen, k\u00f6nnen auf moderne IIoT\u2011Daten zugreifen, ohne umger\u00fcstet zu werden.<\/p>\n\n\n\n Die Industrie 4.0\u2011Plattform (die deutsche Standardisierungsinitiative) hat sich klar positioniert: Die Administration Shell<\/strong> (Verwaltungsschale) eines Assets wird als OPC UA\u2011Informationsmodell abgebildet. Der Transport kann \u00fcber MQTT erfolgen. Das bedeutet, dass zuk\u00fcnftige Systeme beides k\u00f6nnen m\u00fcssen \u2013 und beides auch tun werden.<\/p>\n\n\n\n Hersteller wie Siemens, Beckhoff, Bosch Rexroth und Microsoft arbeiten an der nahtlosen Integration. Siemens bietet mit Industrial Edge<\/strong> eine Plattform, die MQTT von Sensoren sammelt und als OPC UA\u2011Server bereitstellt. Microsofts Azure IoT Edge<\/strong> kann OPC UA\u2011Publisher direkt in die Cloud streamen.<\/p>\n\n\n\n Die Entwicklung geht dahin, dass die Grenzen verschwimmen: OPC UA wird leichter (UA\u2011FX, Field eXchange f\u00fcr die Feldebene), MQTT wird informationsreicher (durch standardisierte Topic\u2011Namensr\u00e4ume, z.\u202fB. Sparkplug B). Aber ein Sieger wird nicht ermittelt \u2013 weil es keinen Kampf gibt.<\/p>\n\n\n\n OPC UA und MQTT sind keine Rivalen, sondern zwei Werkzeuge im Werkzeugkasten des Automatisierers. Das eine (OPC UA) gl\u00e4nzt durch Informationsreichtum, Sicherheit und Standardisierung. Das andere (MQTT) durch Leichtgewichtigkeit, Skalierbarkeit und einfache Cloud\u2011Anbindung. Die kluge Architektur nutzt beide dort, wo ihre St\u00e4rken liegen, und verbindet sie \u00fcber Gateways oder native Pub\/Sub\u2011Integration.<\/p>\n\n\n\n Der vermeintliche \u201eKampf der Standards\u201c ist ein Konstrukt der Marketingabteilungen und der Foren, die einfache Narrative lieben. Die Realit\u00e4t ist komplexer \u2013 und langweiliger: zwei Protokolle, die sich gegenseitig brauchen, um die Vision der durchg\u00e4ngigen, interoperablen Industrie 4.0 zu verwirklichen. Wer nur eines von beiden beherrscht, hat die H\u00e4lfte des Werkzeugs vergessen.<\/p>\n\n\n\n von DerSchneider Einleitung: Zwei Schwergewichte, zwei Welten Wer heute \u00fcber Industrie 4.0, IIoT (Industrial Internet of Things) oder die Vernetzung von Produktion spricht, st\u00f6\u00dft unweigerlich auf zwei Protokolle: OPC UA (Open Platform Communications Unified Architecture) und MQTT (Message Queuing Telemetry Transport). In Foren und Fachartikeln wird oft ein \u201eKampf der Standards\u201c beschworen \u2013 als m\u00fcsste […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,18,46,26],"tags":[1894,3231,3274,5094,5095,5611,6364],"class_list":["post-3121","post","type-post","status-publish","format-standard","hentry","category-denkwerkzeuge","category-im-kopf-methoden-werkzeuge","category-industrie-4-0","category-mit-den-handen","tag-edge-gateway-integration","tag-iiot-kommunikationsprotokolle","tag-industrie-4-0-verwaltungsschale","tag-opc-ua-pub-sub-uber-mqtt","tag-opc-ua-vs-mqtt","tag-publish-subscribe-architektur","tag-skalierbare-sensornetzwerke"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/3121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=3121"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/3121\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=3121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=3121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=3121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Architektur: Client\/Server mit optionaler Pub\/Sub<\/h3>\n\n\n\n
St\u00e4rken von OPC UA<\/h3>\n\n\n\n
\n
Schw\u00e4chen von OPC UA<\/h3>\n\n\n\n
\n
MQTT: Das leichtgewichtige Postamt f\u00fcr Sensordaten<\/h2>\n\n\n\n
Herkunft und Philosophie<\/h3>\n\n\n\n
factory\/hallA\/temperature\/sensor3<\/code>.<\/p>\n\n\n\nArchitektur: Broker\u2011zentriertes Publish\/Subscribe<\/h3>\n\n\n\n
\n
\n
St\u00e4rken von MQTT<\/h3>\n\n\n\n
\n
Schw\u00e4chen von MQTT<\/h3>\n\n\n\n
\n
Der vermeintliche Konflikt: Wo die Lager sich streiten<\/h2>\n\n\n\n
machine\/fft<\/code>) oder in einem begleitenden Metadaten\u2011Kanal. OPC UA h\u00e4tte diese Metadaten eingebaut, aber der Sensor ist daf\u00fcr zu schwach.<\/p>\n\n\n\nDie Zweckgemeinschaft: Integrationsszenarien<\/h2>\n\n\n\n
Szenario 1: MQTT in der Feldebene, OPC UA in der Leitebene<\/h3>\n\n\n\n
Szenario 2: OPC UA Pub\/Sub \u00fcber MQTT als Transport<\/h3>\n\n\n\n
Szenario 3: OPC UA als \u201eBackend\u201c f\u00fcr MQTT\u2011Daten<\/h3>\n\n\n\n
Entscheidungshilfe: Wann nehme ich was?<\/h2>\n\n\n\n
Anforderung<\/th> Prim\u00e4re Wahl<\/th> Begr\u00fcndung<\/th><\/tr><\/thead> Einfacher Sensor mit geringer Rechenleistung (8\u2011Bit)<\/td> MQTT<\/td> Minimaler Ressourcenverbrauch<\/td><\/tr> Komplexe Maschine mit vielen Variablen und Methoden (z.\u202fB. Roboter)<\/td> OPC UA<\/td> Informationsmodell und Aufruf von Methoden<\/td><\/tr> Daten m\u00fcssen \u00fcber unzuverl\u00e4ssige Netze (Funk, Satellit) \u00fcbertragen werden<\/td> MQTT mit QoS 1\/2<\/td> Broker puffert bei Verbindungsabbr\u00fcchen<\/td><\/tr> Sicherheitskritische Steuerung (z.\u202fB. Not\u2011Abschaltung)<\/td> OPC UA (oder PROFIsafe \u00fcber OPC UA)<\/td> Integrierte Sicherheit, Authentifizierung<\/td><\/tr> Tausende Sensoren an einem Ort mit guter Netzinfrastruktur<\/td> OPC UA Pub\/Sub \u00fcber MQTT<\/td> Skalierbarkeit + Informationsmodell<\/td><\/tr> Bestandsanlage mit vielen propriet\u00e4ren Feldbussen<\/td> Gateway mit OPC UA<\/td> Einheitliche Schnittstelle nach oben<\/td><\/tr> Cloud\u2011Anbindung mit geringem Aufwand<\/td> MQTT (z.\u202fB. an AWS IoT Core)<\/td> Jede gro\u00dfe Cloud unterst\u00fctzt MQTT nativ<\/td><\/tr> Anlage muss mit anderen Anlagen desselben Herstellers kommunizieren<\/td> Herstellerspezifisch (z.\u202fB. PROFINET)<\/td> Meist am besten integriert<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Zukunftsperspektive: OPC UA \u00fcber MQTT als Standard<\/h2>\n\n\n\n
Fazit: Keine Hochzeit, aber eine produktive Zweckehe<\/h2>\n\n\n\n
Quellen<\/h2>\n\n\n\n
\n