Eine neue Maschine soll an das MES angebunden werden.

Der Maschinenhersteller bietet OPC UA an.

Ein Kollege schlägt MQTT vor.

Die IT möchte lieber eine REST-API.

Und die vorhandene Anlage kommuniziert ohnehin über Modbus TCP.

Welche Schnittstelle ist nun die richtige?

Die häufig gestellte Frage lautet deshalb:

OPC UA oder MQTT?

Manchmal auch:

OPC UA, MQTT oder REST?

Doch genau diese Fragestellung führt schnell in die falsche Richtung. Denn OPC UA, MQTT und REST sind keine drei austauschbaren Technologien, die dasselbe Problem auf unterschiedliche Weise lösen. Sie haben unterschiedliche Stärken.

Vereinfacht:

Maschine verstehen und bedienen
            ↓
          OPC UA

Ereignisse und Daten verteilen
            ↓
           MQTT

IT-Systeme und Anwendungen integrieren
            ↓
        REST / HTTP

Und darunter existiert in vielen Produktionsbetrieben noch eine vierte Ebene – die Sprache, die eine konkrete Maschine tatsächlich spricht:

S7
Modbus
RS232
Herstellerprotokolle
Feldbusse

Die entscheidende Frage lautet deshalb nicht: „Welches Protokoll ist das beste?"

Sondern: „Welche Aufgabe möchten wir auf welcher Ebene unserer Architektur lösen?"

Eine Schnittstelle muss zur Aufgabe passen

Betrachten wir zunächst eine typische Produktionsarchitektur:

                    ERP
                     │
                     ▼
                    MES
                     │
                     ▼
             Integrationsschicht
                     │
                     ▼
                Edge / OT
                     │
                     ▼
                  Maschine

Zwischen diesen Ebenen werden völlig unterschiedliche Informationen ausgetauscht. Das ERP möchte vielleicht wissen:

Produktionsauftrag 4711
wurde abgeschlossen
Istmenge = 4.982 Stück

Das MES benötigt:

Auftrag läuft
Maschinenzustand = RUNNING
aktuelle Menge = 3.417

Ein Monitoring-System interessiert sich für:

Temperatur = 62,4 °C
Motorstrom = 8,2 A

Technisch handelt es sich überall um Daten. Fachlich sind es aber völlig unterschiedliche Aufgaben. Deshalb ist es selten sinnvoll, ein einziges Kommunikationsverfahren für die gesamte Fabrik erzwingen zu wollen.

Beginnen wir mit OPC UA

OPC UA ist wesentlich mehr als ein Protokoll zum Lesen einzelner SPS-Variablen. Die OPC Foundation beschreibt OPC UA als plattformunabhängigen Standard für sichere und zuverlässige Kommunikation zwischen Systemen und Geräten. Neben dem eigentlichen Datenaustausch besitzt OPC UA insbesondere ein umfangreiches Informationsmodell.

Das ist ein entscheidender Unterschied. Nehmen wir einen einfachen Wert:

62.4

Eine Schnittstelle kann diesen Wert übertragen. Damit wissen wir aber noch nicht: Was bedeutet er? Welche Einheit besitzt er? Von welchem Gerät stammt er? Ist er ein Soll- oder Istwert? Ist er beschreibbar? Gehört er zu einem Motor? Gibt es einen Alarm dazu?

Mit OPC UA kann aus einem einfachen Wert ein strukturiertes Informationsmodell werden:

Machine
 │
 ├── Identification
 │    ├── Manufacturer
 │    ├── SerialNumber
 │    └── Model
 │
 ├── Production
 │    ├── State
 │    ├── Counter
 │    └── CurrentOrder
 │
 └── Motor
      ├── Temperature
      ├── Current
      └── State

Ein Client kann diese Struktur durchsuchen und Informationen dynamisch entdecken. OPC UA stellt dafür unter anderem Mechanismen für Browsing, Lesen, Schreiben, Methodenaufrufe, Events, Alarme sowie aktuelle und historische Daten bereit. Das macht OPC UA gerade in der Maschinenintegration interessant.

Der eigentliche Vorteil von OPC UA ist Semantik

Nehmen wir zwei Maschinen. Maschine A liefert:

DB42.DBW18 = 350

Maschine B:

Register 40127 = 350

