Wer Maschinendaten aus der Fertigung holen will, landet schnell bei zwei Begriffen: OPC UA und MQTT. In Angeboten und Foren werden sie gern gegeneinander gestellt. In der Praxis beantworten sie aber unterschiedliche Fragen. Dieser Artikel zeigt, wo welches Protokoll seine Stärken hat und wie man beide sinnvoll kombiniert.
OPC UA in einem Satz
OPC UA ist ein Industriestandard für den Datenaustausch mit Bedeutung: Ein Server (z. B. in der Steuerung) stellt nicht nur Werte bereit, sondern auch deren Struktur, Datentyp, Einheit und Zusammenhang im sogenannten Informationsmodell.
- Selbstbeschreibend: Ein Client kann den Adressraum durchsuchen und findet Achsen, Spindeln oder Programmzustände, ohne vorher eine Liste von Adressen zu kennen.
- Companion Specifications: Branchenmodelle wie OPC UA for Machine Tools oder umati sorgen dafür, dass Maschinen verschiedener Hersteller gleich aussehen.
- Sicherheit eingebaut: Zertifikate, Verschlüsselung und Benutzerrechte sind Teil des Standards.
- Lesen, schreiben, Methoden aufrufen: OPC UA eignet sich auch für Rückkanäle, etwa Aufträge an eine Maschine übergeben.
Viele Steuerungen bringen einen OPC-UA-Server mit oder lassen sich damit nachrüsten, zum Beispiel SINUMERIK-Steuerungen über eine Option oder SIMATIC S7-1500 direkt im TIA Portal.
MQTT in einem Satz
MQTT ist ein schlankes Publish/Subscribe-Protokoll: Geräte senden Nachrichten an einen zentralen Broker, und jeder, der ein Thema (Topic) abonniert hat, bekommt sie.
- Leichtgewichtig: Wenig Overhead, funktioniert auch über instabile oder langsame Verbindungen.
- Entkoppelt: Sender und Empfänger kennen sich nicht. Neue Abnehmer (Dashboard, Datenbank, Cloud) kommen dazu, ohne die Maschine anzufassen.
- Skalierbar: Ein Broker verteilt Daten von Hunderten Maschinen an beliebig viele Systeme.
- Aber: MQTT legt nur den Transport fest. Was in der Nachricht steht und wie sie aufgebaut ist, muss man selbst definieren, zum Beispiel mit Sparkplug B oder einem eigenen JSON-Schema.
Der direkte Vergleich
| Kriterium | OPC UA | MQTT |
|---|---|---|
| Prinzip | Client/Server (zusätzlich PubSub möglich) | Publish/Subscribe über Broker |
| Datenmodell | Umfangreich, standardisiert | Keines – frei oder per Sparkplug B |
| Typischer Ort | Maschine ↔ Leitrechner, MES | Shopfloor ↔ IT, Cloud, Dashboards |
| Rückkanal / Steuern | Sehr gut (Schreiben, Methoden) | Möglich, aber selbst zu regeln |
| Aufwand Einstieg | Höher (Modell, Zertifikate) | Gering |
| Viele Abnehmer | Jeder Client verbindet sich zur Maschine | Broker verteilt, Maschine bleibt entlastet |
Wann OPC UA die bessere Wahl ist
- Sie brauchen strukturierte Maschinendaten mit Kontext, etwa Programmstatus, Werkzeugdaten oder Alarme, und wollen sie nicht selbst modellieren.
- Ein MES oder Leitrechner soll Aufträge, Programme oder Parameter an die Maschine übergeben.
- Der Kunde oder die Branche verlangt einen herstellerunabhängigen Standard wie umati.
Wann MQTT die bessere Wahl ist
- Daten sollen an mehrere Systeme gleichzeitig gehen: Dashboard, Datenbank, Instandhaltung, Cloud.
- Die Verbindung ist unzuverlässig, zum Beispiel bei mobilen Anlagen oder verteilten Standorten.
- Sie bauen einen Unified Namespace auf, also eine zentrale Datendrehscheibe für das ganze Werk.
Die Praxis: beides kombinieren
In den meisten Projekten fällt die Entscheidung nicht entweder-oder aus. Ein bewährtes Muster:
- An der Maschine OPC UA: Ein Gateway (Edge-Rechner, eigene Java-Anwendung oder fertiges Produkt) liest die Daten per OPC UA aus der Steuerung.
- Im Werk MQTT: Das Gateway veröffentlicht die aufbereiteten Werte strukturiert auf einem MQTT-Broker.
- Abnehmer abonnieren: Dashboard, Datenbank und ERP holen sich, was sie brauchen, ohne die Steuerung zusätzlich zu belasten.
So bleibt die Steuerung mit genau einer Verbindung entlastet, die Daten behalten ihre Bedeutung, und neue Anwendungen lassen sich jederzeit anhängen.
Worauf Sie bei der Umsetzung achten sollten
- Sicherheit von Anfang an: OPC UA mit Zertifikaten und Verschlüsselung betreiben, MQTT nur über TLS und mit Benutzer-Authentifizierung. Die Steuerung gehört nicht direkt ins Büronetz.
- Datenmenge planen: Nicht jeden Wert im 10-ms-Takt abfragen. Subscriptions mit sinnvollen Abtastraten und Totbändern sparen Last auf Steuerung und Netz.
- Namen festlegen: Eine klare Topic-Struktur (z. B.
werk/halle/linie/maschine/messwert) erspart später viel Umbauarbeit. - Klein anfangen: Eine Maschine, drei aussagekräftige Werte, ein Dashboard. Danach skalieren.
Fazit
OPC UA ist stark, wenn es um Bedeutung und Steuerung an der Maschine geht. MQTT ist stark, wenn Daten effizient an viele Abnehmer verteilt werden sollen. Wer beide an der richtigen Stelle einsetzt, bekommt eine Datenanbindung, die mit dem Betrieb mitwächst.