OPC UA oder MQTT für Messdaten: Datenmodell, Kommunikationsrichtung und IT/OT-Integration vergleichen

→ Produktkategorie: IIoT-Lösungen

 

Ein Drucksensor liefert:

6,42 bar

Ein Temperatursensor meldet:

78,3 °C

und ein Vibrationssensor erzeugt mehrere Zustandswerte für eine Maschine.

Die Messwerte sollen anschließend:

• im Leitsystem angezeigt,
• in einem Historian gespeichert,
• für ein Dashboard bereitgestellt,
• an ein übergeordnetes IT-System übertragen

werden.

Spätestens bei der Systemarchitektur stellt sich häufig die Frage:

OPC UA oder MQTT?

Die Frage ist sinnvoll – technisch betrachtet handelt es sich jedoch nicht um zwei vollständig austauschbare Protokolle.

OPC UA stellt neben Kommunikationsmechanismen ein umfangreiches Informationsmodell für industrielle Daten bereit. MQTT ist dagegen vor allem ein leichtgewichtiges Publish/Subscribe-Nachrichtenprotokoll, bei dem Anwendungen die Semantik der übertragenen Nutzdaten selbst definieren.

Typisch vereinfacht:

OPC UA → Maschinen- und Prozessdaten strukturiert bereitstellen

MQTT → Daten effizient an viele Empfänger verteilen

In vielen IIoT-Projekten lautet die richtige Antwort deshalb nicht:

OPC UA ODER MQTT

sondern:

OPC UA UND MQTT

Beispielsweise:

Maschine / SPS → OPC UA → Edge-Gateway → MQTT → Broker → Historian / Dashboard / Cloud

Oder sogar:

OPC UA PubSub → MQTT-Broker

denn OPC UA besitzt selbst ein Publish/Subscribe-Modell, das unter anderem MQTT als Transportmechanismus verwenden kann.

Die Protokollauswahl sollte deshalb nicht nur anhand von Datenrate oder Herstellerunterstützung erfolgen. Entscheidend sind Datenmodell, Kommunikationsrichtung, Semantik, Zeitbezug, Datenqualität, Skalierbarkeit, Security und die spätere Nutzung der Messdaten.

IIoT-Lösungen für industrielle Messdaten finden Sie bei ICS Schneider unter IIoT-Lösungen.

Warum OPC UA und MQTT nicht direkt dasselbe sind

In Diskussionen werden OPC UA und MQTT häufig als zwei alternative Industrieprotokolle gegenübergestellt.

Diese Vereinfachung ist für eine erste Orientierung hilfreich, technisch aber unvollständig.

OPC UA umfasst mehr als den Datentransport

OPC UA kann unter anderem:

• Objekte modellieren,
• Variablen bereitstellen,
• Datentypen definieren,
• Beziehungen zwischen Objekten darstellen,
• Methoden bereitstellen,
• Ereignisse übertragen,
• Datenqualität kennzeichnen,
• Zeitstempel übertragen.

MQTT konzentriert sich auf Nachrichtenverteilung

MQTT arbeitet im Kern mit:

Publisher → Broker → Subscriber

Ein Publisher veröffentlicht eine Nachricht auf einem Topic.

Alle berechtigten Subscriber, deren Subscription zum Topic passt, können die Nachricht erhalten.

Das erklärt bereits einen wesentlichen Unterschied

OPC UA beantwortet unter anderem die Frage:

Was bedeutet dieser Wert innerhalb eines industriellen Informationsmodells?

MQTT beantwortet primär:

Wie verteile ich diese Nachricht effizient an interessierte Empfänger?

Was ist OPC UA?

OPC UA steht für:

Open Platform Communications Unified Architecture

OPC UA wurde für den strukturierten und interoperablen Informationsaustausch zwischen industriellen Systemen entwickelt.

Address Space

Ein OPC-UA-Server stellt Informationen in einem:

Address Space

bereit.

Dort können beispielsweise dargestellt werden:

Werk → Linie → Maschine → Pumpe → Druck

Ein Wert ist mehr als eine Zahl

Eine Variable kann beispielsweise enthalten beziehungsweise zugeordnet bekommen:

• Wert,
• Datentyp,
• Status,
• Zeitstempel,
• Engineering Unit,
• Beschreibung,
• weitere Beziehungen und Metadaten.

Beispiel

Statt lediglich:

6.42

zu übertragen, kann ein System sinngemäß bereitstellen:

Asset: Pump_17

Variable: DischargePressure

Value: 6.42

Unit: bar

Quality: Good

SourceTimestamp: 2026-08-19T10:15:42.250Z

Die Semantik ist damit wesentlich stärker an die Daten selbst gekoppelt.

Was ist MQTT?

MQTT steht für:

Message Queuing Telemetry Transport

Das Protokoll wurde für eine effiziente Nachrichtenübertragung nach dem Publish/Subscribe-Prinzip entwickelt.

Grundstruktur

MQTT verwendet:

• Clients,
• Publisher,
• Subscriber,
• einen Broker,
• Topics,
• Nachrichten beziehungsweise Payloads.

Beispiel

Ein Edge-Gateway publiziert einen Druckwert unter:

plant/berlin/line3/pump17/pressure/discharge

Der Payload könnte beispielsweise lauten:

{"value":6.42,"unit":"bar","quality":"good","ts":"2026-08-19T10:15:42.250Z"}

Wichtiger Unterschied

MQTT schreibt nicht grundsätzlich vor, dass ein solcher Payload:

• JSON,
• XML,
• Binärdaten,
• eine einzelne Zahl

enthalten muss.

Die Nutzdatenstruktur wird durch die beteiligten Anwendungen beziehungsweise das eingesetzte Datenmodell festgelegt.

MQTT sorgt zuverlässig für die Nachrichtenverteilung – die fachliche Bedeutung der Nachricht muss die Systemarchitektur definieren.

OPC UA Client/Server verstehen

Die klassische OPC-UA-Kommunikation arbeitet häufig nach:

Client ↔ Server

Server

Der Server stellt seine Informationen bereit.

Client

Der Client entscheidet, welche Informationen er:

• durchsuchen,
• lesen,
• gegebenenfalls schreiben,
• überwachen

möchte.

Browsing

Ein großer Vorteil besteht darin, dass ein Client die Struktur eines Servers durchsuchen kann.

Beispielsweise:

Objects

→ ProductionLine3

→ Pump17

→ Measurements

→ DischargePressure

Subscriptions

Ein Client muss Werte nicht permanent durch wiederholtes Lesen abfragen.