Technisch können beide Werte erfolgreich ausgelesen werden. Aber für eine übergeordnete Anwendung besitzen sie zunächst keine Bedeutung. Mit einem Informationsmodell könnte daraus beispielsweise werden:

Production.CurrentSpeed
Value: 35.0
Unit: pieces/min

Damit wird aus einer technischen Adresse eine fachliche Information.

OPC UA kann nicht nur Daten transportieren, sondern auch deren Bedeutung beschreiben.

Companion Specifications gehen noch einen Schritt weiter

Ein Hersteller könnte sein Informationsmodell natürlich selbst definieren. Dann würde Hersteller A beispielsweise schreiben:

Machine.Speed

Hersteller B:

Production.ActualVelocity

und Hersteller C:

CurrentProductionSpeed

Damit hätten wir zwar OPC UA, aber noch immer keine echte Herstellerunabhängigkeit. Deshalb gibt es sogenannte OPC UA Companion Specifications. Diese definieren Informationsmodelle für bestimmte Branchen, Maschinentypen, Geräte und Anwendungsfälle. Die OPC Foundation beschreibt Companion Specifications ausdrücklich als domänenspezifische Informationsmodelle auf Basis von OPC UA mit dem Ziel der Interoperabilität auf semantischer Ebene.

Für eine moderne Maschinenbeschaffung ist deshalb die Frage „Hat die Maschine OPC UA?" eigentlich noch nicht ausreichend. Die bessere Frage lautet:

Welches OPC-UA-Informationsmodell stellt die Maschine bereit und unterstützt sie eine relevante Companion Specification?

OPC UA eignet sich deshalb besonders für Maschinenzugriff

Eine Anwendung kann über OPC UA Maschinenzustände lesen, Produktionswerte überwachen, Parameter schreiben, Methoden aufrufen, Alarme empfangen und verfügbare Variablen durchsuchen. Das Kommunikationsmodell ist dabei nicht ausschließlich einfaches Polling. OPC UA unterstützt sowohl Client/Server-Kommunikation als auch Publish/Subscribe. Dieser Punkt wird beim Vergleich mit MQTT häufig übersehen.

Was macht MQTT dagegen?

MQTT verfolgt zunächst ein wesentlich einfacheres Prinzip. Ein Teilnehmer veröffentlicht eine Nachricht unter einem Topic. Beispielsweise:

factory/line1/machine5/temperature

mit:

62.4

Ein MQTT-Broker nimmt diese Nachricht entgegen. Andere Teilnehmer können das Topic abonnieren:

Publisher
    │
    ▼
MQTT Broker
    │
    ├──► Subscriber A
    ├──► Subscriber B
    └──► Subscriber C

Publisher und Subscriber müssen sich gegenseitig nicht kennen. Das ist der wesentliche Vorteil des Publish/Subscribe-Modells.

MQTT transportiert Nachrichten – aber versteht deren Inhalt nicht

Nehmen wir wieder:

factory/line1/machine5/temperature

Payload:

62.4

MQTT weiß nicht, was 62.4 bedeutet. Es könnte 62,4 °C sein, 62,4 °F oder 62,4 bar. Die MQTT-Spezifikation legt den Inhalt des Application Payloads bewusst nicht fachlich fest. Der Inhalt und dessen Format sind anwendungsspezifisch. Das ist gleichzeitig Stärke und Schwäche. MQTT ist dadurch sehr flexibel. Aber: MQTT alleine schafft noch kein gemeinsames Datenmodell.

Das bekannte MQTT-Problem: Jeder erfindet seine eigenen Topics

Ein Projekt beginnt beispielsweise mit:

machine/1/temp

Das nächste Team verwendet:

factory/m01/temperature

Ein anderer Standort:

plant1/machines/1/process/tempActual

Und der nächste Hersteller veröffentlicht:

devices/4711/t1

Technisch funktioniert alles über MQTT. Semantisch hat man trotzdem vier unterschiedliche Schnittstellen. Dasselbe gilt für Payloads. System A:

{
  "value": 62.4
}

System B:

{
  "temperature": 62.4,
  "unit": "C"
}

System C:

{
  "v": 624,
  "scale": 10
}

