OPC UA vs. MQTT: Welches Protokoll für Produktionsdaten wohin gehört

Wer Produktionsdaten aus der Werkhalle holen will, landet schnell bei der Frage OPC UA vs. MQTT. Oft wird sie gestellt, als müsse man sich für eines entscheiden. Tatsächlich lösen die beiden Protokolle unterschiedliche Aufgaben. OPC UA ist dafür gebaut, eine Maschine mit ihrer Bedeutung zu beschreiben und gezielt abzufragen. MQTT ist dafür gebaut, Nachrichten zuverlässig und mit wenig Aufwand über unsichere Netze zu verteilen. Dazu kommt eine zweite Frage, die mindestens so wichtig ist: Wo wird gerechnet, an der Maschine oder in der Cloud? Dieser Artikel erklärt beide Protokolle, vergleicht sie und zeigt am Beispiel unserer Zustandsüberwachung für CNC-Spindeln, wie eine Architektur aussieht, die beide sinnvoll kombiniert.

OPC UA: Client/Server mit Informationsmodell

OPC UA (Open Platform Communications Unified Architecture) folgt im Kern dem Client/Server-Prinzip. Die Steuerung betreibt einen OPC-UA-Server, ein Client verbindet sich, durchsucht den Adressraum und liest Werte, einmalig oder wiederkehrend. Der Standard-Port ist 4840.

Der eigentliche Unterschied zu einfachen Protokollen ist das Informationsmodell. Ein OPC-UA-Server liefert nicht nur Zahlen, sondern Knoten mit Typ, Einheit, Beschreibung und Beziehungen zueinander. Ein Client kann den Adressraum durchsuchen (Browse) und Werte über Browse-Pfade finden, statt sich auf fest verdrahtete Adressen zu verlassen.

Für Werkzeugmaschinen gibt es mit OPC 40501 eine eigene Companion Specification, bekannt unter dem Namen umati. Sie legt fest, wo eine Maschine Zustände, Overrides, Programminformationen und Alarme in einem einheitlichen Modell bereitstellt. Für die Zustandsüberwachung hat das eine Grenze: Kontinuierliche Prozesswerte wie Spindeldrehzahl oder Spindellast sind nach unserer Auswertung der Spezifikation nicht Teil des Grundmodells. Sie kommen aus herstellerspezifischen Bereichen des Adressraums.

Sicherheit ist in OPC UA eingebaut. Client und Server haben jeweils ein Anwendungszertifikat, das die Gegenseite ausdrücklich als vertrauenswürdig einstufen muss. Der Sicherheitsmodus legt fest, ob Nachrichten nur signiert oder signiert und verschlüsselt werden (Sign, SignAndEncrypt). Die Security Policy bestimmt die Algorithmen, zum Beispiel Basic256Sha256. Zusätzlich meldet sich der Client mit einem Benutzer an, dessen Rechte auf der Steuerung festgelegt sind.

MQTT: Publish/Subscribe über einen Broker

MQTT funktioniert anders. Es gibt keine direkte Verbindung zwischen Datenquelle und Empfänger. Beide verbinden sich mit einem Broker. Der Sender veröffentlicht Nachrichten unter einem Thema (Topic), Empfänger abonnieren die Themen, die sie interessieren. Der Broker verteilt.

Für die Zuverlässigkeit kennt MQTT drei Dienstgüten (Quality of Service):

• QoS 0: höchstens einmal. Die Nachricht wird gesendet, aber nicht bestätigt.
• QoS 1: mindestens einmal. Die Nachricht wird wiederholt, bis sie bestätigt ist. Doppelte Zustellung ist möglich.
• QoS 2: genau einmal, mit einem aufwendigeren Handshake.

Für die IT eines Fertigungsbetriebs ist eine Eigenschaft entscheidend: Ein MQTT-Client baut die Verbindung zum Broker selbst und ausgehend auf. Die Box im Werk muss also nicht von außen erreichbar sein. Gesichert wird die Verbindung mit TLS, der Standard-Port dafür ist 8883. Mit einem Client-Zertifikat weist sich jedes Gerät gegenüber dem Broker aus, ohne Passwort. Wo Port 8883 gesperrt ist, lässt sich MQTT über sichere WebSockets auf Port 443 führen.