Er kann für relevante Variablen Subscriptions beziehungsweise überwachte Elemente anlegen.

Der Server liefert anschließend entsprechende Änderungen.

OPC UA PubSub nicht vergessen

Die Aussage:

OPC UA = Client/Server

ist heute unvollständig.

OPC UA besitzt auch ein eigenes:

Publish/Subscribe-Modell

Publisher und Subscriber sind entkoppelt

Bei OPC UA PubSub veröffentlicht ein Publisher konfigurierte Datensätze.

Subscriber empfangen die für sie relevanten Datensätze.

Brokerlos oder brokerbasiert

OPC UA PubSub unterstützt unterschiedliche Transportkonzepte.

Dazu gehören:

• brokerlose Kommunikation, beispielsweise über Datagramm-Mechanismen,
• brokerbasierte Kommunikation.

MQTT kann dabei Teil von OPC UA sein

Für brokerbasierte OPC-UA-PubSub-Kommunikation kann MQTT als Messaging-Protokoll eingesetzt werden.

Damit kann eine Architektur beispielsweise lauten:

OPC-UA-Informationsmodell → OPC UA PubSub → MQTT → Broker

Wichtige Konsequenz für die Auswahl

„OPC UA oder MQTT?“ ist deshalb teilweise die falsche Frage. OPC UA kann die industrielle Semantik liefern, während MQTT gleichzeitig für den Nachrichtentransport verwendet wird.

Publish/Subscribe bei MQTT

MQTT basiert grundsätzlich auf Publish/Subscribe.

Publisher

Ein Publisher sendet beispielsweise:

Topic:

plant/berlin/line3/pump17/pressure

mit:

Payload: {"value":6.42}

Subscriber

Ein Subscriber kann sich beispielsweise anmelden auf:

plant/berlin/line3/pump17/pressure

Wildcard-Subscription

Ein anderes System könnte beispielsweise alle Messdaten der Pumpe abonnieren:

plant/berlin/line3/pump17/#

Vorteil

Der Publisher muss nicht wissen:

• welches Dashboard die Daten verwendet,
• welcher Historian sie speichert,
• welche Cloud-Anwendung sie verarbeitet.

Er publiziert lediglich seine Nachricht.

Welche Rolle spielt der MQTT-Broker?

Der Broker bildet den zentralen Nachrichtenvermittler einer klassischen MQTT-Architektur.

Beispiel

Edge-Gateway

↓

MQTT-Broker

↓ ↓ ↓

Historian / Dashboard / MES

Der Broker übernimmt unter anderem

• Entgegennahme von Nachrichten,
• Abgleich mit Subscriptions,
• Weiterleitung an Subscriber,
• QoS-Verarbeitung,
• je nach Konfiguration Session-Verwaltung,
• Retained Messages,
• Zugriffskontrolle.

Architekturvorteil

Neue Datenverbraucher können hinzugefügt werden, ohne dass das Feldgerät oder Gateway jeden Empfänger individuell kennen muss.

Datenmodell: der größte Unterschied

Gerade bei industriellen Messdaten ist der Zahlenwert allein selten ausreichend.

Ein Druckwert benötigt Kontext

Beispielsweise:

• Messstelle,
• Messgröße,
• Einheit,
• Zeitstempel,
• Qualität,
• Messbereich,
• Sensor-ID.

OPC UA

OPC UA besitzt dafür ein standardisiertes Informationsmodell mit:

• Nodes,
• Objects,
• Variables,
• References,
• DataTypes,
• Properties.

MQTT

MQTT transportiert eine Nachricht zu einem Topic.

Was innerhalb der Nachricht bedeutet:

6.42

muss die Anwendung definieren.

Schlechtes MQTT-Beispiel

Topic: sensor17

Payload: 6.42

Hier fehlen beispielsweise:

• Messgröße,
• Einheit,
• Standort,
• Zeitbezug,
• Qualitätsinformation.

Besser

plant/berlin/line3/pump17/pressure/discharge

mit:

{"value":6.42,"unit":"bar","ts":"2026-08-19T10:15:42.250Z","quality":"good"}

MQTT-Topics richtig strukturieren

MQTT-Topics können hierarchisch aufgebaut werden.

Die einzelnen Ebenen werden typischerweise durch:

/

getrennt.

Beispiel für eine industrielle Struktur

plant/{werk}/area/{bereich}/line/{linie}/device/{id}/measurement/{messgroesse}

Konkretes Beispiel

plant/berlin/area/production/line/3/device/pump17/measurement/pressure

Wichtig sind stabile IDs

Ungünstig wäre beispielsweise ein Topic, das von frei veränderbaren Beschreibungstexten abhängt.

Besser sind:

• eindeutige Asset-IDs,
• ein fest definiertes Namensschema,
• eine dokumentierte Versionierung.

Topics nicht mit dem vollständigen Datenmodell verwechseln

Die Topic-Hierarchie kann zwar bereits fachliche Informationen enthalten.

Sie ersetzt jedoch nicht automatisch ein konsistentes Datenmodell.

MQTT-Payload eindeutig definieren

Ein häufiger IIoT-Fehler besteht darin, zwar MQTT einzuführen, aber kein einheitliches Payload-Schema festzulegen.

System A sendet

{"pressure":6.42}

System B sendet

{"p":6.42,"u":"bar"}

System C sendet

6.42

Folge

Jede nachgelagerte Anwendung benötigt individuelle Übersetzungslogik.

Besser

Ein gemeinsames Schema definieren, beispielsweise:

{"value":6.42,"unit":"bar","timestamp":"2026-08-19T10:15:42.250Z","quality":"good"}

Zusätzliche mögliche Felder

• deviceId,
• measurementId,
• status,
• alarm,
• rangeMin,
• rangeMax,
• firmwareVersion,
• configurationVersion.

Zeitstempel bei Messdaten richtig behandeln

Bei Messdaten ist nicht nur wichtig:

Welcher Wert?

sondern ebenso:

Wann wurde dieser Wert tatsächlich erfasst?

OPC UA unterscheidet verschiedene Zeitbezüge

Ein OPC-UA-DataValue kann unter anderem enthalten:

• SourceTimestamp,
• ServerTimestamp.

SourceTimestamp

beschreibt möglichst den Zeitpunkt an der Quelle des Messwertes.

ServerTimestamp

beschreibt den Zeitpunkt, zu dem der Server den Wert erhalten beziehungsweise als gültig erkannt hat.