Deshalb löst die Aussage „Unsere Maschinen sprechen alle MQTT" noch nicht automatisch das Integrationsproblem. Es fehlt weiterhin eine Vereinbarung darüber: Was bedeuten Topic und Payload?

MQTT ist besonders stark bei Datenverteilung

MQTT wird sehr interessant, wenn Daten nicht nur von einem System benötigt werden:

Maschine
   │
   ▼
Edge Gateway
   │
   ▼
MQTT Broker
   │
   ├──► MES
   ├──► Dashboard
   ├──► Historisierung
   └──► Analytics

Der Edge-Service veröffentlicht ein Ereignis nur einmal. Mehrere Systeme können darauf reagieren. Das Gateway muss diese Anwendungen nicht kennen. Damit entsteht eine lose Kopplung – besonders interessant für Telemetrie, IoT, Edge-to-Cloud, Zustandsdaten und verteilte Systeme.

MQTT besitzt verschiedene Zustellqualitäten

MQTT definiert drei Quality-of-Service-Stufen:

QoS 0  –  At most once
QoS 1  –  At least once
QoS 2  –  Exactly once

Diese beziehen sich auf die Übertragung einer Nachricht zwischen Sender und Empfänger innerhalb des MQTT-Protokolls. Das bedeutet aber nicht automatisch, dass ein vollständiger Geschäftsprozess exakt einmal ausgeführt wird. Selbst wenn MQTT seine Nachricht korrekt zustellt, können zwischen Anwendung und Datenbank weitere Fehler auftreten. Zuverlässige verteilte Systeme benötigen deshalb weiterhin Konzepte wie Idempotenz, Wiederholungsmechanismen, eindeutige Ereignis-IDs, Transaktionen und Fehlerbehandlung. Der Transport allein löst nicht jede Frage der Verarbeitungssicherheit.

Und was ist dann REST?

REST wird häufig ebenfalls als Protokoll bezeichnet. Streng genommen ist das nicht korrekt. REST steht für Representational State Transfer und ist ein Architekturstil für verteilte Systeme. In der Praxis meint man mit einer REST-API meistens eine HTTP-basierte API mit ressourcenorientierten Endpunkten. HTTP selbst arbeitet nach einem Request/Response-Modell: Ein Client sendet eine Anfrage an einen Server, der darauf antwortet.

Zum Beispiel:

GET /machines/4711

Antwort:

{
  "id": "4711",
  "state": "running"
}

REST ist hervorragend für klassische Softwareintegration

REST-APIs eignen sich deshalb sehr gut für die Kommunikation zwischen:

Web-Frontend und Backend,
MES und ERP,
verschiedenen Backend-Services,
mobilen Anwendungen,
externen Systemen.

Eine typische Architektur kann beispielsweise so aussehen:

Angular Frontend
      │
      │ REST
      ▼
     MES
      │
      │ REST
      ▼
     ERP

Hier ist Request/Response genau das gewünschte Kommunikationsmodell.

REST ist aber nicht automatisch ideal für kontinuierliche Maschinendaten

Stellen wir uns vor, eine Maschine erzeugt zehn Messwerte pro Sekunde. Technisch könnte man dafür Requests verwenden. Die Frage lautet aber: Ist dieses Kommunikationsmodell für die Aufgabe sinnvoll? Bei kontinuierlichen Ereignissen möchte man häufig eher Producer → Broker → Consumer als ein klassisches Request/Response-Modell. Denn im Publish/Subscribe-Modell können Producer und Consumer stärker voneinander entkoppelt werden.

Das bedeutet nicht: REST ist langsam und MQTT ist schnell. Eine solche pauschale Aussage wäre falsch. Es geht vielmehr um das Kommunikationsmodell. REST passt sehr gut, wenn eine Anwendung bewusst etwas von einer anderen Anwendung anfordert. Publish/Subscribe passt gut, wenn ein Ereignis entsteht und unbekannt sein darf, wer es später verarbeitet.

Request oder Event?

Eine einfache Entscheidungshilfe:

REST

„Gib mir Auftrag 4711."

GET /orders/4711

OPC UA Client/Server

„Gib mir den aktuellen Maschinenzustand."

Read MachineState

MQTT

„Der Maschinenzustand hat sich geändert."

machine/state/changed

Der Unterschied steckt im Satz.

Anfordern: Ich möchte etwas wissen.