Was MQTT nicht mitbringt, ist ein Informationsmodell. Der Inhalt einer Nachricht ist für das Protokoll nur eine Folge von Bytes. Welche Felder sie hat und was sie bedeuten, muss ein eigener Datenvertrag festlegen.

OPC UA und MQTT im direkten Vergleich

Das Ergebnis des Vergleichs ist keine Entweder-oder-Entscheidung. OPC UA ist stark dort, wo man eine Maschine verstehen muss. MQTT ist stark dort, wo Daten über eine Firewall hinweg zu einer zentralen Plattform sollen. Eine gute Architektur nutzt jedes Protokoll für den Abschnitt, für den es gebaut ist.

Unsere Architektur: OPC UA im Werk, MQTT nach außen

Unsere Zustandsüberwachung für CNC-Spindeln ist in drei Abschnitte geteilt. Jeder nutzt das Protokoll, das dafür passt:

Steuerung zur Box: OPC UA, nur lesend

SINUMERIK- und HEIDENHAIN-TNC-Steuerungen bieten OPC UA als Option des Herstellers an. Die Box ist dort ein reiner Lese-Client. Sie fragt Werte wie Drehzahl, Last, Programm und Alarme einmal pro Sekunde ab. Technisch ist die Abfrage auf höchstens alle 0,1 Sekunden begrenzt, damit die Steuerung nicht belastet wird. Jede Anfrage läuft durch eine einzige Stelle mit einer Positivliste: Erlaubt sind Lesen, Durchsuchen, Abonnieren und der Sitzungsaufbau. Schreiben, Methodenaufrufe sowie Anlegen und Löschen von Knoten werden blockiert, bevor sie die Box verlassen. Die Verbindung läuft mit SignAndEncrypt und Basic256Sha256, das Zertifikat der Steuerung wird bei der Einrichtung ausdrücklich hinterlegt. Signalpfade werden vor Ort mit einem Lesewerkzeug aus dem Adressraum ermittelt und in der Konfiguration eingetragen, nicht geraten. Details im Artikel SINUMERIK und HEIDENHAIN per OPC UA anbinden.

Sensor zur Box: eigene Messung

Für die Lagerdiagnose reicht die Steuerung nicht. Ihre Standard-Schnittstellen liefern Werte deutlich unter 1 kHz, die Hüllkurvenanalyse braucht Signale im Kilohertz-Bereich. Deshalb misst ein Schwingungssensor direkt am Spindelgehäuse. Warum das so ist, erklärt der Artikel Wälzlagerschaden früh erkennen.

Box zur Plattform: MQTT über TLS, nur ausgehend

Die Box sendet ihre Ergebnisse per MQTT über TLS 1.2 oder höher an die Plattform, auf Port 8883, sonst über Port 443. Sie öffnet keinen eingehenden Port und ist von außen nicht erreichbar.

Edge oder Cloud: Warum Rohdaten nicht in die Cloud gehen

Die zweite Grundsatzfrage lautet, wo gerechnet wird. Unsere Antwort: Die Signalanalyse findet auf der Box an der Maschine statt, die Bewertung über die Zeit auf der Plattform. Rohsignale verlassen das Werk nicht. Dafür gibt es drei Gründe.

Bandbreite. Ein Schwingungssignal für die Lagerdiagnose wird mit einer Abtastrate im Kilohertz-Bereich aufgenommen. Angenommen, ein Kanal wird mit 25,6 kHz und 4 Byte je Wert abgetastet: Das sind rund 100 Kilobyte pro Sekunde und knapp 9 Gigabyte pro Tag, für einen einzigen Kanal ohne Kompression. Die berechneten Kennwerte sind dagegen wenige Zahlen je Messfenster. Für eine Firmenleitung, die auch andere Aufgaben hat, ist das ein erheblicher Unterschied.