Bei MQTT muss der Messzeitpunkt bewusst definiert werden

Nur weil der Broker eine Nachricht um:

10:15:45

empfängt, bedeutet das nicht, dass der Messwert zu diesem Zeitpunkt aufgenommen wurde.

Beispiel bei Offline-Pufferung

Sensorwert aufgenommen:

10:10:00

Netzwerk wieder verfügbar:

10:15:00

Nachricht veröffentlicht:

10:15:01

Ohne Messzeitstempel könnte der Historian den Wert um fünf Minuten falsch einordnen.

Empfehlung

Bei MQTT-Telemetrie sollte der Payload für relevante Prozessdaten einen eindeutigen:

UTC-Zeitstempel der Messwerterfassung

enthalten.

Messwertqualität übertragen

Ein Messwert ist nicht automatisch gültig, nur weil er numerisch vorliegt.

Beispiel

Ein Druckwert lautet:

6,42 bar

Der Sensor befindet sich jedoch gleichzeitig in einem Diagnosezustand.

OPC UA

OPC UA kann einen StatusCode zusammen mit dem Wert übertragen.

Damit kann zwischen beispielsweise:

• Good,
• Uncertain,
• Bad

unterschieden werden.

MQTT

Bei einem eigenen MQTT-Datenmodell sollte eine entsprechende Qualitätsinformation ausdrücklich vorgesehen werden.

Beispielsweise:

{"value":6.42,"unit":"bar","quality":"bad"}

Warum wichtig?

Ein Historian sollte einen fehlerhaften Sensorwert nicht genauso behandeln wie einen gültigen Prozesswert.

Einheiten und Skalierung dokumentieren

Der Zahlenwert:

25

kann beispielsweise bedeuten:

• 25 bar,
• 25 kPa,
• 25 °C,
• 25 %,
• 25 mm.

OPC UA

OPC UA bietet standardisierte Möglichkeiten, Engineering Units an Variablen zu beschreiben.

MQTT

Bei MQTT muss die Einheit beispielsweise:

• im Payload,
• über Metadaten,
• über eine zentrale Schema-Definition

festgelegt werden.

Skalierung nicht nur im Empfängersystem verstecken

Ein Rohwert:

16384

ist langfristig problematisch, wenn nur eine einzelne SPS weiß:

16384 entspricht 6,42 bar

Eine saubere Edge-/IIoT-Architektur sollte Messgrößen möglichst eindeutig und dokumentiert bereitstellen.

Kommunikationsrichtung vergleichen

Die Kommunikationsrichtung beeinflusst wesentlich die Netzarchitektur.

OPC UA Client/Server

Typisch:

Client → Verbindung zum Server

Der Client liest, browsed oder abonniert Informationen des Servers.

MQTT

Typisch:

Publisher → ausgehende Verbindung zum Broker

und:

Subscriber → Verbindung zum Broker

Vorteil bei IT/Cloud-Anbindung

Ein Edge-Gateway kann Messdaten aktiv nach außen zu einem definierten Broker übertragen.

Damit muss nicht zwangsläufig jedes übergeordnete System direkt auf jedes Feldgerät zugreifen.

OT-Sicht

Für lokale SCADA- oder Maschinenintegration kann dagegen das Browsing und gezielte Lesen eines OPC-UA-Servers besonders komfortabel sein.

MQTT QoS richtig einordnen

MQTT definiert drei Quality-of-Service-Stufen:

QoS	Grundprinzip	Typische Überlegung
0	At most once	Geringer Overhead, Nachricht kann verloren gehen
1	At least once	Zustellung wird bestätigt, Duplikate sind möglich
2	Exactly once	Höherer Protokollaufwand

QoS ist keine Messwertqualität

Das ist eine wichtige Unterscheidung.

MQTT QoS

beschreibt die Nachrichtenübertragung.

Es sagt nichts darüber aus, ob:

der Drucksensor korrekt misst

Ebenso ersetzt QoS keinen Zeitstempel

Eine zuverlässig zugestellte Nachricht kann trotzdem einen alten gepufferten Messwert enthalten.

Retained Messages sinnvoll einsetzen

MQTT kann eine Nachricht für ein Topic als:

retained

speichern.

Ein neuer Subscriber kann dadurch den zuletzt gespeicherten Wert unmittelbar erhalten.

Gut geeignet beispielsweise für

• Gerätestatus,
• Konfigurationsinformationen,
• letzten bekannten Zustand,
• bestimmte Metadaten.

Bei Ereignissen vorsichtig

Ein alter Alarm sollte nicht allein deshalb wie ein neues Ereignis erscheinen, weil ein neuer Subscriber die retained Nachricht erhält.

Zustand und Ereignis unterscheiden

state

und:

event

sollten deshalb im Datenmodell eindeutig getrennt werden.

Bandbreite und Datenmenge

MQTT wird häufig dort eingesetzt, wo Messdaten effizient an übergeordnete Systeme verteilt werden sollen.

Datenmenge hängt nicht nur vom Protokoll ab

Entscheidend sind ebenso:

• Abtastrate,
• Publikationsrate,
• Payload-Größe,
• Anzahl der Messstellen,
• QoS,
• Metadaten,
• Verbindungsaufbau.

Abtasten und Publizieren unterscheiden

Ein Edge-Gateway kann beispielsweise intern:

10 Werte/s

erfassen.

An die IT werden jedoch nur:

1 Wert/s

oder statistische Größen übertragen.

Edge-Vorverarbeitung

Mögliche Funktionen:

• Min/Max,
• Mittelwert,
• Median,
• Deadband,
• Publish-on-change,
• Alarmereignisse.

Rolle des Edge-Gateways

In vielen industriellen Anlagen sitzt zwischen Feldtechnik und IT ein Edge-Gateway.

Typische Architektur

Sensoren / SPS / Feldgeräte

↓

Modbus / HART / IO-Link / OPC UA

↓

Edge-Gateway

↓

MQTT / HTTPS / OPC UA

↓

SCADA / Historian / MES / Cloud

Edge-Aufgaben

Das Gateway kann beispielsweise:

• Feldprotokolle lesen,
• Rohwerte skalieren,
• Einheiten vereinheitlichen,
• Zeitstempel setzen beziehungsweise übernehmen,
• Qualitätsinformationen abbilden,
• Topics erzeugen,
• lokale Alarme berechnen,
• Daten puffern,
• Protokolle übersetzen.

Das Gateway wird damit zur semantischen Grenze

Genau an dieser Stelle sollte klar dokumentiert werden:

Wie wird aus einem Feldwert ein IT-verwendbarer Messwert?

Brownfield-Anlagen integrieren

Bestehende Anlagen besitzen häufig keine modernen IIoT-Schnittstellen.

Typische vorhandene Signale

• 4 … 20 mA,
• 0 … 10 V,
• HART,
• Modbus RTU,
• PROFIBUS,
• digitale Schaltzustände.

Diese Geräte müssen nicht zwangsläufig ersetzt werden

Ein Edge-System kann vorhandene Signale erfassen und in ein einheitliches Datenmodell überführen.

Beispiel

4 … 20 mA Drucktransmitter

↓

Edge-Analogeingang

↓

Skalierung 0 … 10 bar

↓

MQTT-Payload mit Wert + Einheit + Zeit + Qualität

Oder

Eine bestehende SPS stellt bereits strukturierte Daten über OPC UA bereit.

Dann kann das Edge-System diese Daten übernehmen und für weitere IT-Systeme beispielsweise über MQTT publizieren.

OPC UA für SCADA und OT

OPC UA ist besonders stark, wenn ein übergeordnetes System die Struktur eines industriellen Systems verstehen und gezielt auf Daten zugreifen soll.

Typische Anwendungen

• SCADA,
• HMI,
• Maschinenintegration,
• SPS-Kommunikation,
• Prozessleitsysteme,
• OT-Datendrehscheiben.

Vorteil

Ein Client kann die bereitgestellte Struktur browsen und muss nicht ausschließlich eine extern gepflegte Liste kryptischer Datenpunkte kennen.

Auch Kommandos und Methoden sind möglich

OPC UA ist deshalb nicht auf reine Telemetrie beschränkt.

Je nach implementiertem Modell können auch:

• Schreibzugriffe,
• Methoden,
• Ereignisse,
• Diagnoseinformationen

bereitgestellt werden.

MQTT für IT, Cloud und Standortkopplung

MQTT eignet sich besonders für die entkoppelte Verteilung von Telemetriedaten.

Typische Architektur

Werk A ─┐

Werk B ─┼→ MQTT-Broker → Datenplattform

Werk C ─┘

Mehrere Konsumenten

Die gleichen Messdaten können beispielsweise gleichzeitig von:

• Historian,
• Dashboard,
• Alarmdienst,
• Analytics-System,
• MES

verwendet werden.

Neue Anwendung hinzufügen

Die bestehende Feldkommunikation muss dafür nicht zwangsläufig verändert werden.

Der neue Subscriber abonniert lediglich die erforderlichen Topics.

Security bei OPC UA und MQTT

Beide Technologien können sicher betrieben werden.

Die Sicherheitsmechanismen unterscheiden sich jedoch in ihrer Architektur.

OPC UA

OPC UA besitzt eigene Sicherheitsmechanismen, unter anderem im Zusammenhang mit:

• Secure Channels,
• Anwendungszertifikaten,
• Authentifizierung,
• Autorisierung,
• Signierung und Verschlüsselung entsprechend der eingesetzten Profile.

MQTT

MQTT selbst darf nicht mit Verschlüsselung gleichgesetzt werden.

Für eine sichere industrielle MQTT-Architektur werden typischerweise zusätzlich eingesetzt:

• TLS,
• Broker-Authentifizierung,
• Client-Zertifikate beziehungsweise geeignete Zugangsdaten,
• Topic-basierte Rechte,
• Netzsegmentierung,
• Firewall-Regeln.

Beispiel Rechtekonzept

Ein Mess-Gateway darf:

PUBLISH plant/berlin/line3/#

aber nicht:

SUBSCRIBE plant/other-site/#

Least Privilege

Ein Gerät sollte nur die Topics beziehungsweise OPC-UA-Bereiche erreichen dürfen, die für seine Aufgabe erforderlich sind.

Verbindungsabbrüche und Pufferung

Industrienetze und Standortverbindungen sind nicht immer dauerhaft verfügbar.

Beispiel

Das Edge-Gateway erfasst:

60 Messwerte/min

Die Verbindung zum zentralen System fällt für:

10 Minuten

aus.

Ohne lokale Pufferung

entsteht eine Datenlücke.

Mit Store-and-Forward

können Messwerte lokal gespeichert und nach Wiederherstellung der Verbindung übertragen werden.

Zeitstempel erneut entscheidend

Die gespeicherten Werte müssen dabei ihren ursprünglichen:

Messzeitpunkt

behalten.

Andernfalls würde der gesamte Rückstau zeitlich falsch eingeordnet.

OPC UA und MQTT gemeinsam einsetzen

Für viele Industrieprojekte ist eine Kombination besonders sinnvoll.

Beispielarchitektur

SPS / Maschine

↓ OPC UA

Edge-Gateway

↓ MQTT

Broker

↓

Historian / Dashboard / MES / Cloud

OPC UA übernimmt

• strukturierte OT-Anbindung,
• Browsing,
• Datentypen,
• Semantik,
• Status- und Zeitinformationen.

MQTT übernimmt

• entkoppelte Verteilung,
• Broker-Kommunikation,
• Verteilung an viele Subscriber,
• Standort- und IT-Integration.

Mapping ist entscheidend

Das Edge muss beispielsweise festlegen:

OPC-UA-Node Pump17.DischargePressure

wird zu:

plant/berlin/line3/pump17/pressure/discharge

mit Payload:

{"value":6.42,"unit":"bar","quality":"good","ts":"2026-08-19T10:15:42.250Z"}

Semantik nicht verlieren

Eine Protokollumsetzung ist erst dann vollständig, wenn neben dem Zahlenwert auch Einheit, Qualität, Zeitbezug und Asset-Zuordnung sauber übertragen werden.

Typische Fehler bei OPC-UA- und MQTT-Integrationen