Publizieren: Etwas ist passiert.

Beides wird in industriellen Architekturen benötigt.

Und wo gehören klassische Maschinenprotokolle hin?

Viele Maschinen besitzen weder eine REST-API noch MQTT oder einen modernen OPC-UA-Server. Stattdessen findet man beispielsweise Modbus TCP, Siemens-SPS-Kommunikation, serielle ASCII-Protokolle, proprietäre TCP-Telegramme oder herstellerspezifische APIs.

Modbus ist ein industrielles Application-Layer-Protokoll, das über TCP/IP oder serielle Verbindungen eingesetzt werden kann und nach einem Request/Reply-Modell funktioniert. Ein Gerät liefert vielleicht:

Holding Register 40127

Ein anderes:

DB20.DBD14

Diese Protokolle sind nicht automatisch schlecht. Sie erfüllen häufig seit vielen Jahren zuverlässig ihre Aufgabe. Das Problem entsteht, wenn man sie durch die gesamte IT-Architektur zieht.

Das MES sollte kein Modbus-Experte sein müssen

Nehmen wir eine Anlage mit fünf Maschinen:

Maschine A → S7
Maschine B → Modbus
Maschine C → proprietäres TCP
Maschine D → RS232
Maschine E → OPC UA

Wenn das MES direkt alle Protokolle spricht, enthält es das Wissen über jede einzelne Maschine – und bei jeder neuen Maschine wächst dieses Wissen weiter. Die bessere Architektur besteht häufig darin, diese Protokolle möglichst nahe am Gerät zu beenden:

Maschine A ─► S7 Driver ────────┐
                                │
Maschine B ─► Modbus Driver ────┤
                                ├──► gemeinsames Modell
Maschine C ─► TCP Driver ───────┤
                                │
Maschine D ─► Serial Driver ────┘

Erst oberhalb dieser Schicht wird entschieden, wie die Informationen weitergegeben werden.

Genau hier können OPC UA, MQTT und REST zusammenspielen

Eine moderne Architektur könnte beispielsweise so aussehen:

                     ERP
                      │
                    REST
                      │
                      ▼
                     MES
                      │
             ┌────────┴────────┐
             │                 │
           REST              MQTT
             │                 │
             ▼                 ▼
        Konfiguration       Events
                               ▲
                               │
                         Edge Services
                               │
             ┌─────────────────┼─────────────────┐
             │                 │                 │
           OPC UA           Modbus              S7
             │                 │                 │
             ▼                 ▼                 ▼
        Maschine A        Maschine B        Maschine C

Hier erfüllt jede Technologie eine andere Aufgabe: OPC UA für strukturierten Zugriff auf eine Maschine. Modbus oder proprietäres Protokoll für Geräte ohne modernere Schnittstelle. MQTT zur Verteilung von Zuständen oder Ereignissen. REST für klassische Anwendungs- und Geschäftsprozesse.

Damit wird aus OPC UA oder MQTT oder REST ein: OPC UA und MQTT und REST – jeweils dort, wo es sinnvoll ist.

Noch interessanter: OPC UA kann MQTT selbst verwenden

Genau deshalb ist die häufige Suche nach „OPC UA vs. MQTT" technisch etwas irreführend. OPC UA besitzt neben dem klassischen Client/Server-Modell auch ein eigenes PubSub-Modell. OPC UA PubSub kann brokerlos oder brokerbasiert über Messaging-Protokolle wie MQTT arbeiten. Die OPC Foundation beschreibt MQTT ausdrücklich als möglichen Broker-Transport für OPC UA PubSub.

Eine Architektur kann deshalb sogar so aussehen:

OPC UA Publisher
        │
        │ OPC UA PubSub
        │ über MQTT
        ▼
     MQTT Broker
        │
        ▼
OPC UA Subscriber

MQTT übernimmt dabei den Nachrichtentransport. OPC UA definiert darüber die Struktur der übertragenen Informationen:

MQTT
=
Transport / PubSub-Infrastruktur

        +

OPC UA
=
Informationsmodell / Semantik

MQTT und OPC UA stehen nicht zwangsläufig im Wettbewerb. Sie können sich ergänzen.

Wann würde ich OPC UA einsetzen?