Datenschutz und Know-how. Ein Rohsignal enthält mehr als den Lagerzustand. Aus den Frequenzen der Schneideneingriffe lassen sich Rückschlüsse auf Drehzahlen, Werkzeuge und Schnittbedingungen ziehen. Das ist Fertigungswissen. Die Box überträgt deshalb nur berechnete Schwingungskennwerte, Drehzahl, Last, Temperatur, Maschinenstatus und Alarme. NC-Programme, Werkzeugkorrekturen, Zeichnungen und Bedienerdaten liest sie nicht. Eine vollständige Liste steht auf der Seite Datensicherheit.

Latenz und Unabhängigkeit. Für die Lagerdiagnose zählen keine Millisekunden. Entscheidend ist etwas anderes: Ein Messfenster ist nur vergleichbar, wenn die Spindel während der Messung mit konstanter Drehzahl lief. Die Box prüft deshalb, ob die Drehzahl laut Steuerung vor und nach dem Fenster gleich war, innerhalb von ±2 % und oberhalb von 300 min⁻¹. Diese Verknüpfung von Steuerungsdaten und Schwingung gelingt am zuverlässigsten dort, wo beide Signale zeitgleich vorliegen. Außerdem rechnet die Box weiter, wenn die Internetverbindung ausfällt.

Puffer und Zustellung: ohne Lücken und ohne Duplikate

Netzwerke fallen aus, Router werden neu gestartet, Firewall-Regeln ändern sich. Eine Zustandsüberwachung, die in dieser Zeit Daten verliert, hat genau dann Lücken, wenn man sie braucht. Unsere Box arbeitet deshalb nach dem Prinzip Store-and-forward:

1. Speichern: Jeder berechnete Datensatz wird zuerst in eine lokale SQLite-Datenbank geschrieben und erhält eine fortlaufende Nummer. Die Datenbank ist so eingestellt, dass auch ein Stromausfall keine gespeicherten Daten kostet.
2. Senden: Die Box sendet ein Paket und wartet auf die Bestätigung der Plattform, dass es angekommen und gespeichert ist. Erst dann folgt das nächste.
3. Löschen: Erst nach dieser Bestätigung löscht die Box die Datensätze aus dem Puffer. Bleibt die Bestätigung aus, sendet sie das Paket erneut.
4. Doppelte erkennen: Die Plattform erkennt anhand der fortlaufenden Nummern, was sie schon hat, und ignoriert Wiederholungen.

Warum reicht nicht einfach MQTT mit QoS 1? Weil QoS 1 nur die Strecke zwischen Box und Broker absichert. Ob die Daten danach wirklich in der Datenbank der Plattform gelandet sind, weiß die Box damit nicht. Erst die Bestätigung aus der Plattform über einen eigenen Rückkanal schließt diese Lücke. Zusammen mit der Duplikaterkennung ergibt das eine Zustellung ohne Lücken und ohne doppelte Werte.

Der Puffer hält mindestens sieben Tage. Fällt die Verbindung länger aus, werden die ältesten Daten verworfen und der Verlust wird gemeldet, statt die Festplatte volllaufen zu lassen.

Was die IT-Abteilung wissen muss

• Firewall: Box zur Steuerung auf Port 4840 (OPC UA), Box zur Plattform auf Port 8883, sonst 443. Von außen zur Box: keine Verbindung.
• Geräteidentität: Jede Box hat ein eigenes Zertifikat. Der private Schlüssel wird auf der Box erzeugt und verlässt sie nie. Ein Passwort-Login gibt es nicht.
• Mandantentrennung: Jede Box darf am Broker nur unter ihrer eigenen Kennung senden. Welcher Kunde zu welcher Box gehört, entscheidet allein die Plattform.
• TLS-Inspektion: Setzt die Firewall TLS-Inspektion ein, braucht die Box eine Ausnahme. Sonst schlägt die beidseitige Zertifikatsprüfung fehl, und es wird nichts übertragen.
• Updates und Speicherort: Die Box installiert nur signierte Updates. Verarbeitung und Speicherung erfolgen ausschließlich in Rechenzentren in Deutschland.

Wie der Ablauf von der Vorabklärung bis zur Anbindung aussieht, beschreibt die Seite Ablauf. Für ein technisches Gespräch mit Ihrer IT nutzen Sie Kontakt.

Häufige Fragen