Beobachtung	Mögliche Ursache	Sinnvolle Prüfung
MQTT-Werte sind vorhanden, aber niemand weiß die Einheit	Unvollständiges Payload-/Metadatenmodell	Schema um Einheit und Messgröße ergänzen
Dashboard zeigt zeitlich verschobene Werte	Broker-/Empfangszeit statt Messzeit verwendet	Source-Zeitstempel übertragen und auswerten
Fehlerhafter Sensorwert wird als gültig gespeichert	Qualitätsinformation beim Mapping verloren	Status-/Quality-Feld in Datenmodell aufnehmen
Jede Anwendung benötigt eigenes Parsing	Unterschiedliche MQTT-Payloads	Einheitliches Schema definieren
MQTT-Topic-Struktur wird nach Anlagenumbau unbrauchbar	Topics basieren auf veränderbaren Namen statt stabilen IDs	Asset- und Topic-Konzept überarbeiten
SCADA findet Datenpunkte nicht automatisch	Reine MQTT-Telemetrie ohne entsprechendes Informationsmodell	OPC-UA-Schnittstelle beziehungsweise Mapping prüfen
Viele direkte Verbindungen belasten die SPS	Viele unabhängige Clients greifen direkt zu	Edge-/Broker-Architektur prüfen
Nach Verbindungsausfall fehlen Messwerte	Keine lokale Pufferung	Store-and-Forward am Edge vorsehen
Nach Wiederverbindung erscheinen alte Daten als neue Werte	Messzeitstempel fehlt	Original-Zeitstempel erhalten
Alter Alarm erscheint bei neuem Subscriber erneut	Retained Message ungeeignet für Event verwendet	Zustand und Ereignis getrennt modellieren
MQTT funktioniert, ist aber unverschlüsselt	TLS nicht konfiguriert	Broker-, Client- und Zertifikatskonfiguration prüfen
OPC-UA-Verbindung scheitert nach Zertifikatwechsel	Trust-/Zertifikatsverwaltung nicht aktualisiert	Zertifikate und Trust Lists prüfen

Systematischer Auswahlablauf für OPC UA oder MQTT

1. Datenquelle bestimmen: Sensor, SPS, Maschine, Edge-System oder Datenbank identifizieren.
2. Vorhandene Schnittstellen erfassen: 4 … 20 mA, HART, Modbus, IO-Link, OPC UA, Ethernet oder andere Protokolle dokumentieren.
3. Datenverbraucher bestimmen: SCADA, HMI, Historian, MES, ERP, Dashboard oder Cloud unterscheiden.
4. Kommunikationsrichtung festlegen: Direkte Abfrage, Subscription oder Publish/Subscribe bestimmen.
5. Datenmodell bewerten: Prüfen, ob strukturierte Objekte, Typen und Beziehungen benötigt werden.
6. Asset-Identitäten definieren: Stabile Maschinen-, Sensor- und Messstellen-IDs vergeben.
7. Messgrößen definieren: Wert, Einheit und Messbereich eindeutig festlegen.
8. Zeitmodell definieren: Messzeit, Empfangszeit und gegebenenfalls Serverzeit unterscheiden.
9. Qualitätsmodell definieren: Good/Bad/Uncertain beziehungsweise entsprechendes eigenes Modell vorsehen.
10. OPC UA prüfen: Besonders bei strukturierter OT-/SCADA-Kommunikation und Browsing.
11. MQTT prüfen: Besonders bei entkoppelter Telemetrie, vielen Datenkonsumenten oder IT-/Cloud-Anbindung.
12. Kombination prüfen: OPC UA auf der OT-Seite und MQTT Richtung IT kann sinnvoller sein als eine Entweder-oder-Entscheidung.
13. Topic-Schema definieren: Bei MQTT stabile, hierarchische Topics festlegen.
14. Payload-Schema definieren: Wert, Einheit, Zeitstempel, Qualität und weitere Metadaten standardisieren.
15. QoS auswählen: Nachrichtenrelevanz und zulässigen Kommunikationsaufwand berücksichtigen.
16. Retain-Konzept definieren: Zustandswerte und Ereignisse unterscheiden.
17. Abtast- und Publikationsrate trennen: Datenmenge an Prozessanforderung anpassen.
18. Offline-Verhalten definieren: Pufferung, Wiederanlauf und Store-and-Forward berücksichtigen.
19. Security-Konzept erstellen: TLS, Zertifikate, Authentifizierung, Rechte und Segmentierung planen.
20. Pilot aufbauen: Einige repräsentative Messstellen vollständig integrieren.
21. Datenqualität prüfen: Werte, Einheit, Zeit, Qualität und Asset-Zuordnung Ende-zu-Ende kontrollieren.
22. Mapping dokumentieren: Feldvariable → OPC-UA-Node → MQTT-Topic → Zielsystem nachvollziehbar festhalten.
23. Skalierung testen: Zusätzliche Geräte und Subscriber hinzufügen und Systemlast beobachten.
24. Betriebskonzept festlegen: Zuständigkeit für Zertifikate, Broker, Gateway, Datenmodell und Änderungen definieren.

Praxisbeispiel: Messdaten einer Pumpenanlage

Eine Produktionsanlage besitzt mehrere Pumpen.

Für jede Pumpe werden erfasst:

• Saugdruck,
• Ausgangsdruck,
• Temperatur,
• Vibration,
• Betriebszustand.

Anforderung 1: lokales SCADA

Das SCADA soll:

• alle Pumpen browsen,
• Messwerte anzeigen,
• Statusinformationen erhalten.

Anforderung 2: zentraler Historian

Ein standortübergreifender Historian soll ausgewählte Messwerte speichern.

Anforderung 3: Condition Monitoring

Eine Analytics-Anwendung benötigt:

• Vibrationskennwerte,
• Temperatur,
• Betriebsstatus.

Schritt 1: OPC UA auf OT-Ebene

Die Pumpeninformationen werden strukturiert bereitgestellt.

Beispielsweise:

Pump17

├── SuctionPressure

├── DischargePressure

├── Temperature

├── Vibration

└── Running

Schritt 2: Edge übernimmt Daten

Das Edge-System übernimmt relevante Messdaten einschließlich:

• Messwert,
• Zeitstempel,
• Qualität,
• Asset-Zuordnung.

Schritt 3: MQTT Richtung IT

Für den Ausgangsdruck wird beispielsweise publiziert:

plant/berlin/line3/pump17/pressure/discharge

Payload:

{"value":6.42,"unit":"bar","quality":"good","ts":"2026-08-19T10:15:42.250Z"}

Schritt 4: mehrere Subscriber

Der gleiche Wert wird verwendet von:

• Historian,
• Dashboard,
• Condition-Monitoring-Anwendung.

Schritt 5: Verbindung zur Zentrale fällt aus

Das Edge speichert die Messwerte lokal zwischen.

Schritt 6: Verbindung wieder verfügbar

Die gepufferten Daten werden übertragen.

Der Historian verwendet weiterhin:

den ursprünglichen Messzeitstempel

und nicht den Zeitpunkt der späteren Übertragung.

Ergebnis