OPC UA ist besonders interessant, wenn eine Anwendung eine Maschine oder Anlage strukturiert verstehen und bedienen soll: aktuelle Maschinenwerte lesen, Parameter schreiben, Methoden ausführen, Zustände überwachen, Alarme empfangen, Gerätestruktur durchsuchen, standardisierte Informationsmodelle verwenden.

Besonders wertvoll wird OPC UA dort, wo Hersteller eine passende Companion Specification implementieren. Dann entsteht nicht nur technische, sondern zunehmend auch semantische Interoperabilität.

Wann würde ich MQTT einsetzen?

MQTT ist besonders interessant, wenn viele verteilte Teilnehmer Ereignisse oder Telemetriedaten austauschen sollen:

             ┌──► Dashboard
Edge ─► MQTT ├──► Historisierung
             ├──► Analytics
             └──► Cloud

Typische Anforderungen: Publish/Subscribe, lose Kopplung, Edge-to-Cloud, Sensordaten, Zustandsänderungen, Events, viele Publisher und Subscriber. Dabei sollte jedoch ein gemeinsames Schema für Topics und Payloads definiert werden. Denn MQTT standardisiert den Transport – nicht automatisch das fachliche Datenmodell.

Wann würde ich REST einsetzen?

REST ist besonders interessant, wenn eine Anwendung gezielt Funktionen oder Ressourcen einer anderen Anwendung verwenden möchte – typisch für Stammdaten, Konfiguration, Auftragsdaten, Benutzeroberflächen, ERP-Integration und klassische Geschäftslogik:

GET /machines
GET /production-orders/4711
POST /production-orders
PATCH /production-orders/4711
GET /users

Wann würde ich ein Maschinenprotokoll direkt verwenden?

Immer dann, wenn genau diese Schnittstelle die beste oder einzige Möglichkeit ist, auf ein Gerät zuzugreifen. Eine 15 Jahre alte Maschine mit stabil funktionierendem Modbus TCP muss nicht zwingend eine neue Steuerung erhalten. Dann kann die Architektur bewusst lauten:

Legacy-Maschine
      │
      │ Modbus
      ▼
Edge Adapter
      │
      │ modernes Datenmodell
      ▼
restliche Architektur

Das proprietäre oder ältere Protokoll bleibt bestehen. Aber: Es endet an einer kontrollierten Integrationsgrenze. Das ist ein wesentliches Prinzip guter Brownfield-Integration.

Der wichtigste Unterschied im Überblick

Eigenschaft	OPC UA	MQTT	REST / HTTP	Maschinenprotokoll
Hauptaufgabe	Maschinen-/Informationsintegration	Nachrichtenverteilung	Anwendungsintegration	Gerätekommunikation
Modell	Client/Server + PubSub	Publish/Subscribe	Request/Response	abhängig vom Protokoll
Broker nötig	Nein (außer PubSub-Varianten)	typischerweise ja	Nein	meistens nein
Datenmodell	Ja, integriert	Nein	selbst zu definieren	gerätespezifisch
Semantik	sehr stark	anwendungsspezifisch	anwendungsspezifisch	meist gering
Browsing	Ja	Nein	normalerweise nein	meist nein
Methoden	Ja	über eigene Messages	Ja, über API	protokollspezifisch
Events	Ja	sehr gut geeignet	nur mit Zusätzen	geräteabhängig
Maschinenintegration	sehr gut	möglich, Modell fehlt	möglich, oft nicht ideal	direkt am Gerät
Backend-/ERP-Integration	möglich	möglich	sehr gut	ungeeignet
Telemetrie/Fan-out	PubSub möglich	sehr gut	bedingt	meist ungeeignet
Brownfield	über Gateway sehr gut	über Gateway möglich	über Gateway möglich	häufig Ausgangspunkt

Die Tabelle zeigt: Es gibt keinen universellen Sieger.

Drei typische Architekturen

1. Moderne Produktionsmaschine

Die Maschine besitzt einen guten OPC-UA-Server. Hier würde es wenig Sinn ergeben, die strukturierte Maschinenschnittstelle künstlich durch eine eigene REST-API zu ersetzen. OPC UA passt direkt zur Aufgabe.

Maschine
   │
   │ OPC UA
   ▼
MES

2. Viele Geräte liefern Telemetrie

Hundert Edge-Systeme liefern regelmäßig Zustände. Hier besitzt ein PubSub-System klare Vorteile. MQTT passt gut zur Aufgabe.

Edge 1 ──┐
Edge 2 ──┤
Edge 3 ──┼──► MQTT Broker ───► Analytics
...      │                 └──► Monitoring
Edge100 ─┘

3. MES kommuniziert mit ERP

Das MES benötigt einen Auftrag. Hier ist eine REST-API sehr natürlich.

MES
 │
 │ GET /orders/4711
 ▼
ERP

Ein realistischer Produktionsbetrieb braucht meistens mehrere Technologien

In realen Produktionsanlagen sieht die Architektur häufig so aus:

                         ERP
                          │
                         REST
                          │
                          ▼
                         MES
                          │
               ┌──────────┴──────────┐
               │                     │
              REST               Messaging
               │                     │
               ▼                     ▼
          Services                  Broker
                                      ▲
                                      │
                                Edge Services
                                      │
                  ┌───────────────────┼───────────────┐
                  │                   │               │
               OPC UA             Modbus        proprietär
                  │                   │               │
                  ▼                   ▼               ▼
              Maschine A         Maschine B      Maschine C

Das ist kein Zeichen für eine schlechte Architektur. Im Gegenteil:

Eine gute Architektur verwendet unterschiedliche Technologien dort, wo ihre jeweiligen Stärken liegen.

Die gefährliche Idee: Ein Protokoll für alles

In Digitalisierungsprojekten entsteht gelegentlich der Wunsch: „Wir standardisieren jetzt alles auf MQTT." Oder: „Ab sofort kommuniziert alles nur noch über OPC UA." Das klingt zunächst attraktiv – ein Protokoll, eine Technologie, eine Dokumentation. Aber dadurch werden unterschiedliche Anforderungen künstlich gleich behandelt. Eine Maschine besitzt andere Kommunikationsanforderungen als ein ERP-System. Ein Sensorevent besitzt andere Eigenschaften als das Abfragen eines Produktionsauftrags.

Deshalb sollte Standardisierung nicht bedeuten: Überall dieselbe Technologie. Sondern: Für dieselbe Aufgabe dieselbe Architektur. Das ist ein großer Unterschied.

Was sollte bei neuen Maschinen gefordert werden?

Bei einer neuen Maschine ist die Frage „Unterstützt die Maschine OPC UA?" noch nicht ausreichend. Sinnvoller sind konkretere Fragen:

Welche Datenpunkte, Methoden, Events und Alarme stehen zur Verfügung?
Welche Schreibzugriffe sind möglich?
Welches Informationsmodell wird verwendet, und gibt es eine passende Companion Specification?
Wie funktioniert die Security (Authentifizierung, Verschlüsselung, Integritätsschutz)?
Welche Daten sind tatsächlich nutzbar – nicht nur technisch vorhanden?

Eine OPC-UA-Schnittstelle mit Variable1, Variable2, Variable3 ist technisch OPC UA. Sie besitzt aber nur wenig Mehrwert gegenüber einer schlecht dokumentierten Registerliste. Die Qualität der Schnittstelle hängt erheblich vom Informationsmodell ab.

Und was sollte bei MQTT definiert werden?

Auch „MQTT vorhanden" ist alleine noch keine ausreichende Schnittstellenspezifikation. Es sollten unter anderem definiert werden:

Topic-Struktur

factory/{site}/{line}/{machine}/state

Payload und Schema-Version

{
  "machineId": "machine-17",
  "state": "RUNNING",
  "timestamp": "2026-08-20T10:15:12.382Z",
  "schemaVersion": "1.0"
}

Außerdem: Welche QoS-Stufe? Sollen Retained Messages den letzten Zustand für neue Subscriber bereithalten? Was passiert bei Verbindungsunterbrechungen? Und was bedeutet RUNNING genau?

Denn die eigentliche Herausforderung beginnt auch bei MQTT nicht beim Transport. Sie beginnt beim gemeinsamen Verständnis der Daten.

Auch eine REST-API braucht einen Datenvertrag

Eine API wie GET /machines/17 ist technisch schnell erstellt. Entscheidend ist aber das Datenmodell und Fragen wie: Welche Werte kann state annehmen? Welche Felder sind Pflicht? Wie wird versioniert? Wie werden Fehler dargestellt? Wie funktioniert Authentifizierung? Wie bleiben alte Clients kompatibel?