OPC UA strukturiert in diesem Beispiel die OT-Daten, während MQTT die ausgewählten Messwerte entkoppelt an mehrere IT-Anwendungen verteilt. Beide Technologien übernehmen unterschiedliche Aufgaben innerhalb derselben Architektur.

Passende ICS-Lösungen für OPC-UA- und MQTT-Architekturen

ICS IIoT-Lösungen

Für dieses Thema ist weniger ein einzelner Sensor entscheidend als die vollständige Datenarchitektur.

ICS Schneider beschreibt seine IIoT-Lösungen als Verbindung von:

Sensorik / Feldgeräte → Edge-Gateway → IT/OT-Systeme

mit Technologien wie:

• RS-485 / Modbus RTU,
• HART,
• IO-Link,
• OPC UA,
• Ethernet,
• MQTT,
• HTTPS.

Typische Aufgaben des Edge-Systems

Im Rahmen einer solchen Architektur können unter anderem erforderlich sein:

• Datenerfassung,
• Register-Mapping,
• Skalierung,
• Datenmodellierung,
• Zeitstempelung,
• Topic-Design,
• lokale Alarmverarbeitung,
• sichere Übertragung an SCADA beziehungsweise Cloud.

Weitere Informationen finden Sie unter IIoT-Lösungen bei ICS Schneider.

Siemens SITRANS MS200 als Beispiel einer IIoT-Messkette

Ein konkretes bei ICS gelistetes IIoT-Feldgerät ist der:

Siemens SITRANS MS200

mit der Artikelnummer:

7MP2210-2AB21-2AB1

Der MS200 ist ein Bluetooth-IIoT-Multisensor für:

• Vibration,
• Temperatur.

Die ICS-Produktseite nennt die Verwendung in Kombination mit:

SITRANS CC220 Gateway

und der entsprechenden Siemens-Monitoring-Lösung.

Wichtig für diesen Beitrag

Der MS200 dient hier als Beispiel dafür, dass ein IIoT-Sensor nicht automatisch selbst:

MQTT-Client

oder:

OPC-UA-Server

sein muss.

Die übergeordnete Gateway- beziehungsweise Plattformebene entscheidet darüber, wie die Daten anschließend in weitere Systeme integriert werden.

Die konkrete Unterstützung von OPC UA, MQTT oder anderen IT-Protokollen muss deshalb immer für die tatsächlich verwendete Gateway-, Firmware- und Softwarekonfiguration geprüft werden.

Weitere Informationen finden Sie unter Siemens SITRANS MS200 bei ICS Schneider.

Siemens IIoT-Wägeelektronik für SIMATIC IOT2050

Ein weiteres bei ICS gelistetes Beispiel ist:

7MH4647-0KK00-0AA2

Die IIoT-Wägeelektronik besitzt einen Kanal zum Anschluss einer:

Wägezelle / DMS-Vollbrücke 1 … 4 mV/V

und ist laut ICS für das:

SIMATIC IOT2050 Gateway

vorgesehen.

Typische Architektur

Wägezelle → IIoT-Wägeelektronik → SIMATIC IOT2050 → übergeordnetes System

Auch hier gilt

Die ICS-Produktseite weist die Wägeelektronik als Hardware für das SIMATIC IOT2050 aus.

Welche konkreten:

• OPC-UA-Funktionen,
• MQTT-Funktionen,
• Security-Funktionen,
• Softwarepakete

in einer konkreten Anwendung zur Verfügung stehen, hängt von der eingesetzten Gateway- und Softwarekonfiguration ab und muss projektspezifisch geprüft werden.

Weitere Informationen finden Sie unter Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 bei ICS Schneider.

Welche Lösung passt zu welcher Aufgabe?

Anforderung	Typischer Ansatz
Maschinenstruktur browsen und Messwerte semantisch bereitstellen	OPC UA prüfen
Messwerte an viele IT-Systeme verteilen	MQTT prüfen
SCADA-Anbindung innerhalb OT	OPC UA häufig besonders geeignet
Edge-zu-Cloud-Telemetrie	MQTT häufig besonders geeignet
Bestehende Feldgeräte in IIoT integrieren	Edge-Gateway mit Feldprotokoll-Mapping
Strukturierte OT-Daten zusätzlich an Cloud verteilen	OPC UA → Edge → MQTT
OPC-UA-Semantik mit Publish/Subscribe	OPC UA PubSub prüfen
OPC UA PubSub über Broker	MQTT kann als Transport eingesetzt werden

Fazit

Die Frage:

OPC UA oder MQTT?

lässt sich nicht pauschal mit einem Gewinner beantworten.

Beide Technologien besitzen unterschiedliche Stärken.

OPC UA ist besonders stark bei

• strukturierten industriellen Informationsmodellen,
• Browsing,
• SCADA- und OT-Integration,
• Datentypen und Metadaten,
• Statusinformationen,
• Source- und Server-Zeitstempeln,
• Engineering Units.

MQTT ist besonders stark bei

• Publish/Subscribe-Telemetrie,
• entkoppelter Kommunikation,
• Verteilung an viele Datenverbraucher,
• Edge-zu-IT-Kommunikation,
• standortübergreifenden Architekturen,
• Cloud- und Datenplattformintegration.

Der wichtigste Unterschied

MQTT allein definiert nicht automatisch ein industrielles Datenmodell.

Ein Topic wie:

sensor17

und ein Payload wie:

6.42

sind technisch übertragbar, aber fachlich nur eingeschränkt nutzbar.

Für langfristig belastbare Messdaten müssen zusätzlich definiert werden:

• Messstelle,
• Messgröße,
• Einheit,
• Zeitstempel,
• Datenqualität,
• Asset-ID,
• Schema-Version.

OPC UA und MQTT können sich ergänzen

Eine sehr typische Architektur lautet:

Feldgerät / SPS → OPC UA → Edge → MQTT → Broker → IT / Cloud

Darüber hinaus besitzt OPC UA selbst ein PubSub-Modell, das auch MQTT als brokerbasierten Transport verwenden kann.

Die richtige Architektur entsteht deshalb nicht durch die Entscheidung für einen Protokollnamen, sondern durch die saubere Zuordnung der Aufgaben: Feldintegration → Datenmodell → Zeit und Qualität → Edge-Verarbeitung → Transport → Datenverbraucher → Security → Betrieb.

Für die Praxis gilt:

Datenquelle bestimmen → vorhandene Schnittstelle erfassen → Datenverbraucher definieren → Kommunikationsrichtung festlegen → Datenmodell entwerfen → stabile Asset-IDs vergeben → Einheit, Zeitstempel und Qualität festlegen → OPC UA für strukturierte OT-Integration prüfen → MQTT für entkoppelte Telemetrie prüfen → Kombination beider Technologien bewerten → Topic- und Payload-Schema definieren → QoS und Retain passend auswählen → Offline-Pufferung vorsehen → TLS/Zertifikate/Rechte planen → End-to-End-Mapping testen → Dokumentation und Verantwortlichkeiten festlegen.

FAQ: OPC UA oder MQTT für industrielle Messdaten

Was ist der wichtigste Unterschied zwischen OPC UA und MQTT?

OPC UA umfasst ein umfangreiches industrielles Informationsmodell und verschiedene Kommunikationsmechanismen. MQTT ist primär ein Publish/Subscribe-Nachrichtenprotokoll zur Verteilung von Anwendungsnachrichten über Topics und einen Broker.

Ist OPC UA ein Client/Server-Protokoll?

OPC UA unterstützt Client/Server-Kommunikation, besitzt aber zusätzlich ein eigenes Publish/Subscribe-Modell.

Ist MQTT immer Publish/Subscribe?

Das grundlegende MQTT-Kommunikationsmodell basiert auf Publishern, einem Broker und Subscribern.

Kann OPC UA auch Publish/Subscribe?

Ja. OPC UA PubSub ergänzt das klassische Client/Server-Modell.

Kann OPC UA PubSub MQTT verwenden?

Ja. OPC UA PubSub kann in einer brokerbasierten Architektur unter anderem MQTT als Messaging-Transport verwenden.

Sind OPC UA und MQTT deshalb keine Alternativen?

Sie können für bestimmte Aufgaben Alternativen sein, übernehmen aber häufig unterschiedliche Rollen und können innerhalb derselben Architektur kombiniert werden.

Wann eignet sich OPC UA besonders?

Wenn strukturierte Maschinendaten, Browsing, industrielle Semantik, Statusinformationen oder eine klassische SCADA-/OT-Integration benötigt werden.

Wann eignet sich MQTT besonders?

Wenn Messdaten effizient und entkoppelt an einen oder mehrere Datenverbraucher, Standorte oder IT-/Cloud-Systeme verteilt werden sollen.

Was ist ein OPC-UA-Address-Space?

Der Address Space ist die strukturierte Informationsdarstellung eines OPC-UA-Servers. Darin werden unter anderem Objekte, Variablen, Typen und Beziehungen abgebildet.

Was ist ein MQTT-Topic?

Ein Topic ist die Bezeichnung des Informationskanals, unter dem eine MQTT-Nachricht veröffentlicht wird.

Können MQTT-Topics hierarchisch aufgebaut werden?

Ja. Topic-Ebenen werden mit einem Schrägstrich getrennt.

Was ist ein gutes MQTT-Topic für einen Drucksensor?

Beispielsweise plant/berlin/line3/pump17/pressure/discharge. Das konkrete Schema sollte jedoch für die gesamte Anlage einheitlich definiert werden.

Sollte die Einheit im MQTT-Topic stehen?

Nicht zwingend. Häufig ist es günstiger, die Einheit im Payload oder in definierten Metadaten zu führen, damit sich das Topic nicht bei einer geänderten Darstellungseinheit ändern muss.

Definiert MQTT das JSON-Format?

Nein. MQTT transportiert anwendungsspezifische Nutzdaten. JSON ist lediglich eine mögliche Payload-Darstellung.

Muss MQTT JSON verwenden?

Nein. Der Payload kann abhängig von der Anwendung beispielsweise Text, JSON oder Binärdaten enthalten.

Was sollte ein MQTT-Messwert-Payload enthalten?

Für viele industrielle Anwendungen sind mindestens Wert, Zeitstempel und Qualitätsinformation sinnvoll. Je nach Topic- und Metadatenkonzept können zusätzlich Einheit, Messstellen-ID und weitere Informationen erforderlich sein.

Warum ist der Zeitstempel wichtig?

Weil der Zeitpunkt der Messung vom Zeitpunkt der Übertragung oder Speicherung abweichen kann.

Was ist der SourceTimestamp bei OPC UA?

Er beschreibt den Zeitstempel möglichst nahe an der ursprünglichen Quelle des Messwertes.

Was ist der ServerTimestamp?

Er beschreibt den Zeitpunkt, zu dem der OPC-UA-Server den Wert erhalten beziehungsweise als gültig erkannt hat.

Hat MQTT automatisch einen Messzeitstempel?

Ein anwendungsspezifischer Messzeitstempel muss bewusst in das Datenmodell aufgenommen werden, wenn er für die Anwendung erforderlich ist.

Was ist ein OPC-UA-StatusCode?

Ein StatusCode beschreibt die Verwendbarkeit beziehungsweise Qualität eines Wertes und kann unter anderem Good, Uncertain oder Bad anzeigen.

Hat MQTT automatisch Good/Bad-Qualitätswerte?

Nein. Eine solche Messwertqualität muss vom verwendeten MQTT-Datenmodell beziehungsweise der Anwendung definiert und übertragen werden.

Was bedeutet MQTT QoS?

QoS beschreibt die Service-Stufe der Nachrichtenübertragung zwischen MQTT-Clients und Broker.

Welche MQTT-QoS-Stufen gibt es?

MQTT definiert QoS 0, QoS 1 und QoS 2.

Was bedeutet QoS 0?

At most once – die Nachricht wird ohne den Bestätigungsmechanismus der höheren QoS-Stufen übertragen.

Was bedeutet QoS 1?

At least once – die Zustellung wird bestätigt, wobei eine Nachricht unter bestimmten Bedingungen mehrfach beim Empfänger eintreffen kann.

Was bedeutet QoS 2?

Exactly once – MQTT verwendet einen umfangreicheren Nachrichtenaustausch, um eine genau einmalige Übertragung auf Protokollebene zu erreichen.

Ist MQTT QoS dasselbe wie Messwertqualität?

Nein. MQTT QoS betrifft die Nachrichtenübertragung. Es sagt nichts über die messtechnische Qualität des Sensorwertes aus.

Was ist eine Retained Message?

Der Broker kann die zuletzt als retained veröffentlichte Nachricht eines Topics speichern und neuen passenden Subscribern bereitstellen.

Sollten Alarme retained übertragen werden?

Zustandsinformationen können davon profitieren. Bei Ereignissen muss dagegen sorgfältig vermieden werden, dass ein alter gespeicherter Alarm fälschlich als neues Ereignis interpretiert wird.

Was ist ein MQTT-Broker?

Der Broker nimmt Nachrichten von Publishern entgegen und verteilt sie anhand der Topics und Subscriptions an berechtigte Subscriber.

Muss jeder Sensor direkt MQTT unterstützen?

Nein. Ein Feldgerät kann beispielsweise 4 … 20 mA, HART, Modbus oder OPC UA verwenden. Ein Edge-Gateway kann daraus MQTT-Telemetrie erzeugen.

Muss jeder Sensor direkt OPC UA unterstützen?

Nein. Auch hierbei können SPS, Remote-I/O oder Edge-Gateway vorhandene Feldsignale integrieren und anschließend über OPC UA bereitstellen.

Was bedeutet Edge-Gateway?

Ein Edge-Gateway bildet eine Schnittstelle zwischen Feld-/OT-Technik und übergeordneten IT-Systemen und kann unter anderem Protokolle übersetzen, Werte skalieren, Daten puffern und Metadaten ergänzen.

Kann ich einen 4–20-mA-Sensor über MQTT übertragen?

Ja. Das analoge Signal muss zunächst über eine geeignete Eingangshardware digitalisiert und skaliert werden. Ein Edge-System kann den resultierenden Messwert anschließend über MQTT übertragen.

Kann ich Modbus in MQTT umsetzen?

Ja. Ein geeignetes Gateway kann Modbus-Register auslesen, skalieren und in ein MQTT-Datenmodell überführen.

Kann ich OPC UA in MQTT umsetzen?

Ja. Ein Edge-System kann Informationen aus einem OPC-UA-Server übernehmen und ausgewählte Daten als MQTT-Nachrichten publizieren.

Was muss bei dieser Umsetzung erhalten bleiben?

Neben dem Wert sollten insbesondere Messstellenidentität, Einheit, Zeitstempel und Qualitätsinformation berücksichtigt werden.

Eignet sich OPC UA für Cloud-Anwendungen?

OPC UA kann auch in entsprechenden IT-Architekturen eingesetzt werden. In vielen IIoT-Projekten wird für entkoppelte Telemetrie Richtung IT beziehungsweise Cloud jedoch MQTT verwendet.

Eignet sich MQTT für SCADA?

MQTT kann in SCADA-Architekturen eingesetzt werden, sofern das SCADA-System und das Datenmodell darauf ausgelegt sind. Für klassisches Browsing strukturierter OT-Daten bietet OPC UA jedoch häufig Vorteile.

Ist MQTT verschlüsselt?

MQTT sollte nicht automatisch mit verschlüsselter Kommunikation gleichgesetzt werden. Für sichere Verbindungen wird typischerweise TLS beziehungsweise eine entsprechend abgesicherte Transportverbindung verwendet.

Ist OPC UA verschlüsselt?

OPC UA unterstützt Sicherheitsmechanismen einschließlich Secure Channels, Zertifikaten sowie Signierung und Verschlüsselung in entsprechenden Sicherheitskonfigurationen.

Benötigt OPC UA Zertifikate?

Für sichere OPC-UA-Kommunikation spielen Anwendungszertifikate und die Verwaltung vertrauenswürdiger Anwendungen eine wichtige Rolle.

Kann MQTT Client-Zertifikate verwenden?

Ja. In einer TLS-gesicherten MQTT-Architektur können Client-Zertifikate zur Authentifizierung eingesetzt werden, wenn Broker und Clients entsprechend konfiguriert sind.

Was passiert bei einem Internetausfall?

Ein Edge-System kann Messwerte lokal puffern und nach Wiederherstellung der Verbindung nachliefern, wenn die konkrete Lösung eine entsprechende Store-and-Forward-Funktion besitzt.

Warum ist dabei der Original-Zeitstempel wichtig?

Damit ein später übertragener Messwert weiterhin seinem tatsächlichen Messzeitpunkt zugeordnet werden kann.

Was ist Brownfield-Integration?

Damit ist die Einbindung bestehender Anlagen und Geräte in eine neue Daten- beziehungsweise IIoT-Architektur gemeint, ohne sämtliche Feldgeräte ersetzen zu müssen.

Welche Feldprotokolle nennt ICS für IIoT-Integrationen?

ICS nennt unter anderem Modbus RTU, HART, IO-Link, OPC UA und Ethernet beziehungsweise entsprechende Edge-Integrationen.

Welche Rolle nennt ICS für MQTT?

ICS beschreibt MQTT insbesondere als leichte Publish/Subscribe-Telemetrie zwischen Edge- und IT-Systemen.

Welche Rolle nennt ICS für OPC UA?

ICS nennt OPC UA insbesondere für Modelle, Browsing und SCADA-Kopplung beziehungsweise als Teil der Brownfield-Integration.

Was ist der Siemens SITRANS MS200?

Der SITRANS MS200 ist ein bei ICS gelisteter Bluetooth-IIoT-Multisensor für Vibrations- und Temperaturüberwachung.

Welches Gateway nennt ICS für den SITRANS MS200?

Die ICS-Produktseite nennt den SITRANS CC220 als zugehöriges Gateway für diese Lösung.

Bedeutet das automatisch, dass der MS200 selbst MQTT oder OPC UA unterstützt?

Nein. Die konkrete Datenkommunikation der vollständigen Lösung muss auf Gateway-, Software- und Firmwareebene geprüft werden.

Was ist 7MH4647-0KK00-0AA2?

Es handelt sich um eine bei ICS gelistete IIoT-Wägeelektronik für eine Wägezelle beziehungsweise DMS-Vollbrücke mit 1 … 4 mV/V zur Nutzung mit SIMATIC IOT2050.

Unterstützt die Wägeelektronik direkt OPC UA oder MQTT?

Die ICS-Produktseite beschreibt sie als Wägeelektronik für das SIMATIC IOT2050. Welche übergeordneten Kommunikationsprotokolle zur Verfügung stehen, muss anhand der tatsächlich verwendeten Gateway- und Softwarekonfiguration festgelegt werden.

Wo finde ich IIoT-Lösungen bei ICS Schneider?

Weitere Informationen finden Sie unter IIoT-Lösungen bei ICS Schneider.

Wo finde ich den SITRANS MS200 bei ICS Schneider?

Weitere Informationen finden Sie unter Siemens SITRANS MS200 bei ICS Schneider.

Wo finde ich die IIoT-Wägeelektronik für SIMATIC IOT2050 bei ICS Schneider?

Weitere Informationen finden Sie unter 7MH4647-0KK00-0AA2 bei ICS Schneider.