Die Technologie transportiert Daten. Die Architektur definiert deren Bedeutung.

Genau darin liegt der gemeinsame Nenner

OPC UA, MQTT und REST unterscheiden sich erheblich. Aber alle drei führen am Ende zur selben grundlegenden Architekturfrage:

Was bedeutet unsere Information?

MQTT mit schlechten Payloads ist keine gute Integration. Genauso wenig wie REST mit undokumentierter API oder OPC UA mit Variable001. Die langfristige Qualität einer industriellen Schnittstelle hängt deshalb nicht ausschließlich vom verwendeten Protokoll ab. Mindestens genauso wichtig sind: Datenmodell, Semantik, Versionierung, Identifikation, Zustandsmodell, Fehlerbehandlung, Security und Dokumentation.

Genau hier setzt auch unser Ansatz bei xpand an

Bei xpand versuchen wir deshalb nicht, jede Kommunikation zwangsläufig über dieselbe Technologie abzuwickeln. Eine vorhandene Maschine kann weiterhin Modbus sprechen. Eine moderne Maschine OPC UA. Ein Edge-Service kann Ereignisse über eine Messaging-Infrastruktur verteilen. Und das MES stellt für Frontend oder ERP eine REST-API bereit.

                        ERP
                         │
                        REST
                         │
                         ▼
                    xpand / MES
                         │
                ┌────────┴─────────┐
                │                  │
              REST             Messaging
                                   │
                                   ▼
                            Integrationslayer
                                   │
                   ┌───────────────┼──────────────┐
                   ▼               ▼              ▼
                OPC UA          Modbus      proprietär
                   │               │              │
                   ▼               ▼              ▼
               Maschine        Maschine       Maschine

Der wichtigste Punkt liegt zwischen diesen Ebenen: Das Datenmodell bleibt möglichst einheitlich, obwohl die technischen Schnittstellen unterschiedlich sein können. Damit muss das MES nicht wissen, ob ein Maschinenzustand ursprünglich aus OPC UA oder aus Modbus Register 17 stammt. Und die ERP-Schnittstelle muss nicht verstehen, wie die Maschine technisch kommuniziert. Jede Technologie endet dort, wo ihre Aufgabe endet.

Fazit: OPC UA vs. MQTT ist meistens die falsche Frage

Welche Technologie ist also die beste? Die Antwort lautet:

Es kommt darauf an, welche Aufgabe gelöst werden soll.

Für strukturierten Zugriff auf Maschinen, Gerätefunktionen und semantisch beschriebene Daten ist OPC UA sehr stark. Für lose gekoppelte Publish/Subscribe-Kommunikation, Telemetrie und die Verteilung von Ereignissen ist MQTT hervorragend geeignet. Für klassische Kommunikation zwischen Softwareanwendungen, MES, ERP und Web-Frontends sind REST-basierte HTTP-APIs häufig eine sehr natürliche Lösung. Und bei vorhandenen Maschinen bleiben Modbus, S7, serielle oder proprietäre Protokolle oft weiterhin die technische Realität.

Maschine verstehen
        ↓
      OPC UA

Legacy anbinden
        ↓
Maschinenprotokoll + Adapter

Ereignisse verteilen
        ↓
       MQTT

Geschäftssysteme integrieren
        ↓
    REST / HTTP

Und manchmal sogar OPC UA PubSub über MQTT – denn MQTT und OPC UA stehen nicht im Wettbewerb. Sie können sich ergänzen.

Ein Kommunikationsstandard ist kein Selbstzweck.

Die richtige Schnittstelle ist diejenige, die zur Aufgabe und zur jeweiligen Architekturebene passt. Das eigentliche Ziel lautet nicht: „Unsere gesamte Fabrik verwendet dasselbe Protokoll." Sondern:

Unsere Systeme verstehen dieselben Informationen – unabhängig davon, wie diese auf der jeweiligen Ebene transportiert werden.

Genau dann entsteht aus einer Sammlung von Schnittstellen eine nachhaltige Industriearchitektur.

OPC UA, MQTT & Maschinenprotokolle: Welche Schnittstelle braucht eine moderne Produktion wirklich?